Administración y Gestión de Proyectos de Software

(1)

Administración y Gestión de

Proyectos de Software

2do. Cuatrimestre 2005

Depto. Cs. e Ingeniería de la Computación Universidad Nacional del Sur

Riesgo: Componentes

9Riesgo de Rendimiento: el grado de incertidumbre con que el producto resolverá los requerimientos y se adecue al rendimiento pretendido.

9Riesgo de Costo: el grado de incertidumbre que tendrá el presupuesto del proyecto.

9Riesgo de Soporte: el grado de incertidumbre que

tendrá el software para permitir corregirlo, adaptarlo y mejorarlo.

9Riesgo de la Planificación Temporal: el grado de

incertidumbre que tendrá la planificación temporal para que el producto se entregue a tiempo.

(2)

Administración y Gestión de Proyectos de Software DCIC UNS – 2005

Prof. Sergio Martig Clase 3 - 3

Riesgo: Proyección

El impacto de cada controlador de riesgo en el

componente de riesgo se divide en cuatro categorías:

despreciable, marginal, crítico, catastrófico.

La proyección de riesgo (estimación) intenta medir cada riesgo de dos maneras:

9la probabilidad de que el riesgo sea real,

9las consecuencias de los problemas asociadas con el riesgo, si ocurriera.

Riesgo: Proyección

El equipo de desarrollo debe realizar cuatro actividades:

9Establecer una escala que refleje la probabilidad del riesgo

9Definir las consecuencias del riesgo

9Estimar el impacto del riesgo en el proceso y en el producto

9Apuntar la exactitud de la proyección para que no haya confusiones

Se construye una Tabla de Riesgo utilizando una planilla de cálculo

(3)

Tabla de Riesgos

9En la 1ra.columna se listan todos los riesgos.

9En la 2da.columna se categoriza el riesgo (riesgo del tamaño, del negocio, de desarrollo, técnico,...).

9En la 3ra.columna se coloca la probabilidad de que ocurra el riesgo. La puede calcular individualmente cada integrante del equipo y luego se coloca la media.

9En la 4ta.columna se coloca la valoración del impacto.

9Se ordena la tabla por probabilidad y por impacto y se determina un nivel de corte.

(4)

Tabla de Riesgos: Consideraciones

9El impacto del riesgo y la probabilidad influyen de manera diferente.

9Un factor con gran impacto y poca probabilidad, no demanda demasiada gestión.

9Un factor con gran impacto y probabilidad moderada o impacto medio y probabilidad alta requieren gestión de riesgo.

9Se consideran los riesgos por encima de la línea de corte, para cada uno de ellos se desarrolla un Plan de Reducción, Supervisión y Gestión del Riesgo.

Riesgos: Evaluación Impacto

Si un riesgo ocurre, existen tres factores que afectan sus consecuencias: la naturaleza, el alcance y cuando ocurre.

9La naturaleza: indica los problemas que aparecerán si ocurre .

9El alcance: combina la severidad (cuánto de serio es) con la distribución (qué proporción del proyecto se ve afectado).

9Cuando Ocurre: considera cuando ocurre y por cuanto tiempo se sentirá el impacto.

La tabla de riesgo debe evaluarse periódicamente y realizar los ajustes necesarios.

(5)

Riesgos: Estrategias

Una estrategia eficaz debe considerar tres aspectos:

9Evitar el riesgo

9Supervisar el riesgo

9Gestión del riesgo y planes de contingencia Como estrategia proactiva se debe desarrollar un

plan de reducción de riesgo: tareas encaminadas a reducir las posibilidades de que los riesgos previstos ocurran.

A medida que el proyecto avanza se debe supervisar el riesgo.

Gestión del Riesgo

9La gestión del riesgo y los planes de contingencia asumen que los esfuerzos de reducción han fracasado y el riesgo se ha convertido en realidad.

9Los pasos de RSGR (reducción, supervisión y gestión del riesgo) provocan aumentos en los costos del proyecto. Parte de la gestión de riesgos es evaluar cuando los costos superan los beneficios.

9Para un gran proyecto se pueden idenificar entre 30 y 40 riesgos. Si para cada uno se determinan entre 3 y 7 pasos de gestión, la gestión se convierte en otro proyecto. Asumir la regla de Pareto 80-20.

(6)

Administración y Gestión de Proyectos de Software DCIC UNS – 2005 Prof. Sergio Martig Clase 3 - 11

Gestión del Riesgo: Regla de Paretto

La describió el economista italiano Vilfredo Pareto en 1897: “El menor número de causas, inputs o esfuerzo llevan a una mayoría de efectos, outputs o

recompensas''

980% del tiempo se consume en un 20% de tareas de desarrollo.

980% del trabajo se hace por el 20% de las personas.

980% de frustración se debe al 20% de los problemas.

980% de los problemas puede solucionarse con el 20% del código.

9El 80% de código restante solo soluciona el 20% de los problemas.

GR : Importancia de una estimación

No son los números, ni las figuras, sino la confianza

en la misma.

Posibilidades de expresar el Riesgo:

9Expresar una desviación.

9Expresar varios niveles del atributo: el peor caso, el nivel planificado y el nivel actual.

9Estimar una probabilidad (también incierta) de que un valor ocurra.

9Listar los factores que pueden contribuir a las variaciones enunciadas, luego de la estimación.

(7)

Motivaciones para lograr Control

Predicciones realistas: sentido común, amplitud de criterio, imaginación, formas simples de expresarse, el deseo de comunicarse efectivamente con otros. Cómo motivar al personal?

9A igual función, igual remuneración?

9La gente que cumple, tiene beneficios?

9Qué pasa con el personal que no cumple?

9Tiene la alta gerencia la amplitud de criterio para que la gente no prometa cosas inútiles?

Ejemplo de motivación: viernes libres.

Especificación de Atributos

9Lo más importante es identificar las funciones del sistema (lo que el sistema hace o hará) involucradas con el proceso de software.

9Lista aspectos esenciales que el producto debe tener, y que deben ser entregados en los tiempos especificados.

9Los requerimientos funcionales generalmente se registran como una lista de requerimientos a ser completada por usuarios o clientes.

9Es opuesto a especificación de atributos que tiene una escala de demanda y posibles negociaciones dependiendo de las prioridades.

(8)

Especificación de Atributos

9Una especificación funcional está presente o ausente de un plan o de un sistema real. No existe un grado de presencia o de ausencia de la función.

9Las ideas funcionales pueden ser definidas con mayor detalle descomponiéndolas en ideas constitutivas.

9Una especificación funcional no es necesariamente una especificación para construir algo nuevo. Pueden usarse para delinear funciones existentes, cuyos atributos deben ser impactados por los cambios planificados..

Especificación de Atributos

Una especificación funcional no es un requerimiento, a menos que específicamente lo hagamos un requerimiento. Las especificaciones funcionales se pueden usar para muchas cosas entre ellas enunciar requerimientos.

Especificación Funcional:

Dpto-Sis: El departamento de sistemas está formado por la gerencia, analistas, programadores y personal administrativo.

Requerimiento Funcional:

Dpto-Sis-Promoción: Se deberá implementar una política de promoción del personal del departamento de sistemas.

(9)

Especificación Funcional: Consejos

9Separar ideas funcionales de ideas de atributos.

Ejemplo: "Redactar un manual de usuario legible"

Legible: un beneficio, una calidad medible.

Redactar Manual de Usuario: una función, sin escala medible, presente o ausente.

Marcar con (F) requerimiento funcional, (A) requerimiento de atributo, (S) solución en el planteo del problema.

Especificación Funcional: Consejos

Ejemplo: Nosotros ( la organización xxx ) (F)

queremos (objetivo imlícito) escribir un manual de desarrollo de sistemas (S), para mejorar sustancialmente la productividad del personal (A = indefinido)

9 Ser cuidadoso: las soluciones enunciadas en esta etapa son generalmente una forma del usuario de decir lo que desea.

9 Ejemplo: ”Construir estándares” . Preguntar: Por qué?, Para qué?. Respuestas posibles: para facilitar el mantenimiento y posibilitar la rotación de personal.

(10)

Especificación Funcional: Consejos

Deben simplificarse. Sólo se enuncian funciones a las cuales se les desea mejorar sus atributos.

9 Especificaciones Funcionales: Bottom-up o Top-Down? No existe la mejor decisión. Depende del proyecto.

9 Si es necesario particionar, explotar la especifi-cación funcional en sub-componentes funcionales útiles

9 Criterios de partición: Performance: frecuencia de uso. Facilidad de Mantenimiento: funciones que se modifican frecuentemente y estables. Funcio-nes implementables rápidamente y otras a entre-gar a posteriori.

Especificación Funcional: Consejos

Cada especificación funcional debe rotularse y enun-ciarse en forma separada.

Ejemplo:

2.1.7 El software debe ser compatible con Unix version V Release 3.2 y tener un soporte de menúes de ventanas-mouse-pull-down.

9 2.1.7 REQUERIMIENTOS DE SOFTWARE

9 COMPAT: Unix version V Release 3.2.

9 VENTANAS: se requiere soporte ventanas.

9 MOUSE: se requiere que soporte mouse.

9 PULLDOWN: se requiere soporte menúes pull-down.

(11)

Especificaciones de Atributos

Atributo: concepto de calidad o concepto de recurso que describe un sistema cuantitativamente.

9 Los atributos son características del sistema que representan restricciones.

9 Especificación de Atributos: es una lista de atribu-tos.

9 La especificación de atributos es el lugar natural donde ubicar el registro de modificaciones, que son los resultados naturales del proceso de diseño o de la construcción de un plan más detallado.

9 La definición de atributos debe ser personalizada para cada proyecto.

9 Todos los atributos críticos deben ser

especificados y controlados durante todo el ciclo de vida del proceso y del producto.

9 Todos los atributos deberían convertirse en medibles en la práctica.

9 Las personas tienden a fracasar al definir una escala de medición por que culturalmente no se demanda esta disciplina.

9 El proceso de medición tambien nos permitirá monitorear el progreso en el diseño y en la entrega del sistema de una manera precisa.

(12)

Especificaciones de Atributos

9 Generalmente es conveniente expresar atributos

como una jerarquía de atributos y sub-atributos.

9 Los atributos pueden ser definidos descomponién-dolos en sub-atributos.

9 La jerarquía de atributos nos facilita administrar una lista importante de atributos de un sistema complejo.

9 La jerarquía reduce la tentación de sobre-simplifi-car la realidad.

9 Los atributos deberían ser especificados en térmi-nos de los resultados requeridos por el usuario final.

Especificaciones de Atributos

9 El lenguaje usado debe ser comprensible por

todos.

9 El test es que la gerencia usuaria firme la especificación de requerimientos de atributos indicando su conformidad.

9 La especificación de atributos inicial debe ser hecha al principio (día cero-hora cero), antes de intentar cualquier especificación de solución

9 Las alternativas de solución sólo pueden ser juzgadas a la luz de todos los requerimientos de atributos.

9 No tratar de congelar los requerimientos de atributos. Son dinámicos.

(13)

Especificación de Atributos: Reglas

9 Confeccionar una lista de las calidades mas críticas

y de los atributos de recursos para el proyecto.

9 Si la lista tiene más de 7..10 elementos, agruparlos bajo un solo nombre.

Ejemplo:

Performance del Sistema

Capacidad de carga de trabajo semanal. Disponibilidad del sistema.

Tiempo de respuesta para consultas de 1 registro.

9 El nombre debe ser corto y fácilmente relacionable por los usuarios.

9 La definición de cada nombre está dada por las definiciones inferiores.

Especificación de Atributos: Reglas

9 Es mas fácil comenzar identificando los objetivos

de bajo nivel. Tienen mayor precisión, son más visibles, más inmediatos.

9 Los atributos de alto nivel son los que están detrás de los de menor nivel. Los atributos de menor nivel: atributos indirectos.

9 Los atributos de alto nivel permiten ver otras posibles soluciones.

9 Para cada atributo identificado, preguntar: Por qué?

Ejemplo: ”confiabilidad”, cuando en realidad se

busca ”disponibilidad”. La disponibilidad es una función de la confiabilidad, pero también de la

(14)

Atributos: Escala de Medición

9 Escala: las unidades de medida definidas.

9 Se sugiere dos tipos de definiciones de medición de atributos

1. Teórica: la escala. Dice algo sobre qué se trata de medir.

Ej: voltios.

2. Práctica: el test. Dice algo sobre cómo se va a intentar medir.

Ej: voltímetro.

9 Los atributos de alto nivel no necesitan su propia escala. Se generalizan de las escalas inferiores.

Atributos: Escala de Medición

Ejemplo:

AMIGABLE:

Aprendizaje: Escala = horas para aprender Plan = 5 hs

Productividad: Escala = tareas por hora Plan = 20 tareas.

9 Si encuentra dificultoso definir una medida para un concepto, es un atributo de alto nivel, descomponerlo en sub-conceptos.

Ejemplo: Amigable siempre necesita descomposición. Entre otros: cantidad de errores cometidos, velocidad de trabajo luego de capacitación,…

(15)

Atributos: Escala de Medición

9 Se deben definir atributos hasta el nivel de detalle

necesario para controlar los parámetros críticos del sistema.

Ejemplo:

0. Un producto de mejor calidad y una organización mas productiva

0.1 SATISFACCION (de clientes de la empresa)

0.2 CALIDAD DE EMPLEADOS (sólo del departamento de sistemas)

0.3 ADAPTABILIDAD (de los empleados)

Atributos: Test de Medición

9 Test: una forma de medir en la escala

especificada.

9 Es recomendable especificar tests de medición que ya estén en uso. Para asegurar que las mediciones estarán disponibles y se confíe en ellas.

9 Poner por escrito las primeras ideas y luego refinarlas.

9 Los puntos en los cuales se aplicarán los tests se pueden definir entre paréntesis.

(16)

Atributos: Test de Medición

Ejemplo:

TEST (Etapa de Diseño) = Usar datos del método de inspección de Fagan

TEST (Etapa de Codificación) = Usar procedi-mientos de pruebas unitarias (ISO 1234)

TEST (Etapa de Testing) = Usar los datos reco-lectados del sistema anterior.

9 No se puede juzgar ninguna solución de manera segura a menos que sea capaz de medir los efec-tos de su implementación sobre los atribuefec-tos críticos.

Atributos: Especif. Peor Caso

Peor Caso: el peor nivel aceptable bajo cualquier circunstancia.

9 Cualquier cosa peor constituye un fracaso oficial de satisfacer los requerimientos mínimos del proyecto.

9 Procedimiento: Imagine cualquier nivel totalmente inaceptable bajo cualquier circuns-tancia.

9 Imagine mejoras a ese nivel, hasta que piense que ese nivel será aceptable por algún usuario, bajo algunas circunstancias.

9 La especificación del peor caso puede ser la base para un contrato legal.

(17)

Atributos: Especif. Peor Caso

Ejemplo

TIEMPO DE ACTUALIZACION

– ESCALA: Tiempo desde que ocurre el evento hasta que la BD está actualizada.

– TEST: Medición de un día aleatorio que incluye al menos 10 casos (preferente 50).

– PEOR: Al día diguiente. – PLANIFICADO: El mismo día. – MEJOR: 1 Hora.

– ACTUAL: No hay medida.

Atributos: Especif. Nivel Planificado

9 Nivel Planificado: el nivel esperado junto con

todos los otros niveles planificados del resto de los atributos.

Peor Caso: límite entre fracaso y no fracaso. Nivel Planificado: logro de éxito formal.

9 El nivel planificado nunca es la perfección. Debería ser un valor suficientemente bueno.

9 Deberían ser lo mas realistas posibles, pero también intencionalmente ambiciosos.

(18)

Atributos: Especif. Mejor Caso

9 Mejor Caso: el mejor nivel alcanzado bajo

cualquier circunstancia.

9 Es informativo. Indica un potencial no explotado en el atributo.

9 Es llamado el límite de la ingeniería.

9 No es un requerimiento. Es una referencia.

Atributos: Nivel Actual y de Referencia

9 Nivel Actual: nivel de un atributo en un sistema

con el cual queremos comparar.

9 Provee información comparativa útil.

9 La diferencia entre el nivel actual y el nivel planificado es una medida del cambio que deberá dar el nuevo sistema o solución.

9 Es útil incluir referencias a las fuentes de medición. Citar las fuentes de autoridad.

(19)

Solución:

9 Solución: es un conjunto de ideas de ingeniería

de diseño para satisfacer la especificación de los requerimientos de atributos del usuario.

9 Los atributos determinan soluciones.

9 Se puede usar los requerimientos de atributos como una lista de ítems que necesitan alguna especificación de solución.

9 La herramienta mas simple es la tabla de análisis de impacto.

9 Presunción escondida: para cada solución se conocen los atributos de calidad y de recursos.

Solución

9 Se debe tener suficientes soluciones para

satisfacer todos los objetivos.

9 Las funciones determinan los atributos de interés.

9 Se comienza por los requerimientos funcionales por que son mas visibles.

9 Los atributos determinan soluciones, pero las funciones determinan los requerimientos de atributos.

(20)

Solución: Proceso de búsqueda

1. Concentrarse en un atributo por vez. Hacer lluvia de ideas para plantear soluciones que satisfagan el nivel planificado. 2. Estimar efectos colaterales (usando tabla de estimación de

impacto) en los otros atributos.

3. Eliminar soluciones que produzcan el peor caso en algún atributo.

4. Repetir el proceso hasta que se encuentren todos los niveles planificados o no se encuentren mas soluciones.

5. Si se encontraron todos los niveles planificados, ir a paso 7. 6. Si no hay mas posibles soluciones y no se alcanzaron los

niveles planificados:

(a) Buscar mas experiencia en diseño (ir a paso 1). (b) Cambiar y negociar los niveles planificados. 7. Testear las hipótesis de diseño:

Método de inspección de Fagan - Entregas parciales y medición - Otras herramientas de análisis

Consejos Prácticos…

9 No preocuparse por obtener la solución de diseño

completa y perfecta.

9 Hacer un trabajo razonable.

9 Estar preparado para aprender de entregas

evolutivas, o para cambiar el diseño cada vez que sea necesario.

9 Se puede hacer bien desde la primera entrega, pero se puede mejorar.

9 Mantenerlas resumidas.

9 Ser lo mas preciso (no ambiguo) posible.

(21)

Soluciones: Identificación

9 Todas las ideas de solución deberían tener una

etiqueta de identificación única para referencias futuras.

9 Pueden ser etiquetas numéricas o mnemotécnicas.

9 Las etiquetas mnemotécnicas no sufren el proceso de obsolescencia.

9 El identificar soluciones permite resumir ideas en tablas de evaluación, proveer una base para ad-ministrar la configuración de software (versiones).

Soluciones: Identificación

9 Etiquetas Jerárquicas: pueden usarse para indicar

que las ideas pertenecen a un grupo.

9 Etiquetas Temporales: la definición puede cam-biarse, mejorarse o corregirse. Pueden usarse para versiones de software.

9 Son útiles para métodos automatizados y para métodos de inspección.

(22)

Jerarquía de Soluciones

9 Se necesita un método para clarificar las áreas

principales de arquitectura de un sistema en relación a decisiones de diseño mas detalladas.

9 Un proceso de lluvia de ideas puede proveer una mezcla de soluciones de alto y bajo impacto.

9 Se necesita concentrarse primero en recolectar soluciones de alto impacto (en requerimientos de atributos).

9 Una vez ubicada la arquitectura principal, se debe realizar con un proceso sistemático de refina-miento.

Jerarquía de Soluciones: Beneficios

9 Cuando se elimina una idea de alto nivel, se

eliminan todas las ideas de menor nivel.

9 Toda la explosión detallada sirve para definir los conceptos de alto nivel de manera mas precisa (menos ambigua).

9 Nuestra habilidad para estimar correctamente el impacto de las ideas de alto nivel aumenta en proporción al nivel de las definciones detalladas.

9 El proceso de modularización depende de los objetivos y de las prioridades.

(23)

Soluciones. Evaluación

9 Cómo podemos saber que las soluciones

sugeridas cumplimentarán los requerimientos?

9 La tabla de estimación de impacto es la herramienta básica, administrable con una planilla de cálculo.

9 La dificultad de estimar el valor de una solución también se ve influenciada por los cambios en los costos y disponibilidad de la tecnología.

9 La Estimación del Impacto esta plagada de posibilidades de error.

9 Son inevitables. Se debe comunicar el concepto de incertidumbre.

Incedrtidumbre Inevitable

1. Hacer intencionalmente estimaciones rápidas.

2. No tener disponibles los hechos que permitan estimar con precisión.

3. Varias soluciones con efectos disímiles en los resultados.

4. Muchas soluciones serán parte del sistema final, no disponibles aún.

5. Muchas soluciones no han sido refinadas para estimar correctamente.

6. La implementación puede depender de la habi-lidad profesional del Ingeniero de Software.

(24)

Mejor Solución

9 Una buena solución esta caracterizada por el

número y nivel de impacto positivo que tiene en los atributos.

9 Una forma es sumar algebraicamente los efectos en los atributos.

9 Cuanto mayorsea la suma para los atributos de

calidad = Mejor

9 Cuanto menor sea la suma para los atributos de

recursos = Mejor

9 El ratio de los impactos para una solución = S impactos de calidad / S impactos de recursos.

Método de Inspección de Fagan…

1. Las inspecciones son realizadas en un número de puntos prefijados del proceso de planificación del proyecto y del desarrollo del sistema.

2. Se inspeccionan todas las clases de defectos en la documentación, no sólo errores lógicos o funcionales.

3. Las inspecciones son realizadas por colegas de todos los niveles, con excepción del gerente.

4. Las inspecciones se realizan de acuerdo a una serie de pasos predefinidos. Ej: preparación individual, reunión pública, reconstrucción de errores, etc.

(25)

… Método de Inspección de Fagan

5. Las reuniones de revisiones están limitadas a 2 horas.

6. Las inspecciones están conducidas por un moderador entrenado.

7. A los inspectores se les asigna roles específicos para aumentar la eficiencia.

8. Se utilizan checklists de preguntas que los inspectores deben hacer para definir las tareas y estimular el aumento de detección de defectos.