Instituto Tecnologico De Tepic :Materia: Gestión de proyectos de Software
:Carrera: Ingeniería en sistemas computacionales
:Maestro: Mariza Ramirez Llamas
:Alumno: Jose Angel Duran Reynoso
:No. Control: 10400363
4. Presentación de la información 4.1. Propuesta Una propuesta de proyecto es un documento escrito con un propósito específico en mente: convencer a alguien de que un proyecto puede y debe ser llevado a cabo. Aunque no hay un formato universal para estas propuestas, muchos de sus elementos son importantes y, en muchos casos, obligatorios. Sobre todo, debes recordar que una propuesta de proyecto es un argumento. Si no presentas un argumento lógico y viable, es probable que tu propuesta sea rechazada. Se pueden seguir los siguientes puntos para mejorar la propuesta de un proyecto: ● Situar un proyecto en su contexto más general ○ Las ideas de proyectos no deben aparecer de repente como surgidas de
la nada, sino formar parte de un programa nacional mucho más amplio o de una estrategia de ordenación de los humedales del país o de la regiÛn de que se trate. Lo ideal serÌa, pues, que el proyecto reforzarse un programa o una estrategia ya existentes, en lugar de reemplazarlos. De no haber un programa o una estrategia m·s generales, el proyecto deberÌa ser una actuación innovadora al respecto y tratar de definir, iniciar o incluso crear ese programa o esa estrategia. ● Mejorar el contenido de un proyecto ○ El contenido de un proyecto se refiere a la manera en que se detectan los problemas y se buscan las adecuadas soluciones. La primera cualidad de un proyecto debe ser su realismo. Un proyecto no debe tener por objetivo resolver todos los problemas de un país o un sector. Debe consistir en un ejercicio riguroso de fijación de prioridades y en una decisión acerca de cuál es la tarea más importante que haber que realizar y quién puede hacerla pensando de manera realista. Quienes propongan un proyecto deber·n evaluar además quién posee la capacidad técnica necesaria para gestionar un proyecto importante. ● Mejorar la presentación de una propuesta de proyecto ○ La presentación de un documento de proyecto es asimismo importante. El documento no es más que un instrumento empleado para mostrar que el proyecto ha sido concebido correcta y lógicamente. Si no está bien redactado o estructurado, al oficial de desarrollo que estudia una propuesta le será difícil comprender sus motivaciones. La manera en que se presenta el documento es además un buen indicio de la capacidad técnica y administrativa de quienes lo proponen. ● El análisis conforme al marco lógico como instrumento analítico para preparar proyectos ○ El éxito de un proyecto guarda estrecha relación con una serie de factores: una buena planificación, una capacidad suficiente de la organización, equipos de los proyectos competentes y motivados, que quienes intervienen cumplan sus compromisos, etc. Pero el punto de partida más importante es, sin duda, que el proyecto aborde el verdadero problema existente. Para que se determine y comprenda bien el
verdadero problema, antes de formular en una propuesta completa una idea de proyecto, habrá que realizar un "análisis conforme al marco lógico" cuya finalidad es llegar a un estudio claro y bien documentado del contexto en que intervendrá· el proyecto propuesto. Deberá sentar los problemas que abordará el proyecto y, a partir de ahí, exponer claramente los objetivos, resultados y actividades que perseguir·. AsÌ pues, habrá· que efectuar el análisis conforme al marco lógico antes de compilar el documento del proyecto (la propuesta), pues, a decir verdad, es la base necesaria para poder preparar un proyecto adecuadamente argumentado, defendible.
4.1.1. Justificación del proyecto Explíquese por qué motivos debe realizarse el proyecto y por qué se ha elegido determinado enfoque, mediante: 1. Una descripción del problema que se busca resolver. 2. Una descripción de la situación que se prevé exista al final del proyecto, una vez concluido con éxito. 3. Los beneficiarios previstos: quiénes se beneficiarán de los resultados del proyecto y cómo 4. Los motivos para intervenir de la institución o la organización que propone el proyecto. 5. Una descripción de la capacidad de prestar apoyo del organismo ejecutante.
4.1.2. Calendario o cronograma de actividades Una vez completado el análisis conforme al marco lógico, se enumeran todas las actividades fijadas en el marco lógico, por el orden en que serán ejecutadas. Cronograma es un concepto que se utiliza en varios países latinoamericanos para mencionar a un calendario de trabajo o de actividades.
El cronograma, por lo tanto, es una herramienta muy importante en la gestión de proyectos. Puede tratarse de un documento impreso o de una aplicación digital; en cualquier caso, el cronograma incluye una lista de actividades o tareas con las fechas previstas de su comienzo y final.
4.1.3. El personal involucrado La selección del personal consiste en el análisis de 3 puntos: ● Madurez del Proceso de Software ● Los participantes – Jefe de Proyecto ● El equipo Madurez del proceso de software El modelo de madurez ● Proceso que nos muestra y explica el camino de una organización para alcanzar la excelencia en la gestión de proyectos a través de diversos niveles de madurez ● Ofrece una estructura para comparar el grado de desarrollo de la capacidad de la administración de proyectos existente en la organización Modelos: ● CMMI-SW (Modelo Integrado de Madurez de la Capacidad de Software) ● MMCGP (Modelo de Madurez de la Capacidad de Gestión del Personal). Software Engineering Institute (SEI), de la Carnegie Mellon Univ. (EEUU) El MMCGP define las siguientes prácticas clave: ● Reclutamiento ● Selección ● Entrenamiento ● Selección de la carrera ● Desarrollo de la cultura de equipo ● Gestión del desempeño ● Retribución ● Diseño de la organización y el trabajo Taxonomía de participantes en un proceso de software: ● Gestores ejecutivos ● Gestores (técnicos) del proyecto ● Profesionales ● Clientes ● Usuarios Habilidades deseables para un jefe de proyecto ● liderazgo y motivación ● ideas o innovación ● resolución de problemas ● gestion ● fomento de la cultura de equipo ● integridad ● influencia y relación ● visión de negocio ● comprensión técnica ● presteza y decisión ● versatilidad y flexibilidad
● previsión Buen técnico ≠ Buen jefe ● “En una jerarquía, todo empleado tiende a ascender hasta su nivel de incompetencia”. Lawrence J. Peter ● “Las compañías tienden a ascender sistemáticamente a sus empleados menos
competentes a cargos directivos para limitar así la cantidad de daño que son capaces de provoca”. Scott Adams
Modelo de gestión (habilidades del jefe de proyecto): ● Motivación. Adecuar la producción conforme a las mejores capacidades de cada empleado ● Organización. Adecuar/Crear procesos para llevar el concepto inicial al producto final ● Ideas/Innovación. Motivar al personal para aportar ideas dentro de los límites del proyecto ● Objetivo principal: hacer ver al equipo la importancia de la calidad del producto en
desarrollo
4.1.4 Políticas de comunicación y seguimiento Una de las principales debilidades que tienen actualmente las organizaciones, es la ausencia de una política de comunicación que; por un lado, permita alinear el discurso de la empresa a sus objetivos de negocio y; por el otro, establecer los vínculos necesarios con sus audiencias claves para asegurar su viabilidad en un entorno cada vez más dinámico y complejo. El desarrollo de una política de comunicación permite a las organizaciones desarrollar mayores capacidades para la gerencia de su reputación. De esta forma se logran sincronizar los activos comunicacionales de la empresa, orientarlos y administrarlos en la dirección correcta. Una política de comunicación empresarial debe contener entre otros aspectos: objetivos estratégicos de comunicación, indicadores de gestión de las comunicaciones, mapa de grupos de interés, una clara definición de los ejes de posicionamiento institucional, desarrollo de mensajes claves, una política de vocería, un manual de contingencias compartido por las diferentes áreas de la empresa, entre otros lineamientos. Así mismo, es importante establecer escenarios de planificación y desarrollo de los procesos de comunicación. Para ello, es útil integrar un equipo multidisciplinario de alto nivel y con poder de decisión, bajo el paraguas de un comité de comunicaciones y asuntos públicos, que permita establecer la agenda comunicacional de la empresa, tanto interna como externa, el mix de medios, mensajes, los voceros adecuados para atender las demandas de información o generar éstas y los lineamientos para el desarrollo de las acciones previstas. Otro de los criterios importantes para sostener una adecuada política de comunicación en la práctica, es tener un continuo monitoreo del entorno, que permita identificar los issues asociados a la actividad de la empresa. De esta forma, la organización es capaz de establecer su posición ante estos issues de manera proactiva y minimizar o capitalizar su impacto según sea el caso. Para desarrollar estos elementos existen múltiples metodologías, pero fundamentalmente lo que se necesita es la voluntad de la alta gerencia para dedicar tiempo y concentrar parte de su esfuerzo en atender la dinámica comunicacional de la organización. Las empresas actualmente se enfrentan a un escrutinio público desde los medios de comunicación, grupos de presión, el gobierno y sus instituciones, organizaciones no gubernamentales y la comunidad. Muchos de estos escenarios de coyuntura son manejados de manera espontánea y en la mayoría de los casos los costos de los desaciertos terminan generando daños a la imagen de la empresa que no son cuantificables, pero cuyos efectos se evidencian en las barreras que se crean alrededor de la actividad de la organización, afectando su viabilidad y generando coyunturas cada vez más frecuentes.
Las empresas están aprendiendo que tienen que administrar y reforzar la gestión de sus activos intangibles con la misma energía que asignan a los activos tangibles del negocio. Un primer paso en este sentido es trabajar sobre una política de comunicación, contar con un “manual de vuelo”, una guía que les permita enfocar su actividad gerencial con una eficiente
gestión comunicacional.
4.2. Lineamientos de comunicación y seguimiento //NO ENCONTRE INFORMACIÓN
4.2.1. Formatos El formato es simple y se estructura en el siguiente orden: 1. Nombre del proyecto 2. Identificación del problema 3. Objetivos 4. Etapas y actividades contempladas del proyecto 5. Etapas y actividades en el tiempo 6. Productos del proyecto 7. Beneficiarios del proyecto 8. Impactos del proyecto 9. Relación del proyecto con otras iniciativas 10. Breve resumen del proyecto 11. Presupuesto del proyecto 12. Fuentes de financiamiento 13. Responsable del proyecto y seguimiento del proyecto 14. Evaluación
4.2.2. Herramientas 1. Reflexión Descripción de los contenidos del primer balance, o reflexivo A. Competencias genéricas y grado de dominio B. Calificaciones y rendimiento en los estudios C. Revisión de las actividades laborales hechas hasta ahora D. Visión sintética de tu trayectoria E. Las potencialidades F. Las debilidades G. Revisión de la ayuda y de la orientación recibidas H. Reflexión sobre las consecuencias de lo que he hecho hasta ahora I. Mi decisión una vez hecho el primer balance 2. Balance de síntesis Descripción de los contenidos del segundo balance A. Mis aptitudes B. Mis valores laborales C. La relevancia de mis valores en mi futura carrera profesional D. Mi propio concepto y rasgos psicológicos E. Mi autobiografía F. Mis conocimientos y adquisiciones Competencias A. Competencias específicas y grado de dominio (al finalizar la carrera) B. Valoración de las competencias genéricas (al finalizar la carrera) C. Cuadro comparativo de consecución de las competencias genéricas D. Relaciones entre las competencias genéricas y el futuro lugar de trabajo Conocimiento del mundo del trabajo A. ¿Cuáles pueden ser mis preferencias profesionales? B. Inventario de las actividades profesionales desarrolladas hasta ahora C. ¿Cuáles son mis creencias sobre el trabajo? D. Maneras de conocer el mundo del trabajo E. Construyendo tu agenda personal de información profesional F. ¿Qué tengo que saber del lugar de trabajo que pienso desarrollar en el futuro? G. Exigencias mínimas de un lugar de trabajo H. Las exigencias del perfil profesional de un lugar de trabajo I. Problemas que pueden surgir al planificar mi carrera profesional J. Mi directorio para empezar a buscar un trabajo 3. Previas A. Un flash de mi evolución personal B. Las motivaciones hacia el trabajo
C. ¿Dónde viviré yo de aquí a unos años y qué haré? 4. Portafolio A. Proceso de construcción del proyecto profesional. El pasado B. Proceso de construcción del proyecto profesional. El presente C. Proceso de construcción Actualmente en la red existen gran variedad de manuales e información que coinciden bastante en sus bases, los cuales sirven para la descripción detallada paso a paso de como realizar la presentación de un proyecto. a continuación dejo algunos enlaces que pueden servir para la misma elaboración: ● http://www.ilo.org/wcmsp5/groups/public/---ed_emp/---emp_ent/--coop/documents/instructionalmaterial/wcms_173149.pdf ● http://www.taringa.net/posts/info/1075959/Como-presentar-un-proyecto.html ● http://www.publicacions.ub.edu/liberweb/mundo_trabajo/cuestionario.pdf ● http://www.fondoempleo.com.pe/descargas/MANUAL10CONCURSO.pdf ● http://universitas.net.ve/manualprocomuni.pdf
4.3. Contrato El éxito en los proyectos de desarrollo de software a la medida depende, en gran medida, de que el trabajo entre el cliente y el desarrollador se encuentre debidamente normado. En este sentido, es un factor reconocido de éxito para estos proyectos formalizar los acuerdos entre ambos, las especificaciones del trabajo por desarrollar, precios, términos y condiciones, entre otros elementos. Cuando el cliente y el desarrollador forman parte de organizaciones distintas, normalmente se firma un contrato informático ad hoc. En este artículo presentaremos algunos aspectos y características especiales por considerar en la elaboración de este tipo de contratos. Comencemos por revisar las principales ventajas de cuidar la elaboración de un buen contrato informático para el desarrollo de proyectos de software: Describe técnica y legalmente las actividades por desarrollar, de manera que un buen contrato debe evitar que dichas actividades queden sujetas a la interpretación de cualquiera de las dos partes: el cliente y el desarrollador. En esta descripción debe emplearse, en el mayor número de aspectos, mecanismos cuantitativos, para que la evaluación del cumplimiento pueda ser objetiva. Promueve la definición más exacta posible del producto a desarrollar, pues un buen contrato debe incluir relaciones completas y claras de los requerimientos y especificaciones del software que se construirá, así como mecanismos de control tales como los criterios para su aceptación a la entrega final, y el plan de pruebas para corroborar su funcionamiento. Documenta los acuerdos verbales tomados por las partes, antes de la firma del instrumento legal, y proporciona un marco de actuación para los acuerdos que deban tomarse durante el desarrollo del contrato. De esta manera, dichos acuerdos y los compromisos asumidos no podrán ser cambiados ni por el tiempo ni ante eventos futuros, a menos que el mismo contrato indique cómo puede haber modificaciones. Esto es particularmente útil para el caso de tareas de cuya terminación dependa el desempeño de la otra parte; por ejemplo, de la aprobación de un diseño formal por parte del cliente depende el inicio de las actividades de programación por parte del desarrollador. Ayuda a proteger tanto al cliente como al desarrollador ante cualquier “desastre”
potencial, lo que previene eventos y riesgos desde la negociación inicial y la definición del producto por desarrollar. Ejemplos de estos sucesos son los cambios de personal clave para el proyecto, por cualquiera de las partes, casos de fuerza mayor, desastres naturales, huelgas, cambios en los requerimientos o especificaciones, terminación anticipada, en fin, situaciones que pudieran enrarecer el proceso de desarrollo e implementación del software. Define la forma en que se dará por terminado este proyecto y, por lo tanto, la relación legal entre el cliente y el desarrollador, cualquiera que sea el resultado y la forma de finalización (normal o anormal), protegiendo el interés común, y aún incluyendo sanciones por incumplimiento de cualquiera de las partes. Promueve la participación, comunicación e involucramiento de ambas partes para el desahogo y seguimiento de actividades durante el desarrollo del proyecto, y previene la manera de resolverse los posibles conflictos entre el cliente y el desarrollador.
En este orden de ideas, es sumamente conveniente hacer las siguientes preguntas para comprobar que un contrato de desarrollo de software cumple con las características deseables en instrumentos de esta naturaleza, particulares a este tipo de proyectos: ¿Se incluyeron requerimientos y especificaciones detalladas como parte del contrato, o serán construidas y validadas como parte del proyecto contratado? ¿Se hicieron explícitas las exclusiones, esto es, lo que no incluirá el producto final, o lo que no se contemplará durante el desarrollo del proyecto? ¿Qué productos de trabajo, además del sistema de información, van a ser generados? ¿Están amparados por el contrato? ¿Cuál será su contenido? ¿Cuál será el procedimiento para aceptar cada uno de los productos? ¿Cómo se comprobará que cumplen con lo comprometido? ¿Se establecieron en el contrato controles para los cambios en requerimientos y especificaciones? ¿Se dividió el proyecto en fases y se elaboró un calendario de actividades? ¿Bajo qué mecanismos y procedimientos, y con qué frecuencia, se dará seguimiento conjunto al proyecto? ¿Se estableció quién retiene la propiedad del código fuente “original”, creado para el
proyecto? ¿Quién retiene la propiedad del código que el desarrollador incluye en el producto, pero que forma parte de sus librerías, y si es el caso, si le va a proporcionar al cliente documentación de esa parte? Si el desarrollador se hace responsable de la corrección de defectos, ofreciendo algún tipo de garantía, ¿se especifican en el contrato los escenarios para las correcciones, y el tiempo comprometido para hacerlas? ¿Quién será el responsable de la instalación, y en general, de las actividades de implantación del sistema? ¿Dónde residirá el sistema en las instalaciones del cliente, en qué servidor y bajo qué condiciones para la operación del software? ¿Quién será el responsable del mantenimiento al sistema? ¿En su caso, contará el cliente con los elementos suficientes y necesarios para poder abordar las tareas de mantenimiento? ¿Quién será el responsable de la operación del sistema? ¿Contará con los elementos suficientes y necesarios para realizar sus tareas? ¿Se firmarán acuerdos de confidencialidad? ¿Cuáles son las implicaciones para el desarrollador y cuáles para el cliente? ¿Se ha protegido la relación laboral con el personal de cada una de las partes, y las posibles contrataciones de miembros del equipo del desarrollador, por parte del cliente? ¿Se han definido las pruebas a que será sometido el producto final? ¿Quién las llevará a cabo? ¿Cuáles son los criterios para aceptar el producto final? ¿Quién es el responsable de determinar si se cumplen o no? ¿Qué mecanismos protegen tanto al cliente como al desarrollador de los posibles desacuerdos al determinar el cumplimiento de los criterios de aceptación? ¿Se estableció un plan de pagos acorde con la programación de entregas de productos parciales y finales?
Bibliografía ● ● ● ● ● ●
http://www.ehowenespanol.com/escribir-propuesta-proyecto-como_31836/ http://www.ramsar.org/cda/es/ramsar-activities-grants-rsgf-advice-ondeveloping/main/ramsar/1-63-68-159%5E23256_4000_2__ http://definicion.de/cronograma/ http://www.kybele.etsii.urjc.es/docencia/IS_LADE/2012-2013/Material/[IS-LADE2012-13]TEMA%20IV%20-%20Gesti%C3%B3n%20de%20proyectos.pdf http://competitividadresponsable.wordpress.com/2010/01/04/la-politica-decomunicacion-corporativa/ http://www.slideshare.net/jfk791021/formato-bsico-para-la-presentacin-deproyectos
