INGENIERA DE SOFTWARE

Roger Pressman 6TASEGUNDA PARTE : GESTIN DE PROYECTOS Roger Pressman 6ta Ed. PARTE CUATRO : GESTIN DE PROYECTOS DE SOFTWARE Roger Pressman 6ta Ed. Capitulo V :LA PRACTICA

La gestin de proyectos es un tema fundamental para afrontar cualquier proyecto de software. Si se nos presentan demasiados problemas al llevar adelante un proyecto es claro indicador de que no existe buena gestin del proyecto

Se centra en las cuatro Ps

Personal Producto Proceso Proyecto

orden no es arbitrario

Un gestor que: se olvida de que trabajo de ISW es un esfuerzo humano intenso nunca tendr xito en la gestin. Si no fomenta la comunicacin con el cliente se arriesga a construir una solucin equivocada, el administrador que presta poca atencin a l proceso corre riesgo de arrojar mtodos y herramienta al vacio, y aquel que enfrenta al proyecto sin un plan arriesga el producto.

 1.

PERSONAL

El factor humano siempre ser el ms importante en el desarrollo de soluciones software, muchos empresarios famosos, lderes de empresas tecnolgicas, coinciden que el xito que han alcanzado sus empresas no se debe a las herramientas que utilizan, es la gente y el trabajo en equipo.

2. PRODUCTO
Muchas veces cuando un cliente pide que le construyan una solucin, siempre pregunta. Cunto me va a costar? Pues bien, todo producto requiere:
Estimaciones cuantitativas y una adecuada planificacin. Una adecuada recoleccin de informacin y un anlisis detallado de los requerimientos.

Con una buena planificacin se puede estimar el tiempo que tomar desarrollar o construir el producto y redimensionar el valor cuantitativo del producto.

3. PROCESO
Proporciona un marco de trabajo desde el cual se puede establecer un plan detallado para la construccin del software. El gestor del proyecto debe elegir el modelo de procesos adecuado para ser aplicado para:
Los clientes que han solicitado el producto y el personal que har el trabajo. Las caractersticas del producto. El ambiente del proyecto en el que trabaja el equipo de desarrollo del software.

4. PROYECTO

Cuando se gestiona un proyecto exitoso, es necesario entender que este puede llegar a fracasar. Segn John Reel, existen 10 razones : 1. El personal de software no entiende las necesidades del cliente. 2. El mbito del producto est mal definido. 3. Los cambios se gestionan mal. 4. La tecnologa elegida cambia. 5. Las necesidades comerciales cambian.

4. PROYECTO

6. Los plazos de entrega no son realistas. 7. Los usuarios se resisten a la utilizacin del software. 8. Se pierde el patrocinio. 9. El equipo del proyecto carece de personal con las habilidades apropiadas. 10. Los gestores evitan las mejores prcticas y las lecciones aprendidas. Para tener xito es necesario comenzar con pie derecho, esto se lo logra trabajando duro para entender el problema y dar una solucin adecuada.

PRCTICAS DE LA PLANEACIN

La actividad de planeacin permite definir el camino mientras se tiene presente una meta estratgica y unos objetivos. Entender los alcances del proyecto Involucrar al cliente en la actividad de planeacin Reconocer que la actividad es iterativa Estimar con base en el conocimiento disponible Considerar el riesgo cuando se define el plan Ser realista Definir como se intentar asegurar la calidad Definir como se pretende incluir el cambio Adaptar el plan a menudo y hacer ajustes cuando estos se requieran

Para poder realizar exitosamente un proyecto de software debemos entender:

El alcance del trabajo a realizarse Los riesgos que estamos enfrentando Los recursos requeridos Las tareas a realizarse Los eventos importantes a observar El esfuerzo (costo) a invertir El calendario a seguir

La gestion comienza antes que el trabajo tcnico empiece, contina con la transformacin del SW desde que es una idea hasta que es una realidad, y termina cuando el SW es discontinuado.

1 2. 3.

Definicin de objetivos y alcances. Medidas y mtricas Estimacin, que incluye:

-Esfuerzo humano (en meses-persona) -Duracin (en unidades de tiempo) -Costo (en unidades monetarias $$$)

Ejemplo de una definicin de Objetivos y Alcances

Definir Objetivos y Alcances del proyecto de curso

4.

Anlisis de Riesgo, que implica:

Identificacin del riesgo Evaluacin del riesgo Determinacin de prioridades Administracin del riesgo Monitoreo del riesgo

5. 6.

Calendarizacin Seguimiento y Control

1. Consiste en establecer detalladamente las fechas en que se realizarn actividades y se entregarn documentos y software, as como la asignacin de quienes sern responsables de realizar las actividades Por lo general tiene estrecha relacin con la calendarizacin .

Fechas lmite de entrega poco realistas Cambios en los requerimientos Sub-estimacin en la planeacin de recursos Errores no considerados Dificultades tcnicas no predecibles Dificultades humanas no predecibles Falta de comunicacin en el equipo Falta de reconocimiento por parte de la administracin de retrasos y falta de medidas para corregir el problema.

17

Divide el proyecto en tareas manejables Establece interdependencias entre las tareas Determina el tiempo de manera realista! (ni mas, ni menos) Determina el esfuerzo involucrado en cada tarea Determina responsabilidades Determina entregables Determina puntos clave de inicio/terminacin de fases

Diagramas de Gantt Diagramas PERT/CPM Redes de tareas y tablas de recursos

Hay muchos paquetes automticos para control de proyectos...

Manera simple de definir actividades Relaciona actividades, entregables e hitos con tiempo de desarrollo/ejecucin Puede incluir responsables

realizar su calendario de proyecto

Los recursos involucrados son: - Hardware, software y Personal Para cada recurso se debe especificar: - Descripcin del recurso - Disponibilidad del recurso - Tiempo cronolgico en el que se utilizar - Tiempo de uso del recurso

Especificar adems: Con respecto a Personal: - Habilidades requeridas

Con respecto a Hardware: - Mquina de desarrollo - Mquina final - Hardware adicional requerido Con respecto a Software: - Software a re-utilizarse - Herramientas CASE* a utilizarse *CASE= Ing. de Software Asistida por Computadora

1. Introduccin
1.1 1.2 1.3 1.4 1.5 Propsito del documento Identificacin del problema Objetivos Generales Funciones principales el proyecto Limitantes tcnicas y administrativas

2. Estimacin de recursos

3. Calendarizacin

2.1 Datos histricos utilizados para estimar 2.2 Tcnicas de estimacin 2.3 Estimaciones 2.3.1 Esfuerzo 2.3.2 Costos 3.1 Diagrama PERT 3.2 Diagrama de Gantt 3.3 Tabla de recursos

Considerar estos puntos para el proyecto del curso. Salvo alguno que no sea aplicable

24

4. Recursos del proyecto 4.1 Personal Involucrado 4.2 Contratos externos 4.3 Hardware 4.4 Software 4.5 Recursos especiales
5. Organizacin del equipo de trabajo 5.1 Estructura del equipo 5.2 Reportes de administracin 5.3 Mecanismos de control

25

El PROYECTO de software lo integran participantes que pueden clasificarse de las siguientes categorias: 1. 2. 3. 4. 5. Gestores ejecutivos Gestores tcnicos Profesionales Clientes Usuarios finales

La gestin del proyecto es una actividad intensamente humana; por tanto los profesionales competentes por lo general no son lideres.

Motivacin Organizacin Ideas e innovacin Resolucin de problemas Dotes de gestin Incentivos Influencia y fomento a la cultura de equipo

La mejor estructura depende del estilo de gestin de cada organizacin, del numero de personas que integraran el equipo y de sus grados de habilidad, as como la dificultad global del problema. Por tanto se pueden considerar los siguientes factores: La dificultad del problema El tamao del programa El tiempo de vida del equipo El grado en que el problema puede separarse en mdulos La calidad y confiabilidad La rigidez de fechas de entrega El grado de sociabilidad que requiere el proyecto.

Para la estimacin de software se debe considerar aspectos como las mtricas como las siguientes:

Por qu medimos software?

1.
2.

3.

4. 5.

Para conocer la calidad del producto Para evaluar la productividad de las personas que lo producen Para evaluar los beneficios de nuevas herramientas de software Para formar una base a fin de estimar Para justificar nuevas herramientas o entrenamientos adicionales.

Formulacin. Disear las medidas y mtricas apropiadas para el software en consideracin Recoleccin. Determinar y aplicar el mecanismo para acumular los datos requeridos Anlisis: Clculo de las mtricas y aplicacin Interpretacin: Evaluacin de las mtricas a fin de obtener informacin sobre la calidad Retroalimentacin. Recomendaciones al equipo de trabajo derivadas de la interpretacin de las mtricas

Las medidas puede ser directas (ejemplo longitud) o indirectas (ejemplo calidad) Las mtricas de software se pueden clasificar de diferentes maneras:
De acuerdo a lo que miden:
Medidas tcnicas Medidas de calidad Medidas de productividad

De acuerdo a la manera como lo miden:

Medidas orientadas al tamao Medidas orientadas a funciones Medidas orientadas a humanos

En promedio un punto funcional (PF) equivale a:

337 lneas de cdigo en lenguaje ensamblador 90 lneas de cdigo en PASCAL 77 lneas de cdigo en COBOL 66 lneas de cdigo en C++ 63 lneas de cdigo en Java 60 lneas de cdigo en Pearl 47 lneas de cdigo en Visual Basic 40 lneas en de cdigo en SQL 26 lneas de cdigo en Small Talk

[Pressman 2006]

FACTOR
Oportunidad de Mercado

DESCRIPCION
Una organizacin en desarrollo puede escoger un precio bajo debido a que se est cambiando al rea del mercado de sw. Pocas ganancias ahora puede significar mejores ganancias despus

Incertidumbre software

en

la

estimacin

del

Si una organizacin no est segur de su estimacin de costos, puede incrementar sus precios

Trminos contractuales

Un cliente puede permitir al desarrollador que mantenga la posesin del cdigo fuente para re-usarlo en otros proyectos. En este caso el precio cargado sera menor que si el cliente mantiene la posesin del software
Si es probable que cambien los requerimientos, la empresa podra cargar precios bajos a fin de ganar un contrato, y compensar despus en los cambios. Si el desarrollador tiene problemas financieros puede bajar sus precios a fin de ganar la venta. Es mejor ganar poco o no ganar que salir del mercado

Volatilidad en los requerimientos

Salud Financiera de la empresa

[Sommerville 96]
35

TCNICA

DESCRIPCIN

Modelado algortmico del costo Juicio Experto

Se desarrolla un modelo usando informacin histrica relacionada a alguna mtrica de software (usualmente tamao) al costo del proyecto. Se estima la mtrica y el modelo predice el esfuerzo requerido. Se consultan varios expertos en el dominio de la aplicacin y en la tcnica de desarrollo de software escogida. La estimacin puede realizarse varias veces hasta que llegan de acuerdo. Est tcnica es til si se han realizado otros proyectos en el mismo dominio de la aplicacin. Esta ley establece que el trabajo se expande hasta llenar el tiempo disponible. El costo se determina entonces de acuerdo a los recuros disponibles, ms que a los objetivos establecidos. si el software ha de entregarse en 12 meses y hay 5 personas involucradas entonces en esfuerzo requerido se estima como 60 personas-mes El costo se estima de acuerdo a lo que el consumidor est dispuesto a gastar. El esfuerzo sestimado depende del presupuesto del consumidor y no de la funcionalidad del software.

Estimacin por analoga La ley de Parkinson

Precio a ganar

[Sommerville 96]
36

Bsico Intermedio Avanzado COCOMO II

Dentro de cada modelo COCOMO los proyectos se pueden clasificar de 3 tipos,. Los tipos son:
Orgnico (Fcil): Proyectos desarrollados con grupos de trabajo pequeos, en un ambiente familiar y construyendo aplicaciones que les son familiares. Semi-independiente (Intermedio): Etapa intermedia entre proyectos orgnicos y de modo incorporado. De modo incorporado (Avanzado): Proyectos que deben operar dentro de limitaciones estrictas.

Dependiendo del tipo de proyecto, sern los valores de las constantes que utilizar la frmula de COCOMO involucrada

El modelo calcula 3 valores para estimar el costo del proyecto, esto utilizando como entrada las lneas de cdigo estimadas. Los valores estimados son:
MP: TDES: N:
Meses-persona Tiempo de desarrollo Nmero de personas necesarias

Las frmulas utilizadas para realizar esta estimacin, dependern del tipo de proyecto en cuestin

PROYECTOS TIPO ORGNICO: MP= [2.4 (KLOC)1.05] KLOC = Miles de lneas de cdigo TDES= 2.5 (MP) 0.38 N= MP/TDES PROYECTOS TIPO SEMI-INDEPENDIENTE: MP= 3.0 (KLOC)1.12 TDES= 2.5 (PM)0.35 N= MP/TDES PROYECTOS TIPO INCORPORADO PM= 3.6 (KLOC)1.20 TDES= 2.5 (PM)0.32 N= MP / TDES
40

CURVAS DE ESFUERZO DEL MODELO DE COCOMO

12000

10000

8000

MESES-PERSONA

SIMPLE 6000 MODERADO COMPLEJO

4000

2000

10 0

12 0

14 0

16 0

18 0

20 0

22 0

MILES DE LINEAS DE CODIGO

24 0

20

40

60

80

41

CURVAS DE ESFUERZO DEL MODELO DE COCOMO

350000

300000

250000

MESES-PERSONA

200000

SIMPLE MODERADO

150000

COMPLEJO

100000

50000

10 00

12 00

14 00

16 00

18 00

20 00

22 00

24 00

26 00

28 00

30 00

32 00

MILES DE LINEAS DE CODIGO

34 00

42

Modifica las ecuaciones de estimacin aadiendo un parmetro multiplicador, el cual ser calculado en base a una tabla que evala la complejidad aadida debido a otros atributos asociados al proyecto. Las formulas entonces quedan de la forma:

E FAE * B * (ev )

Donde FAE = producto de multiplicadores y es la multiplicacin de los valores de la tabla escogidos para cada atributo

ATRIBUTOS DEL PRODUCTO 1. Confiabilidad requerida en el SW (RELY) 2. Tamao de base de datos (DATA) 3. Complejidad del producto (CPLX) ATRIBUTOS COMPUTACIONALES 1. Limitantes del tiempo de ejecucin (TIME) 2. Limitantes de almacenamiento (STOR) 3. Volatilidad de la mquina virtual (VIRT) 4. Tiempo de respuesta computacional (TURN)

44

ATRIBUTOS DEL PERSONAL 1. Capacidad del analista (ACAP) 2. Experiencia en la aplicacin (AEXP) 3. Experiencia en la mquina virtual (VEXP) 4. Capacidad del programador (PCAP) 5. Experiencia en el lenguaje de programacin (LEXP) ATRIBUTOS DEL PROYECTO 1. Practicas modernas de programacin (MODP) 2. Herramientas de SW (TOOL) 3. Calendario de desarrollo requerido (SCED)

45

Se define como la congruencia con requerimientos funcionales y de desempeo explcitamente establecidos, estndares de desarrollo explcitamente documentados y caractersticas implcitas que se esperan de todo software desarrollado profesionalmente
[Pressman 2005]

Los factores que afectan la calidad pueden dividirse en aquellos que pueden medirse de forma directa y los que solo pueden medirse indirectamente. Asimismo, pueden clasificarse de acuerdo a diferentes aspectos del producto.

47

Funcionalidad: Grado al cual el software satisface las necesidades establecidas. Puede identificarse a travs de los atributos: Exactitud, interoperabilidad, seguridad,

conformidad

Confiabilidad: Cantidad de tiempo en que el software est disponible para usarse, segn lo indicado por los siguientes atributos: madurez, tolerancia a fallas y

capacidad de recuperacin

Usabilidad: Grado al cual es software es fcil de usar segn lo indicado por los siguientes atributos: capacidad

Contina

de entenderse, capacidad de aprenderse, capacidad de operarse.

Eficiencia: grado al cual el software hace uso ptimo de los recursos del sistema, segn indicado por los atributos:

comportamiento de tiempo, comportamiento de recursos

Mantenibilidad: Facilidad con la que el software puede repararse, segn lo indicado por los atributos: facilidad de

anlisis, facilidad de cambio, estabilidad, facilidad de pruebas

Portabilidad: Facilidad con la que el software puede transportarse de un medio ambiente a otro, segn lo indicado por los atributos: adaptabiidad, capacidad de instalacin,

capacidad de adecuacin y capacidad de reemplazo

EN BASE A LOS MTODOS Y TCNICAS DE ESTIMACIN ESTUDIADAS. REALC EL ESTUDIO DE FACTIBILIDAD DEL PROYECTO CONSIDERANDO LA FACTIBILIDAD TCNICA FACTIBILIDAD OPERACIONAL FACTIBILIDAD ECONMICA

REF. TESIS PASADAS.

Los requisitos del Software son la base de las medidas de calidad. La falta de concordancia con los requisitos es una falta de calidad. Unos estndares especficos definen un conjunto de criterios de desarrollo que guan la manera en que se hace la ingeniera del Software. Si no se siguen los criterios , habr seguramente poca calidad. Existe un conjunto de requisitos implcitos que ha menudo no se nombran. Si el software cumple con sus requisitos explcitos pero falla en los implcitos , la calidad del software no ser fiable.
51

Los factores que afectan la calidad se pueden categorizar en:

En todos los casos debe aparecer la medicin. Debe ser posible comparar el software (documentos, programas, datos) con una referencia y llegar a una conclusin sobre la calidad.

Factores que se pueden medir directamente, como por ejemplo los defectos por punto de funcin. Factores que se pueden medir slo indirectamente, como por ejemplo la facilidad de uso o mantenimiento.

52

Facilidad de mantenimiento Flexibilidad Facilidad de prueba Revisin del Producto Transicin del producto

Portabilidad Reusabilidad Interoperatividad

Correccin

Operacin del producto Fiabilidad Usabilidad Integridad Eficiencia

53

Correccin : Hasta donde satisface un programa su especificacin y logra los objetivos del cliente. Fiabilidad: Hasta dnde se puede esperar que un programa lleve a cabo de su funcin con la exactitud requerida. Eficiencia: La cantidad de recursos informticos y de cdigo necesarios para que un programa realice su funcin.

54

Integridad: Hasta dnde se puede controlar el acceso al software o a los datos por personas no autorizadas.

Usabilidad (facilidad de manejo):El esfuerzo necesario para aprender a operar los datos de entrada e interpretar las salidas de un programa.

55

Facilidad de mantenimiento: El esfuerzo necesario para localizar y arreglar un error en un programa. Flexibilidad: El esfuerzo necesario para modificar un programa operativo. Facilidad de prueba: El esfuerzo necesario para probar un programa para asegurarse de que realiza su funcin pretendida.

56

Portabilidad: El esfuerzo necesario para transferir el programa de un entorno de sistema hardware y/o software a otro entorno diferente. Reusabilidad ( capacidad de reutilizacin): Hasta donde se puede volver a emplear un programa ( o partes de un programa) en otras aplicaciones. Interoperatividad: El esfuerzo necesario para acoplar un sistema con otro.

57

Es difcil desarrollar medidas directas de los factores de calidad sealados anteriormente, por consiguiente se definen un conjunto de mtricas para desarrollar expresiones que utilicen los factores de acuerdo a la siguiente relacin: Fq = c1 x m1 + c2 x m2 +.+cn x mn

Fq es factor de calidad Cn son coeficientes de regresin Mn son las mtricas que afectan al factor calidad

58

Lamentablemente muchas de las mtricas definidas por McCall solamente pueden medirse de manera subjetiva. Las mtricas se acomodan en una lista de comprobacin que se emplea para puntuar atributos especficos del software. El esquema de puntuacin que se propone es una escala del 0 (bajo) al 10 (alto)

59

Facilidad de auditora: la facilidad con la que se puede comprobar el cumplimiento de los estndares. Exactitud: la exactitud de lo clculos y el control. Estandarizacin de comunicaciones: el grado de empleo de estndares de interfaces, protocolos y anchos de banda. Compleccin: el grado con que se ha logrado la implementacin total de una funcin. Concisin :Lo compacto que es el programa en trminos de lneas de cdigo
60

Consistencia: El empleo de un diseo uniforme y de tcnicas de documentacin a lo largo del proyecto de desarrollo del software. Estandarizacin de datos: El empleo de estructuras y tipos de datos estndares a lo largo del programa. Tolerancia al error : el dao causado cuando un programa encuentra un error. Eficiencia de ejecucin: El rendimiento del funcionamiento de un programa. Capacidad de expansin: El grado con que se pueden ampliar el diseo arquitectnico, de datos o procedimental. Generalidad: la amplitud de aplicacin potencial de los componentes del programa. Independencia del hardware: El grado con que se desacopla el software del hardware donde opera.
61

Instrumentacin: El grado con el que el programa vigila su propio funcionamiento e identifica los errores que ocurren. Modularidad: La independencia funcional de componentes de programa. Operatividad: La facilidad de operacin de un programa. Seguridad: La disponibilidad de mecanismos que controlan o protegen los programas y los datos. Autodocumentacin: El grado en que el cdigo fuente proporciona documentacin significativa. Simplicidad: El grado de facilidad con que se puede entender un programa.

62

Independencia del sistema de software: El grado de independencia de programa respecto a las caractersticas del lenguaje de programacin no estndar , caractersticas del sistema operativo y otras restricciones del entorno. Trazabilidad: La capacidad de seguir una representacin del diseo o un componente real del programa hasta los requisitos. Formacin : El grado en que ayuda el software a manejar el sistema a los nuevos usuarios.

63

Hewlett Packard ha desarrollado un conjunto de factores de calidad del software al que se le ha dado el acrnimo de FURPS: funcionalidad, facilidad de empleo, fiabilidad, rendimiento y capacidad de soporte. Los factores de calidad son cinco y se definen de acuerdo al siguiente conjunto de atributos: Funcionalidad. Se valora evaluando el conjunto de caractersticas y capacidades del programa, la generalidad de las funciones entregadas y la seguridad del sistema global. Facilidad de uso. Se valora considerando factores humanos, la estetica, consistencia y documentacin general.

Fiabilidad. Se evala midiendo la frecuencia y gravedad de los fallos, la exactitud de las salidas, el tiempo medio entre fallos, la capacidad de recuperacin de un fallo y la capacidad de prediccin del programa. Rendimiento. Se mide por la velocidad de procesamiento, el tiempo de respuesta, consumo de recursos, rendimiento efectivo total y eficacia. Capacidad de soporte. Combina la capacidad de ampliar el programa (extensibilidad), adaptabilidad y servicios, as como la capacidad de hacer pruebas, compatibilidad, capacidad de configuracin, la facilidad de instalacin de un sistema y la facilidad con que se pueden localizar los problemas

Jensen, Randall W. and Charles C. Tonies. Software Engineering. Prentice-Hall. New Jersey 1979 Roger S. Pressman. Ingeniera de Software. Un enfoque prctico Mc Graw Hill, 2002 Roger S. Pressman. Software Engineering, A practitioners approach. Sixth Edition, 2005 Sommerville, Ian. Software Engineering. Fifth Edition. Addison-Wesley, 1996

Preparar un plan de proyecto de desarrollo de software y el cronograma en base al empleo de la (s) metodologas. Se sugiere que tomen una metodologa basada en el Proceso Unificado (UP) de Jacobson, Rumbaugh y Booch (cuya principal versin comercial es el Rational Unified Process RUP).

Sistema de Informacin para el seguimiento acadmico de la Escuela Industrial Pedro Domingo Murillo viaWeb

AQU SE APLICA COCOMO PARA COSTO DE SOFTWARE