UNIVERSIDAD TECNOLÓGICA DE QUERÉTARO

Transcripción

1 UNIVERSIDAD TECNOLÓGICA DE QUERÉTARO Nombre del Proyecto ADMINISTRACIÓN DE PROYECTO GESTOR DE LICITACIONES Empresa KOOMONI Memoria que como parte de los requisitos para obtener el título de: INGENIERIO EN TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Presenta Ana Karen Martínez Romero ASESOR DE LA EMPRESA Lic. Jesus Alfredo Vazquez Cervin ASESOR DE ESCUELA ISC. Marco Antonio Arreguin Molina Santiago de Querétaro, Qro. Mayo del 2013.

2 RESUMÉN En el presente documento se muestra el proceso y resultados de la administración del proyecto Gestor de Licitaciones, obtenidos a lo largo de 4 meses. El desarrollo consto de la elaboración de un plan de trabajo de acuerdo a las necesidades de cliente, se realizó una junta de levantamiento de requerimientos, para obtener los datos que el cliente necesitaba para la realización del sistema. De acuerdo a los datos que fueron entregados se fue realizando un plan de trabajo, una vez terminado se presento y se explicó la manera de trabajar, se presento al equipo de trabajo y se inicio con la elaboración de los análisis previos a la construcción de cada funcionalidad requerida en el sistema de Licitaciones. ABSTRACT This document shows the process and results of the project management Contracts Manager, obtained over 4 months. The development and cost to the development of a work plan according to customer needs, we made a requirements gathering meeting, to obtain the data that the client needed to implement the system. According to the data that was delivered was doing a work plan, when completed will present and explain the way to work, was presented to the team and started with the preparation of pre-construction analysis of each functionality required in the Procurement system. 2

3 DECIDATORIAS El presente documento es dedicado a todas las personas que me han apoyado incondicionalmente desde el inicio de este sueño. A mis padres Migadla Romero Hernandez y Servando Martínez Álvarez que siempre me han demostrado lo importante que soy en su vida, me han apoyado en cada momento, se han esforzado por darme todo lo necesario en la vida. A Julio Adrian Martínez Romero que sin su apoyo, sin sus consejos no abría llegado a este punto, y a su amor incondicional de hermano. A todas las personas importante que han estado siempre a mi lado, a mis primos, mis tíos, abuelos, amigos que siempre se han sentido orgullosos de todo lo que he hecho. Sin olvidar a una persona que es muy importante en mi vida Alejandro Luna, que ha estado conmigo en todos los momentos difíciles, me ha demostrado siempre su apoyo, me dio buenos consejos para sobresalir y sobre todo al amor que me ha brindado. A todos les doy las gracias ya que sin ellos no abría llegado a este gran logro. Muchas Gracias!!! 3

4 ÍNDICE Resumen.2 Abstract...2 Dedicatorias...3 Índice 4 I. INTRODUCCIÓN... 5 II. OBJETIVO... 6 III. MARCO TEORICO... 6 IV. DESARROLLO V. OBJETIVOS GENERAL VI. OBJETIVOS ESPECIFICOS VII. PROPUESTA TÉCNICA VIII. INICIO DE PROYECTO IX. CRONOGRAMA DE ACTIVIDADES X. REFERENCIAS BIBLIOGRAFÍCAS

5 I. INTRODUCCIÓN A continuación, se presenta el siguiente anteproyecto que tiene como finalidad, especificar en qué consiste el proyecto de Estadía: Administración de Gestión de Licitaciones el cual se creará dentro de la empresa Koomonisoft, y tendrá como objetivo principal llevar a cabo la administración del proyecto en su totalidad, implementando una metodología basada en CMMI, tomando en cuenta todos los niéveles especificados dentro de la misma. 5

6 II. OBJETIVO Generar la administración del proyecto Gestión de Licitaciones, el cual tiene como finalidad crear un sistema que lleve el control de las licitaciones 1. Se implementaran fases de Solución, dentro del proyecto para obtener el producto final que requiere LICITACOM. III. MARCO TEORICO Para determinar qué es lo que se realizará internamente, el cliente Licitacom deberá proporcionar información acerca del producto que requiere, se realizaran juntas de seguimiento semanalmente, y especificará de manera detallada los requerimientos que serán construidos, generar minutas de reunión, reportes de seguimiento. Una vez que se haya obtenido la información necesaria de los requerimientos proporcionada por el cliente Licitacom, se realizaran documentos de Análisis con el formato FOR-ANL Nombre del RQ- Numero de RQ que pertenecen a la metodología enfocada e identificarlos fácilmente. Para la implementación del proyecto se utilizara la metodología de cascada (una metodología es aquella guía que se sigue a fin realizar las acciones 1 Licitación: también denominada concurso público o contrato del Sector Público y Privado), es el procedimiento administrativo para la adquisición de suministros, realización de servicios o ejecución de obras que celebren los organismos y entidades que forman parte del Sector Público. 2 Ver página 10 6

7 propias de una investigación), la cual está basada en el modelo CMMI, cada documento es identificado por el nombre y formato implementado. Existen diferentes tipos de metodología entre ellos están cascada, espiral, orientada a objetos etc. De las cuales nos enfocaremos a desarrollar la de cascada también conocida como modelo clásico, modelo tradicional o modelo lineal secuencial ( 2013). El método de la cascada es considerado como el enfoque clásico para el ciclo de vida del desarrollo de sistemas, se puede decir que es un método puro que implica un desarrollo rígido y lineal un ejemplo de la metodología en cascada es: 1.Análisis de requisitos 2. Diseño del sistema 3. Codificación 4. Pruebas 5. Implantación 6. Soporte Técnico Para llevar un adecuado orden en las actividades que se realizaran durante el proyecto, se manejaran las herramientas de trabajo que se mencionan a continuación: 7

8 Servidor: Subversion Edge for the Enterprise Potente: consola de administración web que permite tener el control de la empresa Subversion. Rápido y fácil: solo instalador y actualizador incluye todo lo que necesita: Apache Subversion, Apache HTTP server, View VC y la consola basada en la Web, ( ). USO: esta herramienta será utilizada para almacenar documentos en el servidor utilizado dentro de la empresa, así como tener un manejo correcto de todo lo que se tiene que generar en el proyecto desde el análisis hasta la implementación del sistema. Usuarios: Los siguientes usuarios pueden utilizar la herramienta de trabajo, Coach de Proyectos, Líder de QA, Tester, Programadores. Cliente: Tortoise TortoiseSVN administra archivos y directorios a lo largo del tiempo. Los archivos se almacenan en un repositorio central. El repositorio es prácticamente lo mismo que un servidor de archivos ordinario, con la excepción de que recuerda todos los cambios que se hayan hecho a sus archivos y directorios. Esto le permite al usuario recuperar versiones antiguas de sus archivos y 8

9 examinar la historia de cómo y cuándo cambiaron sus datos, y quién hizo el cambio. Esta es la razón por la que mucha gente piensa en Subversion, y los sistemas de control de versiones en general, como una especie de máquinas del tiempo. ( 2012) USO: Esta herramienta es utilizada para el subir versiones de los documentos, diseños o código que son generados para el proyecto. Usuarios: Los siguientes usuarios pueden utilizar la herramienta de trabajo, Coach de Proyectos, Líder de QA, Tester, Programadores. Registro de horas: Teamwork El trabajo en equipo es una red probada, confiable y amigable solución basada en la gestión de proyectos para el manejo de trabajo en cualquier campo. Para la implementación del proyecto se utilizara la metodología de cascada, la cual está basada en el modelo CMMI, cada documento es identificado por el nombre y formato implementado. ( 2001) 9

10 IV. DESARROLLO 1.OBJETIVOS GENERAL Como punto principal es tener en claro qué documentos se tienen que realizar en cada fase del proyecto ya que ayudara a tener un control de los entregables, que se presentaran con el cliente y sobre todo saber qué es lo que se construirá y mostrara como producto final. 2. OBJETIVOS ESPECIFICOS Especificación de desarrollo Propuesta Técnica. Especificación de desarrollo Inicio de Proyecto. Especificación de desarrollo de fase Análisis. Especificación de desarrollo de fase Diseño. Especificación de desarrollo de fase de Construcción. Especificación de desarrollo de fase de Pruebas. Especificación de desarrollo de fase de Pruebas Cliente / Validación. Especificación de desarrollo de fase de Implementación. Especificación de desarrollo de fase de Cierre. 10

11 3. PROPUESTA TÉCNICA Las necesidades de desarrollo son atendidas en una primera etapa por una Propuesta de Solución (Técnica y Comercial). Los documentos entregables son los siguientes: Usuario Nombre Documento Formato /Nomenclaruta Coach de Proyectos Minuta de Minuta_Proyecto_ Fecha (Karen Romero) Levantamiento de creación Coach de Propuesta Técnica Propuesta_Proyecto_Fecha Proyectos(Karen de creación Romero) Coach de Proyectos (Karen Romero) Propuesta Comercial Propuesta_Proyecto_Fecha de Creación 11

12 4. INICIO DE PROYECTO El arranque del proyecto se dará a través de una junta de Kick off (Junta de presentación ante el cliente, se indican las acciones que se realizaran dentro del proyecto, así como las obligaciones que tiene la empresa dentro del proyecto y las obligaciones que tiene el cliente con la empresa, se definen los roles de trabajo, las personas que estarán participando dentro del proyecto tanto como de la empresa como de parte del cliente ) (Teamwork, 2010), donde se formalizaran todos los acuerdos, métodos a ser seguidos, responsables, juntas de seguimientos semanales/ quincenales por parte de la empresa Koomonisoft y del cliente Licitacom. Los documentos entregables son: Usuario Nombre de Documento Formato /Nomenclatura Coach de Proyectos( Documento de FOR_ SGM-000 Karen Romero) KickOff(Firmado por cliente Licitacom y Koomonisoft) Coach de Proyectos Plan de Trabajo del Plan de trabajo _Fecha 12

13 (Karen Romero) proyecto de creación_ proyecto Análisis Dentro de la fase de Análisis del Sistema, se detalla cada funcionalidad requerida por el cliente y las cuales se verán reflejadas en el sistema. Los documentos entregables son: Usuario Nombre de Documento Formato/Nomenclatura Coach de Proyectos Minutas de reuniones ( (Minuta_Proyecto_Fecha (Karen Romero), con los acuerdos y de creación) Analista de Calidad. definiciones de cada junta que será realizada con el cliente Licitacom) Coach de Proyectos Minutas de reuniones: (Karen Romero), Análisis-> Especificación (FOR-ANL-000) Analista de Calidad. funcional de los requerimientos del sistema, detallando sus reglas de negocio y 13

14 comportamiento que tomaran dentro del sistema solicitado Para la realización del análisis se necesitan usuarios que estén involucrados dentro de los procesos que a continuación se describen en la figura 1: Figura 1. Flujo General de Análisis Para tener un mejor control de lo que se realiza dentro de la fase de análisis se describe el flujo completo de lo que se realiza en todo el proceso. 3 3 Ver figura

15 ACTOR ACCION PROCESO FINAL Coach de Proyecto Levantamiento de Se entrega documento (Karen Romero) Requerimientos / de Análisis al cliente, Funcionalidades sistema. del una vez aprobado el documento se presenta el VoBo. 15

16 Levantar Requerimientos Analizar / Entender Requerimientos Especificar Requerimientos Vobo del Analisis Realizar juntas de levantamiento Detallar Funcionalidades Presentación del documento al cliente y VoBo Documentar / Minuta Levantamiento Elaborar Diagramas Funcionalies Vobo del Levantamiento Elaborar Modelo de Datos Actualizar especificación funcional Figura 1.1 Proceso de Análisis Diseño Una vez que se especifique que es lo que requiere el sistema, se genera la fase de Especificación Técnica o Diseño, para cada requerimiento analizado 16

17 funcionalmente en la fase anterior con todas las características que se obtuvieron Figura 2. Los documentos entregables son: Prototipos de las pantallas de cada requerimiento (FOR-ANL-000). Actualización de la documentación de análisis. Figura 2. Flujo General Diseño 17

18 ACTOR ACCIÓN PROCESO FINAL Coach de Proyecto Se generan los Entrega de documento (Karen Romero), prototipos de diseño de de diseño. interviene el Cliente Licitacom. acuerdo a cada funcionalidad especificada, dentro del cuadro de funcionalidades. 18

19 Diseño Generar, Presentar y Aprobar Prototipo Especificación Diseño Pantalla y Reporte Definir o revisar la Arquitectura Definir Tipos / Clases de Prototipos Especificación de Diseño de Pantalla Definir Arquitectura Generar modelos y Consolidar Prototipo Validar Diseño de Pantalla Elaborar y ejecutar prueba de concepto Presentar prototipos Aprobar Arquitectura Validar Prototipo Figura 2.1 Proceso de Diseño 19

20 Construcción Cuando la fase de diseño y análisis sea aprobado por el cliente y este a su vez de el VoBo de los documentos, pasaran a la fase de Construcción del Sistema de acuerdo al plan de trabajo especificado, explicando al recurso humano a utilizar (Programador), qué es lo que tendrá que realizar. Los documentos entregables por parte del programador: Software (Sistema Licitacom). NOTA: Dentro del área de construcción, el coach del proyecto tendrá participación en la explicación de los requerimientos a realizar el programador, así como resolver las dudas que surjan al momento de dicha acción y monitorear semanalmente los avances de cada requerimiento que esté realizando de acuerdo al plan de trabajo Figura 3. 20

21 Figura 3. Flujo General Construcción ACTOR ACCION PROCESO FINAL Programador ( Miguel Construcción de las Se entregan la Mendoza) funcionalidades funcionalidad para (Código) probar. 21

22 Construcción Distribuir Especificaciones Codificar Liberar Programas / componentes para pruebas Integrar Componentes Entregar Especificación al programador Entender y Analizar Especificación Técnica Integrar programas / componentes Presentar al programador la y Aclarar dudas Codificar programa / componente Liberar ensamble para pruebas Realizar pruebas al Programa / componente Figura 3.1 Proceso de Construcción 22

23 Pruebas Una vez liberada el área de construcción, los requerimientos que fueron finalizados pasaran al área de pruebas internas, en la cual se asignara un recurso humano (Tester), para realizarlas, el coach del proyecto revisara cada reporte que se entregue por el área y a su vez reportara al programador en caso de encontrar algún Bug (error/incidencia) dentro del modulo probado. Los entregables por parte del tester: Usuario Nombre del Documento Formato/ Nomenclatura Tester Mendoza) (Alondra Casos de Pruebas (FOR PRB 000) Tester (Alondra Evidencias de Pruebas (FOR-ANL-003) Mendoza) Los entregables por parte del coach del proyecto: Reporte de Bug 4 Análisis de Requerimientos a tester. 4 Errores /incidencias 23

24 Figura 4. Flujo General de Pruebas ACTOR ACCIÓN PROCESO FINAL Tester / QA (Alondra Se realizan los casos Documento de Casos Muñoz) de prueba, una vez ejecutados, se genera el evidencia de prueba y se valida la funcionalidad. de pruebas y Evidencias de pruebas. 24

25 Construcción Distribuir Especificaciones Codificar Liberar Programas / componentes para pruebas Integrar Componentes Entregar Especificación al programador Entender y Analizar Especificación Técnica Integrar programas / componentes Presentar al programador la y Aclarar dudas Codificar programa / componente Liberar ensamble para pruebas Realizar pruebas al Programa / componente Figura 4.1 Proceso de Pruebas 25

26 Pruebas Cliente / Validación Se considera que las pruebas de validación son de responsabilidad del cliente Licitacom, sin embargo abra juntas para resolver dudas o comentarios por parte de este mismo acerca de las funcionalidades. Los documentos entregables por parte de coach de proyecto: Minutas con modificaciones requeridas por parte del cliente Licitacom y Koomonisoft. Evidencias de la Pruebas que se realizaron. Scripts de ambientación del sistema. Credenciales de acceso al sistema. Para la validación del sistema se tienen que crear un plan de actividades para la ejecución de pruebas de acuerdo a las funcionalidades construidas a continuación se muestran las actividades Figura 5: 26

27 Figura 5. Flujo General de Pruebas Cliente ACTOR ACCIÓN PROCESO FINAL Coach de Proyecto (Karen Romero) Realizar plan de actividades de pruebas. Entrega de documento de Plan de Pruebas. Pruebas Cliente- Se realiza la ejecución Documento de VoBo 27

28 Licitacom de pruebas y validación de cada funcionalidad construida en el sistema. firmado por el cliente. Validación Planear Pruebas de Validación Preparar Ambiente de Validación Validar producto VoBo de las Pruebas de Validación Definir Plan de Validación con el Cliente Generar paquete y scripts de ambientación Ejecutar Pruebas VoBo del Sistema / Modulo Crear y Configurar ambiente de pruebas Registrar Resultados de la Validación Figura 5.1 Proceso de Validación 28

29 Implementación Como finalización del proyecto se generara la implementación del software, una vez cerrada las fases anteriormente descritas. Pase a Producción del Software. Los documentos entregables son los siguientes: Elaboración y Entrega del Manual Técnico y Manual de Usuario, La información necesaria y los scripts para la implantación en producción. CD de instalación. Credenciales de acceso al sistema. Figura 6. Flujo General de Implementación 29

30 ACTOR ACCIÓN PROCESO FINAL Tester (Alondra Realizar Manual de Entrega de documento Muñoz) usuarios del sistema. de Manual de Usuarios. Coach de Proyecto Realizar documento de Formato de (Karen Romero) capacitación de Capacitación. usuarios. Cliente (Licitacom) VoBo de capacitación. Documento de Capacitación firmado con VoBo. 30

31 Implantación Elaborar Manual de usuario y técnico Capacitar Usuarios Implantar Solución Elaborar Manual de usuario Definir equipo a ser capacitado Crear Setup de instalación Elaborar Manual Técnico Impartir capacitación Acompañar la instalación Entregar sistema y manuales al cliente Figura 6.1 Proceso de Implementación 31

32 Cierre Para el cierre de proyecto se generara la capacitación al personal acordado en caso de ser necesario. Los documentos entregables para la capacitación son los siguientes: Lista de asistencia por parte de Koomonisoft y cliente Licitacom. Evaluación de la capacitación. Cierre Del Proyecto. Los documentos entregables del cierre de proyecto son los siguientes: Minuta y Reporte de Lecciones aprendidas. Documento de Aceptación del proyecto. Documento de cierre de contrato. Garantía de Sistema. 32

33 Cierre Validar el cierre del proyecto Realizar junta de lecciones aprendidas Validar la aceptación del sistema y los productos entregados Junta de lecciones aprendidas Comunicar el cierre del proyecto Figura 7. Proceso de Cierre 33

34 Garantía de Calidad Planeación del proyecto Preparar Revisión de Calidad Conducir revisión de Calidad Comunicar Resultados de Revisión de Garantía de Calidad Revisar y verificar desvíos de Revisión de Calidad Levantar Informes sobre el proyecto Realizar revisiones de calidad Comunicar Resultados de Revisión Acompañar la corrección de defectos Elaborar Checklist para revisión de Calidad Documentar resultados de revisiones de Calidad Escalar desvíos / Tratar Pedidos de Excepción de Calidad Figura 8. Proceso de Soporte 34

35 IX. CRONOGRAMA DE ACTIVIDADES Se genera el plan de trabajo interno una vez que se hayan obtenidos todos los requerimientos que necesita el cliente para el sistema, tomando en cuenta el alcance especificado que se analiza en la primera fase del proyecto. El proyecto consiste en 19 módulos especificados por el cliente Licitacom, el proyecto inicia el día 7 de enero y tiene como fecha de finalización el 04 de abril. El control de tiempo se llevara dentro de la herramienta implementada, Teamwork esto con finalidad de llevar un registro de cuánto tiempo es destinado para cada fase de la metodología. 35

36 Diagrama de Gantt Figura 9. Plan de actividades (Gantt) 36

37 X. Referencias Bibliográficas Artículo de Internet Subversion, Artículo de Internet Teamwork, =cpc&utm_term=teamworkpm&utm_content=manage%2byour%2bprojects&ut m_campaign=teamworkpm&gclid=coz-zbjj7bucfqkopaodrg0a-w Artículo de Internet Metodologia, Hildebrando, Archivo de pruebas de software, Leonardo Parra, Archivo Formatos,