wiki:metodologia2016/EstandaresDesarrollo

Tabla de Contenido

  1. Sistemas para visualizar el encadenamiento productivo entre países de …
  2. ¿Cómo lo hacemos?
      1. Primera Etapa de Desarrollo del Sistema UNASUR (Año 2016)
        1. Metodología de Desarrollo de Software Libre Utilizada (v2.0)
        2. Equipo de Trabajo 2016
        3. Cronograma de Publicación y Liberación
      2. Tercera Etapa de Desarrollo (Año 2015)
        1. Metodología de Desarrollo de Software Libre Utilizada (v2.0)
        2. Equipo de Trabajo 2015
        3. Cronograma de Publicación y Liberación
      3. Segunda Etapa de Desarrollo (Año 2014)
        1. Metodología de Desarrollo de Software Libre Utilizada (v2.0)
        2. Equipo de Trabajo 2014
        3. Cronograma de Publicación y Liberación
      4. Primera Etapa de Desarrollo (Año 2013)
        1. Metodología de Desarrollo de Software Libre Utilizada (v1.0)
        2. Equipo de Trabajo 2013
      5. Anteproyecto (Año 2012)
    1. Descargas
    2. Publicación y Liberación
    3. Ambiente de Pruebas
    4. Material de difusión
  3. Metodología de Desarrollo de Software Libre (MDSL) Versión 2.0
  4. Sistema SICPSUR 2016
    1. Conceptualización
      1. Plantillas
      2. Flujograma
    2. Administracion
      1. Plantillas
      2. Flujograma
    3. Construcción
      1. Plantillas
      2. Flujograma
    4. Minutas de las reuniones de trabajo
    5. Uso de macros para trazabilidad
  5. Análisis del Dominio
  6. Propuesta de Desarrollo del Proyecto
    1. 1. Necesidades y/o problemas
    2. 2. Solución propuesta
    3. 3. Alcance del software propuesto
    4. 4. Metodología de desarrollo
    5. 5. Plataforma de operación
    6. 6. Plataforma de desarrollo
    7. 7. Licencias de código y documentación
  7. Plan del Proyecto
    1. 1. Priorización de funcionalidades del software según las necesidades …
  8. Estándares de Desarrollo del Proyecto
  9. Estándares de Desarrollo del Proyecto
  10. Especificación de Requerimientos (Funcionalidades)
    1. 1. Casos de uso para la gestión de usuarios y seguridad.
    2. 2. Casos de uso para la consulta en el Mapa UNASUR: Datos básicos, …
    3. 3. Casos de uso para la consulta de reportes de posibilidades de …
    4. 4. Casos de uso para el modelado de las cadenas productivas en la …
    5. 5. Casos de uso para la visualización de la Matriz Insumo Producto …
    6. 6. Casos de uso para la consulta de los aranceles de cada país …
    7. 7. Casos de uso para carga masiva de información relacionada a: …
    8. 8. Casos de uso para la gestión del directorio de empresas de UNASUR.
    9. 9. Casos de uso para el registro de los convenios de complementariedad …
    10. Flujograma de actividades
  11. Codificación
    1. Código Fuente
    2. Flujograma de actividades
  12. Análisis y Diseño
  13. Pruebas
  14. Liberación
    1. Manual de Usuario
    2. Configuración para archivos descargables
    3. Flujograma de actividades

Tabla de Contenido

  1. Sistemas para visualizar el encadenamiento productivo entre países de …
  2. ¿Cómo lo hacemos?
      1. Primera Etapa de Desarrollo del Sistema UNASUR (Año 2016)
        1. Metodología de Desarrollo de Software Libre Utilizada (v2.0)
        2. Equipo de Trabajo 2016
        3. Cronograma de Publicación y Liberación
      2. Tercera Etapa de Desarrollo (Año 2015)
        1. Metodología de Desarrollo de Software Libre Utilizada (v2.0)
        2. Equipo de Trabajo 2015
        3. Cronograma de Publicación y Liberación
      3. Segunda Etapa de Desarrollo (Año 2014)
        1. Metodología de Desarrollo de Software Libre Utilizada (v2.0)
        2. Equipo de Trabajo 2014
        3. Cronograma de Publicación y Liberación
      4. Primera Etapa de Desarrollo (Año 2013)
        1. Metodología de Desarrollo de Software Libre Utilizada (v1.0)
        2. Equipo de Trabajo 2013
      5. Anteproyecto (Año 2012)
    1. Descargas
    2. Publicación y Liberación
    3. Ambiente de Pruebas
    4. Material de difusión
  3. Metodología de Desarrollo de Software Libre (MDSL) Versión 2.0
  4. ECOALBA-TCP 2015
    1. Conceptualización
      1. Plantillas
      2. Flujograma
    2. Administracion
      1. Plantillas
      2. Flujograma
    3. Construcción
      1. Plantillas
      2. Flujograma
    4. Uso de macros para trazabilidad
  5. Análisis del Dominio
  6. Propuesta de Desarrollo del Proyecto: ECOALBA-TCP 2015
    1. 1. Necesidades y/o problemas
    2. 2. Solución propuesta
    3. 3. Alcance del software propuesto
    4. 4. Descripción general de la arquitectura del software
    5. 5. Metodología de desarrollo
    6. 6. Plataforma de operación
    7. 7. Plataforma de desarrollo
    8. 8. Licencias de código y documentación
  7. Plan del Proyecto
    1. 1. Priorización de funcionalidades del software según las necesidades …
  8. Estándares de Desarrollo del Proyecto
  9. Especificación de Requerimientos (Funcionalidades)
    1. 1. Casos de Uso: Gestionar el modelado de cadenas productivas en la …
    2. 2. Casos de Uso: Gestionar la Carga Masiva de Información relacionada …
    3. 3. Casos de Uso: Gestionar la consulta de los aranceles de cada país …
    4. 4. Casos de Uso: Gestionar la Carga Masiva de Información relacionada …
    5. Flujograma de actividades
  10. Codificación
    1. Código Fuente
    2. Flujograma de actividades
  11. Análisis y Diseño
  12. Pruebas
  13. Liberación
    1. Manual de Usuario
    2. Configuración para archivos descargables
    3. Flujograma de actividades

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.

MAPA DE MERCANCÍA DEL SICPSUR

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)

dictkey? = 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.

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.

[A continuación se deben identificar los estándares de desarrollo que serán implementados en el desarrollo de la aplicación]

Last modified 8 years ago Last modified on Jun 17, 2016, 9:52:13 AM