ACI491: Ingeniería de Software

ACI491: Ingeniería de Software
Unidad 6: Administración de Proyectos de Software

Contenidos Recursos, productividad y calidad de software.
Métricas como herramientas de software. Técnicas de estimación de costos, Planificación y control de proyectos de Software. Plan de proyectos de software, Organización del equipo de Proyecto. El administrador de proyecto y sus roles, El líder de proyecto y sus roles, Selección del equipo de proyecto.

Objetivos específicos
Conocer y manejar las diferentes herramientas de administración. Manejar en forma eficiente los recursos asociados al software. Conformar un equipo de trabajo, siendo capaz de identificar las labores mas adecuadas para cada uno de los integrantes

Administración: El Proceso de Gestión del Proyecto de Proyectos de software
Comienzo del Proyecto de Software Antes de empezar a planificar un proyecto el desarrollador y el cliente deben ponerse de acuerdo para definir el ámbito y los objetivos del proyecto. Los objetivos identifican los fines globales del proyecto sin considerar como se llegará a ellos. El ámbito identifica las funciones primordiales del Software y más importante aún, intenta limitar esas funciones de manera cuantitativa.

Administración de Proyectos de software
Medición y métricas Las mediciones y las métricas nos ayudan a entender tanto el proceso técnico que se utiliza para desarrollar un producto, como el propio producto. Frecuentemente en la medición surgen las siguientes interrogantes: ¿Cuáles son las métricas apropiadas para el proceso y para el producto? ¿Cómo se deben utilizar los datos que se recopilan? ¿Es bueno usar medidas para comparar gente, procesos o productos? entre otras.

Estimación La Planificación es una de las actividades del proceso de Gestión de Proyectos de Software. Cuando se planifica un proyecto de Software se tiene que obtener estimaciones: Esfuerzo humano requerido. Duración cronológica del proyecto (en fechas). Costo.

Planificación Temporal La planificación de un proyecto de software no difiere de la planificación de cualquier proyecto de ingeniería por lo tanto: Se identifica una serie de tareas del proyecto . Se establecen interdependencias entre las tareas. Se estima el esfuerzo asociado con cada tarea. Se hace la asignación de personal y de otros recursos. Se crea una “red de tareas”. Se desarrolla una agenda de fechas.

Seguimiento y Control Si una tarea se sale de la agenda se debe determinar el impacto del error sobre los hitos intermedios y sobre la fecha final de entrega. Se pueden reasignar los recursos. Reordenar las tareas o (como último recurso) modificar los compromisos de entrega para resolver el problema no detectado. De este modo se puede controlar mejor el desarrollo del software.

Métrica para la productividad y calidad del software La medición es fundamental para cualquier disciplina de ingeniería. Las métricas del software se refieren a una amplio rango de medidas para el software de computadoras.

Medición del software La medición se aleja de lo común en el mundo de la ingeniería de software, aunque sin embargo, existen varias razones para medirlo: Indicar la calidad del producto. Medir la calidad de la gente que desarrolla el producto. Evaluar los beneficios en términos de productividad y calidad. Establecer una línea de base para la estimación. Ayudar a justificar el uso de nuevas herramientas de formación adicional.

Las métricas del software se pueden clasificar en: Métricas de productividad: Se centran en el rendimiento de procesos de ingeniería de software. Métricas de calidad: Conveniencia del software para su utilización. Métricas técnicas: Se centran en las características del software.

También se puede hacer una segunda clasificación: Métricas orientadas al tamaño. Estas son medidas directas del software y el proceso por el cual se desarrolla. Ecuaciones para calcular la productividad y calidad del software.

Métricas orientadas a la función: Son medidas indirectas del software y del proceso por el cual se desarrolla. Los valores del ámbito de la información están definidos de la siguiente manera: Número de entradas del usuario. Número de salidas del usuario. Número de peticiones del usuario. Número de archivos. Número de interfaces externas.

Métrica para la Calidad del Software Podemos medir la calidad a lo largo del proceso de Ingeniería el Software y una vez que el software se ha distribuido al cliente y a los usuarios. Las métricas de calidad de esta categoría incluyen: La complejidad del programa. La modularidad efectiva. El tamaño del programa.

Conclusiones Integración de las métricas dentro del proceso de la Ingeniería del Software ¿Porqué es tan importante medir el proceso de Ingeniería de Software? Permite determinar si estamos mejorando. Proporciona beneficio a nivel estratégico. Proporciona beneficio a nivel de proyecto. Proporciona beneficio a nivel técnico.

Problemática de la estimación.
Averiguar lo que costara desarrollar una aplicación: tiempo, recursos, $, … Momento en que se desea conocer el costo. Siempre se quiere muy pronto…

Problemática de la estimación
Estimar lo que costará: Experiencia de Empresa:

Métodos utilizados para la estimación de proyectos. Basados en la experiencia. Basado exclusivamente en los recursos. Método basado exclusivamente en el mercado. Basado en los componentes del producto o en el proceso de desarrollo. Métodos algorítmicos.

Juicio experto: Puro Un experto estudia las especificaciones y hace su estimación. Se basa fundamentalmente en los conocimientos del experto. Si desaparece el experto, la empresa deja de estimar…

Estimación Medidas del Software
Planeación => estimar tiempos y recursos => estimar Tamaño del software => medida del software. Medida Proceso por el cual se asignan números o símbolos a entidades de un set determinado para describir algún atributo de ellas.

Estimación Medida directa, indirecta o predicción: Medida directa: se observa la entidad y se aplica el instrumento de medida directa (peso, estatura). Medida indirecta: se mide en forma directa otra entidad (o más de una) y luego se usan relaciones conocidas entre ellas (velocidad = distancia/tiempo). Predicción: queremos una estimación de una medida de una entidad que puede no existir en ese momento.

Estimación Predicción Similar a medición indirecta
Establecer una conexión entre las entidades medidas directamente y las entidades cuya medida será predicha. Refinar la conexión hasta llegar a una o más fórmulas que permitan traducir las medidas directas en medidas aproximadas. La diferencia clave está en que la en la predicción no es posible establecer una conexión completa => sólo se puede aproximar la medida correcta.

Mediciones de Software
Estimación Mediciones de Software Razones de baja aceptación en la industria: Los administradores no saben qué hacer con las mediciones… Falta de validación necesaria => falta de confianza en las medidas.

Estimación Ejemplo 1: El modelo COCOMO simple relaciona el esfuerzo E (meses/hombre) con el tamaño S (MLOCS) de acuerdo a: E = a*Sb Donde a y b son parámetros determinados por el tipo de software a ser desarrollado. Para usar este modelo para predecir el esfuerzo en la etapa de captura de requerimientos, necesitamos primero determinar (predecir) los parámetros y luego el tamaño del eventual sistema. Estrictamente, COCOMO es más que un método de estimación de costos, es un sistema de predicción de costos.

Sistemas de Predicción
Estimación Sistemas de Predicción Ejemplo 2: Puntos de Función (FPs) Los Puntos de Función son una métrica estándar para establecer el tamaño del software. Los Puntos de Función miden la aplicación desde una perspectiva del usuario, dejando de lado los detalles de codificación. Es una técnica totalmente independiente de todas las consideraciones de lenguaje .

Estimación Un Punto de Función se define como una función comercial de usuario final. De esta manera un programa que tenga “x” PF’s entrega “x” funciones al usuario final. Para calcular los PF se deben realizar dos operaciones: Contar tipos de funciones transaccionales. Contar tipos de funciones de datos. Las Funciones Transaccionales representan la funcionalidad provista al usuario de los procesos de datos de una aplicación. El conteo de tipos de funciones transaccionales determina la cantidad de Entradas Externas, Salidas Externas y Consultas Externas.

Estimación Se identifican 5 funciones básicas:
Inputs: pantallas o formularios usados para captura. Outputs: pantallas o reportes que la aplicación produce. Consultas: usuario interroga o pide información. Archivos Interfaz: archivos compartidos de entrada o salida, parámetros, etc.

Estimación Estimación Wideband-Delphi
La idea fundamental de este método es usar varios expertos que hacen estimaciones independientes y luego hacerlos converger hacia una estimación única. Cada experto recibe las especificaciones del programa y un formulario de estimación. Se reúnen a conversar sobre suposiciones, dudas, etc. Cada uno hace una lista de las tareas y produce una estimación.

Estimación Las estimaciones son recogidas por un moderador quien tabula los resultados y los devuelve a los expertos: estimaciones, promedio, media, etc. Se reúnen nuevamente y discuten las tareas. La discusión entre los expertos a menudo clarifica aspectos y produce cambios en las estimaciones para etapa siguiente. El método produce estimaciones bastante precisas.

Estimación con Lógica Difusa
Método de Lógica Difusa (Fuzzy-Logic): Se basa en comparar (en líneas de código) con información histórica de productos anteriores. Se construye una tabla (escala de tipo logarítmica) con rangos y subrangos de tamaño de proyectos previos. Por ejemplo si el programa más pequeño es de 104 LOC y el más grande de LOC ...

Estimación a través de Componentes Estándares
Este método se basa en mantener una base de datos histórica con información de componentes usados en proyectos previos en varios niveles de abstracción: subsistemas completos, módulos, interfaz con usuario, etc.

Estimación a través del Factor de Complejidad
Para calcular el factor de complejidad se consideran 13 aspectos, otorgándosele a cada uno de éstos una influencia de 0 a 5, generándose así un puntaje que va de 0 a 70. El factor de complejidad estará dado por: FC = * Puntaje (rango 0.65 hasta 1.35)

Estimación Los factores son: - comunicaciones - funciones distribuidas
- objetivos de desempeño - configuración sobrecargada - tasa de transacciones - entrada de datos on-line - eficiencia para usuario - actualización en línea - proceso complejo - facilidad de instalación - facilidad de operación - varios sitios - facilidad de mantención

Estimación Estimación Probe
El Método PROBE es aplicable en ambientes de OOP (por lo menos durante el diseño). diseño conceptual  identificación de principales objetos (tipo, tamaño) calcular proyección de LOC estimar tamaño calcular intervalo de predicción

Estimación Método basado exclusivamente en el mercado:
precio para vender. Lo importante es conseguir el contrato… El precio se fija en función de lo que creemos que esta dispuesto a pagar el cliente. Si se usa en conjunción con otros métodos puede ser aceptable, para ajustar la oferta. ¡Peligro! -si es el único método utilizado-.

Estimación Método basado en los componentes del producto o
Proceso de desarrollo: Bottom-up Se descompone el proyecto en las unidades lo menores posibles. Se estima cada unidad y se calcula el costo total. Top-Down Se ve todo el proyecto, se descompone en grandes bloques o fases. Se estima el costo de cada componente.

Estimación Conclusiones
Los modelos teóricos sirven, pero tienen muchas limitaciones. Muchas veces el plazo de desarrollo es fijado por gente del área comercial o por ejecutivos, sin efectuar ningún tipo de cálculo serio.

Estimación Conclusiones
Aunque muchas veces es difícil, el Ingeniero Jefe del Proyecto debe ser muy claro desde un principio y defender enérgicamente los tiempos reales obtenidos científicamente. En muchas ocasiones el encargado del proyecto se pone a si mismo la soga al cuello él solo, sin que nadie realmente lo esté forzando a un agenda tan ajustada.

Administración de Proyectos
Planificación del proyecto Distribuir la estimación del esfuerzo a lo largo del proyecto. Establecer los hitos y las actividades para chequear el avance el proyecto. Redefinir la planificación sobre la marcha, aportando medidas para apalear los desfases respecto a la planificación inicial. Controlar el proyecto, ejecutando las actividades de revisión previstas en la etapa de planificación, y comparar los resultados contra lo planificado.

Para hacer esto hay que seguir una serie de Principios Básicos: Segmentación El proyecto debe ser separado en un número manejable de actividades y tareas. Interdependencia La planificación debe reflejar la separación de tareas, y las relaciones entre ellas. Hay algunas tareas cuya ocurrencia es secuencial, otras en paralelo, algunas son requisito de otras, etc.

Asignación de tiempo A cada tarea se le debe asignar un cierto número de Unidades de trabajo (personas-días, etc.) y Fechas de inicio y Término. Validación del esfuerzo Se debe verificar que las personas asignadas a una tarea estén Disponibles, que la cantidad de trabajo requerido no esté sobredimensionada, y además, que sea suficiente.

Definición de responsabilidades Cada tarea debe tener un responsable. Salida definida Cada tarea debe tener una salida o producto bien definido. Por ejemplo: diseño de un módulo, plan de pruebas, etc. Definición de metas Cada grupo de tareas debe estar asociado con una meta.

Planificación de Tareas Se pueden usar métodos como PERT o CPM Cualquiera de estos métodos provee mecanismos para: determinar la ruta crítica: secuencia de tareas que define la duración del proyecto. establecer estimaciones probables para tareas individuales.

Calcular tiempos límites que definen ventanas de tiempo para las distintas actividades: lo más temprano que una actividad puede empezar si todas las precedentes se completan en el mínimo tiempo. lo más tarde que puede comenzar una tarea sin aumentar el tiempo mínimo del proyecto. Existen herramientas de software para ello: MicroSoft Project, Planner, Open WorkBench, etc...

Control de Tareas Básicamente, es una estrategia de tipo incremental. Se define la entrega del primer incremento, y luego se reajustan todas las tareas de acuerdo a este incremento. Al llegar al límite de tiempo de la tarea para ese incremento, esa tarea se detiene y comienza la siguiente. Aunque una tarea no esté completa, muchas veces es posible postergar la última parte para el siguiente incremento.

“la mayoría de las veces el administrador del proyecto marca la diferencia entre el éxito o el fracaso de un proyecto…” “la gestión es tan importante como la parte técnica ...” “... es difícil encontrar un buen administrador de proyectos!” “la administración de proyectos es una disciplina que se debe aprender ...”

Formas de monitoreo Llevar a cabo reuniones periódicas en las cuales los participantes informan acerca del estado de desarrollo de las tareas, su progreso, o los problemas encontrados. Determinar si las metas están siendo cumplidas de acuerdo a lo programado (checkpoints). Comparar tiempos planeados contra tiempos reales, para las distintas tareas.

¿Que hacer al detectar problemas con la planificación? Asignar más recursos al área afectada. Readecuar el personal en general. Cambiar la programación del proyecto. Usar técnicas de “time-box”.

¿Cómo mejorar la Administración de Software? Requiere saber ¿dónde estamos hoy?. Con exactitud!!! Requiere revisar/rediseñar: El proceso de administración de proyectos actual. La ingeniería de requisitos. La planificación de proyectos. El seguimiento y control de proyectos. El aseguramiento de la calidad. La administración de la configuración.

Cuales son las Malas Noticias al administrar un proyecto: Tratar de avanzar más allá de los sistemas legados, hacia tecnologías más modernas trae su propio conjunto de problemas técnicos y organizacionales. La administración de proyectos de software se hace cada vez más difícil ... La competencia obliga a las empresas a mejorar su productividad, manteniendo o mejorando la calidad a través de desarrollos más rápidos y económicos.

Adicionalmente, la velocidad de preparación de personal de desarrollo calificado, es menor que la requerida. Actualmente el personal tiene competencias adicionales a las tradicionales. La construcción y mantención de software es una tarea difícil y será aún más difícil. Construir software de una cierta calidad, en forma repetible, es una tarea aún más difícil.

Síntomas Comunes Imprecisión en el entendimiento de las necesidades del usuario final. Falta de habilidad para manejar requisitos cambiantes. Módulos que no calzan ... Software que es difícil de mantener o extender. Descubrimiento tardío de fallas serias. Problemas ajenos, como el Y2K. Miembros del equipo en muchas cosas, o ausentes, haciendo imposible reconstruir la historia de cambios. Falta (o problemas) de comunicación entre los miembros del equipo.

Deficiencias Comunes Administración de requisitos ad-hoc. Comunicación ambigua e imprecisa. Responsabilidades y roles difusos. Arquitecturas “escabrosas”. Complejidad muy grande. Falta de segmentación del problema. Inconsistencias no detectadas en requisitos, diseño e implementación. Testeo insuficiente. Evaluación subjetiva del estado del proyecto. Incapacidad de los miembros para trabajar en grupo. Fallas para analizar y atacar los riesgos. Propagación de cambios no controlada. Automatización insuficiente.

Buenas Prácticas de Software Para construir buen software no basta con ser buen programador. Para ello, hay que conocer, planificar y controlar los procesos y recursos asignados a un proyecto.

CONCLUSIONES La planificación del proyecto provee una definición de cada macro-tarea, junto con estimaciones de tiempos y recursos requeridos. La planificación del proyecto provee además un marco de referencia para monitoreo y control de estas tareas. La planificación del proyecto se desarrolla al comienzo pero continuamente refinada a medida que el trabajo progresa.

Salvo raras excepciones, los recursos y tiempos estimados al inicio, difícilmente son alcanzados. Hay que controlar (monitorear) todo ... Pero el monitoreo es un medio, no un fin. Si el trabajo no coincide con los tiempos y recursos asignados, debe recortarse la tarea, o aumentarse los tiempos y recursos asignados.

Proceso de Dirección de Proyectos
Administración de Proyectos Proceso de Dirección de Proyectos Directrices de un Jefe de Proyectos No confundir la dirección de un proyecto con su ejecución. Hacer todo lo posible por tener usuarios activos y comprometidos. Convertir los productos y tareas en proyectos tangibles.

Directrices de un Jefe de Proyectos Pondrás por escrito la definición del proyecto, los planes, la carta Gantt, los controles y los cambios. El tema del sistema se debe conocer a la perfección. Aceptar el cambio como algo inevitable y natural y se debe administrar adecuadamente. Aprovechar la experiencia pasada.

Directrices de un Jefe de Proyectos Utilizar los mejores recursos disponibles en el contexto de la organización. Gastar muy bien todas tus energías. Nunca asumir una lucha contra el destino. El proyecto es de todos, para todos y por todos. El equipo de trabajo estará siempre informado.

Tareas de dirección. Tareas de ejecución. Administración de Proyectos
Dirigir v/s Ejecutar Tareas de dirección. Planificar, Controlar, Obtener y Asignar recursos, Coordinar, Manejar cambios, Negociar, Educar, Liderar, Evaluar ( calidad ). Tareas de ejecución. Analizar, Diseñar, Documentar, Programar, Probar, Mantener, Capacitar, Investigar, Aprender y Evaluar.

Dirigir v/s Ejecutar Todas son acciones necesarias. Ninguna acción es eludible. Las personas no son profesionalmente “mejores o peores” por la acción que realizan, sino por la calidad y oportunidad de su resultado. La dirección es, a ratos, inseparable de la ejecución, pero sus naturalezas son diferentes.

Participación y participantes El personal de informática no siempre es experto en el área de aplicación. El personal de informática no vive los problemas cotidianos de los usuarios y viceversa. El usuario es el mejor “asignador” de valores de beneficio relativo a diferentes opciones de diseño.

El usuario es el más calificado para determinar cuales son los aspectos más importantes de la zona de efecto de la solución o del producto. La administración superior no puede perder de vista el proceso y sus esfuerzos, en caso contrario sólo se concentrarán en los resultados. La seguridad debe estar presente desde el inicio del proyecto: es más barato modificar el diseño que el producto.

Las unidades de contraloría de las organizaciones deben estar siempre presente: exigir controles, no esperar el término del proyecto para tenerlos. Hacer que todos participen: No discriminar.

Hacer Tangibles los Resultados y Productos Eventos y Objetos Tangibles : Son aquellos cuya realidad puede ser apreciada objetivamente por personas distintas a quienes las causaron o produjeron. Eventos u Objetos intangibles: No contribuyen a la visibilidad del avance, se prestan para manipular maliciosamente la información y entorpecen las comunicaciones.

Para una tarea cuya meta es intangible, es muy difícil de planificar y estimar el tiempo y los recursos necesarios para efectuarlas. Una manera de lograrla es escribiendo y comunicándolo, incluso los supuestos.

No recuerdo haber dicho... Me parecía obvio que sí …
Administración de Proyectos Algunas frases célebres: Yo creí que... Yo nunca dije eso, lo que .... No recuerdo haber dicho... Me parecía obvio que sí … Recuerdo que te habías comprometido... Disculpen, pero como yo no vine a la reunión anterior, me pueden poner al día...

Administración del Cambio El cambio es inherente al ciclo de vida de un proyecto. El entender ésto distingue a los Jefes de Proyectos felices de los estresados. En el estado del arte en que se encuentra la dinámica de definiciones de requerimientos y la tecnología hoy en día, la probabilidad de que un proyecto sufra cambios es 1.

Ignorar el cambio  producto inservible.
Administración de Proyectos Administración del Cambio Se pueden hacer solo tres cosas ante un cambio: Ignorar el cambio  producto inservible. Aceptar todos los cambios  Proyecto infinito. Administrar el Cambio  proyecto exitoso.

Evaluar el cambio en términos de costo/beneficio.
Administración de Proyectos ¿Qué hacer entonces?: Evaluar el cambio en términos de costo/beneficio. Simúlar la Carta Gantt. Propónerlo al grupo de proyecto. Aplique o deseche el cambio.

Recomendaciones Personales Aplique su experiencia y resuelva ciertos cambios sin tanta burocracia. Para eso, dejar holguras en la carta Gantt. No estar todo el día pensando que hacer con el cambio, porque lo único que se estará haciendo es perder el tiempo. Tome decisiones. Evalúe.

Actitudes personales Utilizar una metodología. No usarla, porque no se conoce, puede ser peor. La administración de proyectos como una actividad bohemia, artística y libre es un mito del pasado. Cambiar Artesanía por Ingeniería. El buen aprovechamiento de la metodología puede ser determinante en aspectos tales como plazo, costo y tamaño de un proyecto.

¿Por qué necesitamos trabajar en equipos?
Organización del equipo de Proyecto Motivación ¿Por qué necesitamos trabajar en equipos? La mayoría de los productos son demasiado grandes para ser construidos por una sola persona. Cada vez son más necesarios los especialistas, y los grupos interdisciplinarios. Es vital para poder competir. Es vital para mejorar (evolucionar). Es vital para poder asumir desafíos más grandes.

Funcionamiento de Grupos
Organización del equipo de Proyecto Funcionamiento de Grupos El funcionamiento de los grupos puede responder a un enfoque: Jerárquico Supervisado Democrático

Enfoque Democrático Organización del equipo de Proyecto
El grupo toma las decisiones a través del acuerdo de la mayoría de sus miembros. No existe un líder del grupo: Generalmente deciden por votación. Se promueve la identificación de errores, problemas, riesgos, etc. No se presentan los vicios típicos producto de la jerarquía, sumisión, inhibición, etc.

Organización del equipo de Proyecto
Ventajas Muestran actitudes positivas frente a la identificación de errores  encuentran las fallas en forma temprana. Funcionan bien para atacar problemas difíciles. El éxito no depende de una sola persona. ... todos son parte de la solución.

Desventajas Difícil de implantar. A menudo cuesta más llegar a una decisión. Las reuniones tienden a ser más extensas y menos productivas ... No es muy bueno para proyectos grandes.

Enfoque Jerárquico Organización del equipo de Proyecto
Hay un responsable por nivel y por rol. La comunicación se lleva a cabo a través de canales bien definidos.

Todas las comunicaciones se realizan a través del jefe. Éste actúa como administrador (manager) y responsable técnico (technical leader). Hay otros miembros del equipo que actúan como especialistas.

Ventajas Existen pocos canales de comunicación : Se facilita la toma de decisiones Estamos acostumbrados a trabajar así.

Desventajas Los jefes se transforman en cuellos de botella, especialmente el jefe de proyecto. Aparecen vicios propios de los escenarios jerárquicos, sumisión, inhibición, obsesión, etc. El jefe tiene que estar en tantas cosas, que al final no hace nada bien.

Desventajas Es inaplicable en proyectos grandes. Demasiada dependencia de unas pocas personas. Cuando alguien jerárquico se enferma, se va de vacaciones, o se retira de la empresa, puede aparecer el caos.

Enfoque de Supervisión El grupo es administrado por 2 personas El jefe técnico es responsable de las decisiones técnicas. El manager es responsable del presupuesto, planificación, y seguimiento del proyecto (decisiones políticas).

Ventajas Tanto el jefe técnico como el manager pueden especializarse. Uno puede asumir responsabilidades del otro, en caso de ser necesario (por ejemplo, frente al retiro de uno de éstos). Funciona bien, si la gente involucrada tiene mucha experiencia, y profesionalismo. Puede mezclarse con el jerárquico, generando un modelo más sólido.

Desventajas Hay decisiones que pertenecen tanto al área técnica, como a la gerencial. Requiere un muy buen entendimiento entre el jefe técnico, y el manager. ... además de un gran compromiso, y profesionalismo.

Sincronización y Estabilización de Equipos Cada equipo debe estar formado por pequeños grupos (de 3-4 personas) Los miembros trabajarán en forma individual, diseñando o implementando una parte de la especificación del sistema

Esto estimula la creatividad. Evita la sincronización diaria. Alienta la segmentación de los problemas.

Temas Críticos ... Existen 5 temas críticos, que deben ser considerados dentro de un equipo de trabajo: Clarificar la Visión Compartida del Proyecto. Construir la Cooperación y la Confianza. Establecer Responsabilidades y Atribuciones. Establecer la organización y Utilización de los Recursos. Definir las actividades de supervisión.

Resumen La gestión de proyectos de software es una actividad protectora dentro de la ingeniería del software. Empieza antes de iniciar cualquier actividad técnica y continúa a lo largo de la definición, del desarrollo y del mantenimiento del software. Hay cuatro P’s que tienen una influencia sustancial en la gestión de proyectos de software: personal, producto, proceso y proyecto.

El personal debe organizarse en equipos eficaces, motivados para hacer un software de alta calidad y coordinados para alcanzar una comunicación efectiva. Los requisitos del producto deben comunicarse desde el cliente al desarrollador, dividirse (descomponerse) en las partes que lo constituyen y distribuirse para que trabaje el equipo de software. El proceso debe adaptarse al personal y al problema. Se selecciona una estructura común de proceso, se aplica un paradigma apropiado de ingeniería del software y se elige un conjunto de tareas para completar el trabajo. Finalmente, el proyecto debe organizarse de una manera que permita al equipo de software tener éxito.

El elemento fundamental en todos los proyectos de software es el personal.
Los ingenieros del software pueden organizarse en diferentes organigramas de equipo que van desde las jerarquías de control tradicionales a los equipos de «paradigma abierto». Se pueden aplicar varias técnicas de coordinación y comunicación para apoyar el trabajo del equipo. En general, las revisiones formales y las comunicaciones informales persona a persona son las más valiosas para los profesionales. La actividad de gestión del proyecto comprende medición y métricas, estimación, análisis de riesgos, planificación del programa, seguimiento y control.

El planificador del proyecto de software tiene que estimar tres cosas antes de que comience el proyecto: cuánto durará, cuánto esfuerzo requerirá, y cuánta gente estará implicada. Además, el planificador debe predecir los recursos de hardware y de software que va a requerir, y el riesgo implicado. El enunciado del ámbito ayuda a desarrollar estimaciones mediante una o varias de las técnicas siguientes: descomposición, modelos empíricos y herramientas automáticas.

Las técnicas de descomposición requieren un esbozo de las principales funciones del software, seguido de estimaciones: (1) del número de LOC's, (2) de los valores seleccionados dentro del dominio de la información, (3) del número de personas/mes requeridas para implementar cada función, o (4) del número de personas/mes requeridas para cada actividad de ingeniería del software.

Las técnicas empíricas usan expresiones obtenidas de la experiencia de algunas organizaciones para el esfuerzo y para el tiempo, con las que se predicen esas magnitudes del proyecto. Las herramientas automáticas implementan un determinado modelo empírico.

Para obtener estimaciones exactas para un proyecto, generalmente se utilizan al menos dos de las tres técnicas referidas anteriormente. Mediante la comparación y la conciliación de las estimaciones obtenidas con las diferentes técnicas, el planificador puede obtener una estimación más exacta. La estimación del proyecto de software nunca será una ciencia exacta, pero la combinación de buenos datos históricos y de técnicas sistemáticas pueden mejorar la precisión de la estimación.

Ejercicio 1 Se le ha nombrado gestor de proyecto dentro de una organización de sistemas de información. Su trabajo es construir una aplicación que es bastante similar a otras que ha construido su equipo, aunque ésta es mayor y más compleja. Los requisitos han sido detalladamente documentados por el cliente. ¿Qué estructura de equipo elegiría y por qué? ¿Qué modelo(s) de proceso de software elegiría y por qué?

Ejercicio 2 Se le ha nombrado gestor de proyecto de una pequeña compañía de productos software. Su trabajo consiste en construir un producto innovador que combine hardware de realidad virtual con software innovador. Puesto que la competencia por el mercado de entretenimiento casero es intensa, hay cierta presión para terminar el trabajo rápidamente. ¿Qué estructura de equipo elegiría y por qué? ¿Qué modelo(s) de proceso de software elegiría y por qué?

Ejercicio 3 Se le ha nombrado gestor de proyecto de una gran compañía de productos software. Su trabajo consiste en dirigir la versión de la siguiente generación de su famoso procesador de textos. Como la competencia es intensa, se han establecido y anunciado fechas límite rígidas. ¿Qué estructura de equipo elegiría y por qué? ¿Qué modelo(s) de proceso de software elegiría y por qué?

Ejercicio 4 Se le ha nombrado gestor de proyecto de software de una compañía que trabaja en el mundo de la ingeniería genética. Su trabajo es dirigir el desarrollo de un nuevo producto de software que acelere el ritmo de impresión de genes. El trabajo está orientado a I+D, pero la meta es fabricar el producto dentro del siguiente año. ¿Qué estructura de equipo elegiría y por qué? ¿Qué modelo(s) de proceso de software elegiría y por qué?

Ejercicio 5 Suponga que es el gestor de proyectos de una compañía que construye software para productos de consumo y ha contratado la construcción de software para un sistema de seguridad del hogar. Escriba una especificación del ámbito que describa el software. Asegúrese de que su enunciado del ámbito sea limitado. NOTA: Si no está familiarizado con sistemas de seguridad del hogar, investigue un poco antes de comenzar a escribir su especificación.

Ejercicio 5 (continuación - 1)
Desarrolle una lista de las características de software (por ejemplo: operación concurrente, salida gráfica, etc.), que afectan a la complejidad del proyecto. Establezca prioridades en dicha lista. Haga una descomposición de las funciones software para el sistema de seguridad del hogar. Estime el tamaño de cada función en LOC. Asumiendo que su organización produce 450 LOC/pm con una tarifa laboral de $ por persona-mes, estime el esfuerzo y el coste requerido para construir el software utilizando la técnica de estimación basada en LOC.

Ejercicio 5 (continuación - 2)
Utilizando las medidas de punto de función de tres dimensiones, calcule el número de PF para el software de este sistema de seguridad del hogar, y extraiga las estimaciones del esfuerzo y del coste mediante la técnica de estimación basada en PF.

Ejercicio de reflexión final
Parece extraño que las estimaciones de costes y planificaciones temporales se desarrollen durante la planificación del proyecto de software -antes de haber realizado un análisis de requisitos o un diseño detallado-. ¿Por qué cree que se hace así? ¿Existen circunstancias en las que no deba procederse de esta manera?

Fuentes de información
Sommerville, I. “Ingeniería de Software” 7ma edición. Pressman, R. “Ingeniería de Software: Un enfoque práctico” 5ta edición cap 3 18p cap 4 24p cap 5 22p Kendall, K.E. y Kendall, J.E. “Análisis y diseño de sistemas” 6ta edición. Software Productivity Research

ACI491: Ingeniería de Software

Presentaciones similares

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

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

ACI491: Ingeniería de Software

Presentaciones similares

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

Presentaciones similares

Sobre el proyecto

Feedback