You are on page 1of 8

Políticas y procedimientos en un departamento de desarrollo de sistemas

I Políticas generales
1. La única área autorizada para desarrollar, adquirir, rentar, implantar y mantener cualquier software necesario para XXX es la Oficina de Sistemas de TI. 2. Todo software que no ha sido autorizado por la Oficina de Sistemas de TI es considerado ilegal. 3. El único punto de contacto para presentar un requerimiento de software es el Centro de Servicio a través de la Mesa de Ayuda, acompañada del oficio de solicitud. 4. La información del proyecto de cualquier versión se deberá de incluir en un expediente único para la misma. 5. La infraestructura tecnológica para el desarrollo, pruebas y utilización (producción) de los sistemas informáticos de XXX deberá estar configurada de la siguiente forma: 5.1. Red de desarrollo: es una red independiente de almacenamiento y procesamiento orientada exclusivamente al desarrollo de los sistemas solicitados al área de Sistemas. 5.2. Red de pruebas: es una red independiente de almacenamiento y procesamiento orientada exclusivamente a la realización de las pruebas de funcionalidad los sistemas solicitados al área de Sistemas. 5.3. Red de producción: es una red independiente de almacenamiento y procesamiento orientada exclusivamente a la utilización de los sistemas de XXX. 6. Los sistemas que provienen de otras entidades diferentes a XXX o de aquellos proveedores que no son contratados por ésta, no están sujetos a las políticas y procedimientos contenidos en este documento y en el resto de los documentos y procedimientos aplicables al área de Sistemas. 7. Política de Respaldo: En el departamento de Informática de Telecomunicaciones existen dos tipos de respaldos: 7.1. Respaldos de Software: Se refiere a todos los programas que utilizan los usuarios y que son legales. Es responsabilidad de la Administración de Versiones tener una copia de seguridad, en la Biblioteca Definitiva de Software, de cada uno de ellos y de todos sus componentes, librerías módulos o cualquier parte necesaria para su correcto funcionamiento. 7.2. Respaldo de datos: Se refiere a toda la información contenida en las diferentes Bases de Datos que utiliza el Software. Es responsabilidad del líder del proceso y del usuario particular de ese Software respaldar y resguardar el contenido de las mismas. 7.3. Es obligación del líder del proceso enviar una copia mensual de los respaldos realizados en su área de control a la oficina de sistemas.

1/8

Si la complejidad del proyecto.7. los costos de seguir igual. 3. 3.1 Se analizarán las características del proceso. 3.2 En caso de ser necesario. es motivo suficiente para rechazarla.3 Las personas que consideren necesarias el Líder del proceso y el Jefe de la Oficina de sistemas de TI. la insuficiencia de información o cualquier otra incertidumbre impide que la oficina de Sistemas de TI pueda tener certeza sobre la complejidad.1 Subgerente. Emisión del Dictamen de Factibilidad. ésta emitirá su dictamen de factibilidad posterior a la reunión una vez que tenga la información necesaria que le permita anular la incertidumbre que sobre el proyecto se tiene. y todas las demás características operativas que la oficina de Sistemas de TI requiera conocer para evaluar el proyecto de desarrollo de software. 3. 4. costos y tiempo de desarrollo del sistema solicitado.1 Líder del proceso del área solicitante. XI.II Procedimientos 2. desarrollo. 4.1 Motivo o justificación del requerimiento. Esta reunión tiene como objetivo la definición y aclaración de los Requerimientos. El resultado del análisis de factibilidad será comunicado por escrito al área solicitante y registrado en la CMDB de la Mesa de Ayuda. las desventajas de que siga igual. los costos de automatización. El oficio de solicitud debe contener la siguiente información: 2.5 Flujo de actividades de Proceso actual 2.2 Necesidad del área usuaria 2. 2. mantenimiento o compra de software debe estar acompañado por un oficio de solicitud.7 Firmas: 2.2 Líder del Proceso en todas las versiones Todo requerimiento de software deberá tener un análisis de factibilidad indicando si es aceptado o rechazado.4 No necesariamente la reunión debe finalizar con un dictamen de factibilidad.1 El resultado del Análisis de Factibilidad será comunicado con un documento. 1 2 3 4 5 3 4 2/8 .4 Cantidad de Usuarios a beneficiar 2. Para los casos de solicitudes aceptadas corresponde la ejecución del procedimiento No.5 Los involucrados en el proyecto tienen la facultad de citar y llevar a cabo las reuniones que se consideren necesarias.3 Si el área solicitante no entrega la información solicitada en un plazo no mayor a 30 días naturales.2 Es obligación del área solicitante entregar toda la información demandada por la oficina de sistemas de TI necesarias para el desarrollo de su sistema.3 Beneficios que ofrece el proyecto 2. 2. deberá describirse el motivo. cuando sea la primera versión 2. 2. I Requerimientos para el desarrollo de software Cualquier requerimiento. el Jefe de la Oficina de Sistemas de TI asistirá a la reunión.2 Análisis de factibilidad 1 2 Reunión con el área solicitante.2 Si no es factible el proyecto. Deberán asistir a la reunión: 2.7. 3.6 Duración del proceso a automatizar 2. 2. las ventajas de automatizarlo.

Entrega: 7.2 Manejador de Base de datos. 4.1.1 Cumpla con el procedimiento XXX (VI Entrega del producto) Adquisición de software a terceros 8. 4.1.2. 1. Planeación del Proyecto: 2. 1.3 Procedimiento de solicitud aceptada Para cualquier desarrollo de software que se implante llevará las siguientes etapas: 1.1 El nombre de la variable no será mayor a 10 caracteres alfanuméricos. 4. vía Web.3 Nomenclatura de variables.1.5 Documentación.1 Documentación 4. 1. 4.1 Todo proyecto deberá llevar documentación: 6.1.2 Toda función nueva. 4. parametrizable y evaluada satisfactoriamente deberá integrarse a la librería junto con su documentación y se anexa al catálogo de librerías. 3.6 Entrega.2. o cualquier otra modalidad que permita al área de sistemas controlar las versiones de acuerdo a sus políticas y procedimientos internos) 3/8 .1.2. 4.1. 1.1. 3.1 Planeación.1 Nombre del programa.1. 1. 4.3 Herramientas de apoyo (Software y Hardware). Pruebas: 5.2.2.3.2 Cualquier modificación después de la liberación de la versión será documentada.2 Definición de la plataforma. 4.1 Además de cumplir con los siete puntos anteriores todo proyecto de desarrollo externo de software deberá cumplir con los siguientes punto: 8. 3.4 Descripción.1.1 Cumpla con el procedimiento XXX (X Plan de Pruebas de Diseño) Documentación: 6.1.1 Diagrama de flujo del desarrollo. soporte telefónico.3 Fecha. 3.1 Antes de realizar una nueva librería deberá de verificar el catálogo de librerías.1 Cumpla con el procedimiento XXX (VI Plan de Trabajo para cada Proyecto) Diseño: 3.1.3. duración.2 Utilización de librerías.4 Todo sistema deberá de ser parametrizable para tener la capacidad de adecuarse al usuario.1 Lenguaje.2 Diseño.1 Manual Técnico 6. 3.3 Diagrama Entidad – Relación.3 Codificación.1 Se agregará la siguiente información al inicio del código: 4. Codificación: 4.2 Plan de mantenimiento.2 Autor. 4. características (en sitio.4 Pruebas.2 La variable debe codificarse como nemónico.1.2 Manual Operativo. 4. 4.1 2 3 4 5 6 7 8 2. El que determine el líder del proyecto.

2.4 Procedimiento nomenclatura de versiones 1.0 (versión mayor).6 Procedimiento de entrega del producto Deberá existir un documento de culminación del proyecto y entrega del producto al Responsable del Proceso y firmado por los involucrados en el Proyecto. 3.3 8.3 Dificultades y contratiempos 4.1 Lista de verificación de los requerimientos del área usuaria. 1. Deberá existir un documento de entrega del proyecto al Centro de Servicios así como su registro en la CMDB y su correspondiente Manual de Instalación.8. 2. Plan de capacitación: Ya sea la versión mayor. el cual es solo para consulta del área de desarrollo por lo que no podrá entregarse al área usuaria: 4.2 Características del proyecto 4. así como registrar las actividades ejecutadas en la CMDB. los archivos de código fuente del mismo. El Administrador de Versiones podrá solicitar las certificaciones técnicas.4 Recomendaciones 4. y demás información que considere necesaria para avalar que el proveedor es experto en el producto que se le está solicitando o que está ofertando. 2. para un versión menor se conserva el digito principal y cambian los dígitos decimales. Administración de Versiones revisara.5 Plan de versionado: Especificación de los Hitos que componen las diferentes versiones. SIXX 2. Quedará a criterio del Administrador de Versiones decidir si el proveedor tendrá que entregar junto al producto.2 Manual Operativo. La Oficina de Equipos y Accesorios deberá informar del inicio y fin de cualquier implantación de actualización de versiones de hardware. Debe realizarse una reunión para la entrega final del producto terminado junto con los siguientes documentos: 2.1 Nombre corto del sistema: asignado por el líder del proyecto Numero de versión: compuesto por dos dígitos.5 Instalación de nuevas versiones de hardware Administración de Versiones administrara la actualización de nuevas versiones de hardware sin ejecutar alguna actividad o trabajo concreto quedando esta responsabilidad ejecutora a la Oficina de Equipos Y Accesorios. que el proveedor tiene planeadas durante el periodo de mantenimiento contratado. El nombre de una versión estará compuesto de los siguientes campos: 2. referencias. las versiones menores o las reparaciones de emergencia deberán estar acompañadas de su correspondiente plan de capacitación técnica (dirigida al personal del área de desarrollo de sistemas) y funcional (dirigida al usuario final) haciendo énfasis en las diferencias existentes entre la versión anterior y la nueva versión.5 Comparación de la duración y costo del proyecto de lo real con lo planeado. Para una versión mayor cambia el digito principal y los dígitos decimales quedan en cero. Cada versión deberá tener un identificador o nombre único. 1 2 3 4 4/8 . 2.5 (versión menor). Deberá existir un Reporte (Dictamen Postmortem) final de costos del desarrollo del proyecto que incluya la siguiente información. el primero entero y el otro decimal. ejemplo: SIXX 2. evaluara y autorizara los procesos de las actualizaciones de versiones de hardware a implantar diseñados por la Oficina de Equipos y Accesorios. Configuración y Operativo. 2.1 Involucrados en el proyecto 4. irrepetible y no renovable 2.4 8.

3. comparado contra los mismos parámetros de evaluación antes de la implantación de la versión.4 Utilización: Obtener cantidad de usuarios y frecuencia en el uso del producto. 3. 10 Al momento de implantar la Versión se comunicará al grupo de cambios mediante un documento la relación de las actividades necesarias para la implantación de la nueva versión.7 Evaluación de la post-implantación Toda implantación de versión tendrá una evaluación Post-Implantación para evaluar la utilidad de la versión liberada y la satisfacción del usuario con el desarrollo del producto solicitado.5 Deberá existir un documento de las pruebas realizadas con las características establecidas en el proceso de control.3 Utilidad del producto: Aplicación del producto al proceso identificando los beneficios que le aporta.1 Tiempo: Servirá para medir la eficiencia del líder del proceso. 8. bibliotecas o cualquier otra parte de software necesarias de versiones anteriores y si es el caso.2 Capacitación Operativa y Técnica al Centro de Servicios para que el personal de la Mesa de Ayuda esté capacitado en la identificación de Fallas operativas por parte del usuario o errores en el producto o fallas en el Hardware.2 Cuando no se tenga disponible el nombre del responsable o responsables se indicará el Departamento 2.1 Capacitación Operativa del producto al Líder del Proceso para que él la difunda a su personal. 1 2 3 4 5 5/8 .1 Administración de Versiones notificará a Administración de Cambios la lista de Configuration Item’s (CI’s) necesarios para la correcta instalación. 8.1 # Actividad Descripción Responsable 10. la evaluación negativa recaerá sobre el desempeño del líder. etc. tales como tiempo de ciclo del proceso. firmado por los involucrados en el proyecto.2 Calidad: Cumplimiento de las especificaciones solicitadas por el usuario. como se muestra a continuación 10. 6. si es el caso. Si hubo necesidad de aplazar una o más veces la fecha de entrega pactada originalmente. número de fallas. para determinar si cumple con las necesidades de la misma. 8 Se deberá de solicitar a la Administración de Cambios la información sobre el software y el hardware del equipo que se tiene en el área donde se llevara a cabo la instalación de la versión.. ésta no se instalara. y esto se debió a un error de planeación y no a causas externas al ámbito de control de líder del proyecto. 6 Se deberá de realizar un proceso de capacitación previo a la instalación masiva del producto: 6.2 También si existe la necesidad de borrar componentes. Esta evaluación constará de las siguientes fases: 3. el orden de borrado. El plazo para realizar la evaluación no deberá ser superior a un mes natural a partir de la fecha de implantación masiva. Se deberá emitir un documento “Post-Implantación” con el resultado de la evaluación especificada en los puntos anteriores e indicando si fue exitoso o no. deberá notificar el orden de instalación de los mismos. 9 En caso de no cumplir con los requerimientos de software y hardware de la Administración de Versiones para la instalación de esa versión.3 Para la instalación de los CI’s notificados. 8. Criterios de evaluación del desempeño del líder 5. disminución de esfuerzo.1 Tiempo: Cumplimiento del plazo acordado con el usuario para la entrega del software 3. 7 Se deberá de realizar la instalación masiva de acuerdo al plan de instalación elaborado en conjunto con el Líder del Proceso.

Secuencia de actividades: 3.1 Nombre del Proyecto. Métricas del proyecto: 2.5 Librerías. recursos a utilizar y entregables. Dictamen de Factibilidad. Reuniones informativas de evaluación de avance Los documentos que debe llevar el desarrollo del proyecto son: 4. 1.2 Análisis técnico. Estudio de Factibilidad.1 Son todas las actividades ubicadas en un periodo considerado suficiente para desarrollar el producto completamente.3 Versión.3.2 Porcentaje de Avance.2. 1.6 Área Solicitante.2 El periodo está formado exclusivamente por días hábiles.2 Para cada actividad corresponde un ordinal de la secuencia. 4.6 Plataforma. seguido de un consecutivo de 3 dígitos del proyecto y dos de la versión.4 Pantallas.7 Líder del Proyecto 1.8 Lista de verificación de requerimientos cumplidos. 2. 4.2 Identificador: estará formado por los dos últimos dígitos del año. 2. 4.3. 3. excepto la actividad inicial y la actividad final. 1. Programa de Trabajo. (diagrama entidad-relación. 1.3 Calificativo de Avance.4 Todas las actividades tendrán una fecha de inicio y de finalización. 2. 1. Diagramas de flujo) 4. 4.3. 2.8 Objetivo General 1. Documentación del ciclo de desarrollo del proyecto. tiene una actividad antecedente y una actividad siguiente.4 Finalización: Se anexa el Oficio de entrega recepción y dictamen post-mortem.7 Análisis de riesgos.5 Fecha programada de finalización del proyecto.1 Cantidad de Horas-Hombre. los responsables de las mismas.3. Calendario: 2. 1.3. 2.3 Pruebas realizadas.3. 1. registrar y supervisar todas las actividades necesarias para la realización del proyecto.3 Un día hábil es de 7 horas.3.5 El formato del calendario para el desarrollo del proyecto será el siguiente: Formato 01 Anexo a este procedimiento. 4.1 Objetivo: Controlar.1 Requerimientos. es decir.2 Contenido: Oficio de Solicitud del Proyecto. 4. 2. 1.3 Ficha de Identificación: 1.3. 2 3 4 1 2 3 6/8 .8 Procedimiento de control de proyectos 1 Expediente del proyecto 1. Requerimientos.9 Plan de trabajo para cada proyecto El plan de trabajo es el calendario y secuencia de actividades. 2.1 Es la sucesión lógica de las actividades necesarias para cumplir con el calendario de trabajo.4 Fecha de Inicio.

. El proveedor es el que construye el entregable.4 En base a la duración del proyecto.2 Cada una de estas actividades deberán estar numeradas secuencialmente de acuerdo a su cronología.3 Deberá existir un plan de retorno para regresar a las condiciones previas a la implantación del cambio (back-out).1 Los recursos pueden ser: 5. 6.2 Humanos.4 Involucra un cliente y un proveedor. por lo tanto: # Actividad L M M J 3. 10.3 Si existieran cambios en el plan de trabajo se debe actualizar en el Análisis de riesgos. 8. 5. 6. Propuesta de cambio: 8. utilizando las herramientas de control documental oficiales de XXX. 10 Diagrama del proceso actual..1 Describe el proceso actual..1 Financieros. medible y cuantificable de una actividad. Análisis de riesgos: 7.4 5 6 7 8 9 Todas las actividades tienen un número que indica su secuencia pero no indica que se lleve a cabo en ese orden.1.1. dentro del programa de trabajo.Todo el personal necesario para lograr el objetivo del proyecto. sea cumplida en los plazos programados y con el entregable esperado.1 Deberá formar parte del proyecto y anexado al plan de trabajo.1 Todas las actividades deben de tener un responsable. 7/8 9. autorizados e indicados para que rubro o partida están destinados.2 El responsable de una actividad es la persona que tiene la obligación de que la actividad asignada a él.Hardware. 9. 3. 5. Responsables: 4. 7. 9.1 Indica las acciones a tomar para implantar el proyecto sin impactos negativos. Software y conocimientos para el proyecto. por ejemplo: la actividad Num. Recursos: 5.2 Deberá de existir al menos una por proyecto. 8. Retroalimentación: 9. Entregables: 6.3 Tecnológicos. el líder del mismo.1.3 1 2 13 Primera reunión de información Se deberá elaborar minutas de las reuniones de seguimiento. 6.Deberán estar presupuestados.5 Si todo el desarrollo está asignado a una sola persona. determinará el número de reuniones de retroalimentación en el plan de trabajo. 7.1 Resultado concreto.2 Deberá estar autorizado por los involucrados en el proyecto.3 Se define por anticipado. 4. El cliente es el receptor del entregable y quien define las características del mismo. 6.4 El responsable del plan de back-out es la Administración de Cambios. deberán agregarse las actividades necesarias para mantener informados a todos los involucrados en el mismo. 8.4 Puede haber actividades simultáneas en fechas pero con diferente número de secuencia. el entregable debe ser calificado por su nivel jerárquico inmediato superior.1 A todo proyecto.2 Es el criterio de evaluación de la efectividad en la actividad correspondiente a él.3 . 13 dentro del programa de trabajo es la primera reunión de información.

13. Todo proyecto deberá contener una o varias etapas de pruebas según el criterio del líder. 2.1 Describe el proceso utilizando el sistema. Se deberá realizar pruebas de cada uno de los requerimientos y documentarlo de acuerdo al formato 02.11 12 13 14 15 10. Listado de Sistemas afectados 15.2 Software y hardware. Determinan el funcionamiento de los entregables en base a lo esperado por el usuario. 12.1 El sistema hace lo que el usuario desea que haga.3 Si es fácil de usar.3 Capacidad de procesamiento de servidor y estación de trabajo. Todo proyecto deberá contener una o varias etapas de pruebas de funcionalidad según el criterio del líder del proyecto y se determinan en el plan de trabajo. En estas pruebas deberá estar involucrados el usuario y el equipo de desarrollo. 5. Diagrama del proceso interactuando con el sistema.2 Si la información que le reporta corresponde con la realidad. 12. 6. Costo estimado del proyecto. El usuario deberá evaluar la utilidad del sistema en base a los requerimientos. Estas pruebas no involucran al usuario. Deberá generarse evidencia documental de cada prueba realizada. Las pruebas deberán contemplar estos cuatro aspectos: 5.11 Plan de pruebas de funcionalidad 1.2 Sistema operativo 5. Deberán evaluarse los siguientes aspectos: 6.1 Definición de módulos. 3. 6. basado en la duración y complejidad del proyecto y se determinaran en el plan de trabajo. 2.1 Propuesta de presentación al usuario. 6. Prototipo (Pantallas). 14.4 Si es rápido. 6.4 Comunicaciones y red 1 2 3 4 5 2.2 Éste será elaborado por el líder del proceso. 5. y sin oportunidad de cambiarlos. Módulos. 4. 11.10 Plan de pruebas de diseño Estas pruebas tienen finalidad evaluar la funcionalidad del código.1 Nombre de los sistemas proveedores y clientes de información y datos compartidos indicando los formatos o criterios técnicos de diseño que permiten el intercambio de los mismos. 8/8 .1 La administración de Base de Datos 5.1 Horas hombre del proyecto.