Descargar - Speedy Software

Proyecto: Sistema Pirelli Talca.
Soluciones Tecnológicas
www.speedysoftware.cl.nu
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.
Fecha: 13/09/07
Versión: 1.0
1/9
Soluciones Tecnológicas
www.speedysoftware.cl.nu

Proyecto: Sistema Pirelli Talca.
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.
Fecha: 13/09/07
Versión: 1.0
2/9
Soluciones Tecnológicas
www.speedysoftware.cl.nu
Proyecto: Sistema Pirelli Talca.
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.
Fecha: 13/09/07
Versión: 1.0
3/9
Proyecto: Sistema Pirelli Talca.
Soluciones Tecnológicas
www.speedysoftware.cl.nu
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.
Fecha: 13/09/07
Versión: 1.0
4/9
Proyecto: Sistema Pirelli Talca.
Soluciones Tecnológicas
www.speedysoftware.cl.nu
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, a excepción de la primera de cada
palabra, y no llevan espacios ni caracteres extendidos. Además se debe usar nombres
que identifiquen tanto a la variable o función como al contexto en que son usadas
yendo de lo más general a lo particular, se permite el uso de correlativos para
diferenciar.
Ejemplo:
Funciones:
VerificaRutCliente(),
Variables:
RutCliente1,
RutCliente2.
Los nombres, tanto de variables como de funciones, deben ser descriptivos de
lo que representan, esto para que todo el equipo pueda comprender lo que son
a) Nomenclatura de variables:


Cuando se trata de un nombre simple, éste debe comenzar con minúscula y
ser completo o con una abreviatura comprensible y no llevan espacios ni
caracteres extendidos.
Si se trata de un nombre compuesto, cada palabra debe separada por un
guión bajo (_).
Ej: rut_cliente;, valor_producto_aux;
b) Nomenclatura de funciones:


Los nombres simples de funciones deben comenzar con mayúscula y luego
continuar con minúscula.
En caso de que el nombre de la función sea compuesto, este debe tener
cada nombre unido, sin espacios, y respetar la nomenclatura de nombres
simples para funciones para cada una de las palabras componentes.
Ej: VerificaRutCliente();, AplicaIva();
Fecha: 13/09/07
Versión: 1.0
5/9
Soluciones Tecnológicas
www.speedysoftware.cl.nu
Proyecto: Sistema Pirelli Talca.
3.6.-Comentarios de Programas
a) Comentarios para funciones:

Explicación del pasaje de parámetros (variables que recibe)

Explicación del retorno (variable que devuelve)

Explicación del funcionamiento.
b) Comentarios para variables de programas:

Si el nombre de la variable no es suficiente para clarificar su
papel, se debe comentar esto a 3 tabulaciones de su
declaración o primer uso.
c) Cometarios en procesos o iteraciones:

Si no es explícito, se debe comentar lo que realiza cierto
proceso o iteración. Este comentario debe escribirse arriba del
proceso o iteración.
d) Comentarios para documentos HTML, PHP, proceso almacenado de
MySQL o cualquier documento de código fuente.

Versión.

Fecha

Autor

Detalles.
Fecha: 13/09/07
Versión: 1.0
6/9
Soluciones Tecnológicas
www.speedysoftware.cl.nu
Proyecto: Sistema Pirelli Talca.
3.7.-Normas de evaluación de desarrollo:
Cuando se esté próximo a una entrega de prototipo, por lo menos 4 días hábiles
antes, los encargados del testing ya deben poseerlo con el fin de hacerles las pruebas
necesarias, además de dar paso a las acciones correctivas en caso de necesitarlas, y
luego dar la autorización para el cambio de versión y presentación al cliente.
Se medirán los hitos estipulados, esto implica cumplimento de compromisos y
responsabilidades, los que en caso de ser fallados inducirán a una mala imagen para el
cliente, por lo que siempre el equipo velará por que esto no ocurra y siempre estemos
presentando un excelente prototipo y, al final del proyecto, un excelente producto.
Para cualquier tarea de programación que realice algún integrante del equipo de
desarrollo, éste debe registrar en el documento “Registro de Desarrollo” 1 los siguientes
datos: la fecha en que se compromete a realizar la tarea, el caso de uso al que atiende
la tarea, el tipo de trabajo que se realizará (creación, revisión, mantención o
corrección), la descripción detallada de la tarea, los nombres de los documentos
fuentes generados y la fecha de entrega del trabajo. Una vez terminado el trabajo, el
Jefe de Proyecto o la persona que esté a cargo de la revisión, debe dar el Visto Bueno
o solicitar la revisión del trabajo desarrollado.
1
**Anexo 1
Fecha: 13/09/07
Versión: 1.0
7/9
Proyecto: Sistema Pirelli Talca.
Soluciones Tecnológicas
www.speedysoftware.cl.nu
3.8.-Normas de Mantención

Mantención:
Se preverá servicio de mantención
sin límite de tiempo para cualquier
problema en el código fuente. Para los servicios de mantención
adaptativa o
perfectiva, se acordará un costo por valor de horas de trabajo.

Protocolo de comunicación con el usuario:
La comunicación con el usuario, será a través de correo electrónico o por vía
telefónica.

Aceptación:
Se confeccionará un checklist donde se presentarán todas las funcionalidades
cubiertas en la entrega, se deberá verificar junto con el Cliente si lo entregado
corresponde o no a lo solicitado por él y de ser así, se hará un tick en dicha lista. Si
todo corresponde a lo esperado, el cliente dará el Visto Bueno estampando su firma en
el documento.

Definición de Plazos:
Los plazos se fijarán con la aprobación de todo el grupo de trabajo, con el fin de
buscar una fecha en la cual todos los roles alcancen a realizar sus actividades de forma
pareja.
Estos plazos serán formalizados en la planificación de desarrollo y la Carta
Gantt.
Fecha: 13/09/07
Versión: 1.0
8/9
Proyecto: Sistema Pirelli Talca.
Soluciones Tecnológicas
www.speedysoftware.cl.nu
Anexo 1
Registro de Desarrollo
Nombre Programador: __________________________
Fecha de
inicio
Caso de uso
atendido
Tipo de
trabajo
-
Fecha: 13/09/07
Versión: 1.0
Descripción de la tarea
Proyecto: ______________________
Documentos
fuentes generados
Fecha de
entrega
V°B°
Documento tipo Registro de Desarrollo
9/9