Changes between Version 1 and Version 2 of Metodologia1/Administracion/EstandaresDesarrollo

Timestamp:

May 24, 2013, 11:36:47 AM (11 years ago)

Author:

eparedes

Comment:

--

Metodologia1/Administracion/EstandaresDesarrollo

@@ -4 +4 @@
 Los estándares de desarrollo constituyen las normas o patrones de referencia que se deben implementar en el desarrollo de aplicaciones de software. Entre los estándares de desarrollo más comunes se encuentran: normas de codificación, normas y esquemas de seguridad, estándares de interfaz u/s, entre otros.
 
-
-
-[A continuación se deben identificar los estándares de desarrollo que serán implementados en el desarrollo de la aplicación] 
+'''MAPA DE MERCANCIA DEL ECO ALBA-TCP'''
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+'''Estándares de D''''''esarrollo del Proyecto'''
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+||  '''Proceso'''  ||  '''Tipo de documento'''  ||  '''Versión del '''<<BR>>'''documento'''  ||'''Versión de la '''<<BR>>'''aplicación'''<<BR>>||  '''Responsable'''  ||  '''Fecha de elaboración'''  ||
+||Administración de Proyectos de Software||Estándares de<<BR>>desarrollo del Proyecto||  1.0  ||  1.0  ||  Erwin Paredes<<BR>>||  22/04/2013  ||
+
+'''Licencia de Uso'''
+
+
+
+
+
+''Copyright (c), ''2007, CENDITEL''.''
+
+''Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license is included in the section entitled "GNU Free Documentation License".''
+
+
+
+Una copia de la licencia puede obtenerse en los ficheros llamados “copyrigh.txt" en ingles, “copyrigh.es.txt" en español o en los siguientes sitios en Internet:
+
+
+
+ * http://www.gnu.org/copyleft/fdl.html
+ * http://www.fsf.org/licensing/licenses/fdl.html
+
+'''Historial de Revisiones'''
+
+
+
+||  '''Fecha'''  ||  '''Versión'''  ||  '''Descripción'''  ||  '''Responsable(s)'''  ||
+||  22/04/2013  ||  1.0  ||Versión inicial del documento||Erwin Paredes||
+||    ||    ||||||
+
+
+
+
+
+
+
+'''Estándares de Desarrollo del Proyecto'''
+
+
+
+Los estándares de desarrollo constituyen las normas o patrones de referencia que se deben implementar en el desarrollo de aplicaciones de software. Entre los estándares de desarrollo más comunes se encuentran: normas de codificación, normas y esquemas de seguridad, estándares de interfaz u/s, entre otros.
+
+Dados los conocimientos adquiridos por parte de los desarrolladores en la programación en sistemas similares y sobre el tema de Mapa Industrial, se recomienda utilizar el lenguaje de programación python y el frameword django, con el  anexo de librerías de dajax y javasript. Por lo cual se establece como punto de partida para los estándares de desarrollo lo establecido por la Fundación Cenditel, sobre codificación en dicho lenguaje, como se establece a continuación.  
+
+
+
+Como estilo de programación nos apegaremos al PEP-8 (Guía de Estilo para código Python). Algunos de los puntos más importantes a tomar en cuenta al programar en este proyecto son:
+
+Espacios 
+
+
+
+ * Usa 4 espacios en blanco como unidad para la indentación, sólo use espacios en blanco no use tabulaciones.
+ * Todas las líneas deben tener como máximo 79 caracteres.
+ * Separa las definiciones de clases y funciones con dos líneas en blanco. Las definiciones de métodos dentro de una clase se separan con una sola línea.
+ * Evite espacios en blanco en las siguientes situaciones:
+  * Inmediatamente dentro de paréntesis, corchetes o llaves.
+
+
+
+                  spam(ham[1], {eggs: 2})
+
+
+
+  * Inmediatamente antes de una coma, punto y coma o dos puntos.
+
+
+
+                  if x == 4: print x, y; x, y = y, x
+
+
+
+  * Inmediatamente antes del paréntesis/corchete que abre una lista de argumentos de una función/lista de índices.
+
+
+
+                  spam(1)
+
+                  dict['key'] = list[index]
+
+
+
+  * Mas de un espacio alrededor de un = o cualquier otro operador (+=, -=, ==, <, >, !=, <>, <=, >=, in, not in, is, is not, and, or, not, -, *, etc.) para alinear el código con otras líneas.
+
+
+
+                  x = 1
+
+                  y = 2
+
+                  long_variable = 3
+
+
+
+ * Evite colocar múltiples sentencias en una misma línea. Utilice un estilo como el siguiente:
+
+
+
+                  if cad == 'bla':
+
+                      haga_esto()
+
+                      haga_uno()
+
+                      haga_dos()
+
+                      haga_tres()
+
+
+
+Codificación de caracteres 
+
+
+
+ * El código en la distribución del núcleo de Python siempre debería usar la codificación ASCII o Latin-1 (alias ISO-8859-1), para Python 3.0 en adelante debería usarse UTF-8. Los archivos que usan ASCII (o UTF-8, para Python 3.0) no deberían tener una cookie de codificación. Sólo debería usarse Latin-1 (o UTF-8) cuando un comentario o "docstring" necesite mencionar un nombre de autor que requiere Latin-1; de otra forma, se prefiere usar \x, \u o \U escapes para incluir datos no-ASCII en literales de cadenas. 
+
+
+
+Importación de archivos 
+
+
+
+ * Los imports siempre se ponen al principio del archivo, justo después de cualquier comentario o docstrings de módulo, y antes de las constantes y globales del módulo. Coloca los imports en líneas separadas: 
+
+
+
+  import sys
+
+  import snap
+
+
+
+ * Debes colocar una línea en blanco entre cada grupo de imports, el orden de los grupos de imports debería ser el siguiente:
+ * Importaciones de librerías estándar
+ * Importaciones relacionados con terceros
+ * Importaciones locales específicas de la aplicación/librería.
+
+
+
+
+
+
+
+'''Nombramiento''' 
+
+
+
+    '''Paquetes y módulos'''
+
+
+
+        Los módulos deberían tener nombres cortos con todas sus letras minúsculas, podría incluir el carácter de subrayado en el nombre sólo si mejora su legibilidad.
+
+
+
+        Los paquetes también deberían tener nombres cortos con todas sus letras minúsculas pero no se recomienda utilizar el carácter de subrayado.
+
+
+
+    '''Clases'''
+
+
+
+        Los nombres de clases usan la convención de palabras capitalizadas (CamelCase) donde cada palabra inicia con letra mayúscula sin espacios en blanco ni caracteres especiales. Nótese que cuando se usan abreviaciones en este estilo pueden colocarse en mayúsculas todas las letras de la abreviatura, por ejemplo HTTPServerError es mejor que HttpServerError??.
+
+
+
+'''    Métodos y Funciones'''
+
+
+
+        Los nombres de funciones deberían tener todas las letras minúsculas sin espacios, con palabras separadas por el carácter de subrayado si es necesario para mayor legibilidad.
+
+
+
+    '''Constantes'''
+
+
+
+        Las constantes deben contener todas sus letras en mayúsculas con carácter de subrayado para separar palabras, por ejemplo: MAX_OVERFLOW y TOTAL.
+
+
+
+   '''Comentarios '''
+
+
+
+        Siempre que modifique su código actualice los comentarios!{{{{{{}}}{{{{{{}}}''}}}'}}}
+
+
+
+        Los comentarios de bloques generalmente se aplican a algún o todo el código que se encuentra seguidamente después de ellos, y se conserva la unidad de indentación al mismo nivel que el código fuente con el que se relacionan.
+
+
+
+        Cada línea de un bloque de comentario comienza con un # y un espacio en blanco (a menos que haya texto con el nivel de indentación dentro del comentario).
+
+
+
+        Los párrafos dentro de un bloque de comentario se separan con una línea que sólo contiene un #.
+
+
+
+        Los comentarios que se hacen en la misma línea del código son innecesarios y generalmente distraen si no contienen información relevante. En caso de necesitar utilizarlos deberían estar separados al menos por dos espacios del código fuente y deben comenzar con un # y un único espacio.
+
+
+
+'''Docstring''' 
+
+
+
+        Un docstring es una cadena literal que se coloca como primera oración en la definición de un módulo, clase o método. Esa cadena se convierte en el atributo especial doc de ese objeto.
+
+
+
+        Todos los módulos deberían tener docstrings, y todas las funciones y clases exportadas por un módulo también deberían tener docstrings. Los métodos públicos (incluyendo el constructor init) deberían tener docstrings. Un paquete puede ser documentado en el módulo docstring del archivo init.py en el directorio del paquete.
+
+
+
+        Escriba docstrings para todos los módulos, funciones, clases y métodos públicos, no es necesario escribirlas para métodos que no son públicos. Estos métodos que no son públicos deberían tener al menos un comentario que describa lo que hace el método, y que aparezca después de la línea def.
+
+
+
+        El """ que termina un docstring de varias líneas debería estar en una línea única, y preferiblemente precedido de una línea en blanco, por ejemplo:
+
+
+
+      """Retorna la velocidad del viento
+
+       Las gráficas opcionales indican la ubicación de los elementos.
+
+      """
+
+
+
+'''Estándares de Interfaz '''
+
+'''Versión de HTML '''
+
+
+
+        Para la estructura del lenguaje de marcas HTML se usara como formato las especificaciones HTML 4.01 del 24 de diciembre de 1999, o el XHTML 1.0 de fecha 1 de agosto de 2002, de acuerdo a recomendaciones establecidas por la World Wide Web Consortium (W3C). Los mismos deben ser validados con las herramientas en línea disponibles por la W3C.
+
+
+
+'''Consideraciones de Navegabilidad '''
+
+
+
+        Para la mejor navegabilidad entre los diferentes módulos que conforman la aplicación a desarrollar es necesario considerar la inclusión de los siguientes puntos:
+
+
+
+ * Una ruta de acceso que permita mostrar el trazado de las páginas visitadas desde la de inicio hasta la página actual.
+ * Un botón de inicio que permita ir a la página principal del sistema y el cual debe estar posicionado siempre en el mismo lugar.
+ * Un mapa de navegación que refleje la estructura organizativa del contenido de la aplicación. 
+
+
+
+'''Diagramación Gráfica '''
+
+
+
+        En los banners y encabezados de los reportes se seguirá como estándar de desarrollo lo establecido en el Manual de Aplicaciones Básicas del Ministerio del Poder Popular para la Comunicación y la Información, en el cual se establece la disposición de logotipos y posicionamiento de los mismos así como también el ente gubernamental y demás datos que hacen referencia al gobierno nacional.
+
+
+
+Adicionalmente se utilizarán los siguientes aspectos:
+
+
+
+ * Tipografía: Solo se utilizarán estilos de letras de código abierto que no dispongan de licencia restrictiva.
+ * Imágenes: Las imágenes a utilizar dentro de la aplicación deberán ser exclusivamente aquellas en formato PNG (Portable Network Graphics), según lo describe la norma ISO/IEC 15948:2003, dictada por la Organización Internacional para la Estandarización.
+ * Información alternativa: En el elemento IMG se utilizará el atributo ALT para definir un texto alterno con la finalidad de mejorar el acceso y usabilidad para aquellos usuarios que por alguna razón no puedan apreciar las imágenes de la aplicación. 
+
+
+
+'''Juego de carácteres '''
+
+
+
+Para la interfaz de la aplicación, reportes, campos de texto, etc. Se utilizarán las espcificaciones Unicode 8 bit (UTF-8).
+
+
+
+'''Lenguaje de Scripts '''
+
+
+
+Se utilizará, en el caso de que sea necesario, el lenguaje de scripts JavaScript en versiones igual o mayores a la 1.7 ECMA-262, colocando el código o función desarrollado bajo este lenguaje en un archivo separado y el cual tendrá extensión ".js".
+
+
+
+'''Elementos añadibles '''
+
+
+
+En caso de ser requerida la inclusión de controladores, librerías, clases y/o funciones, estas deberán cumplir con la definición de Software Libre en los términos establecidos en el marco legal vigente. No se utilizará dentro del desarrollo del proyecto en ningún momento elementos añadibles que no cumplan con dichas especificaciones.
+
+
+
+'''Hojas de Estilo en Cascada (CSS) '''
+
+
+
+Para el desarrollo de las plantillas que permitirán la visualización gráfica de la aplicación, se utilizarán las hojas de estilo en cascada (CSS) en sus versiones CSS1 y CSS2, según lo describe las recomendaciones planteadas por la W3C del 17 de Diciembre de 1996 o del 12 de Mayo de 1998 respectivamente, con la finalidad de facilitar las labores de mantenimiento de la aplicación. Los mismos serán validados en línea por las herramientas dispuestas por la W3C para tal fin.
+
+
+
+'''Meta Etiquetas '''
+
+
+
+Las meta etiquetas serán utilizadas en el encabezado de los documentos de hipertexto, y las mismas levarán la siguiente información:
+
+
+
+ * Identificación de la aplicación.
+ * Palabras clave.
+ * Nombre de la Aplicación.
+ * Nombre del Órgano o Ente encargado de su desarrollo y mantenimiento. 
+
+
+
+'''Referencias '''
+
+
+
+ * Manual de Aplicaciones Básicas Ministerio del Poder Popular para la Comunicación y la Información
+ * Gaceta Oficial 39.109 pag.29 y 30
+ * Guía general para desarrolladores Python.
+ * PEP 257 Propuesta de mejora de Python sobre Convenciones de Docstrings. David Goodger y Guido van Rossum.
+ * PEP-8 Propuesta de mejora de Python sobre Guía de estilo para la codificación en Python. Guido van Rossum y Barry Warsaw.