1 CONCEPTOS SOBRE GESTION DE PROYECTOSUNIDAD CONCEPTOS SOBRE GESTION DE PROYECTOS

2 ¿Qué es la Gestión de Proyectos?1. INTRODUCCION ¿Qué es la Gestión de Proyectos? Implica la planificación, supervisión y control del personal, del proceso mientras evoluciona el software (desde la fase preliminar hasta la implementación)

3 Gestión de Proyectos Para comprender mejor debemos respondernos las siguientes preguntas: ¿Quién lo hace? ¿Por qué es importante? ¿Cuáles son los pasos? ¿Cuál es el producto obtenido?

4 ¿Quién lo hace? Un INGENIERO DE SOFTWARE gestiona sus actividades diarias, y planifica, supervisa y controla las labores técnicas. Los GESTORES DEL PROYECTO planifican, supervisan y controlan el trabajo del equipo. Los GESTORES EJECUTIVOS coordinan la relación entre el negocio y los profesionales de software

5 ¿Por qué es importante? La construcción de software es una empresa compleja, sobre todo cuando trabaja mucha gente durante un tiempo relativamente largo, por esto es importante la planificación. Supervisión y control. Es muy importante que los Proyectos Software sean gestionados

6 ¿Cuáles son los pasos? Las cuatro “P`s” Personal Producto ProcesoProyecto Debe estar organizado para Desarrollar software con efectividad Se debe planificar para estimar el esfuerzo y el tiempo Debe haber Comunicación Con el Cliente para que sea comprensible el ámbito y los requisitos Debe seleccionarse el proceso adecuado para el personal como para el producto

7 ¿Cuál es el producto obtenido?Un plan de proyecto se realiza al comienzo de cada gestión, este plan define el proceso y las tareas a realizar, el personal que hará el trabajo y los mecanismos para evaluar los riesgos, controlar el cambio y evaluar la calidad.

8 2. EL ESPECTRO DE LA GESTIONLa gestión eficaz de un proyecto de software se centra en las 4 P`s. Un gestor que no establece una buena comunicación con el usuario al principio de la evolución del proyecto se arriesga a construir una elegante solución para un problema equivocado. Por otro lado, un Adm. que presta poca atención al proceso corre el riesgo de arrojar métodos técnicos y herramientas eficaces al vació. El gestor que comprende un proyecto sin un plan sólido arriesga el éxito del producto. Personal Producto Proceso Proyecto ESPECTRO DE LA GESTION

9 2.1 Personal Este factor es tan importante que el Instituto de Ing. de Software ha desarrollado un Modelo de Madurez de Capacidad de Gestión de Personal MMCGP, para llevar a cabo las cada vez más complicadas APLICACIONES ayudando a atraer, aumentar, motivar, desplegar y retener talento necesario para mejorar su capacidad de desarrollo de software. Atraer Aumentar Motivar Desplegar Retener El TALENTO necesario para mejorar su CAPACIDAD DE DESARROLLO DE SOFTWARE

10 2.1 Personal EL MMCGP define las siguientes áreas calve practicas para el personal de software: RECLUTAMIENTO ELECCIÓN GESTION DEL DESEMPEÑO ENTRENAMIENTO RETRIBUCION DESARROLLO DE LA CARRERA DISEÑO DE LA ORGANIZACIÓN DESARROLLO DE LA CULTURA DE EQUIPO MAYOR PROBALIDAD de implementar efectivas practicas de ingeniería de software

11 Para los LIDERES DEL EQUIPO se debe utilizar la técnica MOI2.1 Personal PARTICIPANTES Gestores ejecutivos Gestores del proyecto (técnicos) 3. Profesionales 4. Clientes 5. Usuarios finales Definen los aspectos del negocio Planifican, motivan, organizan y controlan a los profesionales que realizan el software Proporcionan las habilidades técnicas necesarias para realizar la ingeniería Especifican la ingeniería de software Quienes interactúan con el software Para los LIDERES DEL EQUIPO se debe utilizar la técnica MOI

12 2.1 Personal EQUIPO DE SOFTWAREExisten SIETE aspectos importantes que se deben considerar cuando se planifica la estructura de los equipos de INGENIERIA DE SOFTWARE.

13 2.2 Producto Antes de planificar un proyecto, se debe establecer:Los objetivos y el ámbito del producto Considerar las soluciones y alternativas Identificar las dificultades técnicas o de gestión. Sin esta información es imposible definir unas estimaciones razonables de: coste Valoración efectiva del riesgo Subdivisión realista de las tareas del proyecto Una planificación del proyecto asequible que proporcione una indicación fiable del proyecto.

14 2.2 Producto El desarrollador y el cliente deben reunirse para definir los objetivos del producto. Es parte del proceso de ingeniería del sistema o del negocio Se conforma como el primer paso en el análisis de los requisitos de software Los objetivos identifican las metas generales del proyecto sin considerar como se conseguirán. El ámbito identifica los datos primarios, funciones y comportamientos que caracterizan al producto. Una vez que se han entendido los objetivos y ámbito del producto se consideran soluciones alternativas. Inegenieria de software II Ing. Karen Ruth Chura Gonzales

15 2.2 Producto AMBITO DE SOFTWARECONTEXTO: ¿Cómo encaja el software que se desarrollará en un sistema mas grande? OBJETIVOS DE INFORMACION: ¿Qué objetos de datos visibles al usuario se producen como resultado del software? FUNCIONES Y DESEMPEÑO: ¿Qué funciones realiza el software para transformar los datos? El AMBITO EL PROYECTO no debe ser ambiguo ni incomprensible a niveles de gestión y técnico. Se debe describir: DATOS CUANTITATIVOS (número de usuarios, tiempo de respuesta) RESTRICCIONES Y LIMITACIONES (costo del producto, tamaño de la memoria) FACTORES QUE REDUCEN RIESGOS (algoritmos deseados) Inegenieria de software II Ing. Karen Ruth Chura Gonzales 15

16 2.2 Producto DESCOMPOCISON DEL PROBLEMA Llamada PARTICION O ELABORACION DEL PROBLEMA, es una actividad que se asienta en el núcleo del análisis de requisitos de software. Inegenieria de software II Ing. Karen Ruth Chura Gonzales 16

17 del Proceso de SoftwareProporciona el marco de trabajo desde el cual se puede establecer un plan detallado para el desarrollo de software. El problema es seleccionar el MODELO DE PROCESO apropiado para que un equipo de proyecto someta el software a ingeniería. Modelo Prescriptivo del Proceso de Software

18 Modelo Prescriptivo del Proceso de SoftwareCOMUNICACION Inicio del Proyecto Recopilación de requisitos PLANEACION Inicio del Proyecto Recopilación de requisitos MODELADO Análisis Diseño CONSTRUCCION Código Prueba DESPLIEGUE Entrega Soporte

19 Modelo Prescriptivo del Proceso de SoftwareMODELO CASCADA El Modelo de Cascada, sugiere un enfoque sistemático, secuencial hacia el desarrollo del software, que se inicia con la especificación de requisitos del cliente y que continua con la planeación, el modelado, la construcción y el despliegue para culminar con el soporte de software terminado. El Modelo Cascada es el mas antiguo parar al Ingeniería de Software. COMUNICACION PLANEACION MODELADO CONSTRUCCION DESPLIEGUE

20 2.3 Proceso MODELOS DE PROCESO INCREMENTALModelo Prescriptivo del Proceso de Software MODELOS DE PROCESO INCREMENTAL El Modelo Incremental combina elementos del modelo de cascada aplicado en forma iterativa. Aplica secuencias de líneas de manera escalonada conforme avanza el tiempo en el calendario . Cada secuencia produce “incrementos de software” . Modelo incremental se enfoca en la entrega de un producto operacional con cada incremento. Los primeros incrementos son versiones “incompletas” del producto final, pero proporcionan al usuario la funcionalidad que necesita y una plataforma para evaluar. El desarrollo incremental es útil sobre todo cuando el personal necesario para una implementación completa no esta disponible, por lo cual las primeros implementos se puede hacer con menos personas .

21 2.3 Proceso MODELOS DE PROCESO INCREMENTALModelo Prescriptivo del Proceso de Software MODELOS DE PROCESO INCREMENTAL COMUNICACION PLANEACION MODELADO CONSTRUCCION COMUNICACION DESPLIEGUE PLANEACION Funcionalidad y características del software MODELADO CONSTRUCCION COMUNICACION DESPLIEGUE PLANEACION MODELADO CONSTRUCCION DESPLIEGUE Tiempo del calendario del proyecto

22 Modelo Prescriptivo del Proceso de SoftwareMODELO DRA El Modelo DRA Modelo de Desarrollo Rápido de aplicaciones, es un modelo de proceso de software incremental que resulta un ciclo de desarrollo corto. Es una adaptación a “alta velocidad” del modelo en cascada. Cumple con las actividades: Comunicación, Plantación el Modelado incluye tres grandes fases: MODELADO DE NEGOCIOS, MODELADO DE DATOS, y MODELADO DE PROCESOS, la Construcción resulta reutilización de componentes, generación de código automático, y pruebas; Por ultimo el despliegue establece la base para las iteraciones subsecuentes. Si una aplicación de negocios se puede modular de forma que cada gran función pueda completarse en tres meses.

23 Modelo Prescriptivo del Proceso de SoftwareMODELO DRA

24 2.3 Proceso MODELOS DE PROCESOS EVOLUTIVOS CONSTRUCCION DE PROTOTIPOSSe utiliza cuando el cliente no identifica correctamente los requisitos de entrada, o el responsable del desarrollo del software esta inseguro de la eficacia de un algoritmo. comunicación PLAN RAPIDO Desarrollo entrega y retroalimentación Modelado del diseño rápido Construcción del prototipo

25 2.3 Proceso TRABAJO EN GRUPO PROCESOS UNIFICADOMODELOS AGILES DE PROCESO PROGRAMACION EXTREMA (PE) DESARROLLO ADAPTATIVO DE SOFTWARE (DAS) METODO DE DESARROLLO DE SISTEMAS DINÀMICOS (MDSD) DESARROLLO CONDUCIDO POR CARACTERISTUCAS (DCC) MODELO AGIL Presentar un informe y una breve explicación acerca del modelo

26 2.4 Proyecto Es la única manera de gestionar la complejidad que existe en la construcción de software. Se define riesgos en el proyecto de software: El personal de software no entiende las necesidades de sus clientes. 2. El ámbito del producto esta mal definido. 3. Los cambios se gestionan mal. 4. Los plazos de entrega no son realistas. 5. El equipo de proyecto carece de personal con las habilidades apropiadas. Para evitar el fracaso del proyecto, un gestor y los ingeriros de software que contribuyen al producto, deben desarrollar un enfoque común para PLANIFICAR, SUPERVISAR Y CONTRLAR EL PROYECTOS.

27 FIN

28 PLANIFICACION DE PROYECTOS DE SOFTWAREUNIDAD 2 PLANIFICACION DE PROYECTOS DE SOFTWARE Inegenieria de software II Ing. Karen Ruth Chura Gonzales

29 PLANIFICACION DE PROYECTOS DE SOFTWARELa gestión de un proyecto de software comienza con un conjunto de actividades que globalmente se denominan PLANIFICACIÓN DEL PROYECTO. Antes de que el proyecto comience, el gestor y el equipo de software deben realizar una ESTIMACIÓN del trabajo a realizar, de los recursos necesarios y del tiempo que transcurrirá desde el comienzo hasta el final de su realización. Siempre que ESTIMAMOS, estamos mirando hacia el futuro y aceptamos resignados cierto grado de incertidumbre.

30 PLANIFICACION DE PROYECTOS DE SOFTWARELa primera de estas actividades es la ESTIMACIÓN de costes y tiempos Como la estimación es la base de la planificación, hay que prestarle especial atención. La estimación la lleva a cabo el gestor del proyecto La estimación y planificación de un proyecto software requiere: Experiencia. Buena información histórica. Coraje de confiar en las métricas y la experiencia.

31 PLANIFICACION DE PROYECTOS DE SOFTWARE2.1. OBSERVACION SOBRE LA ESTIMACION Hay cuatro factores que influyen significativamente en las estimaciones: La complejidad del proyecto. El tamaño del proyecto. El grado de incertidumbre estructural. Disponibilidad de información histórica.

32 2.1.1. Complejidad del proyectoPLANIFICACION DE PROYECTOS DE SOFTWARE 2.1. OBSERVACION SOBRE LA ESTIMACION Complejidad del proyecto La complejidad es relativa a la experiencia en proyectos anteriores. Existen medidas sobre la complejidad de proyectos basadas en el diseño y código (métricas, técnicas). En la fase de estimación no son aplicables porque no hay ni diseño ni código. Por eso hay que utilizar medidas más subjetivas (e.j. PF)

33 PLANIFICACION DE PROYECTOS DE SOFTWARE2.1. OBSERVACION SOBRE LA ESTIMACION TAMAÑO DEL PROYECTO En los proyectos grandes, crece la interdependencia entre los componentes del proyecto. dificulta el proceso de estimación descomposición del producto en elementos Interdependencia

34 PLANIFICACION DE PROYECTOS DE SOFTWARE2.1. OBSERVACION SOBRE LA ESTIMACION GRADO DE INCERTIDUMBRE ESTRUCTURAL Estructura: Grado en que los requisitos se han definido. Facilidad con la que se pueden compartir funciones. Naturaleza jerárquica de la información a procesar. mejor descomposición del producto Incertidumbre estructural baja mejor estimación.

35 PLANIFICACION DE PROYECTOS DE SOFTWARE2.1. OBSERVACION SOBRE LA ESTIMACION 2.1.4 INFORMACIÓN HISTÓRICA “Aquellos que no pueden recordar el pasado, están condenados a repetirlo”. La existencia de métricas del software de proyectos anteriores facilita la estimación. TAMBIEN SE DEBE TOMAR EN CUENTA: En cualquier caso, la estabilidad de los requisitos por parte del cliente es fundamental para la estimación Si los requisitos cambian, la estimación no vale Por eso son buenos los modelos de proceso ágiles

36 ¿Qué es el peor caso en un proyecto real de ingeniería?PLANIFICACION DE PROYECTOS DE SOFTWARE 2.1. OBSERVACION SOBRE LA ESTIMACION 2.2.5 OBJETIVO DE LA ESTIMACION Definir los escenarios del mejor caso y del peor caso de forma que los resultados del PROYECTO DE SOFTWARE puedan limitarse ¿Qué es el peor caso en un proyecto real de ingeniería? Esto es difícil, puesto que realmente no lo sabrá hasta que el proyecto haya finalizado. Sin embargo, si tienen experiencia y sigue un enfoque sistemático, realiza estimaciones utilizando datos históricos sólidos, crea puntos de estimación mediante al menos dos métodos diferentes y descompone la complejidad y el riesgo, puede estar seguro de hacer acertado correctamente. Inegenieria de software II Ing. Karen Ruth Chura Gonzales

37 2.2.1 OBJETIVO DE LA PLANIFICACIONPLANIFICACION DE PROYECTOS DE SOFTWARE 2.2 PLANIFICACION DE PROYECTO 2.2.1 OBJETIVO DE LA PLANIFICACION El objetivo de la planificación del proyecto de software es proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos, coste y planificación temporal. Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de un proyecto de software, y deberían actualizarse regularmente a medida que progresa el proyecto. Inegenieria de software II Ing. Karen Ruth Chura Gonzales

38 2.2.2 AMBITO DE SOFTWARE PLANIFICACION DE PROYECTOS DE SOFTWAREEs la primera actividad de la planificación del proyecto de software, se debe delimitar su declaración. El ámbito del software describe: El control y los datos a procesar La función El rendimiento Las restricciones Las interfaces Inegenieria de software II Ing. Karen Ruth Chura Gonzales

39 2.2.2 AMBITO DE SOFTWARE PLANIFICACION DE PROYECTOS DE SOFTWAREEl cliente es el único que puede ayudarnos a determinar el ámbito Por tanto la comunicación con el cliente es fundamental La comunicación se puede iniciar con las preguntas de contexto libre Hay tres grupos dentro de estas preguntas El primer grupo se centra en el cliente, los objetivos globales y los beneficios: El segundo grupo permiten comprender mejor el problema y que el cliente exprese sus percepciones sobre una solución: El último grupo se centra en la efectividad de la reunión. Inegenieria de software II Ing. Karen Ruth Chura Gonzales

40 2.2.2 AMBITO DE SOFTWARE PLANIFICACION DE PROYECTOS DE SOFTWAREEl primer grupo se centra en el cliente, los objetivos globales y los beneficios: ¿Quién está detrás de la solicitud de este trabajo? ¿Quién está detrás de la solicitud de este trabajo? ¿Hay otro camino para la solución? ¿Quién utilizará esta solución? ¿Cuál será el beneficio económico de una buena solución? Inegenieria de software II Ing. Karen Ruth Chura Gonzales

41 2.2.2 AMBITO DE SOFTWARE PLANIFICACION DE PROYECTOS DE SOFTWAREEl segundo grupo permiten comprender mejor el problema y que el cliente exprese sus percepciones sobre una solución: ¿Cómo caracterizaría (el cliente) un resultado correcto que se generaría con una solución satisfactoria? ¿Con qué problemas se enfrentará esta solución? ¿Hay aspectos o limitaciones especiales de rendimiento que afecten a la forma en que se aborde la solución? ¿Puede mostrarme (describirme) el entorno en el que se utilizará la solución? Inegenieria de software II Ing. Karen Ruth Chura Gonzales

42 PLANIFICACION DE PROYECTOS DE SOFTWARE2.2.2 AMBITO DE SOFTWARE El último grupo se centra en la efectividad de la reunión. Se denominan metacuestiones: ¿Es usted la persona apropiada para responder a estas preguntas? ¿Son oficiales sus respuestas? Son relevantes mis preguntas para su problema ¿Estoy realizando muchas preguntas? ¿Hay alguien más que pueda proporcionar información adicional? ¿Hay algo más que debiera preguntarle? Estas preguntas y otras similares ayudan a romper el hielo y a iniciar la comunicación esencial para establecer el ámbito del proyecto Inegenieria de software II Ing. Karen Ruth Chura Gonzales

43 PLANIFICACION DE PROYECTOS DE SOFTWARE2.2.2 AMBITO DE SOFTWARE Sin embargo esto es el comienzo, y solo sirve para el primer encuentro Después deberían utilizarse técnicas de especificación más concretas. Por ejemplo disponemos de las TÉCNICAS ÚTILES PARA LA ESPECIFICACIÓN DE APLICACIONES (TUE). Las TUE presentan variaciones de la siguiente aproximación: Se realiza la reunión en un lugar a convenir por clientes y desarrolladores. Se propone una agenda lo suficientemente formal para cubrir todos los puntos importantes, pero lo suficientemente informal para permitir el flujo de ideas. Inegenieria de software II Ing. Karen Ruth Chura Gonzales

44 PLANIFICACION DE PROYECTOS DE SOFTWARE2.2.2 AMBITO DE SOFTWARE LA REUNION Un moderador (desarrollador o cliente) controla la reunión. Se establece un mecanismo de presentación (transparencias, pizarra, etc.). Los objetivos son: Identificar el problema. Proponer elementos de la solución. Negociar las distintas aproximaciones. Especificar un conjunto preliminar de requisitos. Inegenieria de software II Ing. Karen Ruth Chura Gonzales

45 PLANIFICACION DE PROYECTOS DE SOFTWARE2.2.2 AMBITO DE SOFTWARE Hay una preparación antes de la primera reunión TUE: Antes de la reunión se debe realizar una entrevista en la que se realizan preguntas de contexto libre para ayudar a establecer el ámbito. De esta reunión salen una o dos páginas de requisitos del producto. Se eligen lugar, fecha, participantes y moderador de la reunió Inegenieria de software II Ing. Karen Ruth Chura Gonzales

46 PLANIFICACION DE PROYECTOS DE SOFTWARE2.2.2 AMBITO DE SOFTWARE ANTES DE LA REUNIÓN LOS ASISTENTES DEBEN REDACTAR: - Una lista de objetos que son parte del entorno que rodea al sistema (e.j. archivos, dispositivos, etc.), que serán producidos por el sistema y que utiliza el sistema para llevar a cabo su funcionalidad. - Una lista de operaciones que manipulan o interactúan con los objetos. - Una lista de restricciones (e.j. coste, tamaño) y criterios de prestaciones (e.j. velocidad, precisión.). Inegenieria de software II Ing. Karen Ruth Chura Gonzales

47 PLANIFICACION DE PROYECTOS DE SOFTWARE2.2.2 AMBITO DE SOFTWARE DURANTE EL DESARROLLO DE LA REUNIÓN TUE: La primera cuestión que se debe tratar es la necesidad y razón del nuevo producto. Se presentan las listas utilizando el medio convenido de tal forma que se puedan modificar. No se permiten críticas ni debate. Después de que cada persona expone su lista sobre un tema determinado, se realiza una lista aditiva combinada para cada tema (objetos, operaciones y restricciones). Inegenieria de software II Ing. Karen Ruth Chura Gonzales

48 PLANIFICACION DE PROYECTOS DE SOFTWARE2.2.2 AMBITO DE SOFTWARE Una vez completadas las listas: para una o varias entradas de la lista Se forman subequipos que realizan una miniespecificación Aquí se añaden o eliminan ideas y se permite la discusión. Por lo general serán necesarias varias reuniones TUE Inegenieria de software II Ing. Karen Ruth Chura Gonzales

49 PLANIFICACION DE PROYECTOS DE SOFTWARE2.2.2 AMBITO DE SOFTWARE Además del ámbito el software interactúa con otros elementos Hardware. Por tanto el concepto de interfaz también es vital para la planificación temporal Procedimientos Software. De usuario. Inegenieria de software II Ing. Karen Ruth Chura Gonzales

50 PLANIFICACION DE PROYECTOS DE SOFTWARE2.2.2 AMBITO DE SOFTWARE OTRO ASPECTO IMPORTANTE DURANTE LA ESTIMACIÓN ES EL DE LA FIABILIDAD DEL SOFTWARE El gestor/planificador tendrá que aproximarla lo más posible mediante la declaración del ámbito Inegenieria de software II Ing. Karen Ruth Chura Gonzales

51 2.2.3 RECURSOS PLANIFICACION DE PROYECTOS DE SOFTWARELa segunda tarea de la planificación del desarrollo de software es la ESTIMACIÓN DE RECURSOS requeridos para acometer el esfuerzo de desarrollo Estos recursos pueden considerarse una pirámide: Personas. Componentes software reutilizables. Herramientas de hardware/software. Inegenieria de software II Ing. Karen Ruth Chura Gonzales

52 PLANIFICACION DE PROYECTOS DE SOFTWARE2.2.3 RECURSOS 52 Inegenieria de software II Ing. Karen Ruth Chura Gonzales

53 PLANIFICACION DE PROYECTOS DE SOFTWARE2.2.3 RECURSOS Cada recurso queda especificado mediante cuatro características: Descripción del recurso. Informe de disponibilidad. Fecha cronológica en la que se requiere el recurso. Tiempo durante el que será aplicado el recurso . Inegenieria de software II Ing. Karen Ruth Chura Gonzales

54 2.2.3 RECURSOS PLANIFICACION DE PROYECTOS DE SOFTWARERESPECTO AL PERSONAL HAY QUE ESPECIFICAR SU POSICIÓN EN LA ORGANIZACIÓN Y SU ESPECIALIDAD El número de personas requerido debe estimarse Inegenieria de software II Ing. Karen Ruth Chura Gonzales

55 Con experiencia parcialPLANIFICACION DE PROYECTOS DE SOFTWARE 2.2 PLANIFICACION DE PROYECTO 2.2.3 RECURSOS GRAN PARTE DE LA REUTILIZACIÓN DEL SOFTWARE SE DEBE A LA TECNOLOGÍA DE COMPONENTES Ya desarrollados. Ya experimentados Con experiencia parcial Nuevos Respecto a la planificación, tenemos cuatro tipos de componentes: Inegenieria de software II Ing. Karen Ruth Chura Gonzales

56 PLANIFICACION DE PROYECTOS DE SOFTWARE2.2.3 RECURSOS Componentes ya desarrollados Componente adquirido o existente. Validados. Listos para utilizarse Inegenieria de software II Ing. Karen Ruth Chura Gonzales

57 PLANIFICACION DE PROYECTOS DE SOFTWARE2.2.3 RECURSOS Componentes ya experimentado Especificaciones, diseños, códigos o datos de prueba ya existentes desarrollados anteriormente y similares a los requeridos. Miembros del equipo con experiencia completa en el dominio de aplicación de los componentes. Riesgo bajo ante las modificaciones. Inegenieria de software II Ing. Karen Ruth Chura Gonzales

58 PLANIFICACION DE PROYECTOS DE SOFTWARE2.2.3 RECURSOS Componentes con experiencia parcial Especificaciones, diseños, códigos o datos de prueba ya existentes desarrollados anteriormente y relacionados con los requeridos. Experiencia limitada del equipo en el dominio de aplicación de los componentes. Requieren una modificación sustancial. Alto riesgo ante las modificaciones. Inegenieria de software II Ing. Karen Ruth Chura Gonzales

59 Componentes a construir.PLANIFICACION DE PROYECTOS DE SOFTWARE 2.2 PLANIFICACION DE PROYECTO 2.2.3 RECURSOS Componentes nuevos Componentes a construir. También hay que planificar el acceso a hardware o recursos específicos (e.J. la barrera) En cuanto a los recursos de entorno debemos constatar que no hay problemas con el software de desarrollo (E.J. número de licencias) Directrices para la elección de componentes: 1. Adquirir componentes ya desarrollados. 2. Modificar componentes ya experimentados. 3. No aceptar componentes con experiencia parcial Inegenieria de software II Ing. Karen Ruth Chura Gonzales

60 PLANIFICACION DE PROYECTOS DE SOFTWARE2.3 TECNICAS DE ESTIMACION Estimar el coste del software es vital Las estimaciones nunca podrán ser exactas Cuanto mejor estimemos, más rentable será nuestro proyecto Basar las estimaciones en proyectos similares que ya hayan sido completados. Emplear técnicas de descomposición relativamente simples para generar estimaciones de costo y esfuerzo de proyecto. Estimar es difícil, ya que: Los requisitos iniciales no están totalmente delimitados. Puede que necesitemos utilizar tecnologías nuevas. Inegenieria de software II Ing. Karen Ruth Chura Gonzales

61 PLANIFICACION DE PROYECTOS DE SOFTWARE2.4 TECNICAS DE DESCOMPOSICION Tamaño de Software La precisión de la estimación de un Proyecto de Software se manifiesta en varios factores: El grado con el cual el planificador ha estimado adecuadamente el tamaño del producto que se CONSTRUIRA. La habilidad para traducir la estimación del tamaño en esfuerzo humano, programa de trabajo y dinero El grado en el cual el Plan de Proyecto refleja las habilidades del equipo de software La estabilidad de los requisitos del producto y el entorno que soporta el esfuerzo de Ingeniería de Software Inegenieria de software II Ing. Karen Ruth Chura Gonzales

62 Se refiere a un resultado cuantificablePLANIFICACION DE PROYECTOS DE SOFTWARE 2.4 TECNICAS DE DESCOMPOSICION Tamaño de Software Se refiere a un resultado cuantificable PROYECTO DE SOFTWARE El TAMAÑO DE SOFTWARE Desafió del Planificador Líneas de Código LDC Puntos de Función PF Inegenieria de software II Ing. Karen Ruth Chura Gonzales

63 PLANIFICACION DE PROYECTOS DE SOFTWARE2.4 TECNICAS DE DESCOMPOSICION Tamaño de Software Se sugieren cuatro diferentes enfoques al problema del tamaño Tamaño en lógica difusa Tamaño de punto de función Tamaño de componentes estándar Tamaño del cambio Inegenieria de software II Ing. Karen Ruth Chura Gonzales

64 PLANIFICACION DE PROYECTOS DE SOFTWARE2.4 TECNICAS DE DESCOMPOSICION Tamaño de Software Tamaño en lógica difusa: Este enfoque usa técnicas aproximadas de razonamientos, establece su magnitud en una escala CUALITATIVA y luego refine la magnitud dentro del rango original. Tamaño de componentes estándar: El planificador de proyectos desarrolla estimaciones de características del dominio de información (PF) Inegenieria de software II Ing. Karen Ruth Chura Gonzales

65 PLANIFICACION DE PROYECTOS DE SOFTWARE2.4 TECNICAS DE DESCOMPOSICION Tamaño de Software Tamaño de componentes estándar: El software se compone de un número de “componentes estándar” que son genéricos para un área en particular para un sistema de información son: subsistemas, módulos, pantallas, informes, programas interactivos. El planificador de proyectos estima el número de incidencias de cada uno de los componentes estándar y utiliza datos de proyectos históricos para determinar el tamaño de entrega por componente estándar. Tamaño del cambio: El enfoque se utiliza cuando un proyecto comprende la utilización de software existente que se debe modificar de alguna manera como de un proyecto como parte de un proyecto. El planificador estima el número y tipo de modificaciones que se deben llevar a cabo. Inegenieria de software II Ing. Karen Ruth Chura Gonzales

66 ≠ PLANIFICACION DE PROYECTOS DE SOFTWARE2.4 TECNICAS DE DESCOMPOSICION Estimación basada en el problema El planificador del PROYECTO DE SOFTWARE comienza estimando una gama de valores para cada función o valor de dominio de información. Al emplear datos históricos o intuición, el planificador estima un valor de tamaño optimista, más probable y pesimista para cada función. ≠ Líneas de Código LDC Puntos de Función PF Inegenieria de software II Ing. Karen Ruth Chura Gonzales

67 PLANIFICACION DE PROYECTOS DE SOFTWARE2.4 TECNICAS DE DESCOMPOSICION Estimación basada en el problema Al emplear LDC como variable de estimación de descomposición es absolutamente esencial y con frecuencia se lleva a grados considerables de detalle: Mientras mayor sea el grado de partición es más probable que se desarrolle una estimación razonablemente precisa. En las estimaciones de PF la descomposición funciona de manera diferente. Mas que enfocarse sobre la función, se estima cada uno de las cinco características: Número de entradas externas (EE) Número de Salidas externas (SE) Número de consultas externas (CE) Número de archivos lógicos internos (ALI) Número de archivos de interfaz externos (AIE) Inegenieria de software II Ing. Karen Ruth Chura Gonzales

68 PLANIFICACION DE PROYECTOS DE SOFTWARE2.4 TECNICAS DE DESCOMPOSICION Estimación basada en el problema Cuando se especifica un rango de valores se proporciona un indicio implícito del grado de incertidumbre. Entonces se puede calcular un valor de tres puntos o uno esperado. El valor esperado para la variable de estimación (tamaño ) S, se calcula como un promedio ponderado de las estimaciones optimistas (Sopt), más probable (Sm) y pesimista (Spes). S=(Sopt + 4Sm + Spes)/6 Cualquier técnica de estimación, no importa cuán sofisticada sea, debe contrastarse con otra. Incluso debe prevalecer el sentido común y la experiencia Inegenieria de software II Ing. Karen Ruth Chura Gonzales

69 PLANIFICACION DE PROYECTOS DE SOFTWARE2.4 TECNICAS DE DESCOMPOSICION Estimación basada en el problema Ejemplo de estimación basada en LDC Considérese un paquete de software que será entregado para una aplicación de diseño asistido por computadora destinado a componentes mecánicos. El Software se ejecutara en una estación de trabajo de ingeniería y debe tener interfaz con varios periféricos que incluyen ratón, digitalizador, monitor de color de alta resolución e impresión láser. Inegenieria de software II Ing. Karen Ruth Chura Gonzales

70 PLANIFICACION DE PROYECTOS DE SOFTWARE2.4 TECNICAS DE DESCOMPOSICION Estimación basada en el problema Ejemplo de estimación basada en LDC 1. Determinar el Ámbito del Software El software mecánico aceptara del Ingeniero datos geométricos de dos y tres dimensiones. El Ingeniero interactuará y controlará el sistema a través de una interfaz del usuario que exhibirá características de buen diseño de interfaz humano-maquina. Todos los datos geométricos y otra información de soporte se conservaran en una base de datos. Se desarrollaran módulos de análisis de diseño para producir la salida requerida, la cual se desplegará en una diversidad de dispositivos periféricos que incluyen ratón, digitalizador, impresora la ser y ploter. Inegenieria de software II Ing. Karen Ruth Chura Gonzales

71 Ejemplo de estimación basada en LDCPLANIFICACION DE PROYECTOS DE SOFTWARE 2.4 TECNICAS DE DESCOMPOSICION Estimación basada en el problema Ejemplo de estimación basada en LDC 2. Identificación de las funciones de software: FUNCION Sopt SM Spes Facilidades de Interfaz del usuario y control Análisis geométrico bidimensional Análisis geométrico tridimensional 4.600 6.900 8.600 Facilidades de presentación gráfica de computadora Módulos de análisis de diseño Total Por experiencia propia o reseña histórica Inegenieria de software II Ing. Karen Ruth Chura Gonzales

72 Ejemplo de estimación basada en LDCPLANIFICACION DE PROYECTOS DE SOFTWARE 2.4 TECNICAS DE DESCOMPOSICION Estimación basada en el problema Ejemplo de estimación basada en LDC 3. Aplicar la formula respectiva para hallar el valor esperado para la variable de estimación (tamaño ) S. S=(Sopt + 4Sm + Spes)/6 Para cada una de las funciones Inegenieria de software II Ing. Karen Ruth Chura Gonzales

73 Ejemplo de estimación basada en LDCPLANIFICACION DE PROYECTOS DE SOFTWARE 2.4 TECNICAS DE DESCOMPOSICION Estimación basada en el problema Ejemplo de estimación basada en LDC 4. Construir la TABLA DE ESTIMACIONES PARA METODOS LDC FUNCION LDC Estimado Facilidades de Interfaz del usuario y control Análisis geométrico bidimensional Análisis geométrico tridimensional 6.800 Facilidades de presentación gráfica de computadora Módulos de análisis de diseño LINEAS DE CÓDIGO ESTIMADOS Inegenieria de software II Ing. Karen Ruth Chura Gonzales

74 Ejemplo de estimación basada en LDCPLANIFICACION DE PROYECTOS DE SOFTWARE 2.4 TECNICAS DE DESCOMPOSICION Estimación basada en el problema Ejemplo de estimación basada en LDC 5.Realizar una revisión de los DATOS HISTORICOS que indiquen el promedio del nivel de productividad para sistemas similares. 620 LDC/pm Tarifa laboral de Bs. Por mes incluye impuestos de Ley Costo Total de Proyecto Bs. X= ( * 1)/7.500 X = 7 personas 7.500/620 = 12 Bs Costo de cada línea de código Esfuerzo estimado Inegenieria de software II Ing. Karen Ruth Chura Gonzales

75 Ejemplo de estimación basada en LDCPLANIFICACION DE PROYECTOS DE SOFTWARE 2.4 TECNICAS DE DESCOMPOSICION Estimación basada en el problema Ejemplo de estimación basada en LDC 6. Realizar la ESTIMACION DEL PROYECTO Por lo que cada línea de código costo 7.500/620 = 12 Bs EL ESFUERZO ESTIMADO ES: X= (LDCE* 1 persona) / (LDC/pm) X= ( * 1)/620 X=(5500 personas Esfuerzo estimado COSTO TOTAL DEL PROYECTO X= (# personas * Monto a cancelar) X=(5500 personas COSTO DEL PS Inegenieria de software II Ing. Karen Ruth Chura Gonzales

76 Ejemplo de estimación basada en LDCPLANIFICACION DE PROYECTOS DE SOFTWARE 2.4 TECNICAS DE DESCOMPOSICION Estimación basada en el problema Ejemplo de estimación basada en LDC Considere la situación de una Empresa denominada “MUNDO FELIZ”, con sucursales en La Paz, Cochabamba y Santa Cruz cuenta en cada sucursal con 35,50,40 empleados respectivamente. La empresa requiere los servicios de consultaría en Software para el inicio de un proyecto que le permita contar con un sistema integrado que permita el control de del inventario existente de los productos que ofrece, el control de asistencia y sanciones al personal, además como se cuentan con lectores en código de barra se desea que las ventas se controlen usando el mismo así como su registro en inventarios, se desea llevar u registro de toda la clientela de modo que si se tiene alguna promoción éstos resulten primeramente beneficiados, Se desean registrar los activos fijos que tiene la empresa en cada sucursal, también hacer un seguimiento del record de trabajo de cada persona de modo que se las pueda categorizar para el pago de su salario, también en cuanto a ventas se desea realizar un seguimiento de los pedidos y compras realizados a los proveedores, así como las ventas al por mayor bajo convenio con instituciones. Inegenieria de software II Ing. Karen Ruth Chura Gonzales

77 Ejemplo de estimación basada en LDCPLANIFICACION DE PROYECTOS DE SOFTWARE 2.4 TECNICAS DE DESCOMPOSICION Estimación basada en el problema Ejemplo de estimación basada en LDC Considere la siguientes funciones: Control de inventario (Productos Stock, activos fijos) Control de Personal Elaboración de planillas de sueldos Transacciones de productos (Compras , Ventas, Promociones) Según la experiencia obtenida se sabe que se puede realizar 1500 LDC/pm Tarifa laboral de $ por mes Coste total del proyecto $ Tipo de cambio 8.07 Bs REALIZAR EL TRABAJO EN AULA Inegenieria de software II Ing. Karen Ruth Chura Gonzales

78 VALORES DE DOMINIO DE INFORMACIONPLANIFICACION DE PROYECTOS DE SOFTWARE 2.4 TECNICAS DE DESCOMPOSICION Estimación basada en el problema Ejemplo de estimación basada en FD La descomposición de la estimación basada en PF se centra en los valores de dominio de información más que en las funciones de software PF = CONTEO TOTAL * [0,65+ (0,01 * ∑Fi)] VALORES DE DOMINIO DE INFORMACION Número de entradas externas (EE) Número de Salidas externas (SE) Número de consultas externas (CE) Número de archivos lógicos internos (ALI) Número de archivos de interfaz externos (AIE) Inegenieria de software II Ing. Karen Ruth Chura Gonzales

79 Ejemplo de estimación basada en FD FACTORES DE COMPLEJIDADPLANIFICACION DE PROYECTOS DE SOFTWARE 2.4 TECNICAS DE DESCOMPOSICION Estimación basada en el problema Ejemplo de estimación basada en FD FACTORES DE COMPLEJIDAD Respaldo y recuperación Comunicación de datos. Procesamiento distribuido Desempeño crítico Entorno operativo existente Entrada de datos en Línea Transacción de entrada sobre pantallas múltiples ILF actualizado en línea Complejo de valores de dominio de información Complejo de procesamiento interno Código diseñado para reutilización Conservación/instalación en diseño Instalaciones múltiples Aplicación diseñada para cambio Inegenieria de software II Ing. Karen Ruth Chura Gonzales

80 Ejemplo de estimación basada en FDPLANIFICACION DE PROYECTOS DE SOFTWARE 2.4 TECNICAS DE DESCOMPOSICION Estimación basada en el problema Ejemplo de estimación basada en FD 1. Determinar Mediante un Modelo Casos de Uso, Modelo Diagrama de Flujo de Datos o Análisis del Proyecto de Software Número de entradas externas (EE) Número de Salidas externas (SE) Número de consultas externas (CE) Número de archivos lógicos internos (ALI) Número de archivos de interfaz externos (AIE) Inegenieria de software II Ing. Karen Ruth Chura Gonzales

81 Ejemplo de estimación basada en FDPLANIFICACION DE PROYECTOS DE SOFTWARE 2.4 TECNICAS DE DESCOMPOSICION Estimación basada en el problema Ejemplo de estimación basada en FD 2. Realizar el conteo y operaciones VALOR DEL DOMINIO DE INFORMACIÓN CONTEO FACTOR DE PONDERACION CONTEO PF SIMPLE PROMEDIO COMPLEJO Número de entradas externas (EE) 3 4 6 Número de Salidas externas (SE) 2 5 7 Número de consultas externas (CE) Número de archivos lógicos internos (ALI) 1 10 15 Número de archivos de interfaz externos (AIE) CONTEO TOTAL Conteo * factor de ponderación Inegenieria de software II Ing. Karen Ruth Chura Gonzales

82 Ejemplo de estimación basada en FDPLANIFICACION DE PROYECTOS DE SOFTWARE 2.4 TECNICAS DE DESCOMPOSICION Estimación basada en el problema Ejemplo de estimación basada en FD FACTORES VALOR Respaldo y recuperación Comunicación de datos. Procesamiento distribuido Desempeño crítico Entorno operativo existente Entrada de datos en Línea Transacción de entrada sobre pantallas múltiples ILF actualizado en línea Complejo de valores de dominio de información Complejo de procesamiento interno Código diseñado para reutilización Conservación/instalación en diseño Instalaciones múltiples Aplicación diseñada para cambio 4 2 3 5 FACTOR DE AJUSTE DE VALOR 52 3. Estimar cada uno de los factores ponderados de complejidad con la escala de 0-5. Donde 0 No importante o aplicable – 5 absolutamente esencial Inegenieria de software II Ing. Karen Ruth Chura Gonzales

83 PLANIFICACION DE PROYECTOS DE SOFTWARE 2.4 TECNICAS DE DESCOMPOSICIONEstimación basada en el problema Ejemplo de estimación basada en FD 4. Reemplazar valor en la formula PF = CONTEO TOTAL * [0,65+ (0,01 * ∑Fi)] PF = 50 * [0,65+ (0,01 * 52)] PF= 58.5 Inegenieria de software II Ing. Karen Ruth Chura Gonzales

84 Ejemplo de estimación basada en FDPLANIFICACION DE PROYECTOS DE SOFTWARE 2.4 TECNICAS DE DESCOMPOSICION Estimación basada en el problema Ejemplo de estimación basada en FD 5. Revisar datos históricos 6. Realizar la estimación del Proyecto de Software Inegenieria de software II Ing. Karen Ruth Chura Gonzales

85 F I N