Ingeniería de Software

Presentación del tema: "Ingeniería de Software"— Transcripción de la presentación:

1 Ingeniería de Software
Administración de proyectos

2 Composición de un Proyecto
¿Qué es un proyecto? Es un esfuerzo temporal emprendido para crear un producto o servicio único para lograr un objetivo Tiene un objetivo o beneficio a obtener que guía el proyecto Temporal: porque tiene principio y fin Único: No es recurrente, cada proyecto es diferente al otro Posee Recursos limitados Consta de una sucesión de actividades o fases en las que se coordinan los distintos recursos

3 Planificación ¿Por qué es importante planificar los proyectos?
Un estudio hecho por KPMG sobre 252 empresas revela que las causas más comunes son: Fallas en PM, planeamiento y control 32% Fallas en Comunicación 20% Fallas en la definición de objetivos y alcance 17% Insuficiente conocimiento sobre el negocio 17% Otras causas menos relevantes son: Hardware/Software 7% Tamaño del proyecto 2% Otros 5%

4 Project Management ¿Qué es hacer “Project Management”?
La administración de proyectos es una disciplina que consiste en planificar, organizar, obtener y controlar recursos, utilizando recursos herramientas y técnicas para logar que el proyecto logre sus objetivos en tiempo y forma. Existe hace cientos de años, pero formalmente arranca en 1920 con Taylor, donde Gantt y Fayol (discípulos) hacen sus aportes teóricos. En 1969, se forma el PMI (Project Management Institute) publicando el PMBOK (PM Body Of Knowledge) donde aparecen las áreas que comprende la administración de proyectos, comunes a la mayoría de los proyectos.

5 Dimensiones Al ser limitados en recursos, la relación entre los elementos que impulsan al proyecto pueden verse de la siguiente forma: Enfoque 5 Dimensiones Alcance (Funcionalidad) Calidad Recursos Costo Tiempo (Plazo) Enfoque 3 Dimensiones (Triple Constraint) Alcance Tiempo No se puede cumplir con todas a la vez !!

6 Plan de proyecto Objetivos (de negocio / de proyecto) Alcance
Riesgos del proyecto (prox. Clase) Calendario WBS Gantt Recursos asignados a las tareas Estimaciones Técnicas, supuestos,historia Resultados de la estimación Recursos Estructura y roles Procedimientos de tracking y control

7 Objetivos y alcance Objetivo
Describe los resultados de negocio esperados a los cuales contribuye la concreción del proyecto El éxito del proyecto deberá medirse en el grado de cumplimiento de dichos objetivos Los objetivos deben ser precisos (de lo contrario no se podrá corroborar si se alcanzaron) Recordar no confundir la solución con el objetivo del proyecto La solución es el curso de acción para alcanzar el objetivo El objetivo no es la forma en que vamos a hacer algo sino el resultado que esperamos Alcance Define los límites del sistema Lo que incluye Si es necesario se aclaran especialmente que “no” incluye (con el objetivo de despejar dudas)

8 Calendario Armado del plan ¿Qué debemos hacer?
Descomponer el proyecto que estamos planificando en: Fases / Etapas Tareas / Subtareas / Actividades Determinar las relaciones de precedencia en la descomposición anterior Asignar los recursos del proyecto a las tareas Revisar el plan resultante con el objetivo de asegurar el cumplimiento de los plazos esperados y resolver conflictos de asignaciones de recursos a las tareas

9 WBS ¿ Qué es una WBS ? Método para representar en forma jerárquica los componentes de un proceso (en nuestro caso el plan de proyecto) o un producto La WBS no determina dependencias, solo jerarquía La WBS tiene que tener todas las tareas o entregables para cumplir con el alcance. ¿ Cómo se define una WBS ? Definir el nodo raíz de la jerarquía (Por lo general es el nombre del proyecto) Dividirlo en los componentes principales que lo conforman Continuar con la apertura de los componentes principales en otras sub- partes Finalizar el proceso de división cuando se llegue a un nivel donde se pueda trabajar con el nivel de granularidad alcanzado En nuestro caso, hasta que podamos para cada tarea estimar su esfuerzo, su duración y asignarle recursos

10 Tipos de WBS WBS por Proceso WBS por Producto (por funciones)
Análisis Desarrollo Construcción Testing Implementación WBS por Producto (por funciones) WBS Híbridas (ciclo de vida en el alto nivel con detalle de características de productos en el bajo nivel)

11 Dependencias En el siguiente paso debemos definir las dependencias de todas las tareas No olvidarse las dependencias con terceras partes (otros proyectos relacionados) Asegurar que cada tarea tenga un entregable preciso (que permita definir cuando la tarea finalizó) y a su vez los que se necesitan para otras tareas sucesoras Incluir milestones (hitos / puntos de revisión) Todo proyecto debe tener puntos de revisión periódicos Identificar el camino crítico Secuencia de tareas cuyo atraso provoca atrasos en la fecha de fin del proyecto Cuidado con las tareas no críticas que tienen un límite a partir del cual se transforman en críticas

12 Asignación de recursos
Debemos conocer los recursos con los que podemos contar y cuál es su disponibilidad real para asignarlos al proyecto Acordar disponibilidad y confirmar asignación Resolver conflictos de sobreasignación que puedan surgir Por lo general cuando se hace la descomposición y se define las dependencias, la duración de las tareas se realiza teniendo en cuenta la dedicación completa de los recursos y en la práctica no es real !! Podemos resolverlo (siempre que la tarea lo permita): Alargando la duración de la tarea Asignando recursos para su ejecución Alterando el orden de la misma No olvidar la asignación de los roles cubiertos por el usuario El usuario “campeón” suele ser un recurso con alta demanda en su “día a día” y puede comprometer su participación en el proyecto Recomendación: evitar caer en la “dedicación completa” No hay recurso que esté disponible el 100% del tiempo para un proyecto Tener en cuenta vacaciones, enfermedades, emergencias de otros proyectos, training, etc...

13 Asignación de recursos
Conformación del equipo de trabajo: A la hora de construir un equipo tener en cuenta: La complementación técnica y social de los participantes La cantidad de gente (cuidado con los canales de comunicación en grupos grandes) La posibilidad de crecimiento futuro del equipo El skill de las personas (fortalezas y debilidades) Todos los recursos tienen que tener un backup asignado Debidamente asignado y notificado Especial cuidado con los que están asignados a las tareas críticas! Un buen equipo ... Comparte el objetivo y se compromete Tiene una identidad propia Compromiso con el equipo Confianza mutua Comunicación efectiva Tiene un sentido de autonomía Tiene un sentido de empowerment

14 Estimaciones Por qué fallan las estimaciones? Optimismo
Estimaciones informales ( estomacales ) No hay historia Mala definición del alcance Novedad / Falta de Experiencia Complejidad del problema a resolver No se estima el tamaño Porque la estimación fue buena pero cuando empieza el proyecto: Mala administración de los requerimientos No hay seguimiento y control Se confunde progreso con esfuerzo

15 Estimaciones Variables a estimar
Tamaño Esfuerzo Costo La estimación del desarrollo de SW vs la estimación de todo el proyecto La estimación del desarrollo de SW es un componente de la estimación del proyecto. “Nivel de incertidumbre” El “cono de la incertidumbre” define niveles estadísticos predecibles de la incertidumbre de las estimaciones en cada etapa del proyecto Cuanto más refinada la definición, mas exacta será la estimación

16 Consideraciones importantes
Diferenciar entre estimaciones, objetivos y compromisos Asociar a las estimaciones un % de confiabilidad Es recomendable presentar las estimaciones como rangos en lugar de un único valor Siempre presentar junto con la estimación, los supuestos que se tuvieron en cuenta para llegar a la misma Tener presente la Ley de Parkinson: “Toda tarea se expande hasta ocupar el tiempo que tiene asignado” Considerar todas las actividades relacionadas al desarrollo de sw, no solamente codificación y testing (Análisis, diseño, actividades de SCM, etc.) No asumir que solo por el paso del tiempo y de las fases de un proyecto se avanza con menor incertidumbre en las estimaciones (Cono de la incertidumbre) Recolectar datos históricos para tener como referencia Considerar que puede haber enfoques para estimar “Top Down” y “Bottom-Up”

17 Ciclo dorado de la estimación
Estimar: Comenzar x estimar el tamaño para derivar el esfuerzo y el costo Medir: Mientras evoluciona el proyecto, medir el tamaño, el esfuerzo y costo incurrido Registrar: Dejar claras las mediciones tomadas Comparar: Estimaciones vs. Mediciones Analizar: Razones de desvíos supuestos que quizás variaron, temas no contemplados, etc... Calibrar: Ajustar c/u de las variables y parámetros que intervienen en el proceso de estimación Volver a estimar el mismo proyecto pero ahora con mas información que al comienzo del mismo Nuevos proyectos con el proceso ajustado por la “calibración”

18 Métodos para estimar Métodos subjetivos • Métodos mássofisticados
Juicio Experto Pert (también conocido como Clark) Planning Poker Wideband Delphi • Métodos mássofisticados Earned Value Function Points Use case points Object Points

19 Estimaciones - Recomendaciones
¿ Qué hacer ? Juntar historia de todos los proyectos Registrar todas las lecciones aprendidas Tener en cuanta la importancia de la comunicación Desarrollar un método de estimación adecuado a la instalación Basarse en los conocidos y crear el propio Lo importante es su eficacia Apoyarnos en herramientas Permiten ayudarnos en la implementación del ciclo dorado ¿ Qué “no” hacer ? Descartar los métodos Rechazarlos porque los consideramos inaplicables Utilizar métodos elaborados sin experiencia o información suficiente Los métodos elaborados requieren de habilidades que hay que desarrollar Ignorar los supuestos Siempre deben estar claro al comienzo dejando claro el nivel de certidumbre de la estimación

20 Juicio Experto & PERT/Clark
Depende de la persona que haga la estimación Se basa en la experiencia personal Por lo general se recurre a analogías Método Pert (Program Evaluation and Review Technique) Se basa en el juicio experto Incluye los factores optimistas y pesimistas en su estimación Estimación = (Optimista + 4 x Medio + Pesimista) / 6 Se puede usar para estimar tamaño y esfuerzo También se conoce como el método Clark

21 Planning Poker Da lugar a la participación de todos los involucrados
Ventajas Fácil de implementar y da sentido de propiedad sobre la estimación

22 Wideband Delphi Es el juicio experto en grupos
Da lugar a la participación de todos los involucrados Ventajas Fácil de implementar y da sentido de propiedad sobre la estimación Se puede utilizar en etapas tempranas del proyecto Se recomienda utilizarlo en proyectos poco conocidos en donde no se cuenta con historia

23 Earned Value Es una herramienta que permite controlar el costo durante todo el proceso No se encarga de realizar la estimación inicial de las tareas, sino en actualizar la estimación total del proyecto teniendo en cuenta los retrasos No se suele utilizar en metodologías ágiles Es caro de implementar pero en proyectos que requieren control exhaustivo de los gastos y en metodologías mas duras donde las estimaciones se hacen al inicio puede servir

24 Function points Miden el tamaño del SW en base a la funcionalidad capturada en los requerimientos Usa el modelo lógico o conceptual para trabajar En general son aceptados en la industria a pesar de su complejidad y antigüedad Hay muchas heurísticas en el mercado basadas en PFs Los PFs son independientes de la tecnología Requieren un análisis de requerimientos avanzado

25 Function points - Elementos
Archivos lógicos internos (ALI o ILF) Grupo de datos lógicos de información o de control, identificables por el usuario, mantenidos a través de procesos elementales de la aplicación dentro de los límites de la misma. Archivo de interface externa (AIE o EIF) Grupo de datos lógicos de información o de control, identificables por el usuario, referenciados por la aplicación pero mantenidos a través de procesos elementales de una aplicación diferente. Los EIF no son mantenidos por la aplicación. Entradas externas (EE o EI) Proceso elemental de la aplicación que procesa datos o información de control que entran desde el exterior del sistema. Los datos procesados mantienen uno o más ILFs.La información de control puede o no ser mantenida en un ILF. Salidas externas (SE o EO) Es un proceso elemental de la aplicación que envía datos o información de control fuera de los límites del sistema. Puede hacer update de un ILF. Dicho procesamiento de información debe contener al menos una fórmula matemática o cálculo, o crear datos derivados. Una EO puede también mantener uno o más ILFs y/o alterar el comportamiento del sistema. Consultas Externas (CE o EQ) Es un proceso elemental de la aplicación que envía datos o información de control fuera de los límites del sistema. El proceso elemental NO posee fórmulas matemáticas ni cálculos. Y no crea datos derivados.Una EQ no mantiene ILFs durante su procesamiento, ni altera el comportamiento del sistema.

26 Function points – Sin ajuste

27 Function points – Factores de Influencia
Technical Complexity Factor TCF = ( sum de factores ) / 100 Hay 14 factores de complejidad técnica. Cada uno se evalua de acuerdo al grado deinfluencia (0-5). Data communications Performance Heavily used configuration Transaction rate Online data entry End user efficiency Online update Complex processing Reusability Installation ease Operations ease Multiple sites Facilitate change Distributed functions El TCF también se conoce como el CGS, Características Generales del Sistema

28 Function points – Ajustando
Cálculo de puntos de función Puntos de función netos  PFN = UFP * TCF Conversión de FP a LOC (Lines of Code) En base a estandares del Mercado 1 FP equivale a:

29 Use case points - Características
El número de Use Case Points depende de : Cantidad y complejidad de los casos de uso Cantidad y complejidad de los actores intervinientes en el sistema Factores técnicos y ambientales El método requiere que sea posible contar el número de transacciones en cada caso de uso. Una transacción es un evento que ocurre entre el actor y el sistema. Basado en el método de Function Points Elementos del sistema Casos de Uso Transacciones de Casos de Uso Actores

30 Use case points – Clasif. actores
Actores Simples Son sistemas externos, son muy predecibles, todo sistema con interfaz de aplicación bien definida. Actores Promedio Dispositivos de Hardware. Requieren más esfuerzo controlarlos, son más propensos a errores. Personas interactuando a través de una interfaz basada en texto Actores Complejos: Son humanos, son impredecibles y difíciles de controlar. Personas que interactúan a través de una GUI Se cuenta el número de actores en cada categoría, multiplicando ese número por el correspondiente peso y se obtiene el UAW (Unadjusted Actor Weigth). Tipo de actor Peso Simple 1 Medio 2 Complejo 3

31 Use case points – Clasif. Casos de uso
Los casos de uso también se clasifican en Simple, Medio y Complejo Simple: 3 o menos transacciones. Medio: 4 a 7 transacciones Complejo: Más de 7 transacciones Se cuenta el número de casos de uso en cada categoría, multiplicando ese número por el correspondiente peso y se obtiene el UUCW (Unadjusted Use Case Weigth). El UAW + UUCW = UUPC El unadjusted use case points Tipo de caso de uso Peso Simple 5 Medio 10 Complejo 15

32 Use case points – Clasif. Casos de uso
Se trata de asignar un peso a los factores técnicos o del entorno que pueden influir en el costo de desarrollar el software A cada factor se le asigna un valor entre 0 y 5 dependiendo de la influencia que tiene

33 Use case points – Terminando
El TechnicalComplexity Factor (TCF) es calculado en base a multiplicar cada factor de la tabla anterior por su peso y luego sumar todos estos valores para obtener el llamado TFactor. Finalmente se aplica la siguiente fórmula: TCF = (.01*TFactor) El Environmental Factor (EF) es calculado en base a multiplicar cada factor de la tabla 2 por su peso y luego sumar todos estos valores para obtener el llamado Efactor. Finalmente se aplica la siguiente fórmula: EF = 1.4+(-0.03*EFactor) El adjusted use case points (UCP) se calcula por la siguiente formula: UCP = UUCP*TCF*EF Karner propone un valor de 20 horas /hombre por UCP para cada proyecto UCP * 20 HH = Costo en HH del proyecto Enfoque de Kirstein Rubi (2001): 15 a 30 hs x UCP

34 Object points Basado en Function points
Object points no está relacionado necesariamente con programación orientada a objetos. Se asigna a cada componente un peso, de acuerdo a la clasificación peso por su complejidad. Considera como factor de ajuste el porcentaje de reutilización de código. Propuesto por Banker (1994) [Banker(1994) Kauffman, Wright, Zweig, Automating Output Size and Reuse Metrics in a Repository-Based Computer Aided Software Engineering ( CASE ) Environment IEEE Trans. Software Eng, 20(3), pp ,1994.]

35 Object points – Identificar elementos
Elementos del sistema Pantallas Reportes Módulos 3 GL (lenguaje de 3ra generación) El método original contempla solo esos tres tipos de objetos Las implementaciones ad hoc del método consideran otros tipos de componentes, ej: Clases Java Páginas Jsp Programa Cobol Script SQL etc

36 Object points srvr es el número de tablas de datos utilizadas en un servidor ( mainframe o equivalente ) utilizadas en conjunto con las pantallas o reportes. clnt es el número de clientes (personal workstation) utilizadas en conjunto con las pantallas o Reportes Luego, se le asigna un peso de acuerdo a la siguiente tabla. El peso refleja el esfuerzo necesario para cada componente de acuerdo al nivel de complejidad:

37 Object points Calcular el porcentaje de reusabilidad
Object Points brutos = OPB OP = [ OPB * (100 - % Reutilización) ] : 100 Luego se debe transformar el esfuerzo en personas por mes : NOP(new object points) = OP (100-%reusabilidad)/100 Esfuerzo = NOP/PROD PROD (nivel de productividad) puede ser tomado de la siguiente tabla como referencia:

38 Preguntas

39 Sugerencias

40 Aplausos