Normas de Desarrollo

3.-Normas de Desarrollo

3.1.- Políticas de protocolo y respaldo:

Es importante llevar una serie de políticas de protocolo y respaldo con el fin de evitar pérdidas de información que generen un retroceso en el avance del proyecto. Independientemente de que la pérdida de información sea parcial, esta podría llevar a un atraso en el cumplimiento de plazos lo que no es para nada conveniente. Por ello se deben seguir los siguientes puntos a cabalidad:

• La información de planificación se mantendrá a cargo de él o los desarrolladores correspondientes a ésta hasta que se finalice el documento oficial, por lo cual la responsabilidad de velar por la integridad de la información es de quienes realizan esta actividad. Posteriormente, se distribuirá entre todos los integrantes del equipo y también se sincronizará diariamente el directorio de proyecto con un servidor X desde el Servidor de Control de Versiones, lo que permitirá que el respaldo se haga de forma automática mediante un script adecuado. De forma similar se mantendrá una copia de los avances en el servidor web de la empresa, lo que permitirá un fácil acceso para cualquier integrante del equipo.

• La información de desarrollo se mantendrá en el Servidor de Control de Versiones (SCV), el cual es administrado por Subversión versión XXX, que también nos permite obtener y comparar versiones anteriores, cazar errores regresivos, mantener ramas compatibles con las versiones anteriores, producir excelentes registros de cambios (changelogs), trabajar sobre dos mejoras diferentes sin confusiones. El SCV estará a cargo de Adolfo Acuña.

• Se respaldará la información del desarrollo del proyecto cada vez que se realice una modificación, esto con el fin de evitar los riesgos que van desde la pérdida de información por efectos internos (falta de respaldo en momento apropiado) o externos (siniestros como corte de electricidad, incendio u otra catástrofe).

• El directorio del SCV se respaldará semanalmente de forma automática mediante un script ya implementado.

• En caso de ser necesario modificar la tarea de otro integrante del equipo, se debe avisar al involucrado, a fin de realizar la modificación y posterior respaldo.

• Todas las acciones a realizar por alguno de los integrantes del grupo debe ser debidamente informado al resto del grupo, en especial al jefe de proyecto que es el encargado de la organización del equipo.

• Todo cambio a la BD por alguno del grupo de desarrollo debe ser informado al jefe de grupo.

3.2.- Políticas de protocolos de Acceso a datos y/o fuentes de programas:

Este tipo de políticas regulan el acceso a los datos que maneja nuestra aplicación y a su código fuente. Las siguientes acciones tendrán que ser cumplidas rigurosamente:

• Se deberá trabajar en el SCV ya descrito, y cada desarrollador deberá usar su cuenta y password para así dar funcionalidad al sistema.

• Los desarrolladores que no trabajen conectados al SCV (sin Internet) deberán subir las modificaciones lo antes posible usando su cuenta y password, con el fin de evitar saltos cronológicos en los commits e incongruencias en las versiones.

• El código fuente del sistema estará disponible en el servidor Web de la empresa.

• Este código estará comprimido y con clave que resguardará la seguridad de nuestra propiedad intelectual sobre este proyecto y así evitar que extraños accedan a él.

• Cualquier acción sobre los datos y/o fuentes del programa deberá previamente ser consultado al jefe de proyecto, quien rechazará o autorizará esta acción. De ser autorizada es él quien debe comunicárselo al resto del equipo.

3.3.- Políticas, protocolos y productos para el control de versiones:

Un sistema de control de versiones es un software que administra el acceso a un conjunto de archivos, y mantiene un historial de cambios realizados. Normalmente consiste en una copia maestra en un repositorio central, y un programa cliente con el que cada usuario sincroniza su copia local. Esto permite compartir los cambios sobre un mismo conjunto de archivos. Además, el repositorio guarda registro de los cambios realizados por cada usuario, y permite volver a un estado anterior en caso de necesidad.

Subversion nos ofrece esto y mucho más, entre sus características mas importantes encontramos: commits atómicos (se actualizan sólo los datos enviados), intercambio de diferencias entre versiones, operación directa desde el repositorio, backups en caliente, y un largo etc.

En particular, toda nuestra aplicación va a estar regulada por este programa y el control de versiones pasará únicamente por él.

3.4.-Nomenclatura de versiones:

En cuanto a este ítem, también nos regiremos estrictamente por la nomenclatura que propone la aplicación antes mencionada. Subversion será nuestra guía en todo lo que tenga que ver con las versiones y la nomenclatura de éstas.

3.5.-Nomenclatura de variables y funciones:

Tanto para variables como funciones se utilizará el mismo tipo de nomenclatura, esto es utilizar letras minúsculas,

...