UNIVERSIDAD DEL VALLE DE MXICO. Campus Roma.

Alumno:

Emilio Prez Gutirrez Profesor:

Armando Amezcua Herrera

Fecha de entrega:

12 Enero 2013

[2DO TRABAJO INTEGRADOR]

Implantacin y Mantenimiento de Sistemas.

Anlisis de Proyecto para Refaccionaria Automotriz

Tabla de contenido Anlisis de Proyecto para Refaccionaria Automotriz ......................................................................................................... 2 Control de cambios ......................................................................................................................................................... 3 Definicin de objetivos ................................................................................................................................................... 4 Oportunidad de Negocio ................................................................................................................................................. 4 Resumen del proyecto................................................................................................................................................... 4 Visin del proyecto ......................................................................................................................................................... 4 Alcance del Proyecto ...................................................................................................................................................... 4 Anlisis de Requerimientos de Negocio de la empresa .................................................................................................. 5 Requerimientos de negocio ............................................................................................................................................. 5 Objetivos del sistema ...................................................................................................................................................... 5 Requisitos de almacenamiento de informacin .............................................................................................................. 6 Modelos del Sistema ....................................................................................................................................................... 8 Modelo DFD del sistema nivel 0 ................................................................................................................................ 8 Modelo DFD con subsistemas Nivel 1 ...................................................................................................................... 9 Diagramas de casos de uso ............................................................................................................................................... 10 Sub Sistemas o mdulos identificados ........................................................................................................................ 11 Requerimientos no funcionales ..................................................................................................................................... 11 Definicin de actores .................................................................................................................................................... 11 Casos de uso del Sistema .................................................................................................................................................. 12 Diagrama de casos de uso del subsistema Gestin de Clientes ................................................................................ 12 Diagrama de casos de uso del subsistema Gestin de Inventario ............................................................................. 13 Diagrama de casos de uso del subsistema Gestin de Venta .................................................................................... 14 ESPECIFICACIN DE CASOS DE USO ................................................................................................................... 15 Sub Sistemas o mdulos identificados ........................................................................................................................ 21 Subsistema Clientes. ...................................................................................................................................... 21 Subsistema-Ventas ............................................................................................................................................ 21 Subsistema Inventario .................................................................................................................................. 21 (Pendiente) Subsistema Administracin. ....................................................................................................... 21 (Pendiente) Subsistema Compras. .................................................................................................................. 21

Requerimientos no funcionales ..................................................................................................................................... 21 Costos ........................................................................................................................................................................... 21 Tiempos ........................................................................................................................................................................ 21 Visin general de la verificacin ...................................................................................................................................... 12 5. Procedimientos administrativos de verificacin. ............................................................................................................... 6 5.1 Reporte y resolucin de anomalas....................................................................................................................................... 6 5.2 Polticas de iteracin de tareas. .......................................................................................................................................... 7 5.3 Polticas de desviacin. ..................................................................................................................................................... 7 5.4 Procedimientos de control. ................................................................................................................................................. 8 5.5 Estndares, prcticas y convenciones.................................................................................................................................... 8 6. Actividades de verificacin ............................................................................................................................................... 9 6.1 Plantilla de la matriz de trazabilidad. ............................................................................................................................... 9 6.2 Pruebas formales ......................................................................................................................................................... 10 6.3 Revisiones ................................................................................................................................................................... 10

Control de cambios Elaboracin Fecha Fecha Validacin Versin Emilio Prez Gutirrez Diciembre 2012 Enero 2013. 1.0

Definicin de objetivos Oportunidad de Negocio La empresa REFACCIONARIA QUETZAND que actualmente posee solo una sucursal en el estado, no tiene un sistema homogneo para manejar sus procesos, tiene un sistema de inventario en hojas de Excel y factura tambin por el mismo, ofrece y vende los productos a sus clientes en la misma sucursal y usa simples cajeros sin conexin con algn sistema de computo En este momento la empresa har una inversin que le permita crecer ante sus competidores, y para eso tiene planeado modernizar toda su infraestructura contratando nuevo personal y con la adquisicin de un sistema tipo ERP/CRM con el que pretende innovar en el sector adems de tener una mejora en su control de inventario el cual tiene problemas para mantenerse de manera consistente Resumen del proyecto El proyecto consistir en un sistema que permita la captura de toda la informacin concerniente a la empresa esto es : Capturar y tener un registro de clientes actualizado. Tener un sistema que permita recibir las solicitudes del cliente en cuanto a informacin y solicitudes de crdito Tener un registro de todos los movimientos del inventario, de todas las compras y de todas las ventas que se realicen Poder tener un sistema de ventas por internet del catlogo de la refaccionaria, para los clientes registrados Tener un sistema que reporte la situacin de la empresa en cuanto a ventas y para los administradores (BI inteligencia de negocios simplificada) Tener un control del personal laboral y administrativo que use el sistema

Visin del proyecto Ofrecer una mejora en tiempo y calidad de servicio al cliente, acercarse ms a las necesidades del cliente apoyados en el uso de tecnologas de la informacin, adems de tener una mayor vigilancia en el inventario y en la entrega de artculos. Alcance del Proyecto Para el presente proyecto, se definieron metas que se enlistan a continuacin:

Se pretende aumentar el volumen de ventas del negocio en un 50% al final del ao ya con el sistema terminado. Reducir la prdida de inventario a ms del 90%. Poseer un sistema que le permita al administrador tomar decisiones de negocio. Mejorar el sistema de cobranza de adeudos, reducir las cuentas por cobrar de los clientes en un 80%.

Anlisis de Requerimientos de Negocio de la empresa Requerimientos de negocio De acuerdo a la Metodologa utilizada se encontraron requerimientos del negocio expresados en historias de usuario, estos requerimientos se presentan a continuacin de manera tabular:

Objetivos del sistema En este apartado vamos a definir una lista con los diferentes objetivos que se esperan alcanzar cuando el sistema software a desarrollar est en explotacin. Sern especificados mediante una plantilla para objetivos OBJ01 Descripcin Estabilidad Comentarios O B J 0 2 Descripcin Estabilidad Comentarios O B J 0 3 G e s t i o n a r e l i n v e n t a r i o El sistema deber gestionar el tipo de refaccin y marca disponibles en el la refaccionaria: adquisiciones, ventas, disponibilidad, etc. Alta Ninguno G e s t i o n a r l o s c l i e n t e s El sistema deber gestionar a los clientes: altas, bajs, modificaciones de datos, sanciones, personas autorizadas, cuentas, etc. Alta Ninguno G e s t i o n a r l a s v e n t a s

Descripcin Estabilidad Comentarios

El sistema deber gestionar las ventas: entregas, devoluciones, reclamaciones, disponibilidad, etc. Alta Ninguno

Requisitos de almacenamiento de informacin Esta seccin contiene la lista de requisitos de almacenamiento de informacin que se han identificado, utilizando para especificarlos la plantilla para requisitos de almacenamiento de informacin. Se especificar toda la informacin que se debe almacenar en el sistema. RI01 Objetivos asociados Informacin sobre inventarios de refacciones OBJ01 Gestionar el inventario RF04 Alta de refaccin RF05 Alta de marca de refaccin RF08 Baja de refaccin RF10 Consulta de de refaccin RF13 Consulta de marca de refaccin El sistema deber almacenar la informacin correspondiente a las refacciones que se encuentran en la refaccionaria. En concreto: Nombre de la refaccin Cantidad de piezas en almacn Tipo de refaccin Costo de refaccin Marca de refaccin Modelo de refaccin Ao de preproduccin Pas de origen pasado y presente alta ninguno Informacin sobre los clientes OBJ02 Gestionar los clientes RF01 Alta de cliente RF02 Baja de cliente RF03 Modificacin de datos de un cliente RF12 Consulta de clientes con pagos pendientes RF13 Consulta de los clientes ms rentables RF15 Identificacin de socio El sistema deber almacenar la informacin correspondiente a los clientes de la refaccionaria. En concreto:

Requisitos asociados

Descripcin

Datos especficos

Intervalo temporal Estabilidad Comentarios RI02 Objetivos asociados

Requisitos de asociados

Descripcin

Datos especficos

Nmero del cliente que deber ser nico para cada cliente RFC Nombre y apellidos Fecha de nacimiento Sexo Fecha de alta como socio Direccin Telfonos Cantidad de refacciones adquiridas pasado y presente alta ninguno Informacin sobre cuentas de clientes OBJ02 Gestionar los clientes RF01 Alta de cliente RF02 Baja de cliente RF05 Compras efectuadas por cliente RF08 Devolucin de refaccin por falla RF09 Ingreso a cuenta RF11 Consulta de un socio RF12 Consulta de socios con pagos pendientes El sistema deber almacenar la informacin correspondiente a las cuentas de los clientes de la refaccionaria. En concreto Saldo de la cuenta en cada momento Ingresos realizados en la cuenta, indicando fecha y cantidad Cargos realizados en la cuenta, indicando fecha, motivo y cantidad Pagos pendientes, indicando motivo, y la fecha de la venta pasado y presente alta ninguno

Intervalo temporal Estabilidad Comentarios RI03 Objetivos asociados

Requisitos de asociados

Descripcin

Datos especficos Intervalo temporal Estabilidad Comentarios

Modelos del Sistema Modelo DFD del sistema nivel 0 A continuacin se presenta el diagrama de nivel 0 o de contexto del sistema, donde se presentan las entidades principales que actan sobre el sistema, haciendo peticiones (un dialogo).

Requisitos funcionales

Explicacin del diagrama El sistema proyectado recibir y enviara datos como se le solicite a personas o departamentos involucrados, las flechas con doble sentido indican un dialogo entre el sistema y la entidad, el dialogo entre el sistema y la entidad podra ser por ejemplo registrar una alta de artculo, la entidad de persona de inventario hara la peticin y el sistema determinara que procesos son los ms convenientes para la peticin , el sistema se encarga de transformar los datos que se le dan en informacin til para el negocio. Modelo DFD con subsistemas Nivel 1

Explicacin del diagrama Este diagrama sugiere un sistema conformado de 5 subsistemas , con los que se pretende satisfacer las demandas de los posibles usuarios, estos subsistemas, las flechas pueden unir a dos sistemas segn el diagrama, este enlace significa una llamada a otro subsistema para continuar el proceso de la informacin, es una llamada por ejemplo del sistema cliente al sistema ventas , para que el cliente pueda utilizar el subsistema de ventas para hacer una compra de artculos.

Diagramas de casos de uso En esta seccin hemos incluido los diagramas de casos de uso de nuestro sistema, desarrollados con la herramienta Edraw Max

Sub Sistemas o mdulos identificados Subsistema Clientes.-Este subsistema es con el que el cliente entra a hacer compras , previo registro del cliente Subsistema-Ventas .- Este subsistema es el que registra las ventas, tiene a su vez dos interfaces, la del cliente y la del vendedor Subsistema Inventario.- Este es el que registra todo movimiento del inventario por ventas o por compras o por alguna otra razn, su usuario es el almacenista (Pendiente) Subsistema Administracin.- Este es un subsistema que realiza el personal ms administrativo, sus usuarios son el administrador, la persona de recursos humanos y la que se encarga de conceder crditos o hacer cobranzas (Pendiente) Subsistema Compras .- Este es el subsistema que registra las compras que hace la empresa Cada subsistema se encargara de realizar los procesos necesarios y responder a las peticiones delos usuarios y guardando y modificando la informacin para usos posteriores, cada subsistema trabaja de manera casi independiente como aplicacin, usando llamadas a otros sistemas para completar sus procesos

Requerimientos no funcionales Tenernos otros requerimientos como la calidad de servicio, que se pide que sea aceptable y de acuerdo a un contrato, que la plataforma sea robusta y que sea capaz de crecer con el tiempo Definicin de actores Este apartado contiene los diferentes actores que se han identificado, especificados mediante la plantilla para actores de casos de uso.

ACT01 Descripcin Comentarios ACT02 Descripcin Comentarios

Cliente Este actor representa al cliente de la refaccionaria ninguno Empleado de refaccionaria Este actor representa al empleado de la refaccionaria ninguno

Casos de uso del Sistema Diagrama de casos de uso del subsistema Gestin de Clientes

Diagrama de casos de uso del subsistema Gestin de Inventario

Diagrama de casos de uso del subsistema Gestin de Venta

ESPECIFICACIN DE CASOS DE USO RI01 Informacin sobre inventarios de refacciones Objetivos OBJ01 Gestionar el inventario

asociados Requisitos asociados

RF04 Alta de refaccin RF05 Alta de marca de refaccin RF08 Baja de refaccin RF10 Consulta de refaccin RF13 Consulta de marca de refaccin El sistema deber almacenar la informacin correspondiente a las refacciones que se encuentran el refaccionaria. En concreto: Nombre de la refaccin Cantidad de piezas en almacn Tipo de refaccin Costo de refaccin Marca de refaccin Modelo de refaccin Ao de preproduccin Pas de origen pasado y presente alta ninguno Informacin sobre los clientes OBJ02 Gestionar los clientes RF01 Alta de cliente RF02 Baja de cliente RF03 Modificacin de datos de un cliente RF12 Consulta de clientes con pagos pendientes RF12 Consulta de los clientes ms rentables RF15 Identificacin de socio El sistema deber almacenar la informacin correspondiente a los clientes de la refaccionaria. En concreto: Nmero del cliente que deber ser nico para cada cliente RFC Nombre y apellidos Fecha de nacimiento Sexo Fecha de alta como socio Direccin Telfonos Cantidad de refacciones adquiridas pasado y presente

Descripcin Datos especficos

Intervalo temporal Estabilidad Comentarios RI02 Objetivos asociados Requisitos de asociados

Descripcin Datos especficos

Intervalo temporal

Estabilidad Comentarios

alta ninguno

RI03 Objetivos asociados Requisitos de asociados

Informacin sobre cuentas de clientes OBJ02 Gestionar los clientes RF01 Alta de cliente RF02 Baja de cliente RF05 Compras efectuadas por cliente RF08 Devolucin de refaccin por falla RF09 Ingreso a cuenta RF11 Consulta de un socio RF12 Consulta de socios con pagos pendientes El sistema deber almacenar la informacin correspondiente a las cuentas de los clientes de la refaccionaria. En concreto Saldo de la cuenta en cada momento Ingresos realizados en la cuenta, indicando fecha y cantidad Cargos realizados en la cuenta, indicando fecha, motivo y cantidad Pagos pendientes, indicando motivo, y la fecha de la venta Alta de cliente OBJ02 Gestionar los clientes El sistema deber comportarse tal como se describe en el siguiente caso de uso cuando alguien solicite su ingreso como cliente El solicitante no cliente de la refaccionaria y tiene su documentacin disponible 1. El cliente solicita al sistema comenzar el proceso de alta de un nuevo cliente 2. El sistema solicita los siguientes datos del nuevo cliente: RFC, nombre, apellidos, fecha de nacimiento, sexo, direccin, email y telfonos de contacto

Descripcin Datos especficos

RF- 01 Objetivos asociados Descripcin Precondicin Secuencia Normal

3. El sistema confirma la recepcin de los datos 4. El sistema solicita usuario y contrasea 5. El sistema confirma y proporciona nmero de cliente 6. El sistema confirma que esta dado de alta y muestra ventana de compras y saldos. Postcondicin El solicitante es cliente de la refaccionaria y el saldo de su cuenta es 0 Excepciones 2. Si la informacin de llenado de registro es incorrecta manda una ventana de error y solicita que se vuelva a llenar el campo 2. Si el Cliente decide no concluir la operacin regresa a la pantalla principal 4. Si el usuario ya no est disponible solicitar otro usuario diferente 5. Si no se proporciona nmero de cliente poner recuadro de enviar queja por mail Cuota de tiempo 5 segundos ms de 10 veces al da Alta

Rendimiento Frecuencia esperada Estabilidad

Comentarios

La frecuencia ser mayor durante los primeros dos meses hasta ms de 100 veces al da Consulta de cliente OBJ02 Gestionar los clientes El sistema deber comportarse tal como se describe en el siguiente caso de uso cuando el empleado lo considere oportuno Debe de haber registros de clientes en la base de datos 1. El empleado solicita al sistema comenzar el proceso de consulta de los datos de un socio 2. El sistema solicita que se identifique al cliente 3. El empleado proporciona los datos de identificacin al sistema 4. El sistema muestra la siguiente informacin asociada al cliente: nombre, apellidos, direccin, nmeros de telfono, email, compras realizadas y saldo de su cuenta 5. Si el empleado solicita la impresin delos datos, el sistema imprime los datos del cliente

RF- 11 Objetivos asociados Descripcin Precondicin Secuencia Normal

Postcondicin ninguna Excepciones 3. Si el empleado solicita cancelar la operacin, el sistema cancela la operacin, a continuacin este caso de uso termina 5. Si el sistema no tiene registrado ningn cliente con la identificacin proporcionada, el sistema hace que caso de uso termine Rendimiento Frecuencia esperada Estabilidad Comentarios RF- 12 Objetivos asociados Requisitos asociados Descripcin Precondicin Secuencia Normal Cuota de tiempo 1 segundo ms de 10 veces al da Alta El formato de visualizacin de los datos est pendiente de definicin Consulta de cliente con pagos pendientes OBJ02 Gestionar los clientes RI02 Informacin sobre el cliente RI03 Informacin sobre cuentas del cliente El sistema deber comportarse tal como se describe en el siguiente caso de uso cuando el empleado lo considere oportuno ninguna 1. El empleado solicita al sistema comenzar el proceso de consulta de los clientes con pagos pendientes 2. El sistema muestra una lista ordenada por cantidad pendiente con la siguiente informacin por cada cliente: nombre, apellidos, cantidad total pendiente y detalle de las cantidades pendientes 3. Si el empleado solicita la impresin delos datos, el sistema imprime la lista

Postcondicin ninguna Excepciones null null Rendimiento 5 segundos Frecuencia 1 vez por semana esperada Estabilidad Alta Comentarios El formato de visualizacin de los datos est pendiente de definicin RF- 15 Objetivos asociados Requisitos asociados Descripcin Identificacin del Cliente OBJ02 Gestionar los clientes RI02 Informacin sobre el cliente null El sistema deber comportarse tal como se describe en el siguiente caso de uso durante la realizacin de los casos de uso: RF02 Baja de cliente RF03 Modificacin de datos del cliente RF06 Venta de refacciones El socio tiene su documentacin disponible de compra 1. El sistema solicita que se identifique al cliente 2. El sistema muestra la pantalla de inicio donde se muestran sus compras y sus datos generales

Precondicin Secuencia Normal

3. El cliente solicita a sistema actualizar la informacin personal 4. El cliente solicita sistema cancelar el pedido 5. El cliente solicita facturacin 6. El cliente solicita la baja de su cuenta Postcondicin ninguna 1. Si no recuerda usuario y contrasea enva pantalla de reseteo de cuenta Excepciones 2. El cliente no reconoce compra, mandar pantalla de mail para aclaracin y telfonos 3. El sistema manda formato para llenar factura 6. El sistema notifica que se complet la operacin y regresa a men principal Rendimiento 5 segundos Frecuencia ms de 20 veces por da esperada Estabilidad Alta Comentarios Formato de facturacin RF- 02 Objetivos asociados Requisitos asociados Baja de Cliente OBJ02 Gestionar los clientes RI02 Informacin sobre el cliente null

Descripcin

El sistema deber comportarse tal como se describe en el siguiente caso de uso durante la realizacin de los casos de uso: RF02 Baja de cliente RF03 Modificacin de datos del cliente RF06 Venta de refacciones El cliente tiene los datos de ingreso a sistema o el empleado cancela cuenta 1. Se realiza el caso de uso RF-15 (identificacin de cliente) 2. El cliente o empleado inician el proceso de cancelacin de cuenta 3. El sistema indica que al cliente o empleado que la cuenta se ha cancelado con xito siempre y cuando el cliente no tenga adeudo

Precondicin Secuencia Normal

4. El sistema te manda a la pantalla de inicio Postcondicin ninguna 1. Si el sistema no identifica al cliente manda pantalla de reseteo de cuenta Excepciones 3. Si la cuenta no est liquidada, solicita el importe a pagar y las formas de pago Rendimiento 1 segundos Frecuencia ms de 10 veces al mes esperada Estabilidad Alta Comentarios Si el socio que desea darse de baja tiene un pago pendiente, puede hacer un ingreso por su importe y repetir el proceso de darse de baja RF- 03 Objetivos asociados Requisitos asociados Descripcin Modificacin de los datos de un cliente OBJ02 Gestionar los clientes RI02 Informacin sobre el cliente null El sistema deber comportarse tal como se describe en el siguiente caso de uso durante la realizacin de los casos de uso: RF02 Baja de cliente RF03 Modificacin de datos del cliente RF06 Venta de refacciones El cliente tiene los datos de ingreso a sistema o el empleado para modificacin de datos 1. Se realiza el caso de uso RF15(Identificacin de socio) 2. El cliente o empleado solicita al sistema comenzar el proceso de modificacin de los datos de un cliente 3. El sistema muestra los siguientes datos correspondientes al socio a modificar: RFC, email, nombre, apellidos, fecha de nacimiento, sexo, direccin y telfonos de contacto 4. El sistema solicita guardar los cambios 5. El sistema modifica los datos correspondientes del cliente e informa que el proceso ha terminado con xito 6. Regresa a la pantalla de inicio

Precondicin Secuencia Normal

Postcondicin La informacin del socio est actualizada Excepciones 1. Si el sistema no identifica al cliente manda pantalla de reseteo de cuenta 3. Si la cuenta no est liquidada, solicita el importe a pagar y las formas de pago Rendimiento 1 segundos Frecuencia ms de 10 veces al mes esperada Estabilidad Alta Comentarios ninguno

Sub Sistemas o mdulos identificados Subsistema Clientes.-Este subsistema es con el que el cliente entra a hacer compras, previo registro del cliente Subsistema-Ventas .- Este subsistema es el que registra las ventas, tiene a su vez dos interfaces, la del cliente y la del vendedor Subsistema Inventario.- Este es el que registra todo movimiento del inventario por ventas o por compras o por alguna otra razn, su usuario es el almacenista (Pendiente) Subsistema Administracin.- Este es un subsistema que realiza el personal ms administrativo, sus usuarios son el administrador, la persona de recursos humanos y la que se encarga de conceder crditos o hacer cobranzas (Pendiente) Subsistema Compras.- Este es el subsistema que registra las compras que hace la empresa Cada subsistema se encargara de realizar los procesos necesarios y responder a las peticiones delos usuarios y guardando y modificando la informacin para usos posteriores, cada subsistema trabaja de manera casi independiente como aplicacin, usando llamadas a otros sistemas para completar sus procesos Requerimientos no funcionales Se tienen otros requerimientos como la calidad de servicio, que se pide que sea aceptable y de acuerdo a un contrato, que la plataforma sea robusta y que sea capaz de crecer con el tiempo Costos Dentro del estudio del proyecto, se desarrollaron los costos del mismo y de los mdulos, quedando como gran total por el proyecto: $ 180,000.00 MXN, los cuales sern pagados en mensualidad por lo que dure el proyecto y considerando que este monto ampara exclusivamente lo estipulado en el alcance del proyecto, por lo que cualquier adicin de mdulos, se someter a evaluacin y podr generar costos adicionales al cliente. Tiempos Para este proyecto y despus de los estudios necesarios, se estima que tendr una duracin de 146 das debido al diseo que se realizar del software a la medida del cliente. El desglose de actividades se detalla en el Project Plan Anexo a este documento. CAPACITACIN Y DESARROLLO DE RECURSOS HUMANOS

La Capacitacin significa la preparacin de la persona en el cargo. Es una actividad sistemtica, planificada y permanente cuyo propsito es preparar, desarrollar e integrar los recursos humanos al proceso productivo, mediante la entrega de conocimientos, desarrollo de habilidades y actitudes necesarias para el mejor desempeo de todos los trabajadores en sus actuales y futuros cargos y adaptarlos a las exigencias cambiantes del entorno. La capacitacin va dirigida al perfeccionamiento tcnico del trabajador para que ste se desempee eficientemente en las funciones a l asignadas, produzca resultados de calidad, proporcione excelentes servicios a sus clientes, prevenga y solucione anticipadamente problemas potenciales dentro de la organizacin. El Desarrollo se refiere a la educacin que recibe una persona para el crecimiento profesional a fin de estimular la efectividad en el cargo. Tiene objetivos a largo plazo y generalmente busca desarrollar actitudes relacionadas con una determinada filosofa que la empresa quiere desarrollar. La capacitacin es para los puestos actuales y la formacin o desarrollo es para los puestos futuros. La capacitacin y el desarrollo con frecuencia se confunden, puesto que la diferencia est ms en funcin de los niveles a alcanzar y en la intensidad de los procesos. Ambas son actividades educativas. OBJETIVOS DE LA CAPACITACIN Y DESARROLLO Los principales objetivos de la capacitacin son: 1. Preparar al personal para la ejecucin de las diversas tareas particulares de la organizacin. 2. Proporcionar oportunidades para el continuo desarrollo personal, no slo en sus cargos actuales sino tambin para otras funciones para las cuales la persona puede ser considerada. 3. Cambiar la actitud de las personas, con varias finalidades, entre las cuales estn crear un clima ms satisfactorio entre los empleados, aumentar su motivacin y hacerlos ms receptivos a las tcnicas de supervisin y gerencia. BENEFICIOS DE LA CAPACITACIN DE LOS EMPLEADOS Beneficios para la organizacin: Mejora el conocimiento del puesto a todos los niveles. Eleva la moral de la fuerza de trabajo. Ayuda al personal a identificarse con los objetivos de la organizacin. Mejora la relacin jefes-subordinados. Es un auxiliar para la comprensin y adopcin de polticas. Se agiliza la toma de decisiones y la solucin de problemas. Promueve el desarrollo con vistas a la promocin. Contribuye a la formacin de lderes y dirigentes. Incrementa la productividad y calidad del trabajo. Ayuda a mantener bajos los costos. Elimina los costos de recurrir a consultores externos. Beneficios para el trabajador que repercuten favorablemente en la organizacin: Ayuda a la persona en la solucin de problemas y en la toma de decisiones. Aumenta la confianza, la posicin asertiva y el desarrollo. Forja lideres y mejora las aptitudes comunicativas. Sube el nivel de satisfaccin con el puesto. Permite el logro de metas individuales. Elimina los temores a la incompetencia o la ignorancia individual. Beneficios en relaciones humanas, relaciones internas y externas, y adopcin de polticas: Mejora la comunicacin entre grupos y entre individuos. Ayuda en la orientacin de nuevos empleados.

Proporciona informacin sobre disposiciones oficiales. Hace viables las polticas de la organizacin. Proporciona una buena atmsfera para el aprendizaje. Convierte a la empresa en un entorno de mejor calidad para trabajar. PASOS DEL PROCESO DE CAPACITACIN 1. Determinacin de necesidades de capacitacin Detectar las necesidades de capacitacin permite que la empresa no corra el riesgo de equivocarse al ofrecer una capacitacin inadecuada, lo cual redundara en gastos innecesarios. La actividad de capacitacin debe estar fuertemente alineada con los intereses del negocio para ser justificada. Deben realizarse tres tipos de anlisis; estos son: Anlisis Organizacional: Es aqul que examina a toda la compaa para determinar en qu rea, seccin o departamento, se debe llevar a cabo la capacitacin. Se debe tomar en cuenta las metas y los planes estratgicos de la organizacin, as como los resultados de la planeacin en recursos humanos. Anlisis de Tareas: Se analiza la importancia y rendimiento de las tareas del personal que va a incorporarse en las capacitaciones. Anlisis de la Persona: Dirigida a los empleados en forma individual. En este anlisis se debe comparar el desempeo del empleado con las normas establecidas en la empresa y esta informacin es obtenida a travs de una encuesta. Los principales medios utilizados para la determinacin de necesidades de capacitacin son: Evaluacin de desempeo: Mediante la evaluacin de desempeo es posible descubrir no slo a los empleados que vienen efectuando sus tareas por debajo de un nivel satisfactorio, sino tambin averiguar qu sectores de la empresa reclaman una atencin inmediata de los responsables del entrenamiento. Observacin: Debe ser realizada en el sitio de trabajo y permite verificar donde hay evidencia de trabajo ineficiente, tales como excesivo dao de equipos, atraso con relacin al cronograma, perdida excesiva de materia prima, nmero acentuado de problemas disciplinarios, alto ndice de ausentismo, entre otros. Cuestionarios: Investigaciones mediante cuestionarios y listas de verificacin proporcionan evidencias sobre las necesidades de entrenamiento. Solicitud de supervisores y gerentes: Cuando la necesidad de entrenamiento apunta a un nivel muy alto, los propios gerentes y supervisores se hacen propensos a solicitar entrenamiento para su personal. Entrevistas con supervisores y gerentes: Contacto directo con supervisores y gerentes, con respecto a posibles problemas solucionables mediante entrenamiento, por lo general se descubren en las entrevistas con los responsables de diversos sectores. Reuniones interdepartamentales: Discusiones entre los diferentes departamentos acerca de asuntos concernientes a objetivos empresariales, problemas operacionales, planes para determinados objetivos y otros asuntos administrativos. Examen de empleados: Prueba de conocimiento del trabajo de los empleados que ejecutan determinadas funciones o tareas. Modificacin de trabajo: Siempre que se introduzcan modificaciones totales o parciales de la rutina de trabajo, se hace necesario el entrenamiento previo de los empleados en los nuevos mtodos y procesos de trabajo. Entrevista de salida: Cuando el empleado va a retirarse de la empresa es el momento ms apropiado para conocer su opinin acerca de la empresa y las razones que motivaron su salida. Es posible que salgan a relucir varias diferencias de la organizacin, susceptibles de correcciones. Anlisis de cargos: El conocimiento y la definicin de lo que se quiere en cunto a aptitudes, conocimientos y capacidad, hace que se puedan preparar programas adecuados de capacitacin para desarrollar la capacidad y proveer conocimientos especficos segn las tareas, adems de formular planes de capacitacin concretos y econmicos y de adaptar mtodos didcticos. Adems de estos medios, existen algunos indicadores de necesidades de capacitacin, los cules son:

Indicadores a priori: Son los eventos que provocaran futuras necesidades de capacitacin fcilmente previsibles. Los indicadores a priori son: Expansin de la empresa y admisin de nuevos empleados. Reduccin del nmero de empleados. Cambio de mtodos y procesos de trabajo. Sustituciones o movimiento de personal. Faltas, licencias y vacaciones del personal. Modernizacin de maquinarias y equipos. Produccin y comercializacin de nuevos productos o servicios. Indicadores a posteriori: Son los problemas provocados por las necesidades de capacitacin no atendidas. Por lo general, estn relacionadas con la produccin o con el personal y sirve como diagnstico de capacitacin. Se clasifican en: a) Problemas de produccin: Calidad inadecuada de la produccin. Baja productividad. Averas frecuentes en equipos e instalaciones. Comunicaciones defectuosas. Prolongado tiempo de aprendizaje e integracin en el campo. Gastos excesivos en el mantenimiento de mquinas y equipos. Exceso de errores y desperdicios. Elevado nmero de accidentes. b) Problemas de personal: Relaciones deficientes entre el personal. Nmero excesivo de quejas. Poco o ningn inters por el trabajo. Falta de cooperacin. Errores en la ejecucin de rdenes. Dificultades en la obtencin de buenos elementos.

2. Programacin de la capacitacin Consiste en la eleccin y prescripcin de los medios de capacitacin para sanar las necesidades percibidas. En esta etapa se toman en cuenta los siguientes aspectos: Plantacin de la capacitacin. La programacin de la capacitacin exige una planeacin que incluye lo siguiente: Enfoque de una necesidad especifica cada vez. Definicin clara del objetivo de la capacitacin. Divisin del trabajo a ser desarrollado, en mdulos, paquetes o ciclos. Eleccin de los mtodos de capacitacin, considerando la tecnologa disponible. Definicin de los recursos necesarios para la implementacin de la capacitacin, como tipo de entrenador o instructor, recursos audiovisuales, mquinas, equipos o herramientas necesarias, materiales, manuales, entre otros. Definicin de la poblacin objetivo, es decir, el personal que va a ser capacitado, considerando: o Nmero de personas. o Disponibilidad de tiempo. o Grado de habilidad, conocimientos y tipos de actitudes. o Caractersticas personales de comportamiento. Local donde se efectuara la capacitacin, considerando las alternativas en el puesto de trabajo o fuera del mismo, en la empresa o fuera de ella. poca o periodicidad de la capacitacin, considerando el horario ms oportuno o la ocasin ms propicia. Clculo de la relacin costo-beneficio del programa.

Tcnicas de capacitacin. Estas se dividen en: a) Tcnicas aplicadas en el sitio de trabajo: Capacitacin en el puesto: Contempla que una persona aprenda una responsabilidad mediante su desempeo real. Ofrece varias ventajas, tales como que es relativamente econmica, los trabajadores en capacitacin aprenden al tiempo que producen y no hay necesidad de instalaciones costosas fuera del trabajo como salones o dispositivos de aprendizaje programados. El mtodo tambin facilita el aprendizaje ya que los empleados aprenden haciendo realmente el trabajo y obtienen una retroalimentacin rpida sobre lo correcto de su desempeo. Existen varios tipos de capacitacin en el puesto, entre ellas: El mtodo de instruccin o sustituto, en la que el empleado recibe la capacitacin en el puesto por parte de un trabajador experimentado o supervisor. La rotacin de puestos en la que el empleado pasa de un puesto a otro en intervalos planeados. Rotacin de puestos: Con el fin de proporcionar a los empleados, experiencia en varios puestos, se utiliza la rotacin del personal de una a otra funcin. Cada movimiento de un puesto a otro es normalmente precedido por una sesin de instruccin directa. Adems de proporcionar variedad en su labor diaria, esta tcnica ayuda a la organizacin en perodo de vacaciones, ausencias, renuncias, entre otros. Relacin experto-aprendiz: En las tcnicas de capacitacin que utilizan una relacin entre un maestro y un aprendiz se aprecian claras ventajas en la retroalimentacin que se obtiene prcticamente de inmediato. b) Tcnicas aplicadas fuera del sitio de trabajo: Conferencias, videos y pelculas, audiovisuales y similares: Estas tcnicas no requieren de una participacin activa del trabajador, economizan tiempo y recursos. Los bajos niveles de participacin, retroalimentacin, transferencias y repeticin que estas tcnicas muestran, pueden mejorar mucho cuando se organizan mesas redondas y sesiones de discusin al terminar la exposicin. Simulacin de condiciones reales por computadoras: Consiste en la simulacin de instalaciones de operacin real, donde el trabajador se va a aprender de manera prctica su puesto de trabajo. Permite transferencia, repeticin y participacin notable, generalmente las utilizan las compaas areas, los bancos y los hoteles. Actuacin o sociodrama: Esta tcnica obliga al capacitando a desempear diversas identidades. Se utiliza para el cambio de actitudes y el desarrollo de mejores relaciones humanas. Una de las ventajas es que se pueden crear vnculos de amistad, as como tolerancia de las diferencias individuales. Estudio de casos: Permite al trabajador resolver situaciones parecidas a las que se pudieran presentar en su trabajo, mediante el estudio de una situacin especfica real o simulada. Para ello, recibe sugerencias de otras personas y desarrolla habilidades para la toma de decisiones. En esta tcnica de capacitacin, se practica la participacin, ms no as la retroalimentacin y la repeticin. Lectura, estudios individuales, instruccin programada: Se refiere a cursos basados en lecturas, grabaciones, fascculos de instruccin programada y ciertos programas de computadoras. Resultan de gran utilidad en circunstancias de dispersin geogrfica o cuando hay dificultad para reunir un grupo de asistentes a un programa de capacitacin. Los materiales programados proporcionan elementos de participacin, repeticin, relevancia y retroalimentacin. Capacitacin en laboratorio (sensibilizacin): Constituye una modalidad de la capacitacin en grupo. Se emplea para desarrollar las habilidades interpersonales y el desarrollo de conocimientos, habilidades y conductas adecuadas para futuras responsabilidades laborales. Por lo general se utiliza a un profesional de psicologa como moderador de estas sesiones. Se basa en la participacin, retroalimentacin y repeticin. 3. Ejecucin del Programa de capacitacin La capacitacin presupone el binomio instructor/aprendiz. Los aprendices son las personas situadas en cualquier nivel jerrquico de la empresa y que necesita aprender o mejorar los conocimientos que tienen sobre alguna actividad o trabajo. Los instructores son las personas situadas en cualquier nivel jerrquico, expertos o especialistas en determinada actividad o trabajo y que transmiten sus conocimientos de manera organizada a los aprendices. Tambin presupone una relacin de instruccin/aprendizaje. La instruccin es la enseanza organizada de cierta tarea o actividad y el aprendizaje es la incorporacin al comportamiento del individuo de aquello que fue instruido.

La ejecucin del programa de capacitacin, depender principalmente de los siguientes factores: Adecuacin del programa de entrenamiento a las necesidades de la organizacin. La decisin de establecer determinados programas de entrenamiento debe depender de la necesidad de preparar determinados empleados o mejorar el nivel de los empleados disponibles. La calidad del material del entrenamiento presentado. El material de enseanza debe ser planeado de manera cuidadosa, con el fin de facilitar la ejecucin del entrenamiento. La cooperacin de los jefes y dirigentes de la empresa. El entrenamiento debe hacerse con todo el personal de la empresa, en todos los niveles y funciones. Su mantenimiento implica una cantidad considerable de esfuerzo y de entusiasmo por parte de todos los participantes en la tarea, adems de implicar un costo que debe ser considerado como una inversin que capitalizar dividendos a mediano y corto plazo y no como un gasto superficial. La calidad y preparacin de los instructores. El xito de la ejecucin depender del inters, del esfuerzo y del entrenamiento de los instructores. Es muy importante el criterio de seleccin de los instructores, los cuales debern reunir ciertas cualidades personales, tales como facilidad para las relaciones humanas, motivacin por la funcin, raciocinio, capacidades didcticas, exposicin fcil, adems del conocimiento de la especialidad. La calidad de los aprendices. Este aspecto influye de manera sustancial en los resultados del programa de entrenamiento. Los mejores resultados se obtienen con una seleccin adecuada de los aprendices, en funcin de la forma y del contenido del programa y de los objetivos del entrenamiento. 4. Evaluacin de los resultados de la capacitacin. La Evaluacin es un proceso que debe realizarse en distintos momentos, desde el inicio de un Programa de Capacitacin, durante y al finalizar dicho programa. Es un proceso sistemtico para valorar la efectividad y/o la eficiencia de los esfuerzos de la capacitacin. Los datos que se obtienen son tiles para la toma de decisiones y se pueden realizar tres diferentes tipos de evaluacin: Evaluacin de los procesos, la cual examina los procedimientos y las tareas implicadas en la ejecucin de un programa o de una intervencin. Evaluacin de los impactos, es ms cabal y se centra en los resultados de largo alcance del Programa o en los cambios o mejoras al estado de la actividad. Evaluacin de los resultados, se usa para obtener datos descriptivos en un proyecto o programa y para documentar los resultados a corto plazo.

CAMBIOS EN EL PROCESO DE ADIESTRAMIENTO, CAPACITACIN Y DESARROLLO CON EL AUGE DE LAS NUEVAS TECNOLOGAS DE COMUNICACIN E INFORMACIN En cualquier organizacin, el adiestramiento, capacitacin y desarrollo de los recursos humanos, son considerados factores importantes para el logro de los objetivos y metas proyectadas, ya que un personal que pueda responder de manera efectiva a las distintas necesidades institucionales, desde la operatividad de sus funciones en el cargo que ocupa; beneficia a la organizacin porque esto crea en el empleado, un compromiso y una responsabilidad institucional, lo que se traduce en un mejor desempeo laboral. Con el pasar del tiempo se han venido dando cambios en el mundo empresarial, producto del crecimiento de una economa global y del uso de las Tecnologas de Informacin y Comunicacin; incidiendo esto en la estructura interna, jerarqua de cargos, seleccin del personal as como tambin en la metodologa para la capacitacin del personal. El manejo de las tecnologas de informacin y comunicacin actualmente forman parte integral del negocio, constituyen un elemento fundamental para apoyar, mantener y propiciar el crecimiento o vigencia econmica y social de una organizacin. El desarrollo tecnolgico permite a las empresas acortar distancias y colocar de manera ms rpida y efectiva los mejores bienes y servicios que los clientes esperan; lo que se traduce en niveles de competitividad y de productividad para esas empresas.

Por otra parte, adems del manejo de la informacin, el conocimiento es otro pilar fundamental para que se generen respuestas asertivas al cliente, desde la creatividad y la innovacin, permitiendo as que la organizacin se mantenga constantemente actualizada en cunto al uso de estrategias diseadas desde los cambios tecnolgicos en bsqueda del xito institucional. El proceso de innovacin en una empresa que se sustenta en el paradigma tecnolgico, es visto en tres grandes etapas: identificacin de una necesidad en el mercado o de una oportunidad tecnolgica; adopcin y adaptacin de la tecnologa ya existente y transfiriendo esta tecnologa por comercializacin o por algn medio institucional. Se exige en la actualidad empresas que sean capaces de adaptarse de manera rpida a los permanentes cambios y ver que el conocimiento es la opcin para solventar las situaciones que se presentan en la organizacin a travs de la innovacin tecnolgica. Es por esta razn que lo departamentos informticos de las organizaciones, constituyen pilares fundamentales para gestionar estos cambios. Algunos aspectos importantes a destacar de las nuevas tecnologas para el desarrollo de recursos humanos son: La organizacin virtual. Es un concepto donde la relacin entre personas y entre procesos existe, pero no hay una ubicacin, un lugar fijo, se da a travs de Internet. Se trabaja en base a desarrollo de proyectos, propuestas que van y vienen corregidas, se cumple con una agenda y metas de trabajo de un pas a otro, incluso de un continente a otro. Empowerment. Consiste en una nueva forma de administrar la empresa, donde se integran todos los recursos: capital, manufactura, produccin, ventas, mercadotecnia, tecnologa, equipo y personal; haciendo uso de una comunicacin efectiva y eficiente para lograr los objetivos de la organizacin. "Empowerment es donde los beneficios ptimos de la tecnologa de la informacin son alcanzados. Los miembros, equipos de trabajo y la organizacin, tendrn completo acceso y uso de informacin crtica, poseern la tecnologa, habilidades, responsabilidad, y autoridad para utilizar la informacin y llevar a cabo el negocio de la organizacin." Para implantar el sistema de empowerment en una empresa es necesario que haya un cambio en la cultura de trabajo, y para esto es necesario que se aprenda a trabajar en equipo. Teamwork. Un equipo de trabajo tiene la finalidad de crear nuevos conocimientos sobre los procesos organizativos, sobre los procesos grupales y sobre los procesos personales de cada uno de los miembros del equipo, esto permite al equipo optimizar sus recursos y lograr una mejor calidad del producto como de los procesos. Convertir el trabajo en equipo en un modo de gestin organizacional requiere conviccin, fijacin de polticas y actitudes proactivas por parte de las personas que trabajan en la organizacin. El papel del gerente, en este sentido, es el de liderar el cambio mismo, convirtindose en un estratega y un excelente comunicador e inspirador de todos aquellos aspectos que involucren a la organizacin. El desarrollo de nuevas tecnologas y el auge cada vez mayor de la llamada "revolucin de la informacin", ha propiciado cambios acelerados en las estructuras organizacionales, al mismo tiempo que condiciona un nuevo perfil global para el gerente, en donde sus principales caractersticas personales deben incluir una mayor capacidad de adaptacin a nuevas circunstancias, una mentalidad internacional y excelentes condiciones de aprendizaje y comunicacin, adems de contar con principios elementales como tica, honestidad y justicia, cuya valoracin es de carcter universal. Hoy en da, se requiere de una gerencia ms participativa y con menos niveles jerrquicos, en donde se produzca un mayor acercamiento de todos los que la integran, con una participacin mucho ms activa de todo el equipo gerencial en la toma de decisiones y con un nfasis muy particular en equipos decisorios basados en estructuras funcionales por reas de negocios.

CHEECK LIST DE SISTEMAS DE INFORMACIN EN EL CENTRO DE INFORMACIN Y SISTEMAS

4.12.1 LA ORGANIZACIN Y GESTIN DEL REA DE SISTEMAS 4.12.2 Objetivo de Control OG1: Procesos, organizacin y relaciones: El rea de sistemas debe tener definidos los procesos de su organizacin.

S I O OG1-C1: Deben establecerse de forma clara las funciones del rea. Existe algn documento que contiene las funciones informacin respeta. que y son competencia est del centro y de se X

N ones

Observaci

sistemas,

aprobado

OG1-C2: Debe especificarse en el organigrama puestos del rea y el staff. Existe un organigrama con la estructura de organizacin del rea. OG1-C3: Debe establecerse el marco de trabajo de los procesos del rea de sistemas, de modo que permita la ejecucin y puesta en prctica del plan operativo informtico. X

EI marco de trabajo permite la definicin y seguimiento de los objetivos de los procesos que han sido definidos e implementados, as como formalmente documentados y aprobados. OG1-C4: Deben establecerse roles y responsabilidades para la gestin del aseguramiento de la calidad, gestin de riesgos, seguridad y conformidad. El staff cuenta con los sistemas de X X

aseguramiento de la calidad apropiados, as como los controles y asesoramiento de expertos. Las responsabilidades y roles han sido

correctamente establecidos, formalizados, documentados y satisfacen los requisitos del rea. Son ejecutados por personal con la suficiente formacin y experiencia en la materia. X

4.12.3 Objetivo de Control OG2: Gestin de Recursos Humanos: El rea de sistemas debe contar con recursos humanos adecuados para gestionar el desarrollo y mantenimiento de SI. OG2-C1: Deben existir procedimientos de contratacin objetivos. Las ofertas de puestos del rea se difunden de forma suficiente fuera de la organizacin y las selecciones del personal se hacen de forma objetiva. X

Las

personas

seleccionadas

cumplen

los requisitos del puesto al que acceden. OG2-C2: Debe existir un plan de capacitacin que este en consonancia con los objetivos del rea y alineados con los objetivos institucionales. Se tiene aprobado un plan de capacitacin a corto, medio y largo plazo que sea coherente con el plan operativo informtico OG2-C3: Debe existir una biblioteca accesible por el personal del rea. X

Estn disponibles un nmero suficiente de libros, publicaciones peridicos, monografas de X

reconocido prestigio, ya sea en formato electrnico o papel. El personal tiene acceso a ellos. OG2-C4: El personal debe estar motivado en la realizacin de su trabajo. Existe algn mecanismo que permita a los empleados hacer sugerencias sobre mejoras en la organizacin del rea. No existe una gran rotacin de personal, existe un buen ambiente de trabajo. X X

4.12.4 Objetivo de Control OG3: Plan Estratgico de Tecnologas de la Informacin del rea: El rea de sistemas debe participar en la definicin del plan estratgico de Tecnologas de la Informacin OG3-C1: el rea debe tener y difundir su propio plan a corto, medio y largo plazo. Existe el plan estratgico de Tecnologas de la Informacin. Se revisa y actualiza con periodicidad en funcin de las nuevas situaciones. Se difunde a todo el staff para que se sientan partcipes del mismo. OG3-C2: La realizacin de nuevos proyectos debe basarse en el plan estratgico de Tecnologas de la Informacin y en el plan operativo informtico en cuanto a objetivos, marco general. Las fechas de realizacin coinciden con las del plan estratgico. La documentacin relativa a cada proyecto que existe en el plan estratgico se pone a disposicin del director de proyecto una vez comenzado el X X X X X

mismo. Esta informacin debe contener los objetivos, los requisitos generales y un plan inicial.

4.12.5 Objetivo de Control OG4: Gestin de la calidad: El rea de sistemas debe disponer de procesos de desarrollo regidos por estndares y principios de ingeniera de software ampliamente aceptados. OG4-C1: Debe existir un registro de problemas que se producen en los proyectos del rea, incluyendo los fracasos de proyectos completos. Existe un catlogo de problemas, incluyendo para cada uno de ellos la solucin o soluciones encontradas, proyecto en el que sucedi, persona que lo resolvi. EI catlogo es accesible para todos los miembros del rea, esta actualizado y tiene uno o varios ndices que faciliten la bsqueda. Se registran y controlan todos los proyectos fracasados (aquellos que comienzan y no llegan a su fin), as como los recursos invertidos en los mismos. X X X

OG4-C2: Debe mantenerse y comunicarse peridicamente al rea las modificaciones del plan de calidad a fin de promover la mejora continua. El plan existe y se actualiza peridicamente. Existen y se ejecutan actividades de mejora continua segn los estndares, prcticas, procedimientos y polticas de calidad del X X

departamento adoptadas por el rea de sistemas.

OG4-C3: Debe existir algn mecanismo de creacin y actualizacin de prcticas y estndares de calidad as como de prcticas, estndares de desarrollo y mantenimiento.

EI mecanismo para la creacin y actualizacin de prcticas y estndares est documentado y es conocido en el rea. X

Estn definidas las prcticas de anlisis y diseo, e incluye las tcnicas y herramientas a usar. As como tambin hay una gua o prcticas de programacin para cada uno de los lenguajes homologados X

Hay

un

estndar

general

para

toda

la X

documentacin generada, incluyendo documentacin tcnica (anlisis, diseo, documentacin de los

programas), manuales de usuario, etc.

OG4-C4: Debe existir un procedimiento de monitorizacin y medicin del cumplimiento de estndares y prcticas de calidad as como de los de desarrollo y mantenimiento. X Se realizan informes ejecutivos peridicamente sobre la calidad de los SI en el rea. Estn definidas mtricas de calidad y stas estn alineadas con los objetivos de calidad del rea y ayudan en la consecucin de los objetivos del rea. X

Se realizan inspecciones en los hitos de los proyectos para verificar el cumplimiento de los estndares y prcticas. OG4-C5: Debe practicarse la reutilizacin del software. Existe un repositorio con todos los productos software susceptibles de ser reutilizados: libreras de funciones, clases de objetos, componentes software, documentos arquitecturas). EI repositorio o catlogo es conocido y accesible por todos los miembros del rea, esta actualizado y tiene uno o varios ndices que faciliten la X (catlogo de requisitos comunes, X X

bsqueda. OG4-C6: Debe existir un modelo de la arquitectura de informacin que se actualice regularmente y defina los sistemas apropiados que optimicen el uso de la informacin.

Existe un diccionario de datos institucional con las reglas de sintaxis de la organizacin, el esquema de clasificacin de datos y sus niveles de seguridad correspondientes. Se garantiza la consistencia y seguridad de la informacin de los SI con los recursos proporcionales y dicha informacin se alinea con la estrategia y objetivos de la institucin. OG4-C7: Los lenguajes, compiladores, software de pruebas, software de control de versiones; utilizados en el rea deben ser previamente vlidos. Existe un mecanismo para la adquisicin y validacin de cualquier nuevo producto software usado en el desarrollo. Se deben evaluar al menos los siguientes parmetros: productividad, portabilidad a otros entonos, transicin desde los productos actuales, riesgo de cambio, cumplimiento de los estndares del rea, compatibilidad con el entorno tecnolgico, costos, entre otros. X X X

Cuando se valida un nuevo producto de desarrollo se forma al personal del rea que lo vaya a manejar. Se registra la informacin ms importante acerca de la configuracin de los productos recin adquiridos. X X

4.13 DE PROYECTOS DE DESARROLLO Y MANTENIMIENTO 4.13.1 Auditora de la gestin y planificacin del proyecto S N Observaci I O ones 4.13.2 Objetivo de Control P1: El proyecto de desarrollo debe estar aprobado, definido y planificado formalmente. P1-C1: Debe existir documento de aprobacin del proyecto que defina claramente los objetivos, restricciones y las reas afectadas.

Existe algn documento de aprobacin del proyecto autorizada por algn rgano competente. En el documento de aprobacin estn definidos de forma ciara y precisa los objetivos del mismo y las restricciones de todo tipo que deben tenerse en cuenta (recursos tcnicos y humanos, presupuesto, entre

otros.) y su alineacin con el plan estratgico.

Se

han

identificado

las

unidades

de

la organizacin a las que afecta. P1-C2: Debe designarse un responsable o director del proyecto. La designacin se ha llevado a cabo segn el procedimiento establecido. Se le ha comunicado al director su designacin junto con toda la informacin relevante del proyecto. X X

P1-C3: El proyecto debe ser catalogado en funcin de sus caractersticas, se debe determinar el modelo de ciclo de vida que seguir. Se ha descrito y dimensionado el proyecto segn las normas establecidas. Se han evaluado los riesgos asociados al proyecto, especialmente cuando se van a usar X X

tecnologas no usadas hasta el momento. Se ha elegido el ciclo de vida ms adecuado al tipo de proyecto. Se ha hecho uso de la informacin histrica que se dispone tanto para dimensionar el proyecto y sus riesgos como para seleccionar el ciclo de vida. P1-C4: Una vez determinado el ciclo de vida a seguir, se debe elegir el equipo tcnico que realizar el proyecto y se determinar el plan del proyecto. La designacin del equipo de desarrollo se ha llevado a cabo segn el procedimiento establecido. X X X

Se ha comunicado a todos los miembros del staff de desarrollo los objetivos del proyecto, la X

responsabilidad que tendrn en el mismo, las fechas en las participaran y la dedicacin completa o parcial.

EI plan de proyecto realizado es realista y utiliza la informacin histrica de la que se disponga para realizar estimaciones. X

4.13.3 Objetivo de Control P2: El proyecto se debe gestionar de forma que se consigan los mejores resultados posibles teniendo en cuenta las restricciones de tiempo y recursos. P2-C1: Los responsables de las areas afectadas por el proyecto deben participar en la gestin del proyecto. Se ha constituido formalmente el comit de direccin del proyecto y estn incluidos los X

responsables de todas las unidades afectadas. EI comit tiene una periodicidad de

reunin mnima, y en cualquier caso siempre que lo exija el desarrollo del proyecto, debe tener competencia para asignacin de recursos, la revisin de la marcha del proyecto y para modificar el plan del proyecto en funcin de las revisiones. Las reuniones se hacen con un orden del da previo y las decisiones tomadas quedan X X

documentadas en las actas de dicho comit. EI nmero de reuniones y la duracin de las mismas no superan un lmite razonable comparado con la envergadura del proyecto. P2-C2: Se debe establecer un mecanismo para la resolucin de los problemas que pueden surgir a lo largo del proyecto. X

Existen hojas de registro de problemas y hay alguna persona del proyecto encargada de su recepcin, as como un procedimiento conocido de tramitacin. X

Existe un mtodo para catalogar y dar prioridad a los problemas, as como para trasladarlos a la persona que de los debe resolver, informando si es necesario al director del proyecto y al comit de direccin. X

Se controla la solucin del problema y se deja constancia del mismo.

P2-C3: Debe existir un control de cambios a lo largo del proyecto. Existe un mecanismo para registrar los cambios que pudieran producirse, as como para evaluar el impacto de los mismos. La documentacin afectada se actualiza de forma adecuada y se !leva un control de versiones de cada producto, consignando la ltima fecha de actualizacin. Se remite la nueva versin de los documentos actualizados a los participantes en el proyecto. P2-C4: Cuando sea necesario reajustar el plan del proyecto, normalmente en un hito al finalizar una fase, debe hacerse de forma adecuada. Se respetan los lmites temporales y X X X X

presupuestarios marcados al inicio del proyecto. Si no es as debe ser aprobado por el comit de direccin.

Se ha tenido en cuenta los riesgos del reajuste. Se ha hecho uso de la informacin histrica que se dispone en el rea sobre estimaciones. Se notifica el cambio a todas las personas que participen en el proyecto y se ven afectados. X

P2-C5: Debe hacerse un seguimiento de los tiempos utilizados tanto por tarea como a lo largo del proyecto Existe algn procedimiento que permite registrar el tiempo que dedica y qu tarea realiza cada X Existe algn procedimiento para analizar participante. las desviaciones y proponer acciones correctivas. P2-C6: Se debe controlar que se sigan las etapas del ciclo de vida adoptado para el proyecto y que se generan todos los documentos asociados a la metodologa usada. Antes de comenzar una nueva etapa, se ha documentado la etapa previa y se ha revisado y aceptado, especialmente en las fases de anlisis y diseo. X X

La documentacin cumple los estndares y procedimientos establecidos en el rea. Se respeta el uso de recursos previamente establecido. X

P2-C7: Cuando termina el proyecto se debe cerrar toda la documentacin del mismo, liberar los recursos utilizados y hacer balance. La documentacin del proyecto es completa y est catalogada perfectamente para accesos posteriores. X X

Los recursos, tanto personales como materiales, se ponen a disposicin del rea del que provienen. El comit de direccin y el director del proyecto hacen balance del proyecto, estudiando los

posibles problemas y sus causas, los cambios del plan. Toda esta informacin se registra en los archivos histricos sobre estimaciones y problemas.

4.14 FASE DE ESTUDIO DE VIABILIDAD I S O N ones Observaci

4.14.1 Objetivo de Control V1: Antes de la definicin del proyecto deben estudiarse los requisitos, situacin actual, identificando seguidamente las alternativas de solucin y seleccionando aquella que satisfaga ms eficaz y eficientemente los requisitos identificados.

V1-C1: Debe haberse establecido el alcance de las iniciativas requeridas para satisfacer las necesidades planteadas por el usuario. Existe un documento que recoge la descripcin general de la necesidad planteada por el usuario y los objetivos generales as como las posibles restricciones tcnicas, operativas y econmicas. Se han determinado formalmente el grupo de usuarios que participar en el proyecto, identificndose sus perfiles y dejando claras sus tareas y X X

responsabilidades. V1-C2: Debe estudiarse la situacin actual y determinar los sistemas afectados. Se han realizado modelos del sistema. Se ha realizado un diagnstico de la situacin actual. V1-C3: Los usuarios y responsables de las unidades que afecta el nuevo sistema establecern de forma clara los requisitos del mismo. Se ha realizado un plan detallado de entrevistas con el grupo de usuarios y con los responsables de las unidades afectadas que permita conocer cmo valoran el sistema actual y lo que esperan del nuevo sistema. X X X

Existe un catlogo de requisitos. Cada requisito tiene una prioridad y est clasificado en funcional y no funcional. EI catlogo de requisitos ha sido revisado y aprobado por el grupo de usuario y los responsables as como por el comit de direccin. X X

4.15 FASE DE ANLISIS

4.15.1 Objetivo de Control A1: Se debe elaborar una especificacin detallada que A1-C1: Debe realizarse un plan detallado de sesiones de trabajo con el grupo de usuarios permita describir con precisin el sistema de informacin. del proyecto y los responsables de las unidades afectadas para recopilar la informacin necesaria. Las tcnicas que se utilizan para la recopilacin de informacin es la adecuada en funcin de las caractersticas del proyecto y los tipos de usuario a entrevistar. Se remite el guin a los entrevistados con tiempo suficiente para que estos puedan preparar la entrevista y la documentacin que deseen aportar a la misma. Y el guin incluye todas las cuestiones necesarias para obtener la informacin sobre las funciones deseadas y problemas que se quieren resolver. X X

A1-C2: A partir de la informacin obtenida de las entrevistas se debe realizar la descripcin inicial del SI y obtener el catlogo de requisitos detallado del mismo. Existe un catlogo de requisitos, estos estn justificados y detallados. Cada requisito tiene una prioridad y estn clasificados en funcionales y no funcionales. La especificacin del sistema incluye los requisitos no funcionales: de seguridad, rendimiento, disponibilidad, formacin. A1-C3: Se estructura el sistema de informacin en subsistemas de anlisis, para facilitar la especificacin de los distintos modelos y la traza de requisitos. La desintegracin de los subsistemas est orientada a los procesos del sistema. Se han asignado los requisitos a cada uno de los subsistemas identificados, y consecuentemente X X X X X

actualizado el catlogo de requisitos. A1-C4: Se debe realizar el modelo del sistema que sirva de base para el diseo. En el caso de anlisis estructurado, mediante la elaboracin y descripcin detallada del modelo de datos y de procesos. Y en el caso de un anlisis orientado a objetos a travs del modelo de clases y el de interaccin de objetos, mediante el anlisis de los

casos de uso.

Los modelos son correctos tcnicamente y se han realizado con la tcnica adecuada. Existe un diccionario de datos o repositorio, es correcto y se gestiona de forma de automatizada, respetndose todos los procedimientos de gestin de cambios.

A1-C5: Se deben especificar todas las interfaces entre el sistema y el usuario, tales como formatos de pantallas, dilogos, formatos de informes y formularios de entrada. Se han descrito con suficiente detalle las interfaces: pantallas a travs de las cuales el usuario navegar por la aplicacin, incluyendo todos los campos significativos, mens, botones, etc.; as como informes y formularios asociados si existen. Si hay normas de diseo o estilo de pantallas, informes, formularios, etc. en el rea, se verificar que se respetan. X

La interfaz de usuario se ha aprobado por el grupo de usuarios y por el comit de direccin.

A1-C6: Debe especificarse el plan de pruebas que el nuevo sistema debe superar para ser aceptado. Se han definido los requisitos del entono de pruebas y el alcance de las pruebas. Se ha elaborado el plan de pruebas de aceptacin del sistema, ste es coherente con el catlogo de requisitos y con la especificacin funcional del sistema. X X

4.15.2 Objetivo de Control A2: Se debe garantizar la calidad de los distintos modelos generados en el proceso de anlisis del SI, y asegurar que los usuarios y los analistas tienen el mismo concepto del sistema.

A2-C1: Se debe de verificar la calidad tcnica de cada modelo y asegurar la coherencia entre los distintos modelos. La calidad formal de los distintos modelos, comprobando si son conforme a la tcnica seguida para la elaboracin de cada producto y a las X

normas determinadas en el catlogo de normas. Se ha realizado una validacin de los distintos X de informacin, tanto a travs del catlogo de requisitos, A2-C2: Debe realizarse una validacin formal de la especificacin de requisitos y de los modelos della anlisis del requisitos, sistema. como a travs de la mediante traza de validacin directa del usuario. Los usuarios ratifican que los requisitos X modelos con los requisitos especificados para el sistema

especificados en el catlogo de requisitos, as como los casos de uso son vlidos, consistentes y completos.

Cualquier peticin de cambio en los requisitos que pueda surgir posteriormente deben ser evaluada y aprobada. La actualizacin del plan de proyecto seguir los criterios, detallndose en este punto en mayor medida la entrega y transicin al nuevo sistema. X X

4.16 FASE DE DISEO 4.16.1 Objetivo de Control D1: Se debe definir una arquitectura del sistema que sea coherente con la especificacin funcional que se tenga y con el entorno tecnolgico. D1-C1: organizacin en subsistemas de diseo, la especificacin del entono tecnolgico, requisitos de operacin, administracin, seguridad y control de acceso deben estar definidos de forma clara y ser conformes a los estndares y normas del centro de informacin y sistemas. Estn diferenciados y definidos los subsistemas especficos del sistema de informacin (en adelante, subsistemas especficos) y los subsistemas de soporte. X

Estn definidos todos los elementos que configuran el entorno tecnolgico (servidores, PC, perifricos, conexiones de red, sistemas gestores de bases de datos) junto con su planificacin de capacidades y sus requisitos de operacin, administracin, seguridad y control de acceso. X

Existe un catlogo de excepciones, de requisitos, normas y estndares originados como consecuencia de la adopcin de una determinada solucin de arquitectura o infraestructura. X X

Los elementos seleccionados estn dentro de los estndares del rea y son capaces de responder a los requisitos establecidos de volmenes, tiempos de respuesta, seguridad.

D1-C2: Se debe realizar un diseo detallado de los subsistemas de soporte y del sistema de informacin especfico. Se han identificado los mecanismos genricos de diseo, as como las libreras y clases reutilizables. EI tamao de los mdulos o clases es adecuado y el factor de acoplamiento entre ellos es mnimo y la cohesin interna es mxima. Los mdulos o clases, se disean para poder ser reutilizados en el futuro por otros SI. D1-C3: Se debe disear la estructura de datos adaptando las especificaciones del sistema al entorno tecnolgico. X X X

EI

modelo de datos tiene en cuenta el X

entorno tecnolgico y los requisitos de rendimiento para los volmenes y frecuencias de acceso estimados, migracin de datos.

4.16.2 Objetivo de Control D2: Se deben generar todas las especificaciones necesarias para la construccin del sistema de informacin: D2-C1: Se deben generar unas especificaciones de construccin. Se han fijado formalmente las directrices para la construccin de los componentes del sistema, as como de las estructuras de datos. D2-C2: Se debe especificar el procedimiento de migracin y carga inicial de datos as como los requisitos de operacin. Se definen los procedimientos de migracin y sus componentes asociados, con las especificaciones de construccin oportunas. X X

Se definen los requisitos relativos a la propia formacin del sistema en el entorno de operacin y X aquellos relacionados con la documentacin que el D2-C3: Debe realizarse la especificacin tcnica del plan de pruebas. usuario requiere para operar con el nuevo sistema. Existe el plan de pruebas y contempla todos los recursos necesarios para llevarlas a efecto. Es adecuado para validar cada uno de los componentes del sistema, incluyendo pruebas de caja blanca. Tendrn en cuenta las posibles condiciones lgicas de ejecucin, adems de posibles fallos del hardware o software de base y ataques de seguridad. X X

Permite validar la integracin de los distintos componentes y el sistema en conjunto.

D2-C4: Se debe realizar una aprobacin formal del diseo del sistema.

Se realiza la presentacin del diseo al comit de direccin y se registra la aprobacin del mismo. Se actualiza el plan de proyecto segn los criterios de direccin y se registra la aprobacin del mismo. 4.17 FASE DE CONSTRUCCIN

4.17.1 Objetivo de Control CS-1: Los componentes que se desarrollen deben utilizar tcnicas de programacin correctas CS1-C1: Se debe preparar adecuadamente el entorno de desarrollo y de pruebas, as como los procedimientos de operacin y seguridad. Se han creado e inicializado las bases de datos o ficheros necesarios y cumplen las especificaciones de construccin del sistema obtenidas en la fase de diseo. Se han preparado los editores, compiladores, herramientas necesarias y estn disponibles puestos de trabajo. Se han preparado los procedimientos de copia de seguridad y restauracin. X los X X

Estn disponibles todos los elementos lgicos y fsicos para realizar las pruebas unitarias y de integracin. Estn documentados todos los procedimientos de operacin, seguridad y control de acceso al SI para cuando el sistema este en explotacin. Y estos procedimientos cuenta los estndares y normas cada uno de los componentes CS1-C2: Se tienen debe en programar, probar y documentar X identificados en el diseo sistema. recogidos previamente del departamento de del informtica, en el catlogo de normas y estndares. Se han desarrollado todos los componentes y se han seguido los estndares, normas de programacin y documentacin documentado). del rea (cdigo comentado y X X

Se ha probado cada componente de forma unitaria siguiendo el plan de pruebas y se ha generado el informe de prueba. Se ha realizado la codificacin, prueba de los componentes y procedimientos de migracin y carga inicial de datos.

CS1-C3: Deben realizarse las pruebas de integracin para verificar si los subsistemas interactan correctamente a travs de sus interfaces, tanto internas como externas, cubren la funcionalidad establecida y se ajustan a los requisitos especificados en las verificaciones correspondientes. Se han llevado a cabo y realizado un informe segn lo especificado en el plan de pruebas. Se han evaluado las pruebas y se han tomado las acciones correctoras necesarias para solventar las incidencias encontradas, actualizndose el proyecto en consecuencia. CS1-C4: Deben realizarse las pruebas de sistema para comprobar la integracin del sistema de informacin globalmente. Las correcto de pruebas las verifican el entre funcionamiento los distintos X X

interfaces

subsistemas que lo componen y con el resto de sistemas de informacin con los que se comunica, as como el cumplimiento de la especificacin de requisitos, de acuerdo a las verificaciones establecidas en el plan de pruebas para el nivel de pruebas del sistema. X

Se ha generado un informe de pruebas de sistema y se han evaluado las pruebas y tomndose las acciones correctoras necesarias para solventar las incidencias encontradas, actualizndose el proyecto en consecuencia. No han participado los usuarios, solo particip el equipo de desarrollo. X X

4.17.2 Objetivo de Control CS-2: Los proyectos de desarrollo deben definir los procedimientos y formacin necesarios para que los usuarios puedan utilizar el nuevo sistema adecuadamente. CS2-C1: El desarrollo de los componentes de usuarios debe estar planificado. En el plan de proyecto, est incluido el plan para el desarrollo de los procedimientos de usuario e incluye todas las actividades y recursos necesarios. X

Los procedimientos se han realizado despus de la especificacin del SI y antes de su formacin.

CS2-C2: Se deben especificar los perfiles de usuario requeridos para el nuevo sistema. Estn definidos los distintos perfiles de usuario requeridos para la formacin y explotacin del nuevo sistema. Para cada perfil se ha definido el rango de fechas y la dedicacin necesaria CS2-C3: Se deben desarrollar todos los procedimientos de usuario siguiendo los estndares del rea. Estn desarrollados todos los procedimientos de usuario, recopilados formando el manual de usuario, y son coherentes con las actividades descritas en la especificacin del sistema. Los manuales de usuario y el resto de procedimientos cumplen los estndares del rea y llevan asociado su control de versiones. X X X X

4.18 FASE DE IMPLANTACIN Y ACEPTACIN. 4.18.1 Objetivo de Control IA-1: El sistema debe ser aceptado formalmente por los usuarios antes de ser puesto en explotacin. IA1-C1: El plan de formacin y aceptacin se debe revisar para adaptarlo a la situacin final del proyecto.

Se revisa el plan de formacin original y se documenta adecuadamente. Se establece un plan de formacin con la implantacin necesaria para el equipo de formacin, en funcin de los distintos perfiles y niveles responsabilidad identificados y de

se cuenta con la

infraestructura y recursos humanos para llevarla a cabo.

Est incluida la instalacin de todos los componentes desarrollados, as como los elementos adicionales (formacin, libreras, utilidades). X

IA1-C2: Se deben realizar las pruebas de formacin y aceptacin del sistema que se especificaron en fases anteriores. Se prepara el entorno real de operacin y los recursos necesarios para realizar las pruebas Las pruebas de formacin del sistema X

participan los usuarios y con ellas se verifica si el SI cumple las especificaciones funcionales as como detalles de diseo interno, como interacta X

correctamente con el entorno. Se han evaluado los resultados de las pruebas y se han tornado las acciones correctoras IA1-C4: El sistema ser aprobado formalmente antes de ponerse en explotacin. necesarias para debe solventar las incidencias encontradas, actualizndose el proyecto en consecuencia. X Se ha realizado las pruebas de formacin y aceptacin. Se ha fijado el acuerdo de nivel de servicio. El grupo de usuarios y el comit de direccin firman su conformidad. X X X

4.18.2 Objetivo de Control IA-2: El sistema se pondr en explotacin formalmente y pasar a estar en mantenimiento slo cuando haya sido aceptado y est preparado todo el entorno el que se ejecutar. IA2-C1: Se deben instalar todos los procedimientos de explotacin. Se han instalado adems del sistema principal todos los procedimientos auxiliares, como copias, recuperacin, etc., tanto manual como automtico. Estn documentados de forma correcta. Los usuarios finales han recibido la formacin necesaria y tienen en su poder toda la documentacin necesaria, fundamentalmente manuales de usuario. X X X

Se han eliminado procedimientos antiguos que sean incompatibles con el nuevo sistema.

IA2-C2: Si existe un sistema antiguo, el sistema nuevo se pondr en explotacin de forma coordina con la retirada del antiguo, migrando los datos si es necesario. Hay un periodo de funcionamiento en paralelo de los dos sistemas, hasta que el nuevo sistema este funcionando con todas las garantas. Esta situacin no debe prolongarse ms tiempo del necesario. X

Los

datos

se

convierten

de

acuerdo

al procedimiento desarrollado y se

verifica la

consistencia de la informacin entre el sistema IA2-C4: Para terminar el proyecto se pondr en marcha el mecanismo de mantenimiento. nuevo y et antiguo. EI mecanismo existe y est aprobado por el director de proyecto, por el comit de direccin y por el rea de desarrollo y mantenimiento. Tiene en cuenta los tiempos de respuesta mximos que se pueden permitir ante situaciones de no funcionamiento. X X

EI procedimiento a seguir ante cualquier problema o para el mantenimiento del sistema ser conocido por todos los usuarios. X

4.19 FASE DE MANTENIMIENTO 4.19.1 Objetivo de Control M-1: La gestin del proceso de mantenimiento de sistemas de informacin debe ser eficiente y eficaz para conseguir mantener el coste del mantenimiento de los SI del rea bajo control. M1-C1: Debe existir una estrategia y un plan para la gestin del mantenimiento de los SI del rea y de infraestructura tecnolgica. El plan existe y est aprobado por la direccin del rea y se revisa peridicamente. EI plan acordado es compatible con el proceso de gestin de cambios y de problemas. Existe un procedimiento definido y acordado por todas las reas participantes en el plan de mantenimiento a fin de facilitar que la gestin de los cambios o ejecucin de las peticiones de mantenimiento as como gestin de los problemas de los SI se haga de una manera eficaz y eficientemente. X X X

4.19.2 Objetivo de Control M-2: Todos los cambios, ya sean incidentes, problemas o peticiones de mantenimiento, incluido el mantenimiento correctivo de emergencia o cambios relacionados con la infraestructura tecnol6gica del entorno de produccin, deben de ser gestionados formalmente y de una manera controlada a fin de asegurar la mitigacin del riesgo debido a los impactos negativos en la estabilidad e integridad del SI en produccin. M2-C1: Se debe establecer un sistema estandarizado de registro de informacin para las peticiones de mantenimiento, con el fin de controlar y canalizar los cambios propuestos por un usuario, mejorando el flujo de trabajo y proporcionando una gestin efectiva del mantenimiento.

Existe

un

catlogo

de

problemas

de X

peticiones de mantenimiento sobre los sistemas de informacin. Todas las peticiones de mantenimiento son presentadas de una forma estandarizada, para permitir su clasificacin y facilitar la identificacin del tipo de mantenimiento requerido. En cada peticin de cambio se recoge al menos la identificacin, origen y tipo de peticin, se le asigna una prioridad inicial y se le incorpora una descripcin, lo ms precisa posible, que facilite su posterior anlisis. Para cada peticin de mantenimiento aceptada se determina de quien es la responsabilidad de atender la solicitud para proceder a su estudio posterior, es decir, se le asigna un responsable de mantenimiento. X

M2-C2: Se debe llevar a cabo un diagnstico y anlisis del cambio para dar respuesta a las peticiones de mantenimiento que son aceptadas. La informacin registrada es la correcta. Si se trata de una peticin de mantenimiento correctivo, se evala hasta qu punto es crtico el X

problema. Si el problema es crtico, su anlisis y solucin comienza inmediatamente con el fin de reanudar rpidamente el nivel de servicio. Y el procedimiento de actuacin establecido no exime de una revisin posterior del problema para valorar los posibles efectos secundarios, establecer una solucin definitiva y actualizar todos los productos implicados y su X

documentacin. M2-C3: Se realiza el seguimiento de los cambios que se estn llevando a cabo en los procesos de desarrollo, de acuerdo a los puntos de control del ciclo de vida del cambio establecidos previamente.

Slo se han modificado los elementos que se ven afectados por el cambio y que se han realizado las pruebas correspondientes, especialmente las pruebas de integracin y del sistema. Se realiza un informe de la evaluacin del cambio para su posterior aprobacin. Se realizan las pruebas de regresin que especificadas en la actividad anterior, comprobando que ningn sistema de verse no modificado, ha pero variado con su X X X

posibilidades

afectado,

comportamiento habitual. La aprobacin de la peticin se realiza al finalizar las pruebas de regresin, y despus de comprobar que todo lo que ha sido modificado o puede verse afectado por el cambio, funciona correctamente. X

MATRIZ DE PRUEBAS DE SISTEMAS COMPUTARIZADOS

I. Nombre del Sistema: rea responsable del sistema:

DATOS GENERALES. Pruebas de Reforma Fiscal 2010 para los procesos de Ventas, Facturacin y CxC Servicio a Clientes, CxC, Comercio Exterior, Impuestos, Contabilidad N/ A B N egocio

Identificador de la prueba: Tipo de sistema:

Px

Realiz las pruebas IT: Nombre Edgar Espinosa Puesto Lder de Proyecto Revis las pruebas IT: Nombre Lourdes Del ngel Puesto Gerente ERP SC Usuario solicitante del desarrollo modificacin del sistema: Nombre Fernando Garca Puesto Gerente de Proyectos Corporativos Firma Fecha Firma Fecha Firma Fecha

Usuarios de reas involucradas: Si en las pruebas participa un proveedor externo, utilizar el campo de Puesto para identificar la compaa a la que pertenece. Rol en la prueba: Representante de Servicio a Clientes Nombre Antonio Vidal Puesto Coordinador de Servicio a Clientes Firma Fecha

Rol en la prueba: Representante de CxC Nombre Luis Fernando Ramrez Puesto Jefe de Crdito y Cobranza Fecha Rol en la prueba: Representante de Comercio Exterior Nombre Ericka Gamboa Puesto Administradora de Trfico Rol en la prueba: Representante de Impuestos Nombre Guadalupe Gmez Puesto Analista de Impuestos Rol en la prueba: Representante de Contabilidad Nombre Erika Martnez Puesto Contador II. INSTRUCCIONES DE LA PRUEBA: 1. Involucrar a personal de todas las reas que se vean afectadas por el sistema a ser probado. 2. Definir los casos de prueba a retar y llenar un documento por cada caso. 3. Definir el tipo de pruebas a realizar dependiendo del tipo de sistema, as como de si es nuevo se est probando slo una modificacin. 4. Preparar la informacin (datos, documentos software) necesarios para la realizacin de la prueba. 5. Llenar la matriz de pruebas, no se permiten OK palomitas, sino la explicacin completa. 6. Anexar documentos de soporte tales como impresin de pantallas y reportes, conservando las anotaciones manuales originales. 7. Anotar las conclusiones de la prueba, indicando las acciones a realizar de acuerdo al resultado obtenido. Firma Fecha Firma Fecha Firma

Firma

Fecha

III.

PREPARACIN PARA LA PRUEBA.

1. Caso de prueba: Definir el caso de a ser retado

Proce sos: Order To Cash

2. Tipo de prueba: Pruebas Unitarias: Se verifica la implementacin del diseo de un solo elemento o grupo de elementos. Pruebas de integracin: Progresin ordenada de pruebas

Especificar qu tipo de prueba se llevar a cabo, considerando una opcin de cada columna, pues se deben realizar de manera combinada: Nota: Las pruebas estructurales slo se combinan con pruebas unitarias

para verificar el funcionamiento combinado del Sw y Hw para evaluar su interaccin. Pruebas del sistema: Se verificar que el sistema en su conjunto (Sw, Hw e interfaces) funciona de acuerdo a los RU en ambiente de produccin. Pruebas Estructurales: Se basan en la codificacin de los programas, se revisan las estructuras de decisin y estructuras de datos 3. Pre-requisitos de internas de los programas. la prueba: Pruebas Funcionales: Proceso de evaluacin del sw al final de su ciclo de desarrollo. Para realizar pruebas estructurales se requieren las Especificaciones de diseo (ED), mientras que para las pruebas funcionales se requieren las Especificaciones funcionales (EF). En el caso de las pruebas del sistema se requieren los Requerimientos de usuario (RU). Para el caso de cambios menores a un sistema, tomar los requerimientos de usuario de la Solicitud de servicio a Informtica (SSI) Indicar si se utilizar un software auxiliar, as como los datos que deben ser preparados.

Pruebas Unitarias Pruebas de integracin Pruebas del sistema

Pruebas Estructurales (caja blanca) Pruebas Funcionales (caja negra)

Especificaciones de diseo Especificaciones funcionales Requerimientos de usuario Software: BPCS, Buzon-e Datos: Datos del ambiente de pruebas.

SSI Otro

IV.

MATRIZ DE PRUEBAS. A. IMPUESTOS

Mdulo / Programa TA X Guadalupe Gmez cdigos

Descripcin atos Entra da Creacin de nuevos IVA de 16% Factor de

D S ado alida Creacin del nuevo cdigo de impuesto

Re sultado Esper ido

Refe Obten rencia I mp Anexo I

B. FACTURACIN FINANCIERA

El sistema debe calcular el impuesto de acuerdo al nuevo factor

Mdulo / Programa ORD 7001 L uis F. Ramrez B IL560D Luis F. Ramrez

Descripcin atos Entra da Elaborar facturas financieras para las compaa 01, 12, 31, 42 y 51 con los ITEMS Designados con IVA 0 %, IVA 16 % y combinacin Generacin de con ambos impuestos facturas financieras para las compaa 01, 12, 31, 42 y 51 Ingreso de datos para elaboracin de orden y verificar calculo del 16 % del IVA Ingresar No. De Orden para genera facturas

D S alida Genera cin de Orden para facturacin

Re sultado Esper ado ido Genera cin de Orden para facturacin

Refe Obten rencia F acFin Anexo I

Generacin de la factura, verificando su envo a BUZON E y su registro en la cartera Verificar la generacin de la

ON E

Generacin del BUZ documento fiscal

Ingres ar datos del la orden

Generaci n de la factura, verificando su envo a BUZON E y su registro en la cartera Verificar la generacin de la

F acFin Anexo I

F acFin Anexo I

L uis F. Ramrez ORD 7001 L uis F. Ramrez B IL560D Luis F. Ramrez Elaborar Notas de Cargo financieras para las compaa 01, 12, 31, 42 y 51 con los ITEMS Designados con IVA 0 Generacin de las IVA 16 % y notas de%, cargo financieras combinacin con para las compaaambos 01, 12, 31, impuestos 42 y 51 Generacin del documento fiscal Ingreso de datos para elaboracin de orden y verificar clculo del 16 % del IVA Ingresar No. De Orden para generar nota de cargo Ingresar datos de la orden

factura fiscal fiscal

factura F

Genera cin de Orden para facturacin Generaci n de la Nota de cargo, verificando su envo a BUZON E y su registro en la cartera Verificar la generacin de la Nota de cargo

Genera cin de Orden para facturacin Generaci n de la Nota de cargo, verificando su envo a BUZON E y su registro en la cartera Verificar la generacin de la Nota de cargo

acFin Anexo II

F acFin Anexo II F acFin Anexo II F

B UZON E Luis F. Ramrez ORD 7001 L uis F. Ramrez B IL560D Luis F. rez Ram

Elaborar Notas de Credito financieras para las compaa 01, 12, 31, 42 y 51 con los ITEMS Designados con IVA 0 Generacin de las IVA 16 %y notas de%, crdito financieras combinacin con ambos para las compaa 01, 12, 31, impuestos 42 y 51

Ingreso de datos para elaboracin de orden y verificar clculo del 16 % del IVA Ingresar No. De Orden para generar nota de cargo

Genera cin de Orden para facturacin

Genera cin de Orden para facturacin

acFin Anexo III

F Generaci n de la Nota de crdito, verificando su envo a BUZON E y su registro Verificar en la la cartera Generaci n de la Nota de crdito, verificando su envo a BUZON E y su registro Verificar en la cartera la acFin Anexo III

F acFin Anexo III

Generacin del documento

Ingresar datos

fiscal B UZON E Luis F. Ramrez ACR Aplicar pago a los 500D1 documentos originados en el Anexo I L uis F. Ramrez ACR 500D1 L uis F. Ramrez ACR 500D1 L uis F. Ramrez Revisar que las rdenes B IX@ Luis F. Ramrez de ( TMA y CMA ) que caigan en automtico en ORD generadas por BIX@ Aplicar pago a los documentos originados en el Anexo III Aplicar pago a los documentos originados en el Anexo II

de la orden Captura del pago de los documentos originados en el Anexo I Captura del pago de los documentos originados en el Anexo I Captura del pago de los documentos originados en el Anexo I Verificar que coincidan las ordenes generadas con la factura proforma/factura de Alemania Ingreso de datos para elaboracin de orden y verificar calculo de la crdito

generacin de la Nota de crdito Verificar que el pago se registre correctamente en la cuenta del cliente ACR300, as como en contabilidad CEA Verificar que el pago se registre correctamente en la cuenta del cliente ACR300, as como en contabilidad CEA Verificar que el pago se registre correctamente en la cuenta del cliente ACR300, as como en contabilidad CEA Verificar que coincidan las ordenes generadas con la factura proforma/factura de Alemania para su generacin en ORD 700 Genera cin de Orden para facturacin

generacin Nota de Verificar que el pago se registre correctamente en la cuenta del cliente ACR300, as como en contabilidad CEA Verificar que el pago se registre correctamente en la cuenta del cliente ACR300, as como en contabilidad CEA Verificar que el pago se registre correctamente en la cuenta del cliente ACR300, as como en contabilidad CEA Verificar que coincidan las ordenes generadas con la factura proforma/factura de Alemania para su generacin en ORD 700 Genera cin de Orden para facturacin F acFin Anexo IV

F acFin Anexo IV

F acFin Anexo IV

F acFin Anexo V

Elaborar facturas ORD financieras ( TMA/CMA ) para las compaa 01 y 12 con 7001 con IVA L 0 %, IVA 16 % y uis F. combinacin Ramrez

F acFin Anexo V

B IL560D Luis F. Ramrez

con ambos impuestos (BIP- BIIPE TMA IVA16% en automtico )/( BIIPE-BIM TMA nota de cargo con formato de factura )/ (BIPBIM CMA ) Generacin de facturas financieras para las compaa 01, 12,

del 16 % del IVA

F Ingresar No. De Orden para genera facturas Generacin de la factura, verificando su envo a BUZON E y su registro en la cartera Verificar la generacin de la factura fiscal Verificar que el pago se registre correctamente en la cuenta del cliente ACR300, as como en contabilidad CEA Generaci n de la factura, verificando su envo a BUZON E y su registro en la cartera Verificar la generacin de la factura fiscal Verificar que el pago se registre correctamente en la cuenta del cliente ACR300, as como en contabilidad CEA acFin Anexo V

F acFin Anexo V F acFin Anexo VI

Generacin del B documento fiscal y dar aviso a UZON E Contabilidad de las facturas Luis F. generadas para su registro en el Ramrez Bil Log ACR Aplicar pago a los 500D1 documentos originados en el Anexo V L uis F. Ramrez

Ingres ar datos del la orden Captura del pago de los documentos originados en el Anexo I

c. FACTURACIN DE PRODUCTO

Mdulo / Programa O RD Antoni o Vidal ORD Antoni o Vidal

Descripcin Se ingresa el pedido de Co. 51 Con productos con IVA 16 Se aparta el producto de los pedidos

D atos Entra S da Datos del alida Pedido pedido ingresado Inte rvalo de pedidos Inte rvalo de pedidos Inte rvalo de pedidos Inte rvalo de pedidos Datos del pedido Inte rvalo de pedidos Inte rvalo de pedidos Producto apartado

Re sultado Esper ado Pedido ido ingresado satisfactoriament e Produ cto apartado correctamente Pedid os en estatus 01000 Pedid os en estatus 00100 Pedido s facturados y en status 00001 Pedido ingresado satisfactoriament e Produ cto apartado correctamente Pedid os en estatus 01000

Refe Obten rencia Fa cProd Anexo I Fa cProd Anexo II Fa cProd Anexo III Fa cProd Anexo IV Fa cProd Anexo V Fa cProd Anexo VI Fa cProd Anexo VII cProd Anexo VIII Fa

Se realiza Pick Release O RD Antoni o Vidal O RD Antoni o Vidal B IL Antoni o Vidal O RD Antoni o Vidal ORD Antoni o Vidal O RD Antoni o Se ingresa el pedido de Co. 51 Con productos con IVA 16 y productos sin IVA Se aparta el producto de los pedidos Se realiza Pick Release

Pedidos en estatus 01000 Pedidos en estatus 00100 Pedidos facturados y en status 00001 Pedido ingresado Producto apartado Pedidos en estatus 01000

Se realiza Pick Confirm

Se factura

Vidal Se realiza Pick Confirm O RD Antoni o Vidal B IL Antoni o Vidal O RD Antoni o Vidal ORD Antoni o Vidal Co. 51 Con productos sin IVA Se aparta el producto de los pedidos Inte rvalo de pedidos Inte rvalo de pedidos Inte rvalo de pedidos Producto apartado Se ingresa el pedido de pedido Inte rvalo de pedidos Inte rvalo de pedidos Pedidos en estatus 00100 Pedidos facturados y en status 00001 Pedid os en estatus 00100 Pedido s facturados y en status 00001 Fa cProd Anexo IX Fa cProd Anexo X

Se factura

Datos del

Pedido ingresado

Pedido ingresado satisfactoriament e Produ cto apartado correctamente Pedid os en estatus 01000 Pedid os en estatus 00100

Fa cProd Anexo XI Fa cProd Anexo XII Fa

Se realiza Pick Release O RD Antoni o Vidal O RD Antoni o Vidal Se factura B IL Antoni o Vidal

Pedidos en estatus 01000 Pedidos en estatus 00100

cProd Anexo XIII cProd Anexo XIV

Se realiza Pick Confirm

Fa

Inte rvalo de pedidos

Pedidos facturados y en status 00001

Pedido s facturados y en status 00001

cProd Anexo XV

Fa

ORD 02 nio

Se realiza el segundo paso del Anto RMA Vidal B Se factura

Inte rvalo de pedidos Inte rvalo de pedidos

Orden generada lista para facturar y en status 00010 Pedidos facturados y en status 00001

Orden generada lista para facturar y en status 00010 Notas de Crdito facturados y en status 00001

cProd Anexo XVI Prod Anexo XVII

Fa

Fac

IL Antoni o Vidal

D. OUBOUND LOGISTICS MANAGEMENT

Mdulo / Programa OLM 02 Load Maintenance Ericka Gamboa OLM 575D1 S hip Confirm Ericka OL Gamboa MP001B Ericka Gamboa

Descripcin atos Entra da Realizacin de Carga Se consolidan los pedidos

D S ado alida Se calculan los gastos de exportacin

Re sultado Esper ido

Refe Obten rencia

Se gener el Nmero de carga y los gastos.

Se confirma el pedido

Se ingresan datos de carga

Se confirma el pedido

Los pedidos cambian de status 00100 a 00010. Que se transfiera toda la informacin

Imp. Datos de la Web

Se transfieren datos de la Web

Se enva la informacin a BPCS

correctame nte OL MP002D Ericka Gamboa Conciliar cargos del a.a. y estimado Se concilian los datos Anexa r no. De carga Se confirma la informacin correcta Tran sferir los gastos Que solo aparezca la inf. Confirmada. Que se genere una orden de compra de servicios.

OL Generar orden de MP660D compra de servicios Ericka Gamboa OLM Registro de pasivo de la orden de compra del material como de la orden de servicios.

E. CONTABILIDAD D atos Entra S da Pliza alida Evento generada s con registro de IVA Re sultado Esper ado Registro ido contable correcto Refe Obten rencia C ont Anexo I

Mdulo / Programa

Descripcin

Se verifica el registro CEA contable de las facturas, notas 500D1 de crdito y notas de cargo que Erika Servicio a Clientes y Crdito y Mart Cobranza hayan realizado por nez cada compaa. V. CONCLUSIN.

1. Comentarios: Final:

2. Juicio Prueba aprobada

Visin general de la verificacin 4.1 Herramientas, tcnicas y mtodos La metodologa usada por SVV consistir en revisar tcnicamente cada elemento de software (documentacin, mdulos, etc.) creado en cada etapa, constatando su conformidad a las especificaciones realizadas con anterioridad, que el producto se ha desarrollado de acuerdo a los estndares, calidad y procedimientos del proyecto, y finalmente que los cambios implementados se hicieron apropiadamente afectando solamente los sistemas involucrados en ellos. Para llevar a cabo las actividades de verificacin y validacin, es necesario tener el plan SVVP que contendr las restricciones impuestas al software producto de la especificacin de requisitos de usuario; dicho plan permitir documentar las restricciones de usuario recopiladas, y realizar con stas la validacin del software. Dentro de este plan, en la fase SR, al obtener el documento SRD, ser necesario realizar una trazabilidad entre los requisitos de usuario obtenidos en el URD y los requisitos de software del SRD, para constatar que todos los requisitos de usuario hayan sido traducidos en al menos un requisito de software. Dicha matriz se detalla en el punto 6.1 del SVVP/SR. Debido a no tener el SRD a la fecha de entrega del presente documento, se sealar la parte terica y esquemtica del tipo de pruebas que se pueden hacer a los distintos tems de configuracin del proyecto. Dichos esquemas se presentan en los siguientes grficos:

Proyectos Tecnolgicos en el Sector Pblico - Marco conceptual

Al momento de evaluar las diferentes alternativas que el Estado tiene para abordar proyectos tecnolgicos es importante contar con algunos antecedentes de forma de mejorar el entendimiento de contexto y los elementos que pueden afectar el desempeo de estos. Nuestros Estados son un cliente relevante de la industria tecnolgica local. El gasto en TI6 es muy dependiente del nivel de madurez en la adopcin y uso de estas herramientas por parte del Estado, pero en forma complementaria del nivel de la industria local y su capacidad para entregar soluciones que cumplan con las exigencias planteadas (delivery). El nivel de gasto en tecnologas de informacin en la regin bordea el 1% del gasto pblico, en tanto que en pases desarrollados esta cifra llega a cerca del 5%. La consultora Gartner 7 desarroll un estudio el ao 2009 para el gobierno Ingls, con el objeto de identificar la distribucin del gasto pblico en tecnologas de informacin (TI), del gasto total en TI, el cual representa 4.6% del gasto pblico, este se distribuye:
Ilustracin 1: Distribucin gasto TIC - Sector Pblico

G estin y Administr acin, 11 Mant encinSoporte Aplicacion es, 18

Datacenter, 19

Desktop y prefricos, 11

Desarro llo de aplicacio nes, 18

Redes de datos, 1 0 Hel pdesk, 7 Redes de voz, 6

Fuente: Gartner, 2009

El gasto TI al igual que la contratacin pblica en general representan volmenes muy

signficativos - http://www.alejandrobarros.com/segundas-derivadas-de-la-contratacionpublica#content-top
7

http://www.gartner.com

En el ciclo de vida de un proyecto podemos identificar bsicamente tres grandes fases: diseo, ejecucin y operacin. Segn Feeny (Feeny, 2003) los principales factores (ejes) de riesgo asociados al desempeo de un proyecto tienen relacin con tres grandes elementos, esto es: i. ii. iii. tamao del proyecto, calidad de la definicin de los requerimientos y nivel de conocimiento de la tecnologa que se quiere emplear.

Uno de los elementos que debe evaluarse al momento de una decisin entre desarrollo a la medida y adopcin de un producto comercial para abordar la problemtica financiero contable del Estado corresponde a los factores de riesgo mencionados y el comportamiento anterior de proyectos similares 8 lo cual es un buen predictor del nivel de riesgo del proyecto en sus dos modalidades. En el grfico siguiente se muestra el referido espacio tridimensional anteriormente descrito.

Ilustracin 2: Evaluacin de Riesgo - Proyecto TIC

Fuente: Adaptacin propia a partir de Feeny, 2003

Esto puede ser un problema ya que no existen muchos proyectos de la envergadura de un SIAF, lo cual en general no permite

contar con antecedentes en esta rea.

En la medida que al momento del diseo del proyecto se pueda situar la posicin de este en dicho espacio tridimensional, se podr tener una buena aproximacin del riesgo asociado. Cabe sealar que este ejercicio es slo una aproximacin y no representa un modelo cuantitativo de riesgo, pero resulta un proxy adecuado 9.

Car acter sticas de Pr oyectos tecnolgicos en el Estado Algunos de los problemas que presentan los proyectos tecnolgicos dentro del Estado corresponden en general a problemas asociados a su diseo inicial. Es fundamental identificar adecuadamente los elementos que caracterizan a los proyectos tecnolgicos en el sector pblico, ms an cuando un proyecto SIAF corresponde a uno de los proyectos de mayor envergadura de dicho sector.

Ilustracin 3: Elementos de Proyectos TIC - Sector Pblico

Atrib utos y Caracter sticas Pr oceso Adquis icin

Mercado

Proye ctos T IC

Para establecer un modelo ms preciso de riesgo se recomienda utilizar los enfoque metodolgicos del PMI o Prince2

Los proyectos tecnolgicos tienen singularidades propias dentro del sector pblico, las cuales deben ser atendidas y analizadas al momento del diseo y anlisis del mismo. caractersticas se han agrupado en tres reas, gobierno, tecnologa y gestin. G obierno Rendicin de cuentas (accountability), el quehacer y los gastos tienen el escrutinio pblico, por lo que en muchos casos se requiere de una componente importante de difusin del proyecto, actividad que no necesariamente se encuentran evaluada ni dimensionada, ni menos costeada en muchos casos. Tiempos polticos, con frecuencia los proyectos se promocionan antes de su puesta en marcha, lo que afecta desde el punto de vista de la promesa y las expectativas asociadas al resultado, por lo que los proyectos deben identificar entregables intermedios. Estas

Cambios en prioridades de gobierno, lo que implica en ciertas circunstancias merma o reducciones de recursos asignados a proyectos. Marco regulatorio ms rgido, esto afecta en situaciones en las cuales el proyecto debe redisearse y no es posible producto del marco jurdico. Coordinacin inter-institucional, En muchos casos se requiere de coordinacin interinstituciones, esto incorpora nuevas complejidades ya que se requiere de una visin y compromiso que va ms all de una nica institucin.

Tec nologa El cambio tecnolgico es en general de gran velocidad, el Estado se mueve lento, lo cual en ciertas ocasiones le produce que las soluciones se tornen obsoletas. En general los proyectos tecnolgicos dentro del estado tienen alta complejidad debido a los niveles de integracin y volmenes asociados (gran cantidad de transacciones, usuarios y/o volmenes de datos). El nivel de desarrollo tecnolgico de los servicios pblico es muy heterogneo. Se pueden apreciar instituciones con un gran desarrollo, habitualmente cercanas al gobierno central 10, otras con un bajo nivel de desarrollo, tal es el caso de algunos municipios y/o servicios pblicos pequeos. Gestin
10

Falta de habilidades de gestin y administracin de proyectos tecnolgicos

Las reas del gobierno central donde se aprecia el mayor nivel de desarrollo tecnolgicos y mayores niveles de madurez para

enfrentar este tipo de proyectos se encuentran en el gobierno central asociadas al ministerio de hacienda y/o finanzas

Contratos de alta complejidad en su diseo y posterior administracin Niveles de servicio (SLA's) mal definidos y/o no administrados Pobre gestin de proveedores, con un enfoque en algunos casos no cuidan la relacin comprador-proveedor

Esto elementos deben ser considerados al momento del diseo y ejecucin del proyecto.

Pr oceso de Adquisicin Sector Pblico Una de las etapas del ciclo que pueden tener un impacto importante sobre los proyectos tecnolgicos son los procesos de adquisicin asociados, en particular cuando se refiere a procesos licitatorios extremadamente rgidos. En esta etapa podemos mencionar algunos factores identificados por el sector privado (grandes proveedores tecnolgicos) y sector pblico nacional (grandes servicios pblicos) 11 , que afectan el desempeo final de un proyecto tecnolgico, entre estos se puede mencionar: Sector Pblico Las principales dificultades que enfrentan compradores del sector pblico al momento de adquirir soluciones y proyectos tecnolgicos corresponden a: Ausencia de mecanismos que permitan negociar con el mejor calificado de los oferentes. Adopcin de metodologas de desarrollo/diseo no probadas y con poca experiencia local. La falta de una oferta de calidad en el mercado local

Sector Privado Las principales dificultades que enfrentan proveedores tecnolgicos al momento de ofertar soluciones y proyectos tecnolgicos corresponden a: Presupuestos no acordes con los costos reales de la solucin; Modelo contractual excesivamente rgido; Proceso licitatorio mal definido y/o con tiempos inadecuados.

11 Encuesta desarrollada por la Direccin de Compras Pblicas Ministerio de Hacienda, Chile, durante el ao 2005, la cual se ha tomado como base para implementar instructivos a los servicios pblicos para en procesos licitatorios de Tecnologa de Informacin.

En cualquier proyecto tecnolgico de relevancia y en particular un proceso de adquisicin de una plataforma SIAF para el Estado, sea esto en modalidad de desarrollo a la medida o de adquisicin de productos, en ambos casos el proceso de adquisicin es fundamental. El proceso de adquisicin debe estar estructurado y seguir algn modelo estndar que le permita monitorear el proceso y reducir los riesgos que este plantea. Un modelo que resulta especialmente adecuado para estos procesos es el planteado por el Software Engineering Institute de la Universidad Carnegie Mellon, bajo el paragua metodolgico CMMI12, nos referimos al marco metodolgico CMMI for Adquisition (CMMI-ACQ) versin 1.2 13 Lo primero que un proceso de contratacin debe reconocer, es que algunas actividades del proceso estn bajo el control directo del mandante y otras, si bien el mandante puede tener algn tipo de supervisin su nivel de influencia es menor, nos referimos a aquellas actividades que deben ejecutar los proveedores. Por otra parte, los lderes del proceso de contratacin, y dadas las caractersticas de los SIAF, deben establecer procesos flexibles y giles, que permitan la generacin de productos adaptables y con entregas parciales en periodos relativamente cortos de tiempos. Es fundamental que el proceso de contratacin se inserte como parte del proceso completo y no como un apndice, tal como lo plantea CMMI el proceso de contratacin debe estar relacionado directamente con elementos que anteceden y que son posteriores al proceso de adquisiciones.

12

http://www.sei.cmu.edu/cmmi/

13

http://www.sei.cmu.edu/library/abstracts/reports/07tr017.cfm

Ilustracin 4: Proceso de Adquisicin CMMi-ACQ

Gestin de Proyectos

Adquis icin

Soporte

En cada una de estas actividades estructurado para la adquisicin.

se plantean prcticas que definen un proceso

Gestin de Proyecto: Fase inicial del proyecto en la cual se definen los aspectos centrales de su diseo y posterior administracin, como parte de esta etapa del proceso se deben considerar, planificacin, monitoreo y control, gestin integrada, gestin de requerimientos y administracin del riesgo. Adquisicin: En la etapa de contratacin se contemplan una serie de prcticas que dicen relacin con dicho proceso, estos es, desarrollo y solicitud de proveedores, gestin de cambios, desarrollo de requerimientos, gestin tcnica de adquisicin, verificacin de adquisicin y proceso de validacin de adquisicin. Soporte: En esta etapa del proceso se definen las prcticas asociadas a etapas tardas del mismo, nos referimos a, gestin de la configuracin, toma de decisiones y resolucin de conflictos, anlisis y mtricas y aseguramiento de calidad.

Durante la etapa de adquisiciones, las buenas prcticas identificadas por el estndar CMMI-ACQ permiten que se establezca un circuito ordenado y que se cuenten con elementos centrales de un proceso de adquisicin que reduzca los riesgos inherentes a la complejidad que

plantean este tipo de actividades.

Causas de Fr a casos de Pr oyectos TIC Al mirar el comportamiento de los proyectos tecnolgicos 14, aparecen algunos elementos que se repiten y que en general pueden asociarse al fracaso de los mismos. Estos elementos van a estar presentes en mayor o menor medida dependiendo de la madurez de la institucin y de los equipos de proyecto que pueda conformar, en el caso de los SIAF y producto de la envergadura de estos proyectos algunas de estas causales deben monitorearse con mayor frecuencia y profundidad. Entre las principales causas de fracasos de los proyectos se pueden mencionar: Falta de vnculo entre el proyecto y las prioridades estratgicas de la institucin; Falta de liderazgo y ownership del proyecto; Falta de habilidades de gestin de proyectos y administracin del riesgo; Poco conocimiento de la industria tecnolgica y de los proveedores; Evaluacin de propuestas con mirada de corto plazo sustentado en oferta econmica y no en funcin del valor del gasto; Pocas iniciativas para segmentar los proyectos en tamaos ms manejables; Arquitectura tecnolgica mal definida.

Una herramienta que puede ayudar en esta etapa es la pauta de evaluacin desarrollada por la Parliamentary Office of Science and Technology (Government IT Projects) en el Reino Unido 15, cuya finalidad es evaluar un proyecto en particular sobre la base de factores de xito y fracaso para 16 reas, las cuales pueden determinar la evolucin de un determinado proyecto, se adjunta como anexo al presente documento. Es fundamental que a la hora de disear el proyecto se tomen en consideracin estos elementos ya que independientemente de si la solucin que se adoptar es un enfoque de desarrollo a la medida o de implantacin de un producto comercial o un mix de ambos, estos tendrn un impacto significativo en el proceso. Cualquiera sea el caso, los elementos sealados van a afectar de diversa forma, por lo que tomarlos en cuenta a la hora del diseo contribuir a reducir riesgos y sobre costos.

14

Algunos anlisis recientes como el desarrollado por Bent Flyvbjerg y Alexander Budzier de la Universidade de Oxford han

mostrado que 1 de cada 6 proyesctos e transforma en lo que se denomina proyecto Cisne Negro, en el cual los sobrecostos superan el 200% y los sobretiempos el 70%, mas informacin en: http://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think/ar
15

http://www.parliament.uk

III. Visin de los GRPs

Un proyecto SIAF se visualiza como un proceso de implantacin de un ERP 16 sea este utilizando un producto comercial o bien realizando un desarrollo a la medida, incluso puede tratarse de un modelo mixto, esto es, algunos componentes basados en productos comerciales y otros en base a desarrollos a la medida. Para analizar los efectos de costo es necesario identificar los niveles y componentes que se esperan implementar, ya que el alcance de estos proyectos SIAF es muy variado. Algunos incluyen el mdulo de compras y contratacin pblica como parte del proyecto, tal es el caso de varios pases en la regin de Centro Amrica. Algunos pases incluyen mdulos asociados a Tesorera y por lo tanto ya no estamos hablando slo de la gestin contable. El primer desafo que se presenta es aclarar el alcance funcional del proyecto. En la grfica siguiente se muestra el potencial alcance de un sistema SIAF, el cual depender de cada pas y sus autoridades.

16

En el caso del sector pblico se denomina a los sistemas integrados de gestin de recursos (ERP) con la sigla GRP, esto con

el objeto de diferenciarlos de los ERPs tradicionales cuto foco original era esencialmente el sector privado.

Ilustracin 5: Cobertura Funcional SIAF

Fuente: Adaptacin propia, Financial Management Information System, Banco Mundial, 2011

Al analizar el mapa funcional, adems se puede concluir que hay mltiples servicios pblicos involucrados y por lo tanto es muy probable que dependiendo del alcance se trate de un proyecto multi-institucional con las complejidades que eso conlleva.

En el caso de los ERP estos tambin tienen un curso de evolucin y su alcance funcional en general adopta la evolucin que se muestra en la grfica siguiente:
Ilustracin 6: Ruta Adopcin de ERP

Integracin 3ros (otros servicios, web, proveedores) Analtico (BI, Datawarehouse) ERP Extendido (OT, inventario, CRM, etc)

Core ERP (contabilidad, presupuesto, remuneraciones)

Fuente: Adaptacin Transformation, 2008

propia

de

Technologies

for

Government

Otro elemento a considerar es la profundidad del software, nos referimos a las esferas del Estado que incluyen (federal, estatal y municipal), en algunos casos se llega hasta los niveles ms locales del gobierno, la profundidad incidir directamente en la cantidad de usuarios del sistema y en la cobertura funcional, ya que algunas funciones son propias de ciertas esferas de gobierno y por lo tanto afectarn directamente el costo final del mismo. Estos elementos, cobertura y profundidad, son relevantes a la hora de realizar el anlisis correspondiente y deben ser definidos ex ante, independientemente de que el proyecto tenga definida una estrategia escalonada de implementacin.

Ilustracin 7: Elementos de Costo - SIAF

Fuente: Desarrollo propio

Por otra parte, un sistema del tipo SIAF est compuesto por tres niveles de componentes, nos referimos a un primer nivel del software aplicativo, luego el software bsico y finalmente el hardware necesario para su operacin.

Ilustracin 8: Estructura Tcnica de los SIAF

Fuente: Desarrollo propio

De los tres niveles que presenta cualquier sistema SIAF, existen dos de ellos asociados a productos y en los cuales las consideraciones deben ser diferentes. Infraestructura Hardware: En este nivel, estamos hablando de componentes estndares y que tienen costos conocidos a priori, con un mercado oferente bastante competitivo y que no presenta demasiadas sorpresas. Para efectos de anlisis de este nivel es necesario contar con algunos elementos operacionales que permitan su dimensionamiento, nos referimos a, cantidad de usuarios, transacciones por unidad de tiempo y volumen de almacenamiento. Otro elemento necesario para este nivel es el tipo de operacin en trminos de disponibilidad, ya que esto define el nivel de espejamiento y redundancia de

equipos. En este nivel se pueden adoptar modelos basados en contratacin de servicios Cloud Computing del tipo IaaS 17.

Software Bsico: En este nivel las alternativas presentes son bsicamente dos, obviamente se puede dar un mix de ellas, nos referimos a software bsico comercial, representados por compaas tales como Microsoft, Oracle, IBM y otras. El otro modelo corresponde a producto del tipo Open Source o denominados FLOSS en el cual su modelo de cobros est vinculado a servicios y no a licenciamiento propiamente tal.

Tabla 1: Item de Costos Software Comercial - FLOSS

Items de Costo Licenciamiento Soporte Ingeniera

18

Comercial SS

FLO

Software Aplicativo - SIAF: En este nivel las alternativas presentes son bsicamente dos, el desarrollo a medida de cada componente o bien la adaptacin de un producto comercial existente, nos referimos a la implantacin de un ERP comercial. En ambos casos existirn costos asociados al tem diseo y construccin de software, ya sea para el desarrollo a la medida o bien de las adaptaciones que sean necesarias para que el producto opere cumpliendo los requisitos mnimos. A la hora de evaluar los costos, algunos de estos componentes se deben aislar ya que

podran afectar el proceso de anlisis, sobre todo si el proyecto de implementacin de un sistema SIAF va a utilizar infraestructura tecnolgica existente en el gobierno central.

17

IaaS (Infrastructure as a Service): Soluciones de infraestructura tecnolgica empaquetada en modalidad servicios, un ejemplo de

ello son los servicios que hoy tienen las grandes compaas de hardware, tales como, IBM, Dell, HP y Amazon, en los cuales se ofrecen soluciones de almacenamiento, servidores y bases de datos.
18

En algunos casos se incluye en el costo de Licenciamiento algunas horas de soporte

IV. Fundamentos bsicos del Anlisis Costos-Beneficio

El presente anlisis est centrado en identificar los componentes de costo para la puesta en marcha Sistemas Integrados de Administracin Financiera SIAF para el Estado, para lo cual se ha tomado como premisa, que la decisin de implementar un SIAF ya est definida y nos encontramos en la segunda etapa del proceso de decisin, esto es, seleccionar desarrollo a la medida - LDSW 19 o implementacin de un producto comercial - COTS 20 del tipo ERP 21. La etapa anterior presupone un anlisis costo-beneficio de contar con una herramienta de este tipo, para lo cual se debe realizar una evaluacin entre dos escenarios, evaluar los costos de no contar con un sistema SIAF versus los costos de puesta en marcha. Los costos de no contar con una herramienta de este tipo est asociadas generalmente a: Gestin deficiente del tesoro pblico, Costos de transaccin para la gestin financiera (activos, transferencias de fondos, entre otros), Diseo y ejecucin del presupuesto Monitoreo del uso de fondos pblicos

Una vez tomada la decisin de incorporar una plataforma SIAF en el Estado, la siguiente pregunta es: Construir a la medida o comprar un producto comercial? Esta pregunta se la hacen muchos gestores tecnolgicos, tanto en el sector pblico, como privado. La eleccin tiene impactos y consecuencias diferentes a los largo del ciclo de vida del proyecto y en la operacin posterior, por lo tanto el anlisis de ambas alternativas es muy relevante. En los ltimos aos, la decisin se ha complejizado an ms, ya que los niveles de sofisticacin de los productos empaquetados ha aumentando de forma muy significativa. En el caso de los sistemas ERP, este aumento de complejidad ha sido muy significativo producto de un mayor conocimiento de los requerimientos de los mercados objetivos, as como de una mejor adaptacin a ellos. En particular en el sector pblico, ya que originalmente este tipo de

19

Conocido comnmente como: Locally Developed Software (LDSW)

20

Conocido comnmente como: Commercial off-the-shelf (COTS) Enterprise Resource Planning (ERP), Sistema informticos integrados de gestin financiera-operacional de organizacin de

21

diverso tamao - http://en.wikipedia.org/wiki/Enterprise_resource_planning .

productos estaba fundamentalmente orientado a los requerimientos del sector privado y por lo tanto eran descartados rpidamente. Por otra parte, el desarrollo de software cada vez ms, se trata de un proceso de ensamblaje que de construccin de software desde cero. Algunos de los criterios que plantea el documento Build versus Buy 22 resultan fundamentales a la hora decidir entre ellos. En este contexto, podemos mencionar: Importancia estratgica: corresponde al nivel de relevancia de la aplicacin que se est evaluando, esto es, mientras ms cerca del ncleo (corazn) del negocio y ms crtica sea su operacin, la diferenciacin por la va de desarrollos a la medida - LDSW es relevante. Cobertura funcional: a mayor cobertura de los requerimientos funcionales y del negocio, la solucin basada en Productos Comerciales - COTS se transforma en una solucin ms clara. El mercado siempre habla de la regla de cobertura del 80%, es decir, si la cobertura funcional es mayor o igual al 80% se recomienda tomar el camino de los productos comerciales. Evolucin: Es fundamental en los productos comerciales evaluar su capacidad de evolucin y el nivel de flexibilidad que presentan a cambios futuros del mercado. Estos aspectos van de la mano de la arquitectura y diseo del sistema. No es recomendable aventurarse con productos comerciales que no han tenido una evolucin clara en el tiempo, ya que existen serios riesgos de que el producto se discontine a futuro.

Costo: Evaluar el costo total de propiedad - TCO 23 . En el caso de los productos empaquetados se requiere contar con un modelo de servicios claro con el proveedor del software. En el caso de los desarrollos a la medida, se requerir contar con recursos internos para las mantenciones futuras que requiera la aplicacin. Tiempos: La puesta en marcha de sistemas empaquetados puede tener tiempos de implementacin menores. Esto depender del nivel de profundidad de los cambios necesarios para su operacin. Es decir, si un paquete tiene un alto nivel de cobertura funcional, la puesta en marcha puede ser bastante gil. Uso de Estndares: En general los productos comerciales estn adoptando estndares de industria en general empujados por presin del mercado, lo cual en el caso de desarrollos a la medida dependen del equipo de desarrollo y sus prcticas. Eventualmente existen menos incentivos en el caso del LDSW a adoptar los referidos estndares ya que no hay una presin similar.
22

Build v. Buy, A Decision Paradigm for Information Technology Applications, Kenneth S. Ledeen, 2002

23

Total Cost of Ownership

Por lo tanto al analizar todas estas variables, la decisin entre desarrollar un producto desde cero y adaptar un producto comercial pasa por un proceso que debe analizar al menos estas variables.

Tabla 2: COTS versus LDSW

C riterio Core-Misin Crtica 80% o ms de cobertura funcional Tiempos de implementacin cortos Costo total de propiedad (TCO) Evolucin Mercado proveedor consultores funcionales Mercado desarrollo de software Reducir dependencia futura del proveedor(vendor lock-in)

C OTS E valuar DSW

El proceso de decisin debiera analizar estos factores, de forma tal que el anlisis sea sobre la base de un mtodo lo ms objetivo posible y no slo sobre la variable de costos como habitualmente se aborda el tema. En un estudio desarrollado por la consultora Aberdeen Group, The Total Cost of ERP Ownership in Small Companies, se mostr que las principales razones para seleccionar un ERP en el sector privado son: (i) la cobertura funcional que tiene, llegando a un 75% de las respuestas, y, (ii) el costo total de propiedad con un 52% de las respuestas.

Ilustracin 9: Razones para la adopcin de un ERP

Razones para adoptar un ERP

2006 2007 75 64 8 50 5 48 52

Funcionalidad

Facilidad de Uso

TCO

Fuente: The Total Cost of ERP Ownership in Small Companies, Aberdeen Group, 2007

En el presente documento, nos centraremos en el proceso de anlisis de los costos asociados a ambas lneas de accin, esto es, cobertura y costo, sin perjuicio de que la evaluacin debe incorporar los otros criterios. En el caso de la seleccin de producto ERP para el Sector Pblico, la evaluacin debe considerar los elementos que le son propios a dicho sector, tanto desde el punto de vista funcional como de los atributos asociados a proyectos tecnolgicos como se plante en el punto anterior. En ese contexto, el proyecto SIGFE 24, Sistema Integrado de Gestin Financiera del Estado, del Ministerio de Haciendo de la Repblica de Chile 25 , realiz una evaluacin funcional de productos comerciales del tipo ERP, entendida como una prueba de concepto 26, durante el ao 2008. Los productos evaluados tenan en ese momento bastante presencia en el mercado local de instituciones pblicas. La evaluacin consider tres grandes componentes: Aspectos funcionales, Arquitectura tecnolgica Capacidades de integracin con otros componentes. 1

24

http://www.sigfe.gov.cl SIAF Chileno POC: Proof of Concept

25

26

En el mbito funcional se definieron 136 criterios agrupados en las siguientes reas funcionales:

Tabla 3: Evaluacin POC SIGFE Cant idad de Pond eracin F inal

Afectacin presupuestaria Devengo presupuestario y Asiento Contable Imputacin contable Instancia de Efectivo

Va 2 riables

2 2 2 2

9 3 3 1

4 2 4 1

5% 5% 5% 5%

100

36 Chile, 2008 % Fuente: Evaluacin POC, Direccin de Presupuestos, Ministerio de Hacienda, Para cada una de las variables se defini una escala con la cual fueron evaluados los diferentes productos.
Tabla 4: Escala de Evaluacin POC

N ota 00 5 0

Nivel de Cumplimiento Excelente: no slo cumple con el requerimiento de calidad a 1cabalidad, sino incorpora elementos que aportan valor agregado a la Bueno : cumple a cabalidad con el requerimiento de calidad 7 aplicacin. establecido Regular: cumple con el requerimiento de calidad establecido, sin embargo se tuvieron que hacer compromisos leves, sin impacto a 5 nivel de negocio. Implicando un funcionamiento levemente sub ptimo. Deficiente: cumple con el requerimiento de calidad, sin embargo se tuvieron que hacer compromisos relevantes o suavizar los criterios de

evaluacin. No hay impacto graves a nivel funcional, pero si elementos 2 que potencialmente pudieran conducir a errores, impactar el desempeo u otros elementos indeseables. 0 No cumple

Fuente: Evaluacin POC, Direccin de Presupuestos, Ministerio de Hacienda, Chile, 2008

La evaluacin obtenida por los productos se resume en el siguiente cuadro, se han omitido los nombres de los productos y empresas, ya que existen acuerdos de confidencialidad establecidos con la Direccin de Presupuestos.

Tabla 5: Resultado de la Evaliacin POC - SIGFE

rea de Evaluacin
Afectacin presupuestaria Devengo presupuestario y Asiento Contable Imputacin contable Instancia de Efectivo ucto 1

Prod

Produ cto 2

Prod ucto 3

6 7 7 7

3 4 3 3

4 4 2 4 4

9.7 4.7 3.0 5.1

0.8 2.3 4.6 5.4

1.3 7.2 8.3 4.1 0.2

Nota Final Ponderada

Fuente: Evaluacin POC, Chile, 2008

7 3 3.2 5.7 Direccin de Presupuestos, Ministerio de Hacienda,

Como se puede apreciar ninguno de los productos cumple con el nivel de 75 puntos, equivalente a Bueno, es decir, cumple a cabalidad con el requerimiento de calidad establecido por el Estado de Chile. En el caso del Producto 1, fue quien estuvo ms cerca de dicho nivel. En su momento se recomendaron otras pruebas que finalmente no arrojaron los resultados esperados por lo que a la postre el producto 1 tambin fue descartado. Luego del proceso descrito se opt por embarcarse en un desarrollo a la medida, ya que la cobertura funcional de los productos comerciales evaluados se distanciaba de los requerimientos mnimos establecidos. Al analizar los costos de una solucin comercial COTS y un desarrollo a la medida LDSW, el anlisis se debe realizar sobre todo el ciclo del proyecto, esto es, costos iniciales, implementacin, puesta en marcha y finalmente de mantencin y soporte, los cuales varan segn la alternativa que se seleccione.

Ilustracin 10: Ciclo de Anlisis de Costo

Costos Inciales

Impleme ntacin y Puesta en Marcha

Mante ncin y S oporte

Costos Iniciales En esta etapa se evala el costo total de propiedad del proyecto (TCO 27). Cuando la alternativa que se est evaluando es un producto comercial COTS, se establecen criterios de cumplimento de los requerimientos funcionales y tcnico que la solucin debe cumplir, esto es, identificando los niveles funcionales de: carcter obligatorio, deseable, y finalmente aquellos opcionales;

Las soluciones a medida no tienen esa segmentacin establecida en forma tan clara y precisa. El diseo de las soluciones a medida se hace para cubrir todos los requerimientos del sistema con una segmentacin poco clara. En general, en el proceso de evaluacin de desarrollos a la medida no se incluyen los requerimientos opcionales, ya que es muy frecuente que no se cuenta con una especificacin que llegue a ese nivel. Estimar costos iniciales para productos comerciales es ms sencillo que para desarrollos a la medida, ya que algunos de los valores, son montos con alto nivel de certeza, ejemplo de ello es el costo por licencia de uso, habitualmente dependiente de la cantidad de usuarios del sistema y/o servidores dependiendo de la modalidad de licenciamiento. Es en el proceso de implantacin y/o adaptacin donde aumenta el nivel de incertidumbre. En esta etapa va a influir especialmente el nivel de brecha respecto de la solucin estndar y el requerimiento especfico. Para ello los proveedores de sistemas GRP de clase mundial cuentan con modelos de estimacin de esfuerzo, los cuales habitualmente se expresan en cantidad de horas-hombres por tipo de perfil profesional.

27

Total Cost of Ownership, corresponde al costo total de una solucin tecnolgica, el cual incluyen adquisicin, soporte,

capacitacin y en general todos los tems de costo asociados.

Ilustracin 11: Proceso de Implementacin de ERP

Fuente: Adaptacin propia a partir de Technologies for Government Transformation

La estimacin de costos para desarrollos a la medida puede tener mrgenes de error bastante significativos en funcin del tamao del proyecto y la precisin de las especificaciones. Incluso en algunos casos en los cuales no existe un proceso riguroso de control de cambios, la estimacin de esfuerzo original puede resultar totalmente errnea. Por tal motivo, se deben utilizar mtodos alternativos para la evaluacin del esfuerzo del proceso con el objeto de utilizarlos como mecanismo de validacin. Para ello un mtodo que puede ser utilizado como una forma de validacin complementaria es el peso porcentual del esfuerzo por actividad del proceso para un desarrollo de estas caractersticas, tomando como referencia las mtricas estudiadas para ello por Capers Jones, las que podemos resumir en:

Tabla 6: Peso en el esfuerzo total por actividades del proyecto

Act ividad Especificacin Programacin Pruebas Documentacin Gestin del Proyecto (PMO)

Peso porcentual

20% 41% 25% 2% 12%

Fuente: Elaboracin propia en base a mtricas de Applied Software Measurement, Capers Jones

Implementacin y Puesta en Mar cha Cuando la solucin est seleccionada aparecen otros costos, tales como: capacitacin, adopcin de usuarios, integracin con procesos de negocio propios de cada implementacin y finalmente las horas-hombre involucradas en la puesta en marcha del sistema. En el caso de los sistemas la medida, no se cuenta con documentacin ni material de capacitacin, el cual debe ser desarrollado desde cero. Para los sistemas comerciales este tipo de documentacin es parte del producto y por lo tanto no debe estimarse como costo separado, ya que habitualmente como parte del producto, estos cuentan con material estndar de capacitacin y entrenamiento de los usuarios. En ciertas ocasiones slo se hace necesario adecuarlos en funcin de las adaptaciones desarrolladas para la implementacin en particular. Un elemento relevante a la hora de adoptar un producto comercial es el esfuerzo necesario para adaptarlo a los procesos y prcticas de la organizacin, los cuales en el caso de los SIAF estn bastante regulados y el nivel de flexibilidad que se tiene es relativamente bajo, por lo que en caso que el producto tenga una brecha funcional relevante, este esfuerzo se puede transformar en un elemento sustantivo a la hora de estimar el costo total del proyecto. Otro elemento importante a destacar es que en el caso de productos comerciales se puede desarrollar un proceso con entregas ms parcializadas, ya que existe un producto funcional desde

el comienzo del proyecto, cosa que no ocurre en el caso de los desarrollos a la medida, salvo que se utilice un enfoque metodolgico basado en modelos giles 28.

Mantencin Sopor te

Una vez que el producto se encuentra operando, los costos estn asociados fundamentalmente a modificaciones en el software, producto de cambios en los procesos de negocios, correcciones de errores y re-adopcin de usuarios. En el caso de los cambios en los procesos de negocios, el nivel de flexibilidad de productos comerciales es menor. Si la parametrizacin que se hizo a la hora de adaptarlo a los requerimientos de la organizacin fue muy profunda, puede resultar muy complejo adoptar nuevas versiones del producto. La correccin de errores depender del tipo de relacin contractual con la que se cuente con el proveedor del producto. En el caso de un desarrollo a la medida este esfuerzo est directamente relacionado con los conocimientos que la organizacin que opera el SIAF tenga. Para un producto comercial, la correccin de errores depender del contrato de mantencin que se establezca con el proveedor del mismo.

Con sider acion es Gener ales As como es relevante tener un entendimiento de los costos asociados a las diferentes etapas del proceso, es muy relevante incorporar algunos antecedentes que permitan sensibilizar el costo final, tal es el caso de los efectos del uso de software libre y del impacto que cada una de las componentes del proyecto tienen en el costo final Software Libre: Existen muchos mitos respecto de los costos asociados al uso del software libre o FLOSS. Cabe sealar que el impacto del uso de este tipo de producto, residen fundamentalmente en el costo asociado al licenciamiento. Esto puede ser importante en la capa de software bsico, nos referimos a sistema operativos, bases de datos, middleware y el framework de desarrollo, pero ello no tiene impacto en los costos

28

Con esto nos referimos a metodologas del tipo gil, SCRUM, Extreme Programming y otros -

http://www.alejandrobarros.com/content/view/560804/Nuevas-practicas-de-desarrollo-de-software.html#content-top

asociados a los otros niveles del proceso, nos referimos a desarrollo de software, capacitacin, puesta en marcha y capacitacin.

Impacto por etapa: El Departamento de Defensa de los Estados Unidos de Norteamrica desarroll una evaluacin de la distribucin de los costos asociados a proyectos de desarrollo de software y puesta en marcha de ERPs en algunas de las instituciones de la defensa norteamericana. En las grficas siguientes se muestra la distribucin de los costos en ambos escenarios. Si bien la muestra no es muy grande en trminos de cantidad de proyectos, al menos entrega algunas luces del peso de cada componente en el proceso.

Ilustracin 12: Distribucin de costos para ERP

Fuente: Departamento de Defensa, USA

y para el caso de los desarrollos a la medida

Ilustracin 13: Dsitribucin de costos - Desarrollo de Software

Fuente: Departamento de Defensa, USA

Al comparar ambos escenarios se observan diferencias significativas que resultan entendibles producto de los diferentes enfoques.

Tabla 7: Diferencial de Impacto de costos - COTS versus LDSW

Distribucin del Costo segn Escenario Adquisicin Desarrollo de Software Implementacin y Puesta en marcha Capacitacin Gestin de Proyectos (PMO)
Fuente: Defensa, USA Departamento de

C OTS 5% 8% 8% % 2% 1 DSW % 1 2 5% 7 3 5% % 8%

L 9 4 2 3 1 % 27% % % 4% -

6 3 4 1

En la modalidad COTS, los costos del proyecto se concentran fundamentalmente en la etapa de adquisicin. Esto es producto de licenciamiento del aplicativo ERP y en la gestin del proyecto, lo cual puede deberse al uso de los enfoques metodolgicos estandarizados que utilizan los 2

consultores implantadores de soluciones ERP.

En el caso de LDSW los mayores

impactos de estn dado por la etapa de desarrollo de software. Otra rea que presenta diferencias importantes es la gestin de proyectos, lo cual se debe a que en general los enfoques metodolgicos de los procesos de implantacin de COTS requieren de perfiles profesionales de mayor costo y sus modelos de gestin son ms estructurados en base a metodologas estndares.

V. Variables de Anlisis
Las plataformas modernas de sistemas integrados de gestin financiera SIAF 29, son plataformas que buscan ayudar a los Estados con su gestin, los cuales deben cumplir con las siguientes caractersticas: tipo BI sobre los datos, acceso a los ciudadanos, transparencia presupuestaria. cumplimiento de estndares contables comnmente aceptados, estndares de reportabilidad, operacin centralizada en modalidad web (web-based), acceso a gran cantidad de usuarios del sector pblico en todos los niveles, agregacin de la data permitiendo realizar anlisis de inteligencia de negocios del

En trminos generales estos sistemas ofrecen un gran potencial para mejorar el quehacer del Estado, su eficiencia, transparencia y rendicin de cuentas (accountability). La implementacin de estos sistemas han generado toda clase de discusiones respecto de su real impacto, esto producto de que el esfuerzo que debe realizar un Estado en su proceso de diseo e implementacin es muy significativo. En el estudio del Banco Mundial - Financial Management Information Systems 30, en el cual se analizan 87 proyectos de sistemas de administracin financiera SIAF, algunos de estos proyectos ya terminados y otros en curso en 51 pases a nivel mundial, cuyos costos totales ascienden a 2,200 millones de dlares, lo cual significa un monto promedio de los proyectos de 25.3 millones de dlares por pas, demuestra que estamos ante proyectos de gran envergadura y en muchos se trata de los proyectos tecnolgicos ms significativos del sector pblico. Cuando los pases abordan este tipo de proyectos surgen preguntas asociadas al modelo a adoptar y sus costos i. ii. software desarrollado a la medida versus productos comerciales costos estimados iii. iv. principales factores de riesgo y sus medidas de mitigacin aprendizajes de otros proyectos similares que se pueden adoptar 4

29

FMIS Financial Management Information Systems segn el Banco Mundial Financial Management Information Systems, Cem Dener Joanna Alexandra Watkins - William Leslie Dorotinsky, World Bank,

30

2011

Desde un punto de vista del esfuerzo este tipo de proyecto demoran prcticamente 8 aos en promedio segn lo pudo comprobar el Banco Mundial en su anlisis.
31

Ilustracin 14: Cantidad de Proyectos SIAF segn duracin

Duracin del de Proyectos SIAF

< 5 aos 5-6 6-7 7-8 8-9 9 - 10 > 10 aos 7 7 0 1 5 7 1 6

Fuente: Financial Management Information Systems World Bank, 2011

Desde el punto de vista del diseo y la puesta en marcha de las soluciones TI para estos proyectos el mismo anlisis se concluye que la implementacin tecnolgica es de 2.5 aos en promedio.

C ostos El anlisis muestra que de los 87 proyectos analizados los gastos asociados a tecnologas de informacin corresponden a 612 millones de dlares, de los cuales 324 millones son especficamente para los sistemas SIAF, correspondiendo el saldo a otras inversiones que no son atribuibles directamente al sistema de gestin financiera.

31

Esto incluye no slo la componente de desarrollo tecnolgicos sino todos los elementos del proyecto.

En el caso de los proyectos especficos SIAF y sus gastos en tecnologas de informacin, un porcentaje importante (70%) de la muestra analizada tienen inversiones en TI que van desde los 4 y hasta los 8 millones de dlares.

Ilustracin 15: Costos Proyecto SIAF

Costos Proyecto TI - SIAF

< $4 4-8 12 16 $ 16 20 > $ 20 MM
Fuente: Financial Management Information Systems World Bank, 2011

1 4 2 1 4 3 4 3

$ $8$ 12 -

Los diferenciales de costos estn fundamentalmente asociados al modelo y diseo del proyecto tecnolgico que se adopt, esto es, software comercial (COTS) o desarrollos a la medida (LDSW). Es importante aclarar que las desviaciones de los proyectos respecto de sus estimaciones iniciales son relativamente bajas segn lo analizado por el Banco Mundial en su estudio. Desde un punto de vista del impacto en el costo de los modelos COTS o LDSW, estos varan en funcin de algunas variables en forma significativa entre las variables relevantes a la hora de analizar el costo se encuentran: cantidad de usuarios profundidad funcional 7

centralizado versus descentralizado

El propio Banco Mundial plantea un modelo de evaluacin de costos expresado en millones de dlares, en funcin de la cantidad de usuarios para desarrollo a la medida (LDSW) y software comercial (COTS):

_ = 0.0018 + 7.8135 _ = 0.0072 + 6.8046

Como se aprecia en las curvas, los costos bajan en la medida que aumenta la cantidad de usuarios. Las grficas siguientes muestran ambas curvas para pocos usuarios y para grandes cantidades de usuarios.

Ilustracin 16: Modelo de Costos - Pocos Usuarios

Fuente: Financial Management Information Systems World Bank, 2011

En el caso de gran cantidad de usuarios el comportamiento de los modelos se muestra en la siguiente grfica.

Ilustracin 17: Modelo de Costos - Gran cantidad de Usuarios

Fuente: Financial Management Information Systems World Bank, 2011

Esto es, la brecha entre ambos escenarios aumentan en la medida la cantidad de usuarios.

En la tabla siguiente se muestran los costos promedio para las alternativas de productos comerciales y desarrollos a la medida.

Tabla 8: Costo promedio por usuario - Banco Mundial

Tipo de Desarrollo Producto Comercial (COTS)

Fuente: Bank, 2011

Desarrollo a la medida (LDSW) Financial Management Information Systems

World

Costo Promedio Usuario ( 1 US$) 5.900 9 .000 32

Un elemento que se debe destacar es que el anlisis desarrollado por el Banco Mundial tiene proyectos desarrollado en modalidad cliente-servidor, los cuales aumentan los valores comparativamente con proyecto basados en una modalidad web, por lo que los costos podrn ser menores, ya que la modalidad cliente-servidor requiere de software en las puntas, con el consiguiente costo de su desarrollo, pero sobre todo del esfuerzo logstico que ello implica. La regin latinoamericana ha optado en forma mayoritaria por proyectos basados en desarrollos a la medida. En otras latitudes la seleccin de una u otra modalidad es bastante ms pareja. Por lo tanto, tal como lo analizamos la estructura de costos debe considerar los siguientes elementos: Mtricas de dimensionamientos, las cuales incluyen cantidad de usuarios, volumen de transacciones por tipo y frecuencia y finalmente volumen de datos. Esfuerzo, expresado en horas-hombre de las labores de ingeniera involucradas (diseo, desarrollo, adaptacin, capacitacin y soporte entre otras) Adopcin de usuarios, lo cual incluye todas las funciones de capacitacin, soporte usuarios final. Costos asociados a la adquisicin de software bsico y su posterior mantencin Costos asociados a la adquisicin de equipamiento y la mantencin asociada

32

Cabe sealar que este valor es muy sensible y para proyectos de gran tamao baja a 3.000, llegando a 15.000 en el caso de proyectos

pequeos.

Con sider acion es Cualitativas Existen algunas consideraciones adicionales al momento de evaluar los costos, que son ms de carcter cualitativo y que pueden influir en los costos finales del proyecto. Ellas estn fundamentalmente asociadas a la calidad del mercado oferente en el pas. Nos referimos a su madurez, competencias tcnicas y de gestin de proyectos de este tipo y envergadura. En el caso que en el pas no se cuente con profesionales conocedores de la tecnologa, esto incorpora riesgos importantes, los cuales en el largo plazo se traducen en mayores costos. Otro elemento adicional a la hora de evaluar costos es la experiencia de la empresa adjudicada para el desarrollo de este proyecto en trminos de cantidad de proyectos de similar envergadura que hayan desarrollado en el pasado. Es parte del anlisis y de elementos que pueden influir en el costo de la solucin, las restricciones institucionales que pudieren existir. Nos referimos a condicionantes a la hora de la contratacin o bien definiciones de estndares tecnolgicos nacionales que impacten en la decisin. Un ejemplo de ello es la opcin que ciertos Estados han tomado respecto del uso de open source versus productos comerciales o de restricciones asociadas a la contratacin de servicios en modalidad cloud computing. Este tipo de normas y/o definiciones previas pueden encarecer la solucin definida.

VI. Modelo de Evaluacin

El modelo de evaluacin debe considerar no slo los costos directos asociados a la implementacin ya que este anlisis podra estar sesgado y no contemplar elementos esenciales a la hora de definir el modelo ms adecuado para el pas. Analicemos algunas de estos criterios: Periodo de Evaluacin: Este tipo de proyectos debe ser analizado con horizontes de tiempo que van de 8 a 10 aos. La experiencia comparada indica que muchos de estos proyectos estn asociadas a modernizaciones de mayor envergadura (gestin del gasto pblico) que tienen procesos de maduracin con horizontes de tiempo como los planteados.

Vida til: La vida til de estos proyectos tienen dos componentes, nos referimos a la vida til tecnolgica, la cual no va ms all de 5 aos y la funcional, cuya vida til puede ser mucho mayor. En el caso de la vida til tecnolgica est asociada a la obsolescencia tecnolgica de las componentes que se utilicen en la implementacin de la solucin. En el caso de las soluciones basadas en productos COTS, estos tienen en general ciclos definidos de evaluacin, denominado roadmap del producto. En el caso de la vida til funcional, estas dependen de los modelos de negocio y la sistematizacin de estos. En el caso que existan cambios normativos mayores, el modelo funcional se mantendr durante el tiempo. Costos de Mantenimiento: En la evaluacin se deben incluir los costos de mantencin. En el caso de productos de software, estos se mueven dependiendo del producto en un rango que va entre 15% y 20% del costo de licenciamiento anualmente. Para efectos de la evaluacin del proyecto habitualmente se considera un periodo de 3 aos. Precios Sombra: Estos estn relacionados con el costo de oportunidad, en este caso debiera evaluarse el proyecto con respecto a la situacin sin la puesta en marcha de un sistema SIAF. Este tipo de evaluaciones se realiza al momento de iniciar el proceso. En este documento no hemos analizado esa situacin ya que como se mencion al inicio, damos por supuesto que se va a implementar un sistema SIAF. Existen otros elementos que impactan el anlisis. Nos referimos a la experiencia asociada a procesos de externalizacin y a la madurez del mercado oferente, ya que esto definir que tan profundo es el modelo de externalizacin que se quiere adoptar y/o se puede adoptar.

Modelo de Evaluacin COTS El estudio de Aberdeen reflej adicionalmente que los costos son muy dependientes de la cantidad de usuarios, lo cual parece algo ms o menos obvio, en la tabla siguiente se muestran los resultados del anlisis:

Tabla 9: Costos de Implantacin de ERP

Licencia U suarios o 38 ) 92 19 5 4 5 87 65 34 47 21 33 (USD 76.597 82.941 95.395 85.714 .364.286 .360.577 .652.500 1 2 2 1 4 6 9 6% 5% 0% 0% 4% 0% 5% s Mont % nto cin Mo % nto Implanta n 33 Mo % Mantenci Co sto Total Propiedad (USD) 2 3 84.295 2 1 .081.869 2 1 .719.551 1 1 .987.616 2 3 .092.021 2 5 .920.785 2 5 .918.809 Costo Usuario (USD) 34 1 3.854 5.304 8.157 .738 .712 .025 .068 1 1 7 8 6 2

Fuente: Group, 2007

Aberdeen

(US 1 D)4 26.022 4 3 51.374 4 5 81.090 5 6 55.263 4 1 .110.000 4 2 .081.000 4 2 .102.778

3% 2% 4% 3% 6% 5% 6%

(US 8 D)3 1.676 3 2 47.554 3 4 43.066 3 3 46.639 3 6 17.735 3 1 .479.208 3 1 .163.531

1% 3% 6% 7% 0% 5% 0%

Como se puede apreciar en el estudio de referencia, los costos por usuario varan desde cerca de 18.000 dlares a algo ms de 2.000 dlares, mantenindose ms o menos estable la distribucin de costos en trminos de licenciamiento, implantacin y costos de mantencin. El impacto de los tems de costos es:

33

Costos de mantencin por un periodo de 3 aos

34

El costo por usuario no se desprende directamente ya que algunas de las empresas contestaron el dato directamente y otras

contestaron toda la investigacin por lo que no se puede obtener directamente de la divisin

Tabla 10: Relacin de Costos de ERP's

rea de Costo Licenciamiento de Software Servicios de Implantacin Servicios de Mantencin nimo 0% 2% 7%

M 4 edia 3 4% 1 4% 2%

M 4 ximo 0% 3 6% 2 6%

M 5 3 2

En el anlisis realizado por Kavanagh y Miranda (Kavanagh, Miranda 2005) se identifican costos de software y de servicios, incluyendo estos ltimos los costos asociados a mantencin. En el anlisis se realiza una segmentacin por tipo de software ERP en dos niveles, esto es, el denominado TIER I correspondiente a productos de clase mundial orientado a grandes corporaciones e instituciones. Este tipo de productos es bastante sofisticado, habitualmente los consultores especialistas en estos productos son las grandes compaas consultoras 35. El TIER II corresponde a productos ms locales, menos sofisticados en trminos de cobertura funcional y que tienen una menor presencia mundial como es el caso de los productos evaluados por Chile y presentados con anterioridad. Adicionalmente las empresas que realizan implantaciones de este tipo de productos son firmas consultoras ms pequeas y en algunos casos se trata de los mismos fabricantes del productos de software ERP.

Tabla 11: Diferencial de costos segn tipo de ERP

TIE Licenciamiento de Software Servicios

Fuente: Technologies Transformation, 2010 for Government

TIE R II 0% 0% 4 6

RI 6% 4%

1 8

En base a los antecedentes anteriores para el caso de las implantaciones de sistemas SIAF, y considerando que se trata de plataformas muy masivas en trminos de cantidad de usuario, las distribuciones de costo que se debieran establecer corresponden a:

35

Nos referimos a empresas tales como: Accenture, IBM, Deloitte y otros.

Tabla 12: Distribucin de costos - SIAF

Licenciamiento de Software Proyecto de Implantacin Costos de Mantencin

Fuente: Desarrollo propio

Distribucin de Costos S 4 IAF 5% 3 6% 0% 2

Modelo de Evaluacin Desar r ollo a la Medida (LDSW) Hoy en da existen mltiples mtodos de estimacin de esfuerzo y por ende de costos asociados al desarrollo de software. En nuestro caso analizaremos bsicamente dos mtodos, lneas de cdigo (SLOC) y puntos de funcin (PF). Si bien existen otros mtodos, hoy la experiencia acumulada con estos mtodos, es ms amplia y por lo tanto tiene mayores niveles de precisin en sus estimaciones.

Lneas de Cdigo (SLOC) Este mtodo es probablemente el ms antiguo de los mtodos de estimacin de desarrollo de software y fue asociado a los modelos de Putman 36 y Boehm 37 . La estimacin de lneas de cdigo habitualmente se hace en base a criterio experto, otros sistemas similares y a experiencia de la industria, para ello se establecen tres niveles de estimacin de cada rea funcional: optimista (AFO), ms probable (AFMP) y pesimista (AFP) con lo cual se estima la cantidad de lneas totales para un sistema:

+4 +

=1 6

1 .000

36

Modelo: Software Lifecycle Management (SLIM) de 1979 Constructive Cost Model (COCOMO) publicado en 1981

37

Para llevar esta estimacin de tamao del proyecto a costos de desarrollo se utiliza un modelo exponencial del tipo:

= +

En el cual corresponde al costo marginal por cada mil lneas de cdigo, el exponente de KLOC y finalmente al costo fijo del proyecto. Estos parmetros dependen de la arquitectura y del lenguaje que se vaya a utilizar en el desarrollo. Algunos ejemplos de los valores a utilizar en el modelo pueden ser obtenidos de Caper Jones (Capers Jones 2008).

Puntos Funcin

de

Otro mtodo alternativo para la estimacin de costos de desarrollo es el mtodo denominado puntos de funcin desarrollado por Albrecht 38 (Albrecht 1979), para lo cual el sistema a desarrollar debe ser segmentado en cinco tipos de funciones, esto es: Entradas externas: se refiere a todas las funciones asociadas al ingreso de datos, un ejemplo de ello es un formulario de ingreso de datos. Salidas externas: Corresponde a todos los datos procesados para ser entregados a entes externos a la aplicacin (reportes, listados, archivos de intercambio). Consultas externas: corresponden a entradas-salidas que involucran una respuesta inmediata del sistema y no modifican datos internos.

Interfaces externas: Son todos las funciones asociadas al intercambio de datos con sistemas externos. Archivos internos: funciones de gestin de los datos internos de la aplicacin.

Con estas funciones se procede a contabilizarlas y asignarles un nivel de complejidad (bajo, medio, alto), para luego contabilizar todo el sistema:

38 Measuring Application Development Productivity, A. J. Albrecht, Proceedings of the Joint SHARE, GUIDE, and IBM Application Development Symposium, Monterey, California, 1979

Tabla 13: Clculo de Complejidad de Puntos de Funcin

B Entradas externas Salidas externas Archivos internos Interface externa Consulta externa x3 x4 x7 x5 x3 ajo

Compl ejidad Me dio x4 x5 x 10 x7 x4 x6 x7

A lto

x 15 x 10 x6

Para obtener la cantidad de puntos de funcin con su respectivo peso, denominado puntos de funcin no ajustados (UFP) este se obtiene de:

3 5

=
= 1 =1

Con esto se obtiene una idea bastante precisa de la cantidad de funciones con que cuenta el sistema. Adicionalmente Albrecht define algunas categoras sobre las cuales la aplicacin debe centrarse y que definirn el peso del esfuerzo para obtener los valores de ajuste con que el desarrollo debe ser sensibilizado, nos referimos a 39: Transferencia de datos (data communication) Funciones distribuidas Desempeo (performance) Procesos de configuracin Volumen transaccional 8


39

Ingreso de datos online Eficiencia para usuarios final Actualizacin online Procesamiento complejo

Mayor informacin en: http://www.softwaremetrics.com/fpafund.htm

Reutilizacin Facilidad de instalacin Facilidad operacional Mltiples ubicaciones (sites) Facilidad de mantencin

Cada una de estas caractersticas debe ser valorizada con un valor que va entre 0 y 5 (de menor a mayor nivel de complejidad), el valor final de ajuste a los puntos de funcin, se obtiene de la siguiente frmula:

14

= 0,65 + 0,01
=1

Por lo que el valor final de los puntos de funcin ajustados se obtiene:

El costo final del desarrollo ser funcin de algunas otras variables tales como, nivel de productividad del equipo de trabajo, el cual se expresa como cantidad de puntos de funcin por hora, generalmente y dependiendo del nivel de conocimiento y background del equipo de proyecto este se mueve entre 8 y 24 horas por punto de funcin dependiendo de varios atributos (lenguaje, arquitectura, productividad y otros). Una forma de determinar este valor es en base a la historia del desempeo del equipo de proyecto.

El costo final del proyecto se determinar de la siguiente forma:

___

Segn el experto Capers Jones, la productividad de puntos de funcin depende del tipo de software que se est desarrollando, la metodologa a utilizar y envergadura del desarrollo, algunas mtricas de productividad Puntos de Funcin (PF) por staff mensuales. En la tabla siguiente se muestran algunos ejemplos de productividad por equipos de proyecto segn tamao del desarrollo y la metodologa utilizada:
Tabla 14: Productiviad de Equipo de Desarrollo en funcin de tamao y mtodo

M todo 0 PF 50 50 00 00 ,50 .00 .50 64 Capers

40

CMM Nivel 5 Orientado a objeto (OO) RUP Scrum CMM Nivel II Cascada CMM Nivel I Promedio
Fuente: Applied Software Measurement, Jones, 2008

Tamao del Desarrollo expresado en puntos 1.00 10.0de 100.0 funcin (PF) 00 PF 00 PF 12, 9 7 ,25 8 ,75 6 15, 11, 23, 7 8 6 13, ,25 ,50 ,00 ,00 .50 .50 ,00 7 7 4 2 1 7 ,75 ,50 ,25 ,25 ,50 .25 ,23 5 5 2 1 1 5

Existe una gran cantidad de herramientas en la web que permiten evaluar el esfuerzo para un proyecto especfico. Incluso existen algunos sitios web que cuentan con calculadoras on-line de puntos de funcin 41 el principal desafo a la hora de generar las estimaciones reside en los parmetros a usar, en particular los niveles de productividad. En el caso de que no se cuente con parmetros especficos de la situacin que se est evaluando es recomendable utilizar mtricas comnmente aceptadas y aumentar los factores de riesgo de la estimacin. De ambos mtodos hoy por hoy el ms utilizado es el correspondiente a puntos de funcin, si bien por ambos caminos se puede llegar a un resultado equivalente ya que:

40

El promedio fue calculado con otros mtodos adems de los mostrados en esta tabla, mtodos que son menos comunes en el

caso de los desarrollos del tipo SIAF

41

Algunos ejemplos de calculo online de puntos de funcin tal es el caso de

http://developergeeks.com/functionpoint.aspx y http://groups.engin.umd.umich.edu/CIS/course.des/cis525/js/f00/harvey/FP_Calc.html

 =
Siendo parmetro puede ser consultado en mltiple bibliografa. como una forma de chequeo y validacin del resultados final. Est alternativa puede ser utilizada

un

parmetro que depende del tipo de sistema y del lenguaje utilizado, este

Productividad del Sector Pblico Una de las variables relevantes en la evaluacin en base a puntos de funcin, es el nivel de productividad de los equipos de desarrollo para lo cual se debe utilizar la experiencia previa de desarrollo de software. En caso que no exista una mtrica precisa, es factible utilizar mtricas internacionales considerando las diferencias propias de cada mercado. Se adjunta como anexo niveles de productividad del sector pblico para diferentes lenguajes. En su estudio Software Development Projects in Government, desarrollado por International Software Benchmarking Standards Group, se efectu un anlisis del comportamiento de los proyectos de desarrollo de software 42, que permiten contar con algunas mtricas asociadas a dicho desempeo. Entre estas mtricas podemos destacar las siguientes: Los proyectos del sector pblico son aproximadamente un 8% ms productivos que los del sector privado. Los proyectos desarrollados en la modalidad in-house son 14% ms productivos que aquellos en una modalidad externalizada.

Los valores anteriormente sealados pueden utilizarse para sensibilizar los resultados del modelo.

Dimensionamiento Algunas mtricas de carcter aproximado, de un par de experiencias de desarrollos a la medida en la regin, es relevante destacar que se trata de mtricas aproximadas y slo deben utilizarse
42

Corresponde a una muestra de cerca de 2.000 en 30 pases lo que permiten un anlisis bastante preciso de dicho comportamiento.

como una referencia, ya que cada caso depender como se mostr anteriormente de la cobertura funcional y el alcance del proyecto.

Tabla 15: Dimensionamiento de costo desarrollo

M CASO 1trica Atributos

V alor Pas tamao medio Cobertura gobierno central

Cobertura funcional de mediana complejidad Puntos de Funcin (estimado) LOC Horas-Hombre desarrollo CASO 2 Atributos 15. 500 PF 8 50.0003 80.000 Pas de gran tamao Estructura federal Alta complejidad 48. 000 PF

Puntos de Funcin (estimado)

Fuente: Antecedentes recopilados en la regin por el autor

El primer caso se trata de un pas de la regin de tamao medio y que ya ha recorrido algo de camino en este proceso, su desarrollo contempl slo el gobierno central y una cobertura funcional del software slo parcial. En el segundo caso se trata del otro extremo, es decir, un gran pas con estructura federal y de alta complejidad. Considerando costos promedios por punto de funcin segn Caper Jones, para desarrollo de sistemas comerciales en Estados Unidos y los costos promedios en la modalidad de offshore, generalmente correspondiente a factoras de software en India y otros pases, para los casos anteriores se obtienen los siguientes costos de desarrollo.

Tabla 16: Estimacin de costo desarrollo

CASO 1 Desarrollo de Software USA Desarrollo Offshore CASO 2 Desarrollo de Software USA Desarrollo Offshore

Costo Unitario (U S$/PF) .518 819

P F 1 1 5.500 1 5.500 1 4

Cost o Total ( US$) 23.5 44.000 12.6 94.500 72.9 12.000 39.3 12.000

8.000 4 8.000 Fuente: Desarrollo propio sobre la base de antecedentes recopilados en la regin
por el autor

.518 819

Para efectos de anlisis en la regin es razonable utilizar un costo punto de funcin en torno a los US$ 1.000 por punto de funcin como un buen proxy, sin perjuicio de que cada pas tiene su propia realidad que debe ser evaluada. Cabe sealar que estos costos no incluyen el resto de las componentes, tales como mantencin, infraestructura y operacin, las cuales al momento de realizar una estimacin de costos completa debieran incluirse.

Funcin de Costos Por lo tanto la funcin de costos para un proyecto SIAF debe contemplar los siguientes elementos:
Tabla 17: Elementos de Costo - Proyecto SIAF

rea Hard ware

Desc ripcin Costo del equipamiento necesario para desarrollo y produccin Costos de mantencin anual de la plataforma (), para efectos de evaluacin considerar un periodo de 3 a 5 aos Costo de la plataforma de software bsico, la cual debe incluir el software necesario para el desarrollo y operacin del SIAF. Este costo

So ftware B sico

habitualmente est asociado a la cantidad de usuarios. En el caso de productos open source este costo podra ser 0, pero deber considerarse costos de soporte. Costos de mantencin anual de la plataforma de software bsico
().Para

efectos de la evaluacin considerar un periodo 3 a 5 aos. En el caso deEn este punto es cuando se producen las mayores diferencias productos open source estos costos corresponden a horas de entre ellos modelo COTS y LDSW. soporte. COTS: Debe incluir el licenciamiento y los costos asociados al Soft proceso de adaptacin del producto. ware LDSW: Costos asociados a los equipos de desarrollo, para lo cual Aplic su estimacin debe basarse en los mtodos anteriormente ativo anunciados. Puest a en cha Costos asociados a la puesta en marcha del sistema, el cual debe incluir capacitacin, documentacin y soporte. Estos costos Mar corresponden fundamentalmente horas-hombre. Se debe considerar a un costo asociado a la gestin global del proceso, lo cual dependiendo de la envergadura del proyecto debiera considerar una oficina de proyectos (PMO). Las estimaciones para este tipo de actividades van entre 10% y 15% del costo total del el proyecto. Estimar un monto de contingencia para el proyecto, cual debe cubrir aquellos elementos no considerados y/o desviaciones de la estimacin inicial, para este tem en general se utilizan valores que van entre 5% y 10% 8

Gest in del Pr oyecto Contin gencia

La funcin de costos sera:

_ = ( + ) + ( + ) + + + +
Esta funcin debe ser sensibilizada respecto de otros proyectos, de forma tal que los rangos que tienen algunas de las variables puedan ser acotados, en caso que no exista experiencia previa debe tomarse el peor escenario. Por otra parte, como una forma de aislar el problema y poder tomar la decisin respecto de los escenarios desarrollo a la medida versus COTS, algunas de estas variables se pueden considerar constantes en ambos casos, como son las adquisiciones de hardware y un porcentaje del software bsico.

Proceso Simplificado de Pruebas

Info rmacin Programa

Prue ba del

PLAN DE PRUEBAS

Re sultado Esperado

Res ultado Prueba

T asa E

E valuar

E rrores

Modelo de Fiabilidad
Prediccin Fiabilidad del Sistema

Depuraci n

Nuevo Cdigo, Diseo, Anlisis, etc

Pruebas de Caja Negra

D atos

PROCE SO

alida

RROR

Con junto de Casos Pruebas

COMPARAD
S alida Esperad

OR

N O ERROR

Pruebas de Caja Blanca (I)

Una Decisin: Dos Caminos

Dos Decisiones: Tres Caminos

Pruebas de Caja Blanca (II)

1-2-4-6 1-3-5-6

Cubren todos los Caminos

1-3-4-6

No Aseguran

5. Procedimientos administrativos de verificacin.

Las anomalas encontradas en la verificacin de los documentos desarrollados, sern comunicadas inmediatamente en forma directa al equipo de desarrollo, en el documento Reporte de problema de Software que se muestra a continuacin. Luego de notificar las anomalas encontradas la resolucin de estas deber estar finalizada en un periodo mximo de una semana. Por otra parte, las anomalas encontradas en la validacin de los documentos, sern comunicadas directamente va e-mail al equipo de desarrollo. La resolucin de estas deber estar finalizada a ms tardar una semana despus de la notificacin electrnica y se desarrollara priorizando los requisitos de usuario relacionados con el problema. En el caso, de la comunicacin electrnica el equipo de SVV esperara una confirmacin de la notificacin de las anomalas por parte del equipo de desarrollo para as evitar fallas comunicacionales; atrasando el desarrollo del proyecto. El documento que se presenta a continuacin, se utilizar para proponer soluciones o mejoras de software, dada su estructura que, permite reportar anomalas como proponer las soluciones que permitan superarlas. Reporte del Problema de Software

5.1 Reporte y resolucin de anomalas

REPORTE DE PROBLEMA DEL SOFTWARE AUTOR

SPR N FECHA

1. Ttulo del elemento de software Nombre e identificador del trozo de cdigo que presenta el problema 2. Nmero de entrega/versin del elemento de software Nmero de entrega y revisin 3. Prioridad Indicar si el problema es de carcter : Crtico: presenta riesgo para las persona Urgente: Compromete gran parte del funcionamiento del software Rutinario: No presenta urgencia de resolucin 4. Descripcin del Problema Detallar la falla o problema que presenta el elemento de software en cuestin 5. Descripcin del Ambiente Definir el ambiente operacional bajo el cual se present el error, las condiciones que lo desencadenaron 6. Solucin Recomendada Presentar una posible solucin a seguir, o lo que debiera hacer el software funcionando correctamente 7. Decisin de la mesa de revisin de software Se detalla el veredicto dado por el equipo encargado de las revisiones con respecto al problema planteado en el documento y la solucin propuesta 8. Documentos Adjuntos Mencionar los documentos que pueden respaldar la existencia del problema reportado, o que corroboran la solucin propuesta, y adjuntarlos al presente documento

5.2 Polticas de iteracin de tareas.

El proceso de verificacin del software se realizar en base a revisiones iterativas del mismo, contrastndolas tanto con los requisitos de usuario como con las especificaciones tcnicas que debe cumplir cada uno. Al principio del proceso, cuando an no se ha realizado ninguna actividad de SVV, cuando se realice la primera revisin se tendr una cierta cantidad de errores. Estos errores deben ser corregidos y el software nuevamente deber someterse a verificacin. Se realizar el proceso de iteracin hasta que se haya logrado resolver al menos un 90% de los errores encontrados en la primer iteracin. La iteracin de la validacin de los documentos a desarrollar en la etapa SR se efectuara luego de que el equipo de desarrollo resuelva los problemas notificados. Dado que el presente documento corresponde slo a una estimacin de lo que suceder en el proyecto, eventualmente puede ocurrir un cambio en la programacin de proceso de desarrollo, ya sea en la calendarizacin y lo que ello implique, como es en el presupuesto aqu presentado. En el caso de alguna de esas situaciones, habr cambios tambin en la verificacin respecto de lo que presenta originalmente este documento. Sin embargo, la gerencia y subgerencia se hacen responsables del cumplimiento de la planificacin por parte de los ingenieros de especialidad.

5.3 Polticas de desviacin.

Al ocurrir una desviacin del plan, deber generarse un reporte, el cual es presentado a continuacin con sus respectivas instrucciones de llenado. Su objetivo es, reportar la desviacin o diferencia con respecto al plan vigente en el momento que ocurra para SVV. Por otra parte, deber modificarse el presente documento para que el SVVP contenga efectivamente lo presupuestado.
Reporte de Cambios en SVV

REPORTE DE CAMBIOS EN SVV AUTOR 1. Cdigo Del Documento

Nmero de referencia del documento, dado por SCM

RC-SVV N FECHA

2. Nmero de entrega/versin del documento

Nmero de entrega y revisin

3. Descripcin de la desviacin
Indicar cual era la programacin original, y en qu ha sido desviada

4. Causa de la desviacin
Razn por la cual ha ocurrido el cambio en la programacin

5. Decisin de la mesa de revisin del software

Se detalla el veredicto dado por el equipo encargado de las revisiones con respecto a la diferencia ocurrida entre lo planificado y lo efectivamente realizado, para aprobar o no, dicho cambio.

6. Documentos adjuntos
Mencionar los documentos que pueden respaldar la razn por la cual se dio el cambio en la programacin, y adjuntarlos al presente documento

SVV ocupara la notificacin del N de revisin de los documentos entregados para el control en esta fase; no se utilizarn mecanismo de control de acceso o de seguridad. Se controlar por parte del gerente y subgerente de SVV, que el o los ingenieros de especialidad cumplan con los plazos y compromisos adquiridos con el jefe de proyecto. Para esto la gerencia y subgerencia de SVV harn conjuntamente un seguimiento del cumplimiento de tareas por parte de los ingenieros de especialidad, y sern los responsables del desempeo de ellos.

5.4 Procedimientos de control.

Se usar el estndar de la ESA PSS-05-0 para realizar la verificacin y la validacin de los productos de software obtenidos a lo largo del ciclo de desarrollo. Para realizar la verificacin y validacin de los requisitos de usuario, es necesario tener como supuesto que es el cliente mismo, quien se hace responsable por los requisitos de usuario. No se realizarn pruebas formales (6.2 del presente documento) en los casos que est fuera del mbito del objetivo de desarrollo del proyecto.

5.5 Estndares, prcticas y convenciones.

6. Actividades de verificacin
6.1 Plantilla de la matriz de trazabilidad.

Se desarrollar una matriz de trazabilidad para verificar que cada input de la fase SR, es decir los requisitos de usuario, tenga un output en la fase SR, es decir los requisitos de software. Es importante que ningn requisito de usuario haya sido pasado por alto y adems que una actividad haya sido especificada para todas las posibilidades de input. Por lo tanto, esta matriz de trazabilidad permitir al IE de SVV demostrar la completitud de los requisitos de usuario y software, ya que los espacios vacos en la matriz indican claramente la existencia de incompletitud. A continuacin se presenta la plantilla a utilizar para realizar el seguimiento de los requisitos de usuario hacia los requisitos de software. Debe tenerse en cuenta que durante la fase UR no hay requisitos de usuario a los cuales hacerles un seguimiento debido a que las especificaciones en la calidad del software no las ha requerido en este caso, por lo que esta matriz de trazabilidad, se aplica a partir de la fase SR.

Matriz de Trazabilidad CS S R 01 R 02 R 03 U U U R 01 S R02 S R 03 S

Por fila, para cada requisito de usuario se muestra los requisitos de software que lo satisfacen, lo que se indica por la presencia de un visto bueno o cruz en el casillero correspondiente a esa componente de software. Por columna, para cada componente se indica con un visto bueno o cruz en el respectivo casillero, el requisito de software al cual obedece. No debe haber columnas o filas en las cuales no haya al menos un casillero marcado, pues ello significara que existiran requisitos del software funcionales no justificados por la existencia de al

menos un requisito de usuario. Es importante mencionar que se debe incluir todos los requisitos de software, funcionales y no funcionales. No se plica en esta etapa ya que no se harn revisiones tcnicas. Esta actividad se empezara a desarrollar desde la fase de diseo arquitectnico en adelante.

6.2 Pruebas formales

6.3 Revisiones
Las revisiones de los documentos desarrollados se realizaran segn los procedimientos de la gerencia de SVV descritos en el estndar de la ESA. PSS-05-0 En la fase SR, se debe confirmar la correspondencia entre los requerimientos de usuario obtenidos en el URD y los requisitos de software obtenidos en el SRD, para lo cual se utilizar la matriz de trazabilidad. Tambin en esta fase, es necesario evaluar la construccin del modelo lgico y los documentos generados, para lo cual se utilizarn las caminatas y las inspecciones de software. Las caminatas estn orientadas a identificar defectos y considerar posibles soluciones. Las inspecciones de software estn orientadas a detectar problemas por no conformidad con el estndar, formato, etc. Por ltimo en la fase SR/R se harn revisiones tcnicas para evaluar los productos de la fase en conformidad con los procedimientos establecidos para el proyecto, el estndar, especificaciones realizadas en la etapa anterior, etc. Revisiones: Se realizarn tanto revisiones tcnicas, para verificar el progreso de cada elemento de software respecto a lo planificado, como las inspecciones de software, las cuales permitirn detectar e identificar defectos. Estas estarn basadas principalmente en revisin de la documentacin generada, as como del cdigo mismo. Adems, se realizarn revisiones de tipo caminatas para revisar los cambios de tipo estilsticos en el software. o Revisiones Tcnicas: Se evaluarn elementos de software especficos para verificar el progreso con respecto a la planificacin, para proveer informacin acerca de la conformidad del elemento de software con las especificaciones hechas en etapas anteriores, si ste ha sido producido de acuerdo a los estndares y procedimientos seguidos en el proyecto, y si los cambios sugeridos para tal elemento en revisiones anteriores han sido implementados. o Inspecciones de software: Se utilizarn para evaluar tanto documentos generados como cdigo, antes de las revisiones tcnicas y de las pruebas. El objetivo de stas es detectar e identificar errores en el software, es decir, disconformidad con respecto a las especificaciones que debe implementar un determinado elemento de software, y con respecto al apego y estndares y procedimientos. Trazabilidad: Se realizar un seguimiento de los requisitos a travs de matrices de trazabilidad, una que relaciones UR con los SR que los satisfacen (para la fase SR), y otra que relacione SR con las componentes que los satisfacen (para las fases AD y DD), hasta que se haya obtenido la implementacin de cada uno de los requisitos de usuario que hayan sido especificados. Testing: Se realizar para confirmar que se estn satisfaciendo los requisitos especificados por el usuario y para identificar diferencias entre los resultados esperados y obtenidos. Los tipo de prueba que se llevarn a cabo son los siguientes: o Pruebas de integracin o Pruebas de unidad o Pruebas de sistema o Pruebas de aceptacin

En particular, durante la fase SR/R se realizar una revisin tcnica del SRD generado en la fase SR.