Conceptos Básicos para la Gestión de Proyectos_Marino Uitzil.pdf

18
1 Instituto Tecnológico Superior de Felipe Carrillo Puerto Unidad Académica Tulum Ingeniería en Sistemas Computacionales Gestión de proyectos de software Unidad 1 Mariano Jediel Uitzil Basto Ing. José Torres Ek Investigación temas 1.1 Conceptos Básicos para la Gestión de Proyectos 18/Agosto/2015

Transcript of Conceptos Básicos para la Gestión de Proyectos_Marino Uitzil.pdf

1

Instituto Tecnológico Superior de Felipe Carrillo Puerto

Unidad Académica Tulum

Ingeniería en Sistemas Computacionales

Gestión de proyectos de software

Unidad 1

Mariano Jediel Uitzil Basto

Ing. José Torres Ek

Investigación temas 1.1 Conceptos Básicos para la Gestión de Proyectos

18/Agosto/2015

2

Índice

Introducción ........................................................................................................................................ 3

Investigación ....................................................................................................................................... 4

Conceptos Básicos para la Gestión de Proyectos ................................................................................ 4

Conclusión ......................................................................................................................................... 17

Bibliografía ........................................................................................................................................ 18

3

Introducción

La gestión de proyectos de software es el control y la planeación que conllevan a

la realización de un software ya que como todo, tiene que llevar un proceso de

elaboración y documentación y planificación para que obtenga la el alcance de las

expectativas deseadas, dicha planificación y control de todos los procesos tienen

sus etapas en los cuales son llevados a cabo por cada uno del personal

correspondiente a la tarea asignada por el equipo de trabajo para el desarrollo del

software de tal modo que todo la organización realizada para el proceso de

creación cumpla los estándares correspondientes de calidad y de tal modo tener la

eficiencia deseada por cada uno de los desarrolladores y gestores en cada caso.

4

Investigación

Conceptos Básicos para la Gestión de Proyectos

Gestión son todas las actividades y tareas ejecutadas por una o más personas con el propósito de planificar y controlar las actividades de otros para alcanzar un objetivo o completar una actividad que no puede ser realizada por otros actuando independientemente. 1.1 Definición de las actividades de gestión. Planificación: Predeterminación de un curso de acción para alcanzar los objetivos organizacionales. Organización: Arreglo de las relaciones entre las unidades de trabajo para el cumplimiento de objetivos y el otorgamiento de responsabilidad y autoridad para obtener esos objetivos. Staffing: Selección y entrenamiento de personas para puestos en la organización. Dirección: Creación de una atmósfera que apoye y motive a la gente para alcanzar los resultados finales deseados. Control: Establecimiento, medición y evaluación del desempeño de las actividades a través de los objetivos planeados.

5

1.2 Universalidad de la gestión Los administradores realizan las mismas funciones independientemente de su lugar en la estructura organizacional o el tipo de empresa.

1.3 Habilidades de Gestión y la Jerarquía Organizacional.

Habilidades Técnicas. Conocimiento y pericia en actividades que involucran métodos, procesos y procedimientos. Esto implica trabajar con herramientas y técnicas específicas. Habilidades Humanas. Habilidad para trabajar con gente, del esfuerzo cooperativo, del trabajo en equipo, de la creación de un ambiente donde la gente se sienta segura y libre de expresar sus opiniones. Habilidades Conceptuales. Habilidad para ver la “Imagen Completa” (the big picture), para reconocer los elementos relevantes de una situación, y para entender las relaciones entre los elementos.

6

Habilidades de Diseño. Habilidad para resolver problemas de manera que beneficie a la empresa. Para ser efectivos, particularmente en los niveles organizacionales altos, los gerentes deben ser capaces de más que sólo ver un problema. Si los gerentes solamente ven los problemas y se transforman en “observadores de problemas”, fallarán. Deben tener, además, la habilidad de un buen ingeniero de diseño para generar una solución práctica a un problema. Planteo del problema de la gestión La gestión de proyectos de software persigue la misma finalidad que todas las gestiones de proyectos de ingeniería: · Estimar que sucederá con un proyecto nuevo · Analizar qué sucedió con un proyecto ya finalizado En todos los casos se tratará de dar respuestas cuantitativas a preguntas precisas tales como: · ¿Cuál será el plazo de entrega? · ¿Cuántas personas necesito? · ¿Cuánto costará el proyecto? La gestión de proyectos de software es una rama especializada de la Ing. de software. Gestión de proyectos de Software No debe perderse de vista nunca que lo que intentamos hacer no es una rama de la brujería sino una rama de la Ing. del Software. No se busca preparar gurús sino ingenieros, no se apela a oscuros mecanismos sino a datos numéricos en información medible. No debe confundirse una ecuación empírica, obtenida del análisis de muchos casos y sometida reiteradas veces al contraste con la experiencia práctica con una forma de brujería. Por esta razón, estamos hablando de una rama de la ingeniería que: · Emplea metodologías bien definidas. · Realiza medidas repetibles y confiables. · Estima costos y tiempos. · Da elementos para la gestión de los proyectos.

7

· Replantea resultados para ajustar la información disponible.

Diferentes tipos de proyectos.

Debemos diferenciar tres tipos de proyectos desde el punto de vista de su gestión: · Proyectos nuevos: se busca analizar costos, tiempos y cantidad de personas. Es el caso más difícil de todos. · Replanteo de proyectos viejos: se busca afinar las metodologías de estimación. Es la principal fuente de información · Extensiones: o ampliaciones de un proyecto existente: Es un caso intermedio donde se desea tener buena precisión en plazos y costos. El tamaño de los proyectos Los proyectos de software son diferentes por la sola razón de su tamaño. · Proyectos pequeños: consisten solamente en implementación. No tienen costos indirectos importantes · Proyectos medianos: es un caso intermedio entre los dos. · Proyectos grandes: poseen implementación, pero hay más cosas. Poseen gerencia de proyecto, control de calidad, capacitación de personal, hay un plan de mantenimiento, hay documentación importante para uso interno y externo. Se genera información para mercadeo. Un error clásico en la historia de la gestión de proyectos fue no advertir la existencia de éstas tres categorías y es un error pensar que la experiencia adquirida en proyectos pequeños nos pueda servir en proyectos medianos o grandes. La constitución del equipo de trabajo es uno de los mejores indicadores del caso que se considera.

8

· Pequeños: - Menos de un año de tiempo de desarrollo - Menos de 25 meses-persona de esfuerzo total - Menos de 3 personas en el equipo de trabajo · Grandes: - Mas de 3 años de tiempo de desarrollo - Mas de 100 meses persona - Mas de 10 personas en el equipo de trabajo Un equipo de trabajo de menos de 3 personas puede trabajar con una documentación informal, un equipo de mas de 10 personas, durante varios años, no puede confiar en los contactos personales ni en la memoria de la gente. Es más, puede ocurrir que muchos de los que comienzan en el proyecto sean reemplazados por otros, en plazos tan largos.[3] 3. Desarrollo El trabajo desarrollado se basa en el enfoque de las 4 P (Personal, Producto, Proceso y Proyecto). Personal • Sin duda alguna en todas las empresas el elemento más importante es el recurso humano o personal. • El SEI, desarrollo ha desarrollado el MMCGP con el fin de: “Aumentar la rapidez con la cual las organizaciones de sw acometen las aplicaciones cada vez más complejas al ayudar a atraer, aumentar, motivar, desplegar y retener el talento necesario para mejorar su capacidad de desarrollo de sw” • El equipo de dirección del proyecto debe identificar a los interesados, determinar sus requisitos y expectativas y, gestionar su influencia en relación con los requisitos para asegurar un proyecto exitoso.

9

¿Qué tomar en cuenta? • Reclutamiento, selección, entrenamiento, diseño de la organización, el trabajo y desarrollo de la cultura de equipo. Participantes: • Se proponen las siguientes categorías: – Gestores Ejecutivos.- definen aspectos del negocio – Gestores del proyecto.- planifican, motivan, organizan y controlan a los profesionales que realizan el trabajo de sw. – Profesionales.- dan habilidades para la ingeniería de una aplicación. – Clientes.-especifican requisitos y necesidades – Usuarios Finales.- quienes interactúan con el sistema.

Interesados: Director del proyecto. Dirige el proyecto. Cliente/usuario. Persona u organización que utilizará el producto del proyecto. Organización ejecutante. Empresa cuyos empleados participan más directamente en el trabajo del proyecto. Miembros del equipo del proyecto. El grupo que realiza el trabajo del proyecto. Equipo de dirección del proyecto. Miembros del equipo del proyecto que participan directamente en las actividades de dirección del proyecto.

Patrocinador. Persona o grupo que proporciona los recursos financieros, monetarios o en especie, para el proyecto. Influyentes. Personas o grupos que no están directamente relacionados con la adquisición o el uso del producto del proyecto, pero que, debido a su posición en la organización del cliente u organización ejecutante, pueden ejercer una influencia positiva o negativa sobre el curso del proyecto. Oficina de Gestión de Proyectos (PMO). Puede ser un interesado si tiene responsabilidad directa o indirecta sobre el resultado del proyecto.

10

¿Cómo estructurar un equipo? Se debe tener en cuenta las siguientes consideraciones: • La dificultad del problema que se resolverá. • El tamaño del programa resultante en líneas de código. • Vida del equipo (trabajo en conjunto) • El grado en el que el problema puede separarse en módulos. • La calidad y confiabilidad requeridas del sistema que se construirá. • La rigidez de la fecha de entrega. • El grado de comunicación que requiere el proyecto

11

Paradigmas Organizacionales

Tipos

Características

Cerrado

- Jerarquía tradicional de autoridad - Aconsejable para proyectos similares a anteriores. - Débil para proyectos innovadores

Aleatorio

- Equipo libremente y depende de la iniciativa individual. - Fuerte en proyectos innovadores - Puede haber problemas cuando hay desempeño ordenado.

Abierto

-Usa controles del cerrado e innovación del aleatorio - Sólida comunicación y toma de decisiones basadas en el consenso.

Sincrónico

-Organiza a los miembros para trabajar en partes del problema -Poca comunicación entre los miembros

12

CUIDADO Factores que inciden negativamente en un ambiente de trabajo en equipo: 1. Una atmósfera de trabajo frenética 2. Alta frustración que provoca fricción entre los miembros del equipo 3. Proceso de software pobremente coordinado 4. Una definición poco clara de los papeles del equipo de sw. 5. Continuas y repetidas exposiciones al fracaso. EQUIPOS ÁGILES La filosofía ágil alienta la satisfacción del cliente y la temprana entrega incremental del software. - Pequeños equipos de trabajo enormemente motivados - Métodos informales - Mínimos productos de trabajo de ingeniería del sw. - Simplicidad global de desarrollo

Producto Un proyecto crea productos entregables únicos. Productos entregables son productos, servicios o resultados. Los proyectos pueden crear: · Un producto o artículo producido, que es cuantificable, y que puede ser un elemento terminado o un componente · La capacidad de prestar un servicio como, por ejemplo, las funciones del negocio que respaldan la producción o la distribución · Un resultado como, por ejemplo, salidas o documentos. Por ejemplo, de un proyecto de investigación se obtienen conocimientos que pueden usarse para determinar si existe o no una tendencia o si un nuevo proceso beneficiará a la sociedad La conclusión y la aprobación de uno o más productos entregables caracterizan a una fase del proyecto. Un producto entregable es un producto de trabajo que se puede medir y verificar, tal como una especificación, un informe del estudio de viabilidad, un documento de diseño detallado o un prototipo de trabajo. Algunos productos entregables pueden corresponder al mismo proceso de dirección de proyectos, mientras que otros son los productos finales o componentes de los productos finales para los cuales se creó el proyecto. Los productos entregables, y en consecuencia las fases, son parte de un proceso generalmente secuencial,

13

diseñado para asegurar el adecuado control del proyecto y para obtener el producto o servicio deseado, que es el objetivo del proyecto. En cualquier proyecto específico, las fases se pueden subdividir en subfases en función del tamaño, complejidad, nivel de riesgo y restricciones del flujo de caja. Cada subfase se alinea con uno o más productos entregables específicos para el seguimiento y control. La mayoría de estos productos entregables de las subfases están relacionados con el producto entregable de la fase principal, y las fases normalmente toman el nombre de estos productos entregables de las subfases: requisitos, diseño, construcción, prueba, puesta en marcha, rotación, entre otros, según corresponda.

Por lo general, una fase del proyecto concluye con una revisión del trabajo logrado y los productos entregables, a fin de determinar la aceptación, tanto si aún se requiere trabajo adicional como si se debe considerar cerrada la fase. Con frecuencia, la dirección lleva a cabo una revisión para tomar una decisión a fin de comenzar las actividades de la siguiente fase sin cerrar la fase actual, por ejemplo, cuando el director del proyecto elige la ejecución rápida como curso de acción. Otro ejemplo es cuando una compañía de tecnología de la información elige un ciclo de vida iterativo donde más de una fase del proyecto puede avanzar de forma simultánea. Los requisitos de un módulo se pueden recopilar y analizar antes de que el módulo sea diseñado y construido. Mientras se lleva a cabo el análisis de un módulo, se puede comenzar a recopilar los requisitos de otro módulo de forma paralela.

Proceso Un proceso de software proporciona el marco de trabajo desde el cual se puede establecer un plan detallado para el desarrollo del software. Un pequeño número de actividades del marco de trabajo es aplicable a todos los proyectos de software, sin importar su tamaño o complejidad. Algunos conjuntos de tareas diferentes (tareas, hitos, productos de trabajo y puntos de control de calidad) permiten que las actividades del marco de trabajo se adapten a las características del proyecto de software, así como a los requisitos del equipo del proyecto. Finalmente, las actividades protectoras como control de calidad, la gestión de configuración y la medición cubren el modelo del proceso. Las actividades protectoras son independientes de cualquier actividad del marco de trabajo y ocurren durante todo el proceso

• Elegir el modelo que mejor se adapte

• Para cumplir con:

1. Los clientes que han solicitado el producto y el personal que hará el trabajo. 2. Las características del producto

14

3. El ambiente del proyecto en que trabaja el equipo de software Descomposición del proceso:

Esta descomposición depende mucho del tipo de proyecto que se realizará, así por ejemplo:

•Proyecto pequeño à enfoque secuencial

•Restricciones de tiempo à desarrollo rápido de aplicaciones (DRA)

•Funcionalidad no se alcanza por fecha muy ceñida à estrategia incremental

Proyecto La gestión de un proyecto de software exitoso requiere entender qué puede salir mal. A continuación se indican 10 señales de que un proyecto esté en peligro. 1. El personal de software no entiende las necesidades de sus clientes.

2. El ámbito del producto está mas definido

3. Los cambios se gestionan mal

4. La tecnología elegida cambia

5. Las necesidades comerciales cambian

6. Los plazos de entrega no son realistas

7. Los usuarios se resisten

8. Se pierde el patrocinio

9. El equipo de proyecto carece de personal con las habilidades apropiadas

10. Los gestores evitan las mejores prácticas y las lecciones aprendidas

¿Qué hacer frente a lo anterior?

1. Comience con el pie derecho

• entendiendo bien el proyecto, definir los objetivos

• dar al equipo autonomía, autoridad, y tecnología.

2. Mantenga el ímpetu

• proporcionar incentivos

• Los gestores deben estar fuera del camino del equipo de desarrollo.

15

3. Rastree el proyecto

• mediante revisiones técnicas formales (QA)

• establecer medidas que muestren el progreso.

4. Tome decisiones inteligentes

• “mantenerlo simple”

• Consejo utilice sw o componentes ya desarrollados, no se complique la vida

5. Realice un análisis de resultados

• Métricas del proyecto de sw realimentación de los miembros y clientes

• registre los hallazgos

4. Resultados

En todos los proyectos de ingeniería la buena calidad se adquiere mediante un buen diseño, pero en el caso del software, la etapa de construcción incide pobremente en su calidad, no así en la construcción de hardware o de una obra civil. Así, no se puede gestionar un proyecto de desarrollo de software como si se tratara de un proyecto de fabricación. Es por eso que en el desarrollo de software donde no existe una gestión adecuada podemos encontrar varios problemas tales como:

Requerimientos incorrectos e incompletos, muchas especificaciones de requerimientos son inestables y sujetas a cambios mayores, la planificación no se lleva a cabo por la creencia errónea de que es una pérdida de tiempo y los planes cambiarán de todos modos, es difícil estimar el tamaño y complejidad del proyecto de software de modo de realizar una estimación de costos y plazos realista, no se manejan factores de riesgo, la mayoría de las organizaciones de desarrollo de software no recolectan datos de proyectos pasados, las compañías no establecen políticas o procesos de desarrollo de software.

La gestión del proyecto de software es el primer nivel del proceso de ingeniería de software, que nos permite hacer frente a los problemas anteriormente mencionados, porque cubre todo el proceso de desarrollo.

Para conseguir un proyecto de software fructífero se debe comprender el ámbito del trabajo a realizar, los riesgos en los que se puede incurrir, los recursos requeridos, las tareas a llevar a cabo, el esfuerzo (costo) a consumir y el plan a seguir.

16

En el presente artículo se detalla los elementos más importantes y relevantes de la gestión de proyectos de software, de modo de proveer las bases conceptuales necesarias para llevar a cabo un proyecto exitoso.

Con respecto a la manera en cómo se llevo la clase impartida a nuestros compañeros obtuvimos los siguientes resultados:

· La compresión de forma clara acerca de los pilares de la gestión de proyectos (Personal, Producto, Proceso y Proyecto).

· Los estudiantes están la capacidad de prever en forma general los aspectos importantes al conformar un equipo de trabajo.

· Determinar en forma clara las diferencias y similitudes entre los paradigmas organizacionales. · Estudiamos los síntomas de cuando un proyecto se encuentra en problemas para poder evitarlos en un futuro.

· Aporte por parte de los compañeros al surgir nuevos criterios valederos de los conceptos tratados.

· En el transcurso de la clase realizamos el estudio con ejemplos prácticos de las diferentes culturas organizacionales a nivel local como internaciones específicamente con el ejemplo de cómo se trabaja en google.

17

Conclusión

En conclusión la gestión de los proyectos de software es un proceso por el cual

antes de la creación de algún software tiene que pasar para poder ser elaborado

ya que tiene que tener una base bien fundamentada ya que sin ella no tendría

valides el software, Dicha gestión pasa por varias etapas antes de que llegue a la

etapa de creación tomando en cuenta todos los requerimientos necesarios para su

creación.

18

Bibliografía

LIC. OSCAR LÓPEZ YARZAGARAY. (2013). GESTION DE PROYECTOS DE

SOFTWARE. 18 de agosto del 2015, de ITESCAM Sitio web:

http://www.itescam.edu.mx/portal/asignatura.php?clave_asig=SCG-

1009&carrera=ISIC-2010-224&id_d=136