La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Ingenieria del Software UMG

Presentaciones similares


Presentación del tema: "Ingenieria del Software UMG"— Transcripción de la presentación:

1 Ingenieria del Software UMG
Capítulo 3. Gestión de Proyectos de Software

2 “Caminar sobre las aguas y desarrollar programas a partir de las especificaciones es fácil, si ambas están congeladas” Edward V. Berard

3 El proceso del software. Estructura
Estándares en ingeniería del software Utilidad de los estándares Tipos de estándares Estándares relacionados con el proceso software De evaluación del proceso software: SEI(software Engineering Institute) CMM (Modelo de capacidad de Madurez) De procesos estándar del ciclo de vida ISO 9000 El estudio del estándar IEEE nos va a proporcionar una visión muy completa de los procesos del ciclo de vida del software.

4 Proceso software Distintos procesos de software organizan las actividades de diferentes formas, y las describen con diferente nivel de detalle El tiempo de cada actividad varía, así como los resultados Organizaciones diferentes usan procesos diferentes para producir el mismo producto Sin embargo, para algunos tipos de aplicación, algunos procesos son más convenientes que otros

5 Ciclo de vida Alternativamente, a veces se usan los términos
“Ciclo de vida”, y “Modelo de ciclo de vida” Sucesión de etapas por las que atraviesa un producto software a lo largo de su existencia (durante su desarrollo y explotación) El estándar IEEE 1074 y el IEEE proporcionan sus propias definiciones de ciclo de vida.

6 Ciclo de vida (II) Ciclo de vida  Ciclo de desarrollo
Desde el análisis hasta la entrega al usuario Toda la vida del sistema: desde la concepción hasta el fin de uso

7 Estándares en ingeniería del software
Estándar: conjunto de criterios aprobados, documentados y disponibles para determinar la adecuación de una acción (estándar de proceso) o de un objeto (estándar de producto) Guía: conjunto de criterios bien definidos y documentados que encaminan una actividad o tarea  es más flexible que un estándar

8 ¿Porqué usar estándares en ingeniería del software?
Los estándares son útiles porque: agrupan lo mejor y más apropiado de las buenas prácticas y usos del desarrollo de software engloban los “conocimientos” que son patrimonio de una organización proporcionan un marco para implementar procedimientos de aseguramiento de la calidad proporcionan continuidad entre el trabajo de distintas personas

9 Tipos de estándares en ingeniería del software
Estándares para datos: desde asignar nombres a los datos y especificar longitud y tipo hasta los relacionados con BBDD p.ej., Ansi SQL Estándares de codificación: abreviaturas y designaciones formales para describir actividades dentro de la organización p.ej., Notacion Hungara. Estándares estructurales: políticas de división del software en módulos Estándares de documentación Estándares de proceso software Estándares para otras actividades

10 Métodos de evaluación SEI’s CMM (Capability Maturity Model)
“El primer paso para consolidar y mejorar un proceso es valorarlo” Tiempo Nivel 5 4 3 2 1 Inicial Repetible Gestionado Definido Optimizado SEI (Software Engineering Institute) (Universidad de Carnegie Mellon) Requerido por el DoD Amplio uso en EEUU (Pressman 2002) pp.16-18

11 CMM - Madurez del proceso
4. Gestionado: la calidad del producto y del proceso es medida, predecible y cuantificable. Se pueden usar dichas medidas (“métricas del software”) para detectar situaciones excepcionales y corregirlas. 5. Optimizado: el proceso es continuamente mejorado usando las medidas obtenidas de procesos anteriores. 1. Inicial: el éxito depende de esfuerzos heroicos y personales más que de procesos adecuadamente definidos. No hay proceso definido implícita o explícitamente. 2. Repetible: se establecen políticas y procedimientos para llevar a cabo un proyecto. Una función de calidad asegura que se cumplen dichos procedimientos. Se obtienen niveles de calidad parecidos a proyectos anteriores. 3. Definido: se adopta un proceso sw. estándar, y se adapta a cada proyecto.

12 CMM - Madurez del proceso
1.Representa una situacion sin ningun esfuerzo en la garantia de calidad y gestion del proyecto, donde cada equipo puede desarrollar software de cualquier forma eligiendo los metodos, estandares y procedimientos a utilizar que podrian variar desde lo mejor hasta lo peor. 2. Ha definido ciertas actividades tales como el informe del esfuerzo y del tiempo empleado, y el informe de tareas realizadas 3. Ha definido procesos tecnicos como de gestion por ejemplo un estandar en la programacion y se hace cumplir por medio de procedimientos como auditorias. Pretenden conseguir el estandar ISO 9000. 4.Concepto de medicion y el uso de metricas.

13 CMM - Madurez del proceso
5- Es el nivel mas alto de alcanzar, hasta ahora muy pocos han alcanzado esta fase, representa la analogia del software con los mecanismos de control de calidad que existen en otras industrias de mayor madurez. Para que se alcance el nivel 5 tiene que tener cada proceso bien definido rigurosamente y seguirlo al pie de la letra

14 Nivel 2: Gestion de requisitos, planificacion del proyecto de software, seguimiento y supervision, garantia de calidad. Nivel 3: Revisiones periodicas, coordinacion entre grupos, gestion de integracion del software, definicion del proceso de la organización, enfoque del proceso de la organización. Nivel 4: Gestion de la calidad del software, Gestion Cuantitativa del proceso. Nivel 5: Gestion de cambios del proceso, Gestion de cambios de tecnologia, prevencion de defectos.

15

16

17 Procesos estándar Multitud de estándares, métodos, técnicas, y entornos para desarrollar y gestionar software Software usado en multitud de sistemas diferentes: militar, finanzas, medicina, etc. El primer paso para clarificar este estado de cosas sería establecer cuáles son los procesos que se pueden encontrar en el ciclo de vida del software, y eso es lo que hace el IEEE La armonización de las distintas técnicas y métodos que se usan en el desarrollo de software sería un siguiente paso, y es el objetivo de Eurométodo. Dificultades para gestionar la producción de software, integrando productos y servicios

18 Procesos estándar Necesario conseguir un marco común para “hablar el mismo lenguaje” en el desarrollo y gestión de software Objetivo: definir los procesos de desarrollo y mantenimiento del software, y de gestión del mismo, de forma genérica y abstracta Marco común  Estándares del ciclo de vida

19 Procesos estándar Estándar de calidad: ISO 9000
Familia de estándares para la gestión de la calidad de cualquier proceso de producción. La organización debe tener un sistema de calidad que supervise todas las fases de la producción y entrega del producto: audita los proyectos para asegurar que se cumplen los controles de calidad. mejora la calidad del propio sistema de calidad. proporciona entradas al grupo de desarrollo (como nuevas notaciones, procedimientos, estándares). produce informes para la dirección. Para cada proyecto se define un plan de calidad.

20 ISO 9000 para producción de software (Pressman 2002) p.146
ISO Quality Systems - Model for Quality Assurance in Design, Development, Production, Installation and Servicing. Describe el sistema de calidad utilizado para mantener el desarrollo de un producto que implique diseño Aplicable a cualquier proceso de producción: cojinetes, automóviles, TVs, equipamientos deportivos, etc. Se está convirtiendo en el ppal. medio con el que los clientes pueden juzgar la competencia de un desarrollador de software (aceptado en más de 130 países). Se han desarrollado varios documentos que relacionan el estándar con la industria del software, pero no entran en muchos detalles. No impone ciclo de vida. Puede adoptarse por contrato o voluntariamente.

21 ISO 9000 para producción de software
ISO Quality Systems - Model for Quality Assurance in Design, Development, Production, Installation and Servicing. El control de calidad se debe realizar en todas las fases del desarrollo, adquisición y mantenimiento del software. El comprador debe cooperar estrechamente con el suministrador del software. El suministrador debe definir su sistema de calidad, y asegurar que todo el sistema comprende e implementa dicho sistema de calidad.

22 ISO 9000 para producción de software (II)
ISO Impone 20 requisitos: Responsabilidad de la gestión Inspección, medición y equipo de pruebas Sistema de calidad Inspección y estado de las pruebas Revisión de contrato Acción correctiva Control de producto no aceptado Control de documento Tratamiento, almacenamiento, empaquetamiento y entrega Compras Producto proporcionado al comprador Registros de calidad Identificación y posibilidad de seguimiento del producto Auditorías internas de calidad Formación Control del proceso Servicios Inspección y estado de prueba Técnicas estadísticas

23 ISO 9000 para producción de software (III)
ISO Guidelines for Application of ISO 9001 to the Development, Supply and Maintenance of Software Contiene directrices que interpretan ISO 9001 para el desarrollador de software ISO Quality Management and Quality Systems Elements - Part 2. Contiene guías para proporcionar servicios de software, como por ejemplo el soporte de usuario. Cuidado con la mala traducción de (Pressman 2002): “Contiene las directrices para el servicio de facilidades de software como soporte de usuarios”. En el original en inglés está bien expresado.

24 Efecto “bola de nieve”

25 Gestión de Proyectos La gestión de proyectos es el proceso por el cual se planifica, dirige y controla el desarrollo de un sistema aceptable con un costo mínimo y dentro de un período de tiempo especifico. Causas de proyectos fallidos por la gestión de proyectos. Dentro de las principales causas por las que puede fallar un proyecto, se encuentra el hecho de que los analistas no respetan o no conocen bien las herramientas y las técnicas del análisis y diseño de sistemas, además de esto puede haber una mala gestión y dirección del proyecto. Además existen una serie de factores que pueden hacer que el sistema sea mal evaluado, entre estas están: ·Necesidades no satisfechas o no identificadas · Cambio no controlado del ámbito del proyecto ·Exceso de costo ·Retrasos en la entrega. Cuidado con la mala traducción de (Pressman 2002): “Contiene las directrices para el servicio de facilidades de software como soporte de usuarios”. En el original en inglés está bien expresado.

26 Gestión de Proyectos 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. Cuidado con la mala traducción de (Pressman 2002): “Contiene las directrices para el servicio de facilidades de software como soporte de usuarios”. En el original en inglés está bien expresado.

27 Gestión de Proyectos 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. 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 la 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 Cuidado con la mala traducción de (Pressman 2002): “Contiene las directrices para el servicio de facilidades de software como soporte de usuarios”. En el original en inglés está bien expresado.

28 Gestion de Proyectos 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. Cuidado con la mala traducción de (Pressman 2002): “Contiene las directrices para el servicio de facilidades de software como soporte de usuarios”. En el original en inglés está bien expresado.

29 Gestión de Proyectos Personal Sin duda alguna en todas las empresas el elemento más importante es el recurso humano o personal. 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. ¿Qué tomar en cuenta? • Reclutamiento, selección, entrenamiento, diseño de la organización. Participantes: Se proponen las siguientes categorías: Gestores Ejecutivos.- definen aspectos del negocio Gestores del proyecto.- planifican, motivan, organizan controlan a los profesionales que realizan 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. Cuidado con la mala traducción de (Pressman 2002): “Contiene las directrices para el servicio de facilidades de software como soporte de usuarios”. En el original en inglés está bien expresado.

30 Gestión de Proyectos - 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. Cuidado con la mala traducción de (Pressman 2002): “Contiene las directrices para el servicio de facilidades de software como soporte de usuarios”. En el original en inglés está bien expresado.

31 Gestión de Proyectos ¿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 Cuidado con la mala traducción de (Pressman 2002): “Contiene las directrices para el servicio de facilidades de software como soporte de usuarios”. En el original en inglés está bien expresado.

32 Gestión de Proyectos 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. Cuidado con la mala traducción de (Pressman 2002): “Contiene las directrices para el servicio de facilidades de software como soporte de usuarios”. En el original en inglés está bien expresado.

33 Gestión de Proyectos 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 practicas y las lecciones aprendidas Cuidado con la mala traducción de (Pressman 2002): “Contiene las directrices para el servicio de facilidades de software como soporte de usuarios”. En el original en inglés está bien expresado.

34 Gestión de Proyectos Funciones básicas del director de proyectos:
Un director de proyectos debe aplicar un conjunto de técnicas  y conocimientos diferentes de los que aplica un analista. Las funciones básicas de un director o un jefe de proyectos han sido analizadas y diseccionadas por teóricos de la gestión durante muchos años. Entre estas funciones, se incluyen la planificación, la selección de personal, la organización, la definición de calendarios, la dirección y el control. Cuidado con la mala traducción de (Pressman 2002): “Contiene las directrices para el servicio de facilidades de software como soporte de usuarios”. En el original en inglés está bien expresado.

35 Gestión de Proyectos Planificación de las tareas de proyecto y selección del equipo de proyectos El director evalúa las necesidades de recursos y formula un plan para llegar al sistema objeto. Ello se basa en el conocimiento que tiene el director de los requisitos del sistema objeto en cada momento del desarrollo. Un plan básico para el desarrollo de un sistema de información es el suministrado por el ciclo de vida del desarrollo de sistemas. Muchas empresas tienen su propio ciclo de vida estándar, y algunas de ellas tienen también normas sobre métodos y herramientas que han de usarse. Así ha de planificarse cada una de las tareas requeridas para completar el proyecto: ¿Cuánto tiempo se requerirá? ¿Cuántas personas serán necesarias? ¿Cuánto costara la tarea? ¿Qué tareas deben terminarse antes de empezar otras? ¿Pueden solaparse algunas de ellas? Cuidado con la mala traducción de (Pressman 2002): “Contiene las directrices para el servicio de facilidades de software como soporte de usuarios”. En el original en inglés está bien expresado.

36 Gestión de Proyectos Planificación de las tareas de proyecto y selección del equipo de proyectos Los directores de los proyectos son, frecuentemente, los encargados de seleccionar a los analistas y los programadores de un equipo de proyecto. El director de proyectos debería tener muy en cuenta los conocimientos técnicos y de empresa que pueden ser necesarios para terminar un proyecto con éxito. La clave de esta misión es saber elegir adecuadamente  a las personas que habrían de desarrollar las tareas requeridas e identificada como parte de la planificación de proyecto Cuidado con la mala traducción de (Pressman 2002): “Contiene las directrices para el servicio de facilidades de software como soporte de usuarios”. En el original en inglés está bien expresado.

37 Gestión de Proyectos Organización y definición de calendarios para el proyecto Dados el plan y el equipo de proyecto, el director de proyecto es el responsable  de la organización y la definición del calendario del mismo. Los miembros del equipo de proyecto deberán conocer su cometido y sus responsabilidades concretas, así como su relación de dependencia con el respecto al director de proyecto. Cuidado con la mala traducción de (Pressman 2002): “Contiene las directrices para el servicio de facilidades de software como soporte de usuarios”. En el original en inglés está bien expresado.

38 Gestión de Proyectos Organización y definición de calendarios para el proyecto El calendario de proyecto debería desarrollarse con un conocimiento preciso de los requisitos de tiempo, las asignaciones de personal y las dependencias de unas tareas con otras. Muchos proyectos tienen un límite a la fecha de entrega solicitada. El director del proyecto debe determinar si puede elaborarse un calendario factible basado en dicha fecha. Si ni fuera así, debería retrasarse el limite o reajustarse el, ámbito del proyecto. Cuidado con la mala traducción de (Pressman 2002): “Contiene las directrices para el servicio de facilidades de software como soporte de usuarios”. En el original en inglés está bien expresado.

39 Gestión de Proyectos Dirección y control del proyecto Una vez iniciado el proyecto, el director del proyecto se convierte en su máximo responsable. Como tal, dirige las actividades del equipo y hace evaluaciones del avance del proyecto. Por consiguiente, todo director de proyectos debe demostrar ante su equipo cualidades de dirección, como son saber motivar, recompensar, asesorar, coordinar, delegar funciones y reconocer el trabajo de los miembros de su equipo. Además, el director debe informar frecuentemente del avance del proyecto ante sus superiores. Tal vez, la función más difícil e importante del director sea controlar el proyecto. Cuidado con la mala traducción de (Pressman 2002): “Contiene las directrices para el servicio de facilidades de software como soporte de usuarios”. En el original en inglés está bien expresado.

40 Gestión de Proyectos Dirección y control del proyecto Pocos planes hay que puedan llevarse a la practica sin problemas y retrasos. La labor del director de proyectos es hacer un seguimiento de las tareas, los plazos, los costes y las expectativas, con el fin de controlar todos los estos elementos. Si el ámbito del proyecto tiende a crecer, el director del mismo debe tomar una decisión: ¿habría que reducir el ámbito del proyecto para respetar el presupuesto y los plazos, o revisar dicho presupuesto y dichos plazos?  El director del proyecto debería ser capaz de presentar alternativas, y sus implicaciones, a los plazos y presupuestos para saber responder a las expectativas. Cuidado con la mala traducción de (Pressman 2002): “Contiene las directrices para el servicio de facilidades de software como soporte de usuarios”. En el original en inglés está bien expresado.


Descargar ppt "Ingenieria del Software UMG"

Presentaciones similares


Anuncios Google