En este captulo se desarrollaran los objetivos propuestos para este trabajo. 1. ANLISIS DE LOS PROCESOS DE DESARROLLO DE SISTEMAS INFORMTICOS EN EL PROYECTO ESPECIAL SIGA DEL MINISTERIO DE ECONOMA Y FINANZAS DEL PER
METODO:
A. REVISIN DE DOCUMENTACIN: Para el desarrollo del presente mtodo se realizar la revisin de toda la documentacin oficial de los 5 ltimos proyectos de desarrollo de sistemas informticos en el proyecto especial SIGA del Ministerio de Economa y Finanzas del Per.
CONCLUSIONES: No existe documento alguno en el cual se tenga informacin respecto al cronograma y recursos utilizados en los proyectos. En los proyectos revisados, slo existen 3 documentos: documento de anlisis funcional, documento de anlisis de sistema y documento de pase a produccin. Existe un grupo de personas que realizan pruebas de calidad, sin embargo no existe un documento de pase a calidad ni de anlisis de calidad, tanto el pase como las observaciones y aprobacin final por parte de calidad se manejan a travs de correo electrnico. No se cuenta con una plantilla de ejemplo y/o gua para el llenado de estos 3 documentos, ya que en todos los casos dichos documentos difieren; en cuanto a estructura; unos de otros. El documento de anlisis funcional slo contiene los requerimientos funcionales del proyecto, los cuales en muchos de los casos son ambiguos y no se encuentran debidamente especificados. El documento de anlisis de sistema contiene: o Diagrama de Casos de Uso: los cuales, en los proyectos revisados, se encuentran mal definidos. o Prototipos: los cuales aparentemente fueron hechos despus del desarrollo ya que son captura de las pantallas desarrolladas. Oliveros Ocrospoma Miguel Angel
o Diagrama de Clases: los cuales difieren en su diseo unos de otros, ya que algunos tienen solamente el nombre de la Clase, otros incluyen atributos y hay algunos que tambin incluyen los mtodos. La mayora de los documentos de anlisis de sistema parecen haber sido realizados despus del desarrollo del software. El documento de pase a produccin contiene escasa informacin relevante as como carecer de mecanismos de regresin en casos de falla.
B. OBSERVACIN Para el desarrollo del presente mtodo se observar la forma de trabajo de 3 proyectos, actuales, de desarrollo de sistemas informticos en el proyecto especial SIGA del Ministerio de Economa y Finanzas del Per.
CONCLUSIONES: Los proyectos no cuentan con una metodologa estndar para ser gestionados de manera integral ni tampoco en ninguna de las fases del ciclo de vida de estos. No existen polticas ni estndares oficiales aplicables a los proyectos. Los proyectos no pasan un filtro previo, dentro del equipo SIGA, antes de ser aceptados. Con esto se pierde el enfoque de apoyo a las metas y objetivos estratgicos institucionales por parte del equipo. Actualmente se est desarrollando un proyecto que por el negocio y enfoque del mismo debi ser asignado a otro equipo de trabajo. No existe una adecuada gestin de recursos ya que estos son tomados de manera aleatoria generando sobrecarga en muchos de ellos y holgura en otros. Los recursos muchas veces desempean ms de un rol en los proyectos a los cuales son asignados. No se gestionan los riesgos de los proyectos. Los tiempos no son gestionados adecuadamente. En la mayora de proyectos slo se tiene una fecha estimada de culminacin la cual no se encuentra debidamente documentada. Los proyectos no cuentan con un documento que ayude a definir el alcance claramente, existe un documento de requerimientos funcionales el cual nicamente cuenta con Oliveros Ocrospoma Miguel Angel
un listado requerimientos funcionales que en su mayora suelen ser redundantes y algunos son ambiguos. No se cuenta con un diagrama de procesos tanto actual como propuesto. El documento de anlisis de sistemas es hecho despus del desarrollo del software y es visto como una prdida de tiempo. No se tiene conocimiento claro de cmo hacer los requerimientos de sistema, los diagramas y artefactos incluidos en el documento de anlisis. No se cuenta con un documento de diseo de sistemas. Todos los proyectos desarrollados cuentan los mismos frameworks (zk, spring, hibernate), sin embargo no cuentan con una arquitectura ni estructura estndar, as mismo los estilos del diseo de las pantallas difiere entre uno y otro y el cdigo no se encuentra documentado. Existen muchos problemas en la integracin de sistemas sobretodo desarrollados entre los 2 principales equipos de desarrollo del MEF, los cuales son el equipo SIGA y el equipo SIAF, esto se debe a que los proyectos de ambos equipos requieren consumir datos de las bases de datos de estos, y el problema reside en que los cdigos y nomenclaturas de muchos de estos no se encuentran estandarizados por lo cual cada equipo define estos a su parecer generando problemas a futuro como los que se tienen actualmente. Estos problemas hasta el momento han ocasionado perdida de informacin en produccin as como la generacin de data inconsistente y sancin al personal de ambos equipos. Cuando un nuevo recurso es asignado a un proyecto en curso o a darle mantenimiento a un sistema, este tiene una curva de aprendizaje demasiado alta ya que no se cuenta con documentacin suficiente que facilite su adaptacin y familiarizacin con el proyecto ya que debe leer todo el cdigo e interpretarlo, lo cual adems de generar retraso tambin genera inconsistencia y cdigo redundante. Cuando se culmina el desarrollo, se convoca a una reunin con los miembros del equipo de control de calidad y se les explica cmo funciona el software, en base a esto y al conocimiento del negocio que tienen, los miembros de calidad, ellos piden que se les genere un link para que puedan hacer sus pruebas. Oliveros Ocrospoma Miguel Angel
No se cuenta con un documento de plan de pruebas, todas las pruebas realizadas son funcionales. Si el personal de calidad encuentra un error ellos lo registran en un sistema de control de errores en el cual describen el error y adjuntan una captura de pantalla, y posteriormente envan un correo al desarrollador informndole que han registrado errores. Muchas veces registran sus propuestas de mejora, como si fuesen errores. Una vez que ya se levantaron todas las observaciones registradas, el personal de calidad comunica al desarrollador que ya no existen ms observaciones y envan un correo dando su conformidad para que se realice el pase a produccin. Antes de realizar el pase a produccin el desarrollador hace la documentacin de anlisis de sistema, luego continan con el llenado del formato de pase a produccin el cual nicamente cuenta con 4 puntos. En paralelo, al punto anterior, se asigna un documentador para que realice el manual del sistema. Una vez ejecutado el pase a produccin, por parte del personal de produccin, estos envan el enlace generado de la aplicacin para que el equipo SIGA verifique y de su conformidad.
C. ENCUESTAS Para el desarrollo del presente mtodo se realizarn 2 encuestas; la primera ser aplicada a los jefes y coordinadores de proyectos y la segunda al resto del personal entre los cuales se encuentran los analistas, diseadores, desarrolladores, testers y documentadores; a los miembros del proyecto especial SIGA del Ministerio de Economa y Finanzas del Per, las encuestas son las siguientes:
Las encuestas aplicadas deben de ir en anexos
Datos generales: Nombres y apellidos Nmero de DNI Edad Profesin Oliveros Ocrospoma Miguel Angel
Aos de experiencia laboral en proyectos de desarrollo de software.
Encuesta 1:
Qu cantidad de proyectos suelen manejar en paralelo? De qu manera gestionan los proyectos? Asigna prioridades a los proyectos? En caso de ser afirmativa la respuesta, especifique en que se basa para asignar las prioridades y en que escala estn. De qu forma asignan los recursos disponibles a cada proyecto? Utilizan una metodologa estndar para gestionar cada proyecto? Qu indicadores utiliza para evaluar el rendimiento de cada proyecto? En caso de utilizar indicadores, Los indicadores utilizados son los mismos para todos los proyectos? En caso de que no sea as explique por qu y de forma varan. En caso de utilizar indicadores, Qu porcentaje de stos son entregados en promedio? En caso de utilizar indicadores, Cules de los indicadores son los que menos se entregan y en qu porcentaje estn? La manera en que gestionan los proyectos le permite tener una visin clara del rendimiento de cada uno de estos y a su vez ver el resultado reflejado en trminos de rentabilidad? Tiene conocimiento de ontologa? En caso que la respuesta sea afirmativa, describir que es una ontologa. Actualmente, Utilizan ontologas en sus proyectos? Cree que es necesario contar con una capa de ontologa en los proyectos que desarrollan? En caso de ser afirmativa, indique Qu resultados espera obtener con la aplicacin de ontologas en sus proyectos? Cuentan con un documento de lecciones aprendidas? Toman en cuenta los objetivos y estrategias organizacionales durante el desarrollo de cada proyecto? En caso de ser afirmativa su respuesta, diga de qu forma alinean ambos.
Encuesta 2:
Oliveros Ocrospoma Miguel Angel
Qu rol desempea en los proyectos a los cuales est asignado? Alguna vez ha desempeado ms de un rol en un mismo proyecto? En caso de ser una respuesta afirmativa, indique cuales son aquellos roles por proyecto. Tiene una metodologa de trabajo definida? En caso de tener metodologa, Indique cul es y describa brevemente sus procesos. En todos los proyectos, en los cuales ha participado asumiendo el mismo rol, se ha seguido el mismo proceso? En caso de ser negativa la respuesta anterior, Indique por qu no se ha seguido el mismo proceso? Alguna vez ha utilizado una metodologa de desarrollo de software? En caso de ser afirmativa la respuesta a la pregunta anterior, indique Cul(es) es/son la(s) metodologa(s) que utiliz y cul es su opinin respecto a esta(s)? Tiene conocimiento de ontologa? En caso que la respuesta sea afirmativa, describir que es una ontologa. Alguna vez ha diseado o desarrollado ontologas? Actualmente, Utilizan ontologas en sus proyectos?
Conclusiones:
En lugar de recomendaciones debemos de tener tabulados los resultados de las encuestas para luego hacer un anlisis y tener las recomendaciones que nos lleven al marco de trabajo a proponer, todo esto luego del anlisis de las metodologas estandares.
RECOMENDACIONES: 1. Se debe definir un modelo a medida para la gestin de proyectos de desarrollo de sistemas de informacin en el equipo SIGA acorde a su realidad. 2. Se debe capacitar al personal en el uso del modelo. 3. Se debe de contar con un filtro previo a la aceptacin de un proyecto, el cual deba contemplar que los proyectos a desarrollarse se alineen con los objetivos estratgicos del equipo SIGA. 4. Se debe tener un plan de proyecto el cual permita manejar y gestionar adecuadamente el tiempo, costo y alcance del proyecto. 5. Se debe de manejar una matriz de riesgos del proyecto. 6. Se deben definir los roles y sus respectivas responsabilidades. Oliveros Ocrospoma Miguel Angel
7. Se debe contar con una matriz de trazabilidad para la compatibilidad de los roles que puede asumir un mismo recurso dentro de un proyecto. 8. Se deben definir entregables como parte del modelo y tener plantillas de estos con instrucciones que faciliten su llenado. 9. Se debe contar con actas de reuniones y conformidad que sustenten el avance del proyecto. 10. Se debe contar con un documento que permita tener una visin general del proyecto que sea entendible sin necesidad de tener detalles tcnicos. 11. Se debe contar con un documento de lnea base del proyecto a travs del cual se tenga una visin del estado del proyecto. 12. Se debe contar con un diagrama de proceso del negocio. 13. Se debe contemplar, como parte del modelo, un proceso de anlisis y construccin de ontologas para resolver el problema de la integracin de los diferentes sistemas desarrollados por el equipo SIGA. 14. Se debe contar con un documento de anlisis de software. 15. Se debe contar con un documento de diseo de software. 16. Se debe contar con un plan de pruebas. 17. Se debe contar con un documento de ejecucin de pruebas en el cual se documente la ejecucin y resultado de cada prueba realizada. 18. Se debe contar con un instructivo de configuracin e instalacin del software, en el cual se deba incluir un mecanismo de regresin. 19. Se debe contar con una plantilla y estructura estndar para la elaboracin de los manuales de usuario.
2. ANLISIS DE LAS METODOLOGAS ESTNDARES DE GESTIN Y DESARROLLO DE PROYECTOS Y DE ANLISIS Y DESARROLLO DE ONTOLOGAS PARA SISTEMAS INFORMTICOS
METODO: Anlisis de lectura.
OPM3: o OPM3 es el primer modelo de su clase, que describe las mejores prcticas para la gestin de proyectos, gestin de programas, y gestin de carteras en un modelo de madurez. se alinea con el PMBOK, un estndar aceptado globalmente para la gestin de proyectos. Nos permite: Oliveros Ocrospoma Miguel Angel
o Ganar conocimiento sobre lo que constituye las mejores prcticas en la gestin de organizacional de proyectos. o Medir el nivel de madurez actual de la gestin de proyectos en la organizacin. o Identificar una trayectoria para el mejoramiento continuo, basada en el conocimiento de las mejores prcticas y en el nivel de madurez actual de la gestin de proyectos de la organizacin. (Colocar las citas a la referencia bibliogrfica)
UPMM: o UPMM es un modelo desarrollado sobre PMS (Portfolio Management Standar) y OPM3, abordando y cubriendo completamente las reas de gestin de portafolio extendidas tanto del modelo OPM3 como del PMS. Este modelo a dado mejores resultados al ser aplicado para portafolio de proyectos comerciales como de inversin. Este modelo permite realizar un cambio organizacional , en la gestin de portafolio de proyectos, con las siguientes caractersticas: o Cambiar en el camino los componentes que son mejorados. Moviendo recursos entre los componentes. o Cambios en la composicin del portafolio. Cerrando los componentes que no tienen posibilidad de conseguir la meta para la cual fue creado. o Sugerencias para una modificacin estratgica. Permite concentrarse en las actividades de la organizacin sobre una de las metas estratgicas.
CONCLUSIONES:
Habiendo analizado ambos modelos y tomando en cuenta que la presente tesis est enfocada a brindar una solucin a empresas del sector micro financiero, se puede rescatar 2 puntos relevantes: El modelo OPM3 ha sido desarrollado tomando en cuenta la realidad de grandes y medianas empresas en el mundo, motivo por el cual la cantidad de recursos requeridos y los puntos a implementar as como grado de experiencia y conocimientos sobre PMBOK de los miembros de estos, lo Oliveros Ocrospoma Miguel Angel
hace poco adaptable al tipo de empresa a la cual nos enfocamos. El modelo UPMM por ha sido desarrollado en base a OPM3 presenta un diseo ms flexible y acorde con empresas medianas y pequeas pero no ha sido enfocado para la gestin de proyectos informticos puesto que su aplicacin en el mercado mundial se ha dado mayormente en proyectos comerciales y de inversin.
RECOMENDACIONES: Se recomienda utilizar el modelo OPM3 como base puesto que es ms completo y se puede abstraer de las mejores prcticas y adaptarlas a las empresas del sector micro financiero acorde a las caractersticas que estas presentan. Sin embargo tambin se debe utilizar como apoyo el modelo UPMM puesto que por el hecho de haber sido desarrollado orientado a empresas medianas y pueden tener caractersticas que se adapten adecuadamente a las empresas micro financieras.
3. ELABORACIN DE LA PROPUESTA DE MODELO DE GESTIN DE PROYECTOS DE DESARROLLO DE SISTEMAS INFORMTICOS BASADOS EN ONTOLOGAS EN EL PROYECTO ESPECIAL SIGA DEL MINISTERIO DE ECONOMA Y FINANZAS DEL PER
METODO: Implementacin
RESULTADO: Modelo de Gestin de Proyectos de Desarrollo de Sistemas Informticos Basados en Ontologas en el Proyecto Especial SIGA del Ministerio de Economa y Finanzas del Per:
3.1. Roles/ Responsabilidades: En este punto definiremos los roles que deben existir en los proyectos a desarrollarse, as como la descripcin de sus responsabilidades.
3.1.1. Jefe/coordinador del proyecto especial SIGA: Cdigo: JC Oliveros Ocrospoma Miguel Angel
Responsabilidades: Recibir la carta de solicitud de proyecto, y dar el visto bueno de la viabilidad o no viabilidad del proyecto, en una primera fase. Es el Stakeholder con mayor influencia en el proyecto, por parte del equipo del proyecto especial SIGA. 3.1.2. Jefe de Proyecto Cdigo: JP Responsabilidades: Identificar inicialmente si un proyecto es o no viable. Es el principal responsable de la elaboracin, actualizacin adecuada y cumplimiento del plan de proyecto. Asegurar la calidad del proyecto revisando el cumplimiento del modelo y los estndares definidos por el proyecto especial SIGA. Este aseguramiento lo deber realizar sobre el trabajo desarrollado por el resto del equipo de proyecto y sobre el trabajo desarrollado por los jefes de proyectos de los dems proyectos. 3.1.3. Analista de Sistemas Cdigo: AS Responsabilidades: Comprender y plasmar los requerimientos del usuario en los diversos documentos y diagramas comprendidos dentro del modelo. 3.1.4. Desarrollador Cdigo: DS Responsabilidades: Desarrollar el cdigo fuente del software, hacer determinadas pruebas de calidad y actualizar los documentos de diseo del proyecto. 3.1.5. Tester Cdigo: TS Responsabilidades: Desarrollar el plan de pruebas del proyecto y realizar la mayor parte de pruebas. 3.1.6. Documentador Cdigo: DC Responsabilidades: Oliveros Ocrospoma Miguel Angel
Elaborar el instructivo de configuracin e instalacin y el manual de usuario. Capacitar al responsable del rea usuaria. 3.1.7. Stakeholder Cdigo: ST Responsabilidades: Son los interesados en el proyecto tanto por parte de los usuarios como del proyecto especial SIGA. 3.1.8. Capacitador del rea usuaria Cdigo: CU Responsabilidades: Es la persona, designada por la parte usuaria, que ser capacitada el documentador del proyecto. Realizar la capacitacin al resto de usuarios. 3.2. Matriz de compatibilidad de Roles: En este punto se define la compatibilidad entre los roles que puede asumir un mismo recurso dentro de un proyecto. Aquellas casillas que se encuentran en color verde indican que los roles son compatibles y aquellas que se encuentran en color rojo indican que no son compatibles. ROL JC JP AS DS TS DC ST CU JC SI NO NO NO NO NO SI NO JP NO SI SI NO NO NO SI NO AS NO SI SI SI NO NO SI SI DS NO NO SI SI NO SI SI SI TS NO NO NO NO SI NO SI NO DC NO NO NO SI NO SI SI SI ST SI SI SI SI SI SI SI SI CU NO NO SI SI NO SI SI SI
3.3. Documentos: En este punto definiremos los documentos que se utilizarn en el modelo, estos se dividen en 3 grupos:
3.3.1. Entregables: Son los documentos que contendrn toda la informacin del proyecto de inicio a fin.
3.3.1.1. Carta de solicitud: Cdigo: No tiene Propsito: Oliveros Ocrospoma Miguel Angel
Solicitar el inicio de un proyecto, por parte del usuario.
3.3.1.2. Visin general: Cdigo: E1_<NomProyecto>_SIGA-MEF Propsito: Permitir mostrar la visin de alto nivel del proyecto para poder determinar su viabilidad.
3.3.1.3. Lnea Base: Cdigo: E2_<NomProyecto>_SIGA-MEF Propsito: Contener actualizadas las lneas base de tiempo, costos, alcance del proyecto y la matriz de riesgos.
3.3.1.4. Anlisis del Software: Cdigo: E3_<NomProyecto>_SIGA-MEF Propsito: Proporcionar los casos de uso y sus especificaciones y los prototipos acorde a los estndares definidos por el equipo del proyecto especial SIGA.
3.3.1.5. Plan de pruebas: Cdigo: E4_<NomProyecto>_SIGA-MEF Propsito: Proporcionar las pruebas a realizarse en el proyecto y las fechas en que estas sern desarrolladas.
3.3.1.6. Diseo de Software: Cdigo: E5_<NomProyecto>_SIGA-MEF Propsito: Proporcionar la arquitectura del software y los diagramas y artefactos necesarios para su desarrollo.
3.3.1.7. Documento de ejecucin de pruebas: Cdigo: E6_<NomProyecto>_SIGA-MEF Propsito: Documentar las pruebas realizadas al software.
3.3.1.8. Instructivo de configuracin e instalacin: Oliveros Ocrospoma Miguel Angel
Cdigo: E7_<NomProyecto>_SIGA-MEF Propsito: Brindar las instrucciones necesarias para poder configurar el ambiente de produccin en el cual se instalar el software y realizar la instalacin del software adecuadamente.
3.3.1.9. Manual de usuario: Cdigo: E8_<NomProyecto>_SIGA-MEF Propsito: Brindar la informacin necesaria para hacer un adecuado uso del software.
3.3.2. Actas obligatorias: Es la documentacin que sustenta todo lo acordado y aceptado en el proyecto de inicio a fin.
3.3.2.1. Acta de aprobacin del proyecto: Cdigo: AA1_<NomProyecto>_SIGA-MEF Propsito: Sustentar la aprobacin del proyecto por parte de los principales Stakholder.
3.3.2.2. Acta de aprobacin del plan de pruebas: Cdigo: AA2_<NomProyecto>_SIGA-MEF Propsito: Sustentar la aprobacin de las pruebas que se realizarn al sistema.
3.3.2.3. Acta de aprobacin de Hitos y Entregables: Cdigo: AA3_<NomProyecto>_SIGA-MEF Propsito: Sustentar la aprobacin de los entregables y las fechas de entrega de estos.
3.3.2.4. Acta de conformidad de pruebas internas: Cdigo: AA4_<NomProyecto>_SIGA-MEF Propsito: Sustentar la conformidad de las pruebas realizadas al sistema, por parte del equipo de trabajo.
3.3.2.5. Acta de conformidad de capacitacin: Cdigo: AA5_<NomProyecto>_SIGA-MEF Oliveros Ocrospoma Miguel Angel
Propsito: Sustentar la conformidad de la capacitacin brindada al usuario.
3.3.2.6. Acta de conformidad instalacin del software: Cdigo: AA6_<NomProyecto>_SIGA-MEF Propsito: Sustentar la conformidad en el proceso de instalacin del sistema.
3.3.2.7. Acta de cierre de proyecto: Cdigo: AA7_<NomProyecto>_SIGA-MEF Propsito: Sustentar la aceptacin del sistema por parte de todos los Stakeholder.
3.3.2.8. Acta de conformidad del avance: Cdigo: AA8_<NomProyecto>_SIGA-MEF Propsito: Sustentar la conformidad del avance presentado por hito.
3.3.3. Actas complementarias: Es la documentacin que sustenta las reuniones y acuerdo realizados en temas especficos que no se encuentran contemplados dentro de las actas obligatorias. Estas actas tienen un cdigo asignado segn la siguiente nomenclatura: AR<nroCorrelativo>_<NomProyecto>_SIGA-MEF
3.4. Fases: En este punto definiremos las 4 fases en las que se divide el modelo:
3.4.1. Fase de inicio En esta fase se inicia el proceso del Modelo, tiene como propsito principal determinar la viabilidad del proyecto y en base a ello generar el plan de proyecto.
3.4.2. Fase de anlisis Oliveros Ocrospoma Miguel Angel
Esta fase tiene como propsito principal dotar al proyecto del detalle necesario para poder iniciar su construccin y pruebas.
3.4.3. Fase de construccin Esta fase tiene como propsito el ejecutar lo planificado en base al detalle de las especificaciones generadas en la fase de anlisis, en esta fase se realiza la construccin del software as como las pruebas de calidad.
3.4.4. Fase de transicin Esta fase tiene como propsito principal traspasar el producto de construccin hacia el ambiente de produccin.
3.5. Procesos: En este punto definiremos los procesos agrupados por cada una de las fases del modelo.
3.5.1. Fase de inicio: Esta fase cuenta con 5 procesos:
3.5.1.1. Recepcin de Carta Actor: Jefe/coordinador del proyecto especial SIGA Entrada: Carta de solicitud Salida: Jefe de proyecto asignado Descripcin: Este proceso incluye el ingreso de la carta al proyecto especial SIGA y la asignacin del jefe de proyecto, para que elabore la visin general de la solicitud.
3.5.1.2. Determinacin de la Visin General de la Solicitud Actor: Jefe de proyecto Entrada: Carta de solicitud Salida: Oliveros Ocrospoma Miguel Angel
E1_<NomProyecto>_SIGA-MEF.doc Tiempo estimado: Este proceso debe tomar como mximo tres (3) das hbiles contados a partir de la asignacin del jefe de proyecto. Descripcin: Esta actividad es un primer acercamiento con el usuario para saber en qu consiste el requerimiento mencionado en la carta. Es necesario determinar, en trminos generales, qu desea la parte usuaria, con qu urgencia lo necesita y qu tipo de solicitud se est haciendo. Para aprobar el desarrollo del proyecto, es necesario que: El proyecto se alinee con al menos un objetivo estratgico del rea usuario o institucional. La solicitud amerite desarrollo, ya sea inicial o de modificacin. En caso no cumplir estos requisitos, el proyecto ser declarado como no viable y se responder la carta comunicando lo antes mencionado. Recomendacin: Normar que el nmero mximo de reuniones con el usuario sea 2.
3.5.1.3. Gestin de Lineamientos del Proyecto Actor: Jefe de proyecto Entrada: E1_<NomProyecto>_SIGA-MEF.doc Salida: E2_<NomProyecto>_SIGA-MEF.doc Tiempo estimado: Mximo 5 das hbiles. Descripcin: El propsito de la gestin de lineamientos es contar con las tres lneas base del proyecto: Lnea de Alcance, Lnea de Costo y Lnea de Tiempo. La lnea de Alcance: Una vez definida la visin general del proyecto, es necesario determinar el alcance del proyecto, para esto se realizar un levantamiento de requerimientos a alto nivel y Oliveros Ocrospoma Miguel Angel
definicin de proceso. Se necesita adjuntar flujograma (primera versin). La lnea de Tiempo: La lnea del tiempo consiste en la realizacin de un cronograma de trabajo para las fases de Elaboracin, Construccin y Transicin. La lnea de Costo: La lnea de costo debe cubrir los recursos que se necesiten para la realizacin del proyecto. Matriz de riesgos: Contiene los riesgos tanto inherentes como externos, del proyecto. Recomendacin: Normar que el nmero mximo de reuniones con el usuario sea 3. Para la determinacin de estos lineamientos se recomienda que el jefe de proyecto consulte con otros jefes de proyecto ms experimentados, los cuales pueden asesorarle sobre los tiempos, costos y arquitectura a utilizar. Utilizar el software libre OpenProj como herramienta para la realizacin del cronograma. En la plantilla de la matriz de riesgos se deberan de considerar riesgos fijos aplicables a los proyectos segn su naturaleza o tipificacin.
3.5.1.4. Reunin de Inicio de Proyecto (Kick off) Actor: Jefe/coordinador del proyecto especial SIGA Jefe de proyecto Entrada: E2_<NomProyecto>_SIGA-MEF.doc Salida: AA1_<NomProyecto>_SIGA-MEF.doc E2_<NomProyecto>_SIGA-MEF.doc (actualizacin) Tiempo estimado: Mximo 3 das hbiles a partir de la primera reunin hasta la aceptacin. Descripcin: Oliveros Ocrospoma Miguel Angel
Una vez definidas las lneas base se proceder a negociarlas con el usuario en la reunin de Kick off. En la reunin de Kick off se informar al usuario, el tiempo, costo y alcance que tendra el proyecto. De no estar ste de acuerdo, puede modificar las lneas pero debe considerar que cualquier modificacin en una lnea afectar a las otras dos. Recomendacin: Normar que una vez que se solicite la reunin de kick off, el usuario deber tener como mximo dos das para proponer una fecha de reunin. De no responder, se considerarn como aceptados los lineamientos. La reunin de kick off se puede desarrollar mximo en 2 etapas. Con diferencia de mximo 2 das.
3.5.1.5. Formacin del Equipo de Trabajo Actor: Jefe de proyecto Entrada: E2_<NomProyecto>_SIGA-MEF.doc Salida: E2_<NomProyecto>_SIGA-MEF.doc (actualizacin) Tiempo estimado: Mximo 1 da a partir de la disponibilidad de recursos en la institucin. Descripcin: Asignar el personal disponible a cada rol del proyecto. Recomendacin: Utilizar el software libre OpenProj como herramienta para la asignacin de recursos.
3.5.2. Fase de anlisis: Esta fase cuenta con 5 procesos:
3.5.2.1. Refinacin de Requerimientos del Software Actor: Analista de Sistemas Entrada: AA1_<NomProyecto>_SIGA-MEF.doc E2_<NomProyecto>_SIGA-MEF.doc Oliveros Ocrospoma Miguel Angel
Salida: E2_<NomProyecto>_SIGA-MEF.doc (actualizacin) Tiempo estimado: Mximo 5 das. Descripcin: Tenindose aprobadas las lneas del proyecto, se proceder a hacer el levantamiento de requerimientos del software. Deben incluirse los requerimientos funcionales y no funcionales, dentro de los cuales se deber incluir los requerimientos que permitan la construccin y/o reutilizacin de ontologas, as como una lista de los posibles sistemas con los cuales se integrarn. Recomendacin: Capacitar al personal en temas de definicin de requerimientos de software ya que se ha observado, en la documentacin existente en los proyectos desarrollados por el equipo del proyecto especial SIGA, que muchas veces estos son definidos de manera ambigua e inconsistente. Capacitar al personal en temas de anlisis y definicin de ontologas.
3.5.2.2. Anlisis del Software Actor: Analista de sistemas Jefe de proyecto Entrada: E2_<NomProyecto>_SIGA-MEF.doc Salida: E3_<NomProyecto>_SIGA-MEF.doc E2_<NomProyecto>_SIGA-MEF.doc (actualizacin) Descripcin: En el proceso de anlisis se organizarn los requerimientos que se recopilaron y se construirn los diagramas de casos de uso, las especificaciones y los prototipos del software. En este proceso se deber elaborar el modelo conceptual de las ontologas a utilizar lo cual implica definir los trminos importantes para la ontologa, definir las clases para las ontologas y sus Oliveros Ocrospoma Miguel Angel
jerarquas, definir las propiedades de las clases para las ontologas y las restricciones de las propiedades. Al finalizar el proceso de anlisis se debe actualizar la lnea base de Tiempo, afinando el cronograma en base a los casos de uso del sistema. Recomendaciones: Realizar el nuevo ajuste del cronograma en base a mdulos. 3.5.2.3. Elaboracin de Plan de Pruebas Actor: Tester Jefe de proyecto Entrada: E3_<NomProyecto>_SIGA-MEF.doc Salida: E4_<NomProyecto>_SIGA-MEF.doc AA2_<NomProyecto>_SIGA-MEF.doc E2_<NomProyecto>_SIGA-MEF.doc (actualizacin) Tiempo estimado: Mximo de 5 das. Descripcin: Este plan debe elaborarse en conjunto con el usuario, quien debe dar su aceptacin. En este plan debe especificarse los tipos de pruebas que se van a realizar (caja blanca, caja negra, penetracin, estrs, etc) y los procedimientos para cada una. Este plan de pruebas debe incluir la verificacin y validacin de las ontologas. Recomendacin: Elaborar una lista de pruebas aplicables para los proyectos segn su naturaleza o tipificacin. Capacitar al personal en temas de ontologas para que puedan definir adecuadamente las pruebas que realizaran a estas. Debido a la limitante de recursos con que cuenta la institucin, considerar la proporcin de 1 a 0.5 con respecto al desarrollo. 3.5.2.4. Reunin de aceptacin de Hitos y Entregables Actor: Stakeholder Jefe de proyecto Oliveros Ocrospoma Miguel Angel
Tester Entrada: E4_<NomProyecto>_SIGA-MEF.doc Salida: AA3_<NomProyecto>_SIGA-MEF.doc E2_<NomProyecto>_SIGA-MEF.doc (actualizacin) Tiempo estimado: 3 das hbiles a partir de la primera reunin. Descripcin: Este proceso consiste en una reunin con la parte usuaria donde debe aprobarse el plan de pruebas del sistema y software, as como definir la fecha y alcance de cada hito del proyecto. Un hito del proyecto consistir en una reunin donde se le mostrar al usuario el avance al que se hayan comprometido. Cada una de estas reuniones debe culminar con la aceptacin o no del usuario. La aceptacin debe basarse en la ejecucin por parte del usuario de los casos de prueba y/o del sistema segn corresponda. La consignacin de estos hitos estar en los Lineamientos del proyecto: lnea base de Tiempo.
3.5.2.5. Diseo del Software Actor: Analista de sistemas Desarrollador Entrada: E3_<NomProyecto>_SIGA-MEF.doc Salida: E5_<NomProyecto>_SIGA-MEF.doc Tiempo estimado: Mximo de 5 das Descripcin: El diseo del software debe hacerse de tal manera que cualquier desarrollador, sin estar desde un principio en el proyecto, pueda entender fcilmente la arquitectura del software e incorporarse al desarrollo del mismo. Las tareas que aqu deben realizarse son: la elaboracin del diseo fsico de datos, diseo de clases y diagrama de secuencias. Oliveros Ocrospoma Miguel Angel
Recomendacin: Capacitar al personal en la elaboracin de los diagramas del diseo fsico de datos, de clases y de secuencia. Utilizar Power Designer como herramienta para la elaboracin de los diagramas, ya que el MEF cuenta con licencias para esta herramienta. Capacitar al personal en el uso de la herramienta.
3.5.3. Fase de construccin: Esta fase cuenta con 3 procesos:
3.5.3.1. Desarrollo del Software Actor: Desarrollador Analista de sistemas Entrada: E2_<NomProyecto>_SIGA-MEF.doc E3_<NomProyecto>_SIGA-MEF.doc E4_<NomProyecto>_SIGA-MEF.doc Salida: Cdigo fuente E4_<NomProyecto>_SIGA-MEF.doc (actualizacin) E2_<NomProyecto>_SIGA-MEF.doc (actualizacin) E7_<NomProyecto>_SIGA-MEF.doc Descripcin: Desarrollo de los casos de uso tomando en cuenta el diagrama de secuencias elaborado y el cronograma del proyecto. El analista deber actualizar el Plan del proyecto acorde al estado real del mismo en cada etapa. Por cada conjunto de mdulos enviados a probar, debe llenar todos los puntos del instructivo de configuracin e instalacin (E7) que considere necesarios. Recomendaciones: Se recomienda exigir a los desarrolladores tener un paquete de pruebas unitarias. Oliveros Ocrospoma Miguel Angel
Exigir la actualizacin de los diagramas de secuencia y clases semanalmente. Exigir subir los avances al servidor de versiones, semanalmente. Actualizacin constante del avance de las tareas respecto al cronograma. Designar un responsable de asegurar que se cumplan con los estndares definidos por el equipo del proyecto especial SIGA.
3.5.3.2. Ejecucin de Pruebas Actor: Tester Desarrollador Analista de sistemas Entrada: E2_<NomProyecto>_SIGA-MEF.doc E3_<NomProyecto>_SIGA-MEF.doc E4_<NomProyecto>_SIGA-MEF.doc E7_<NomProyecto>_SIGA-MEF.doc Salida: E4_<NomProyecto>_SIGA-MEF.doc (actualizacin) E2_<NomProyecto>_SIGA-MEF.doc (actualizacin) E6_<NomProyecto>_SIGA-MEF.doc AA4_<NomProyecto>_SIGA-MEF.doc Descripcin: Ejecucin de los casos de pruebas, contemplados en el plan de pruebas, segn el cronograma del proyecto, evaluacin del instructivo de configuracin e instalacin, elaborar el documento de pruebas. En el documento de lineamientos del proyecto (E2), el tester encontrar los casos de prueba que deben realizarse por cada periodo. Al finalizar el periodo, debern presentarse dos documentos: 1) los resultados de las pruebas (E6), cuyos resultados parciales pueden ser informados al desarrollador para que pueda corregirlos antes de la presentacin de avance (hito) del periodo; 2) la acta de ejecucin de pruebas internas (AA4) con las firmas correspondientes. Oliveros Ocrospoma Miguel Angel
Los resultados parciales sern comunicados mediante el llenado del acta de pruebas internas (AA4), en esta acta tambin pueden hacerse las correcciones acerca del instructivo de configuracin e instalacin presentado por el desarrollador. El analista deber actualizar el Plan del proyecto acorde al estado real del proyecto en cada etapa en la que se haya considerado medir dicho avance. Recomendaciones: Actualizacin constante del avance de las tareas respecto al cronograma. El rea de pruebas debera exigir un instructivo de configuracin e instalacin por cada conjunto de mdulos que recibe para realizar pruebas internas.
3.5.3.3. Reunin de presentacin de avance Actor: Jefe de proyecto. Entrada: E6_<NomProyecto>_SIGA-MEF.doc E4_<NomProyecto>_SIGA-MEF.doc Salida: AA8_<NomProyecto>_SIGA-MEF.doc Descripcin: La reunin consiste en presentar el avance del proyecto de acuerdo al hito que se consider en los lineamientos del proyecto. Recomendaciones: Actualizacin constante del avance de las tareas respecto al cronograma.
3.5.4. Fase de transicin: Esta fase cuenta con 4 procesos:
3.5.4.1. Elaboracin de Instructivos y Manuales Actor: Documentador Entrada: Software terminado E7_<NomProyecto>_SIGA-MEF.doc Salida: E7_<NomProyecto>_SIGA-MEF.doc Oliveros Ocrospoma Miguel Angel
E8_<NomProyecto>_SIGA-MEF.doc Tiempo estimado: Mximo de 8 das Descripcin: Este proceso consiste en actualizar los manuales instructivos de configuracin, instalacin y de utilizacin del sistema. Al iniciar este proceso, el instructivo (E7) debe estar ya en una versin estable debido a que se ha ido llenando conforme el desarrollador mandaba a probar sus mdulos al tester, por lo tanto, en este proceso debe considerarse solo algunas actualizaciones que deban hacerse debido a la integracin del sistema u otros motivos.
3.5.4.2. Capacitacin Actor: Documentador Capacitador (es) del rea usuaria Entrada: E8_<NomProyecto>_SIGA-MEF.doc Salida: AA5_<NomProyecto>_SIGA-MEF.doc Descripcin: Se capacitar a las personas designadas por el rea usuario. El objetivo es que despus de la entrega del sistema, sean estas personas las encargadas de capacitar a toda persona que lo requiera. Recomendacin: Normar que el nmero mximo de personas capacitadas debe ser 3.
3.5.4.3. Implementacin Actor: Jefe de proyecto Desarrollador Entrada: AA5_<NomProyecto>_SIGA-MEF.doc E7_<NomProyecto>_SIGA-MEF.doc E8_<NomProyecto>_SIGA-MEF.doc Software terminado Salida: AA6_<NomProyecto>_SIGA-MEF.doc Descripcin: Oliveros Ocrospoma Miguel Angel
Este proceso consiste en el despliegue del sistema. Es responsabilidad del equipo del proyecto especial SIGA, verificar que todo trabaje tal y como lo hara en un ambiente de desarrollo. El proceso termina con un acta de aprobacin por parte del rea de produccin certificando que el sistema funciona correctamente. Recomendacin: Delimitar un tiempo prudencial (3 das) en el cual se est probando el sistema en el ambiente de produccin. Despus de ese tiempo la responsabilidad del sistema ser de produccin. 3.5.4.4. Reunin de cierre Actor: Jefe de proyecto Entrada: AA6_<NomProyecto>_SIGA-MEF.doc Salida: AA7_<NomProyecto>_SIGA-MEF.doc Descripcin: Reunin donde se firmar un acta de aprobacin con todas las gerencias involucradas. Recomendacin: Contar con un documento de lecciones aprendidas a nivel del equipo del proyecto especial SIGA, la cual deber ser actualizado en este proceso. El acta debe contener las observaciones acerca del trabajo general realizado en el equipo del proyecto especial SIGA.
3.6. Diagrama de procesos:
Oliveros Ocrospoma Miguel Angel
3.6.1. Diagrama de procesos por fases
Oliveros Ocrospoma Miguel Angel
3.6.2. Diagrama de procesos por roles
Oliveros Ocrospoma Miguel Angel
CONCLUSIONES: El modelo propuesto cumple los actuales estndares de desarrollo de software NTP ISO/IEC 12207 y la ISO/IEC 9127 as mismo se ajusta a la estructura actual del proyecto especial SIGA. El modelo propuesto es escalable ante una posible reestructuracin debido a la utilizacin de roles. El modelo propuesto cubre la necesidad de implementar una capa de ontologa la cual solucionar el problema de integracin. El modelo puede adaptarse a cualquier proyecto de desarrollo de software sea de pequeo o gran tamao, de corto o largo tiempo, y de diferentes estilos de programacin, mediante la reduccin de ciertos procesos.
RECOMENDACIONES: Designar como experto a un miembro de cada rea por cada tipo de proyecto. Normar las recomendaciones que se hicieron a lo largo de los procesos. Utilizar un servidor de versiones para cada entregable del proyecto.