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