INGENIERA DE SOFTWARE II GR 1.

JORGE ALBERTO GLVEZ CORREA

Tabla de contenido
CAPITULO 1: INTRODUCCIN ........................................................................................................ 7 ISO 9000 .................................................................................................................................... 7 SIX SIGMA .................................................................................................................................. 7 NORMA CMMI FOR DEVELOPMENT ......................................................................................... 8 CMMI FOR DEVELOPMENT (CMMI-DEV) .............................................................................. 8 REAS DE PROCESO POR CATEGORA ....................................................................................... 8 ADMINISTRACIN DE PROCESOS .......................................................................................... 8 ADMINISTRACIN DE PROYECTOS ........................................................................................ 9 INGENIERIA ............................................................................................................................ 9 SOPORTE................................................................................................................................ 9 MEJORA DE PROCESOS.............................................................................................................. 9 ACERCA DEL PROCESO DEL MEJORA ....................................................................................... 10 ACERCA DE LOS MODELOS DE MADUREZ. .............................................................................. 11 CAPACIDAD.......................................................................................................................... 11 CAPITULO 3: PEGANDO TODO JUNTO......................................................................................... 12 COMPRENDIENDO LOS NIVELES.............................................................................................. 12 COMPRENDIENDO LOS NIVELES DE MADUREZ....................................................................... 13 NIVEL DE MADUREZ 1: INICIAL ................................................................................................ 14 NIVEL DE MADUREZ 2: ADMINISTRADO. ................................................................................ 14 NIVEL DE MADUREZ 3: DEFINIDO............................................................................................ 14 NIVEL DE MADURES 4: CUANTITATIVAMENTE ADMINISTRADO ............................................ 15 NIVEL DE MADUREZ 5: OPTIMIZADO ...................................................................................... 16 DISTRIBUCIN DE LAS REAS DE PROCESO ENTRE NIVELES DE MADUREZ ............................ 17 NIVEL DE MADUREZ 2: ADMINISTRADO ............................................................................. 17 NIVEL DE MADUREZ 3: DEFINIDO........................................................................................ 17 NIVEL DE MADUREZ 4: CUANTITATIVAMENTE ADMINISTRADO. ....................................... 17 NIVEL DE MADUREZ 5: OPTIMIZADO. ................................................................................. 17 CAPITULO 4 ................................................................................................................................. 17 RELACIONES ENTRE AREAS DE PROCESO .............................................................................. 17 ADMINISTRACIN DE PROCESOS: ........................................................................................... 18 AREAS AVANZADAS DE ADMINISTRACIN DE PROCESOS .................................................... 20 ADMINISTRACIN DE PROYECTOS. ......................................................................................... 21

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA AREAS BSICAS DE ADMINISTRACIN DE PROYECTOS ..................................................... 21 INGENIERA:............................................................................................................................. 25 RECURSIN DE INTERACCIN EN EL PROCESO DE INGENIERA.............................................. 28 SOPORTE ................................................................................................................................. 29 Areas Bsicas de Soporte. ................................................................................................. 29 METAS GENRICAS Y PRCTICAS GENRICAS. ........................................................................ 32 Panorama ............................................................................................................................ 32 Institucionalizacin de procesos ......................................................................................... 32 Proceso realizado. ............................................................................................................... 33 Proceso administrado ......................................................................................................... 33 Proceso definido.................................................................................................................. 33 PRACTICAS Y METAS GENRICAS. ........................................................................................... 57 GG1: cumplir las metas especficas. .................................................................................... 58 GG2: institucionalizar un proceso administrado. ................................................................ 58 Elaboracin CAR. ................................................................................................................. 58 Estimacin por lnea de cdigo. .......................................................................................... 60 Estimacin por puntos de funcin. ..................................................................................... 61 Factores de Complejidad. .................................................................................................... 62 METODO DE ESTIMACION POR PUNTOS DE CASO DE USO. ................................................... 63 SG 2 DESARROLLAR UN PLAN DEL PROYECTO. Pag 412.......................................................... 68 SP 2.1 establecer presupuesto y el cronograma. ................................................................ 68 Subpraticas: ......................................................................................................................... 68 1. 2. 3. 4. 5. 6. Identificar los mayores eventos (puntos de control). ................................................. 68 Identificar las suposiciones del cronograma. .............................................................. 68 Identificar Restricciones. ............................................................................................. 69 Identificar las Dependencias de las Tareas. ................................................................ 69 Establecer y mantener el presupuesto y el cronograma. ........................................... 69 Establecer criterios para acciones correctivas. ........................................................... 69

CPM (CRITICAL PATH METHOD) .............................................................................................. 70 El Diagrama de Gantt .............................................................................................................. 71 El presupuesto del proyecto. .............................................................................................. 72 FLUJO DE CAJA......................................................................................................................... 73 Comentarios: ....................................................................................................................... 74 ACELERACION DE PROYECTOS. ............................................................................................... 74

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Enfoque Estratgico ................................................................................................................ 74 ENFOQUE TACTICO.................................................................................................................. 75 P.E.R.T...................................................................................................................................... 77 PROGRAM EVALUATION AND REVIEW TECHNIQUE. .............................................................. 77 HISTORIA: ............................................................................................................................ 77 LA PREGUNTA DEL PROBLEMA................................................................................................ 79 Nuevo problema:................................................................................................................. 80 P.E.R.T COSTO ......................................................................................................................... 80 LA COTIZACIN........................................................................................................................ 82 Fenmeno de la Contratacin. ................................................................................................ 83 1. 2. 3. 4. Incumplimiento por parte del cliente en los pagos: ................................................... 83 Fecha para congelar requerimientos .......................................................................... 83 Arbitramiento en caso de conflictos ........................................................................... 83 Casos Fortuitos ............................................................................................................ 83

Sobre Impuestos.................................................................................................................. 84 Sobre el AIU ......................................................................................................................... 84 Sobre los Anticipos .............................................................................................................. 84 MANTENIMIENTO DEL SOFTWARE ......................................................................................... 85 1. 2. 3. Correctivo: ................................................................................................................... 85 Cambios en los requerimientos. ................................................................................. 85 Nuevos requerimientos ............................................................................................... 85

REFACTORING ......................................................................................................................... 85 Qu es Refactoring? .......................................................................................................... 85 CAPITULO 1: Ejemplo de Refactoring .......................................................................................... 86 EL PRIMER PASO DEL REFACTORING....................................................................................... 89 Descomponer y Redistribuir el Mtodo Statement () ......................................................... 90 Moviendo el clculo del monto:.......................................................................................... 93 Eliminar Variables Temporales ............................................................................................ 97 Refactoring de la Lgica Condicional Sobre el Tipo de Pelcula (pricecode) con Polimorfismos.................................................................................................................... 100 Capitulo 3: Malos Olores en el Cdigo ...................................................................................... 110 LOS MALOS OLORES DEL SOFTWARE .................................................................................... 110 Cdigo Duplicado .............................................................................................................. 110 Mtodo muy largo............................................................................................................. 111

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Clase Muy Grande. ............................................................................................................ 112 OBSESION PRIMITIVA ............................................................................................................ 112 SENTENCIAS SWITCH ............................................................................................................. 113 JERARQUIAS DE HERENCIA PARALELAS................................................................................. 113 CLASE PEREZOSA ................................................................................................................... 114 GENERALIDAD ESPECULATIVA .............................................................................................. 114 CAMPO TEMPORAL ............................................................................................................... 114 CADENA DE MENSAJES .......................................................................................................... 115 INTIMIDAD INAPROPIADA ..................................................................................................... 115 CLASES ALTERNATIVAS CON DIFERENTES INTERFACES. ....................................................... 116 LIBRERIAS DE CLASES INCOMPLETAS. ................................................................................... 116 CLASES DE DATOS.................................................................................................................. 116 REHUSAR EL LEGADO. ........................................................................................................... 116 COMENTARIOS ...................................................................................................................... 117 Capitulo 6 .................................................................................................................................. 118 METODOS DE COMPOSICION................................................................................................ 118 EXTRACT METHOD ................................................................................................................ 118 MOTIVACION ......................................................................................................................... 119 MECANICA ............................................................................................................................. 119 Ejemplo Usando Variables locales..................................................................................... 121 Ejemplo: Reasignando la Variable Local ............................................................................ 122

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Ilustracin I 3 Dimensiones criticas. ......................................................................................... 10 Ilustracin 2- Figura 4.1 reas Bsicas de Admn. de Procesos. ................................................ 19 Ilustracin 3 reas Avanzadas de Admn. De procesos. ......................................................... 20 Ilustracin 4 reas Bsicas de Admn. de Proyectos............................................................... 22 Ilustracin 5 reas de Proceso Avanzadas de Admn. de Proyectos ...................................... 24 Ilustracin 6 reas de Proceso de Ingeniera ........................................................................... 27 Ilustracin 7 reas Bsicas de soporte ..................................................................................... 30 Ilustracin VIII 4.7 ..................................................................................................................... 31 Ilustracin 9 Grafo Orientado a Flechas. (Est en el cuaderno) ............................................... 70 Ilustracin 10 grafo de actividades .......................................................................................... 74 Ilustracin 11 Nueva actividad ................................................................................................. 75 Ilustracin 12, GRAFO 2 .............................................................................................................. 76 Ilustracin 13: DISTRIBUCIN BETA ............................................................................................ 77 Ilustracin 14: DISTRIBUCION NORMAL ...................................................................................... 77 Ilustracin 15 Grafo actividad PERT. ........................................................................................ 79 Ilustracin 16 Interacciones del mtodo Statemet() .................................................................. 88 Ilustracin 17 diagrama ............................................................................................................ 97 Ilustracin 18 diagrama............................................................................................................... 99

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA 09/08/2011 Swebok reas de conocimiento Requerimientos del sw Diseo del sw Construccin del sw Prueba del sw Mantenimiento del sw Gestin de la configuracin del sw Administracin de la ingeniera sw Proceso de la ingeniera de sw Herramientas y mtodos de ingsw Calidad del sw KA de disciplinas relacionadas X X X X X X X X X IngeSoft I X X X IngeSoft II Lab. Otras Materias

Libro gua: Swebok CMMI Development Refactoring Martin Fowler Ing del software Pressman Parciales: 1. Introduccin de calidad. 2. Planificacin del proyecto. 3. Refactoring. Calidad Edward Demming (4 pasos de calidad) 1. Crear un proceso productivo. Repetible (igual calidad) Documentado (proceso deja de depender de las personas) Mediciones (conocer la calidad) Administrado (cada persona con una funcin) Capacitacin / Entrenamiento 2. La mejora continua (optimizar el proceso).

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Mejora la calidad un poquito cada vez lo que se mejora es el proceso. ( si se mejora el proceso esta mejorara el producto) 3. Enfocarse en el producto (Optimizar el producto). Como se usa el producto? (ergonmica) Usabilidad del sw. 4. Qu ms podemos hacer con lo q sabemos? Innovacin (interdisciplinaridad)

CAPITULO 1: INTRODUCCIN

ISO 9000
Fue creada por fbricas europeas (Enfoque 2)

SIX SIGMA
Creado por fabricas americanas (enfoque 2) ISO 9001 Industria ISO 9002 Servicios ISO 9003 Comercio ISO 9000-3 Software Universidad Carnegie Mellon SEI: Software Engineering Institute CMMI: Capacity Maturity Model Incosesecam. EIA 731 secm. CMM for adquisition. CMM system engineering CMM for services CMM integratedproductdevelopment Todos se integraron en una sola: CMMI: Capacity Maturity Model Integration CMMI for adquisition CMMI fordevelopment CMMI for servicios (prestacin de servicios). 12/08/2011

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA

NORMA CMMI FOR DEVELOPMENT

Ahora ms que nunca las empresas desean entregar productos y servicios mejores msrpidos y ms baratos. Al mismo tiempo, en los ambientes de alta tecnologa del siglo 21 casi todas las organizaciones se encuentras construyendo productos y servicios incrementalmente ms complejo. Comnmente, algunos componentes son construidos en casa y otros son adquiridos, luego todos los componentes sonintegrados en el producto o servicio final. Las organizaciones deben ser hbiles para administrar y controlar estos complejos procesos de desarrollo y mantenimiento. Los problemas que estas organizaciones manejan hoy involucran soluciones a lo ancho de toda la empresa que requieren un enfoque integrado. La administracin efectiva de los activos organizacionales en critica para el xito de los negocios en esencia estas organizaciones son desarrolladores de productos y servicios que necesitan una forma para manejar sus actividades de desarrollo como parte de la adquisicin de sus objetivos de negocio. En los mercados actuales existen modelos de madures estndares metodologas y guas que pueden ayudar a los organizaciones a mejorar la forma de cmo hacen negocios. Sin embargo los enfoques de mejora ms disponibles se concretan en partes especficas del negocio y no toman un enfoque sistemtico de los problemas que estn afectando a la mayora de las organizaciones. Enfocndose en mejorar un rea de negocios, estos modelos han perpetuado infortunadamente los cuellos de botella y barreras que existen en las organizaciones. CMMI FOR DEVELOPMENT (CMMI-DEV) Proporciona una oportunidad para evitar o eliminar estos cuellos de botella y barreras. CMMI-DEV consiste en las mejoras prcticas para mejorar las actividades de desarrollo aplicadas a productos y servicios. Maneja prcticas que cubren el ciclo de vida desde la concepcin hasta la entrega y mantenimiento. El nfasis est en el trabajo necesario para construir y mantener el producto total. CMMI=DEV contiene 22 reas de proceso de esas reas de proceso, 16 son reas de proceso ncleo, 1 es un rea de proceso compartida y 5 son reas de proceso especficas de desarrollo. Todas las prcticas del modelo CMMI-DEV se enfocan en las actividades de la organizacin desarrolladora. Cinco reas de proceso se enfocan en prcticas especficas para el desarrollo: manejando el desarrollo de requerimientos, solucin tcnica, integracin del producto, verificacin y validacin.

REAS DE PROCESO POR CATEGORA

ADMINISTRACIN DE PROCESOS OPD: Organizational Process Definition. OPF: Organizational Process Focus. OPM: Organizational Performance Management. OPP: Organizational Process Performance. OT: Organizational Training.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA ADMINISTRACIN DEPROYECTOS IPM: Integrated Project Management. PMC: Project Monitoring and Control. PP: Project Planning. QPM: Quantitative Project Management. REQM: Requirement Management. RSKM: Risk Management. SAM: SuplirAgrieement Management. INGENIERIA PI: Product Integration. RD: Requirement Development. TS: Technical Solution. VAL: Validation. VER: Verification. SOPORTE CAR: CasualAnlisis and Resolution. CM: Configuration Management. DAR:DeasionAnlisis and Resolution. MA: Measurement and Anlisis. PPQA: Process and Product Quality Assurance.

MEJORA DE PROCESOS
Las procesos son lo que hace la gente en las empresas los procesos son rutinarios, continuos. Los elementos ms importantes de un proceso son: Las personas. Procedimientos y mtodos. Herramientas y equipos.

Los procesos son los que mantienen unidos las diferentes partes de la organizacin. Proyecto Requera Diseo Construccin Prueba A B C D

Pensar en los procesos (y no en los proyectos) tiene ventajas. Se puede pensar en la escalabilidad del proceso Cmo vamos a atender ms proyectos? Se puede pensar en las tendencias mundiales en proceso, Cmo hacer el proceso?, Cmo ahorrar recursos o hacer

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA lo ms rpido? Las mejores empresas del mundo, las ms exitosas, se han enfocado en mejorar sus procesos. Las normas de calidad como ISO 9000 y CMMItambin se enfocan en la mejora de procesos. Siempre se supone que mejorando los procesos se mejoran los productos y servicios que venden la empresa.

16/08/2011

ACERCA DEL PROCESO DEL MEJORA

En su bsqueda para ayudar a las organizaciones a desarrollar y mantener productos y servicios de calidad el software EnginneringInstitute (SEI) ha encontrado varias dimensiones en que las organizaciones se pueden enfocar para mejorar sus negocios.

Ilustracin I 3 Dimensiones criticas.

La Figura 1.1 ilustra 3 dimensiones crticas en las que las organizaciones tpicamente se enfocan: gente, procedimientos y mtodos, herramientas y equipos. Qu mantiene a todos juntos? Son los procesos usados en las organizaciones. Los procesos le permiten alinear la forma como hace negocios. Ellos le permiten manejar la escalabilidad y le proporcionan una forma para incorporar conocimiento de cmo hacer las cosas mejor. Los procesos le permiten a usted nivelar sus recursos y examinar las tendencias del negocio. Esto no quiere decir que la tecnologa y las personas no sean importantes. Estamos viviendo en un mundo donde la tecnologa est cambiando a una increble velocidad. Similarmente, es tpico que las personas trabajen para muchas empresas a lo largo de sus carreras. Vivimos en

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA un mundo dinmico. Un enfoque en procesos proporciona la infraestructura y estabilidad necesarias para manejar un mundo cambiante y maximizar la productividad de las personas y el uso de la tecnologa para ser competitivas. La manufactura desde hace mucho ha reconocido la importancia de la efectividad y eficiencia. Hay muchas organizaciones de manufactura y servicios reconocen la importancia de los procesos de calidad. Los procesos ayudan a la fuerza de trabajo de las organizaciones a cumplir objetivos de negocios ayudndoles a trabajar ms inteligentemente, no ms duro y con una consistencia mejorada. Los procesos efectivos tambin proporcionan un vehculo para introducir y usar la nueva tecnologa en una forma que cumple mejor los objetivos de los negocios de la organizacin.

ACERCA DE LOS MODELOS DE MADUREZ.

CAPACIDAD. Un modelo de madurez capacidad (CMM), incluyendo el CMMI, es una representacin simplificada del mundo. Los CMMs contienen los elementos esenciales de los procesos efectivos. Estos elementos se basan en conceptos desarrollados por Crosby, Deming, Juran y Humphrey. En la dcada de 1930 Walter Schewhartcomenz a trabajar en mejora de procesos con sus principios de control estadstico de la calidad. Estos principios fueron refinados por W. Edwars Deming, Phillip Crosby y Joseph Juran. Watts Humphrey, Ron radice y otros extendieron estos principios msall y comenzaron a aplicarlos en su trabajo en IBM y el SEI el libro de humphreyManagingthe software Process, proporciona una descripcin de los principios y conceptos en los que se basan muchos de los modelos de madurez capacidad. El SEI ha tomado la premisa de administracin de procesos La calidad de un sistema o producto est altamente influenciado por la calidad del proceso usado para desarrollarlo y mantenerloy definido los CMMs de tal manera que encarnaran esa premisa. La creencia de esta premisa se ve en el movimiento de calidad de todo el mundo, como la evidencia de internacional OrganizationforStandarization / Internacional Electrotechinical Comisin. (ISO/IEC) y su cuerpo de estndares. Los CMMs se enfocan en la mejora de procesos en una organizacin. Ellos cuentan con los elementos esenciales de los procesos efectivos de una o ms disciplinas y describen un camino evolutivo de mejora desde las inmaduras procesos Ad Doc hasta los procesos maduros y disciplinados con mejorada calidad y efectividad. El SEI cre el primer CMM diseado para organizaciones de software y publicado en un libro. The Capability Maturity Model: Guidelines for improving the software process. Hoy, CMMI es una aplicacin de los principios introducidos hace casi un siglo para este infinito ciclo de la mejora de procesos. El valor de este enfoque de mejora de procesos ha sido confirmado en tiempo. Las organizaciones han experimentado productividad y calidad

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA incrementadas, tiempo de ciclo mejorado y cronogramas y presupuestos ms predecibles y precisos.

CAPITULO 3: PEGANDO TODO JUNTO

CMMI-DEV no especifica que un proyecto u organizacin deba seguir un flujo de proceso o particular o que cierto nmero se productos sean desarrollados por da o que se adquieran los objetivos especficos de desempeo. El modelo especifica que un proyecto u organizacin debe tener procesos que manejan las prcticas de desarrollo relacionadas. Para determinar si estos procesos estn en su lugar, un proyecto u organizacin mapea sus procesos a las reas de proceso de este modelo. El mapeo de procesos a reas de procesos habilita a la organizacin a seguir su progreso contra el modelo CMMI-DEV a medida que actualiza o crea procesos no espere que cada rea de proceso CMMI-DEV mapee a un proceso de su organizacin o proyecto.

COMPRENDIENDOLOSNIVELES.
Los niveles son usados en CMMI-DEV para describir un camino evolutivo recomendado para una organizacin que desea mejorar sus procesos que usa para desarrollar productos y servicios. Los niveles tambin pueden ser el resultado de la actividad de pronstico en las evoluciones. Las evaluaciones se pueden aplicar a la organizacin entera o a pequeos grupos tales como una divisin o proyecto. El CMMI soporta 2 caminos de mejora usando niveles un camino le permite a la organizacin mejorar los procesos correspondientes a un rea de procesos individual (O grupo de rea de proceso) seleccionadas por la organizacin. El otro camino habilita a las organizaciones a mejorar un conjunto de procesos relacionados manejando incrementalmente sucesivos conjuntos de reas de proceso. Estos dos caminos de mejora se asocian con los dos tipos de niveles: niveles de calidad y niveles de madurez. Estos niveles corresponden a 2 enfoques de mejoras de procesos llamados representaciones. Las dos representaciones son llamadas continua y por etapas. Usando la representacin continua usted queda habilitado para alcanzar niveles de capacidad. Usando la representacin por etapas usted puede alcanzar niveles de madurez.

19/08/2011 En este curso solo estudiaremos la representacin por etapas.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA

COMPRENDIENDO LOS NIVELES DE MADUREZ

Para soportar aquellos que usan representacin por etapas, todos los modelos CMMI reflejan niveles de madures en su diseo y contenido.

Un nivel de madurez consiste de prcticasespecficas y genricas relacionadas para un conjunto de reas de proceso predefinidos que mejoran el desempeo total de la organizacin. Niveles de madurez

rea de Proceso
* *

Metas Genricas

Metas especificas

Practicas Genricas

Practicas Especficas

El nivel de madurez de una organizacin proporciona una forma para caracterizar su desempeo. La experiencia ha demostrado que las organizaciones hacen lo mejor que pueden cuando sus esfuerzos de mejora se enfocan en un numero manejable de reas de proceso en un tiempo determinado y que esas reas de proceso requieren incrementos en la sofisticacin a medida que la organizacin mejora. Un nivel de madurez es una etapa evolutiva para el proceso de mejora organizacional. Cada nivel de madurez madura un subconjunto importante de procesos organizacionales preparando la organizacin para moverse al siguiente nivel. Los niveles de madurez son medidas por la adquisicin (cumplimiento) de las metas especficas y genricas asociadas con cada conjunto de reas de proceso predefinido. Los cinco niveles de madurez, cada uno capa en el fundamento para el proceso de mejora en ejecucin, esta designacin por un nmero del 1 al 5. 1. inicial. 2. administrado. 3. definido.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA 4. cuantitativo / administrado. 5. optimizado.

NIVEL DE MADUREZ 1: INICIAL

En este nivel los procesos son usualmente ad doc y caticos. La organizacin usualmente no proporciona un ambiente estable para soportar los procesos. El xito en estas organizaciones depende de la competencia y herosmo de las personas de la organizacin y no del uso de procesos probados. A pesar del caos en el nivel de madurez uno las organizaciones a menudo producen productos y servicios que trabajan pero frecuentemente exceden el presupuesto y el cronograma documentados en sus planes. En este nivel las organizaciones son caracterizadas por sus tendencias a sobre cumplir, abandonar sus procesos en tiempos de crisis y ser inhbiles para repetir sus xitos.

NIVEL DE MADUREZ 2: ADMINISTRADO.

En este nivel, los proyectos han asegurado que los procesos son planeados y ejecutados de acuerdo a una poltica los proyectos emplean a personas habilidosas quienes tienen recursos adecuados para producir salidas controlados; involucran actores relevantes son monitoreados, controlados y revisados, y se evala su adherencia a la descripcin de los procesos. La disciplina de procesos reflejada por el nivel de madurez ayuda a asegurar que las prcticas existentes sean retenidas durante los tiempos difciles. Cuando estas prcticas estn en su lugar los proyectos son realizados y administrados de acuerdo con sus planes documentados. Tambin en el nivel de madurez 2 el estado de los productos de trabajo es visible para es la administracin en puntos definidos. (Ej. Puntos de control al terminar las mayores tareas). Se establecen acuerdos con los principales actores (stakeholders personas interesadas) los cuales se revisan cada vez que se necesiten. Los productos de trabajo son apropiadamente controlados, los productos de trabajo y servicios satisfacen las descripciones de su especificacin, estndares y procedimientos.

NIVEL DE MADUREZ 3: DEFINIDO

En el nivel de madurez 3 los procesos son bien caracterizados y comprendidos y descritos con estndares, procedimientos, herramientas y mtodos. El conjunto de procesos estndar de la organizacin que es la base para el nivel de madurez 3 es establecido y mejorado a travs del tiempo.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Estos procesos estndar son usados para establecer consistencias a travs de toda la organizacin, los proyectos establecen sus procesos definidos manipulando el conjunto de procesos estndar de la organizacin de acuerdo con unas gulas de manipulacin. Una distincincrtica entre los niveles de madurez 2 y 3 es el alcance de los estndares, descripciones de procesos y procedimientos. El nivel de madurez 2 los estndares, descripciones de procesos y procedimientos pueden ser bastante diferentes en cada estancia especifica de los procesos, es decir en cada estancia especifica de los procesos, es decir cada proyecto particular. En el nivel de madurez 3 los estndares, descripcin de procesos y procedimientos para un proyecto son obtenidos a partir del conjunto de procesos estndar de la organizacin para adaptarlos al proyecto en particular o unidad organizacional y ser entonces ms consistentes excepto por las diferencias permitidas en las guas de manipulacin. Otra distincin critica en que en el nivel de madurez 3 los procesos se describen de una manera ms rigurosa que en el nivel de madurez 2, un proceso definido claramente establece: el propsito. Entradas. Criterios de entrada. Actividades. Roles. Mediciones. Pasos de verificacin. Salidas y criterios de salida.

En el nivel de madurez 3 los procesos son administrados ms proactivamente usando una comprensin de las interrelaciones entre los procesos y sus actividades, mediciones detalladas del proceso, sus productos del trabajo y sus servicios. En el nivel de madurez 3 la organizacin mejora mucho ms los procesos que estn relacionados con el nivel de madurez 2, las practicas genricas asociadas con las metas genricas del nivel 3 que no fueron manejadas en el nivel 2 ahora son aplicadas para poder alcanzar el nivel de madurez 3.

22/08/2011

NIVEL DE MADURES 4: CUANTITATIVAMENTE ADMINISTRADO

En el nivel de madurez 4, la organizacin y los proyectos establecen objetivos cuantitativos para la calidad y el desempeo de los procesos y los usan como criterios para administrar los proyectos. Los objetivos cuantitativos se basan en las necesidades del cliente, usuarios finales, la organizacin y los implementadores del proceso. La calidad y el desempeo de los procesos son comprendidos en trminos estadsticos y se administran a lo largo de la vida del proyecto.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Para subprocesos seleccionados se coleccionan mediciones especficas del desempeo del proceso y se analizan estadsticamente. Cuando seleccionar subprocesos para anlisis es clave para comprender las relaciones entre diferentes subprocesos y su impacto en el alcance de los objetivos de calidad y desempeo de los procesos. Tal enfoque ayuda a asegurar que los subprocesos se monitorean usando estadsticas y otras tcnicas cuantitativas y que esto se aplica donde tiene ms valor para la empresa. Las lneas base y modelos de desempeo de los procesos pueda ser usados para ayudar a colocar los objetivos de calidad y desempeo de los procesos que ayudan a alcanzar los objetivos de negocios. Una distincin crtica entre los niveles de madurez 3 y 4 es la predictibilidad del desempeo de los procesos. En el nivel de madurez 4, el desempeo de los proyectos y subprocesos seleccionados es controlado usando estadsticas y otras tcnicas cuantitativas y las predicciones se basan en parte, en el anlisis estadstico de grano fino de los datos de los procesos.

NIVEL DE MADUREZ 5: OPTIMIZADO

En el nivel de madurez 5, una organizacin mejora continuamente sus procesos con base en una comprensin cuantitativa de sus objetivos de negocios y necesidades de desempeo. La organizacin usa un enfoque cuantitativo para comprender la variacin inherente de los procesos y las causas de los resultados de los procesos. El nivel de madurez cinco se enfoca en mejorar continuamente el desempeo de los procesos a travs de mejoras incrementales de los procesos e innovaciones tecnolgicas. Los objetivos de calidad de la organizacin y de desempeo de los procesos son establecidos y revisados continuamente para reflejar los cambiantes objetivos de los negocios y desempeo organizacional, y usados como criterios en la administracin de procesos de mejora. Los efectos de desplegar las mejoras de los procesos usando estadsticas y otras tcnicas cuantitativas miden y compran con los objetivos de calidad y desempeo de los procesos. Los procesos definidos del proyecto, el conjunto de procesos estndar de la organizacin y el soporte tecnolgico son objeto de actividades de mejoras medibles. Una distincin crtica entre los niveles de madurez 4 y 5 es el enfoque en administrar y mejorar el desempeo organizacional. En el nivel de madurez 4 la organizacin y los proyectos se enfocan en comprender y controlar el desempeo a nivel de subprocesos y usar los resultados para administra los proyectos. En el nivel de madurez 5 la organizacin se preocupa por el desempeo organizacional total usando datos coleccionados de mltiples proyectos. El anlisis de los datos identifica cadas grietas en el desempeo. Estas grietas son usadas para manejar el proceso de mejora organizacional para generar mejoras medibles en el desempeo.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA

DISTRIBUCIN DE LAS REAS DE PROCESO ENTRE NIVELES DE MADUREZ

NIVEL DE MADUREZ 2: ADMINISTRADO CM: Gestin de la configuracin. MA: Medicin y Anlisis. PMC: Monitoreo y Control de Procesos. PP: Planeacin de Proyectos. PPQA: Aseguramiento de la Calidad del Proceso y el Producto. REQM: Administracin de Requerimientos. SAM: Administracin de Acuerdos con los Proveedores. NIVEL DE MADUREZ 3: DEFINIDO. DAR: Anlisis de Decisiones y Resolucin. IPM: Administracin Integrada del Proyecto. OPD: Definicin de Proceso Organizacional. OPF: Enfoque del proceso Organizacional. OT: Entrenamiento Organizacional. PI: Integracin del Producto. RD: Desarrollo de Requerimientos RSKM: Administracin del Riesgo. TS: Solucin Tcnica. VAL: Validacin. VER: Verificacin. NIVEL DE MADUREZ 4: CUANTITATIVAMENTE ADMINISTRADO. OPP: Desempeo de Proceso Organizacional. QPM: Administracin Cuantitativa de Proyectos. NIVEL DE MADUREZ 5: OPTIMIZADO. CAR: Anlisis Causal y Resolucin. OPM: Administracin de Desempeo Organizacional. 23/08/2011

CAPITULO 4
RELACIONES ENTRE AREAS DE PROCESO En este captulo describimos las relaciones clave entre reas de proceso para ayudar a ver la visin de la organizacin, de las areas de proceso y su mejora, y cmo las reas de proceso dependen de la implementacin de las otras areas de proceso. Las relaciones entre mltiples areas de proceso, incluyendo la informacin y artefactos que fluyen de un rea de proceso a otra ilustradas por figuras y descripciones en este captulo le ayudaran a ver un panorama de la implementacin y mejora de los procesos. Las iniciativas de mejora de procesos exitosas deben ser manejadas por los objetivos de negocios de la organizacin. Por ejemplo, un objetivo de negocios comn es reducir el tiempo

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA que toma poner un producto en el mercado. El objetivo de mejora de procesos derivado de este podra ser mejorar el proceso de administrar el proyecto para asegurar una entrega a tiempo; estas mejoras se basan en las mejores prcticas de las reas de proceso planeacin de proyectos y monitoreo y control de proyectos. Aunque en este captulo agrupamos las reas de proceso para simplificar la discusin de sus interrelaciones, las reas de proceso a menudo interactan y tienen un efecto unas sobre otras, sin importar su grupo, categora o nivel. Por ejemplo, el rea de procesos Anlisis de Decisiones y Resolucin (un rea de proceso de soporte, del nivel de madurez 3) contiene prcticas especficas que manejan el proceso de evaluacin formal usado en el rea de procesos solucin tcnica para seleccionar una solucin tcnica de conjunto de alternativas de solucin. Ser consciente de las relaciones clave que existen entre las reas de proceso del CMMI le ayudar a aplicar el CMMI en forma til y productiva. Las reas de proceso se agrupan en las siguientes categoras: 1. Administracin de Procesos. 2. Administracin de Proyectos. 3. Ingeniera. 4. Soporte. Adems dentro de cada categora, las reas de proceso se dividen en dos grupos: a. reas Bsicas. b. reas Avanzadas.

ADMINISTRACIN DE PROCESOS:
Las reas de proceso de la administracin de procesos contienen las actividades transversales a los proyectos, relacionadas con definir, planear, desplegar, implementar monitorear, controlar, evaluar, medir y mejorar procesos. Las cinco reas de proceso de Administracin de Procesos en CMMI-DEV son las siguientes: Definicin de Proceso Organizacional (OPD). Enfoque de Proceso Organizacional (OPF). Administracin del Desempeo Organizacional (OPM). Entrenamiento Organizacional (OT). Desempeo de Proceso Organizacional (OPP). reas bsicas de administracin de procesos proporcionan a la organizacin la capacidad para documentar y compartir las mejores prcticas, activos de procesos organizacionales y aprendizaje a lo ancho de toda la organizacin. La figura 4.1 proporciona una vista a vuelo de pjaro de las interacciones entre las reas bsicas de administracin de procesos y las otras categoras de reas de proceso.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Como se ilustra en la figura 4.1, el rea de proceso Enfoque de Proceso Organizacional (OPF) ayuda a la organizacin a planear, implementar y desplegar mejoras de procesos organizacionales basadas en una comprensin de las fortalezas y debilidades de los procesos y activos de procesos de la organizacin.

Ilustracin 2- Figura 4.1 reas Bsicas de Admn. de Procesos.

Los candidatos a mejora de procesos de la organizacin se obtienen a partir de varias fuentes. Estas actividades incluyen propuestas de mejora de procesos, medicin de los procesos, lecciones aprendidas en la implementacin de los procesos y resultados de la evaluacin de los procesos y de los productos. El rea de procesos Definicin de Procesos Organizacional establece y mantiene el conjunto de procesos estndares de la organizacin, estndares de ambiente de trabajo y otros activos basados en las necesidades de los procesos y objetivos de la organizacin. Estos otros activos incluyen descripciones de modelo de ciclo de vida, guas de manipulacin de procesos, documentacin y datos relacionados con los procesos. Los proyectos manipulan el conjunto de procesos estndar de la organizacin para crear sus procesos definidos. Los otros activos soportan la manipulacin as como la implementacin de los procesos definidos. Las experiencias y productos de trabajo de realizar estos proyectos definidos, incluyendo datos de mediciones, descripciones de procesos, artefactos de procesos y lecciones aprendidas, son

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA incorporados de la manera apropiada dentro del conjunto de procesos estndar de la organizacin y otros activos. El rea de procesos Entrenamiento Organizacional identifica las necesidades estratgicas de entrenamiento de la organizacin, as como las necesidades tcticas de entrenamiento que son comunes a travs de los proyectos y grupos de soporte. En particular el entrenamiento es desarrollado u obtenido para desarrollar las habilidades requeridas para realizar el conjunto de procesos estndar de la organizacin. Los componentes principales del entrenamiento incluyen un programa de desarrollo de entrenamiento administrado, planes documentados, personal con los conocimientos adecuados y mecanismos para medir la efectividad del programa de entretenimiento. 26/08/09

AREAS AVANZADAS DE ADMINISTRACIN DE PROCESOS

Ilustracin 3 reas Avanzadas de Admn. De procesos.

Las reas avanzadas de administracin de procesos proporcionan a la organizacin una capacidad mejorada para alcanzar los objetivos cuantitativos de calidad y desempeo de los procesos. La figura 4.2 proporciona una vista a vuelo de pjarode las interacciones entre las reas avanzadas de administracin de procesos y las otras categoras de reas de proceso. Cada una de las reas avanzadas de administracin de procesos depende de la habilidad para desarrollar y desplegar procesos y activos de soporte. Las reas bsicas de administracin de procesos proporciona esta habilidad.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Como se ilustra en la figura 4.2 el rea de proceso Desempeo de Procesos Organizacional (OPP) deriva objetivos cuantitativos para la calidad y desempeo de los procesos a partir de los objetivos de negocio de la organizacin. La organizacin proporciona a los proyecto y grupos de soporte mediciones comunes, lneas base para desempeo de los procesos y modelos de desempeo de los procesos Estos activos adicionales de la organizacin son de soporte y componen un proceso definido que puede alcanzar los objetivos de calidad y desempeo del proceso y soportar la administracin cuantitativa. La organizacin analiza los datos de desempeo de los procesos coleccionados a partir de estos procesos cuantitativa de la calidad del producto, calidad del servicio y desempeo del proceso del conjunto de procesos estndar de la organizacin. En la Administracin del Desempeo Organizacional (OPM), las lneas base y modelos del desempeo de los procesos son analizadas para comprender la habilidad de la organizacin para cumplir sus objetivos de negocios y para derivar los objetivos de calidad y desempeo de los procesos. Con base en esta comprensin la organizacin selecciona y despliega proactivamente mejoras incrementales e innovadoras que mejoran mensurablemente el desempeo de la organizacin. La seleccin de las mejoras a desplegar se basa en una comprensin cuantitativa de los probables beneficios y costos predichos de las mejoras candidatas a ser desplegadas la organizacin tambin puede ajustar objetivos de negocios y los objetivos de calidad y desempeo de los procesos como sea apropiado.

ADMINISTRACIN DE PROYECTOS.
Las reas de proceso de administracin de proyectos cubren las actividades de administracin de los proyectos relacionadas con planear, monitoreas y controlar el proyecto. Las siete reas de proceso de Administracin de Proyectos en el CMMI-DEV son las siguientes: Administracin Integrada de Proyectos (IPM). Control y Monitoreo de Proyectos (PMC). Planeacin de Proyectos (PP). Administracin cuantitativa de proyectos (QPM). Administracin de Requerimientos (REQM). Administracin de los Riesgos (RSKM). Administracin de Acuerdos con Proveedores (SAM).

AREAS BSICAS DE ADMINISTRACIN DE PROYECTOS Manejan las actividades relacionadas con establecer y mantener el plan del proyecto, establecer y mantener compromisos, monitorear el progreso contra el plan, tomar acciones correctivas y administrar acuerdos con los proveedores. La figura 4.3 proporciona una vista a vuelo de pjaro de las interacciones entre las reas de proceso de Administracin de Proyectos y las otras categoras de reas de proceso. Como se ilustro en la figura 4.3 el rea de proceso. Planeacin de Proyectos incluye el desarrollo del

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA plan del proyecto, involucrar a los actores relevantes, obtener compromisos para el plan y mantener el plan. La planeacin comienza con los requerimientos que definen el producto y el proyecto (Qu construir en la figura 4.3). El plan del proyecto cubre varias actividades de administracin del proyecto y desarrollo realizadas por el proyecto. El proyecto revisa otros planes que lo afectan a partir de varios actores relevantes y establece compromisos con esos actores para sus contribuciones al proyecto.

Ilustracin 4 reasBsicas de Admn. de Proyectos

Por ejemplo, estos planes cubren la administracin de la configuracin verificacin, mediciones y anlisis. El rea de proceso Monitoreo y Control de Proyectos contiene prcticas para monitorear y controlar actividades y tomar acciones correctivas. El plan del proyecto especifica la frecuencia de las revisiones de progreso y las mediciones usadas para monitorear el progreso. El progreso se determina primariamente comparando el estado del proyecto con el plan. Cuando el estado actual se desva significativamente de los valores esperados se toman las acciones correctivas apropiadas. De estas acciones puede influir el replanteamiento, lo que requiere usar prcticas de planeacin de los proyectos.

29/08/2011

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA El rea de procesos Administracin de Requerimientos, mantiene los requerimientos. Describe actividades para obtener y controlar cambios a los requerimientos y asegurar que otros planes y datos relevantes se mantienen actualizados. Proporciona trazabilidad de los requerimientos desde los requerimientos del cliente hasta los requerimientos de componentes del producto. La administracin de los requerimientos asegura que los cambios a los requerimientos son reflejados en los planes del proyecto, actividades y productos de trabajo. Este ciclo de cambios puede afectar las reas de proceso de ingeniera; luego, la administracin de requerimientos es y dinmica y a menudo una secuencia recursiva de eventos. El rea de proceso de Administracin de requerimientos es fundamental para controlar y disciplinar el proceso de ingeniera. El rea de procesos Administracin de acuerdos con proveedores (SAM)maneja la necesidad de los proyectos de adquirir aquellas porciones del trabajo que son producidas por los proveedores. Las fuentes de productos que pueden ser usadas para satisfacer los requerimientos del proyecto son identificadas prcticamente. El proveedor es seleccionado y acuerdos con el proveedor son establecidos para administrar al proveedor. El progreso y desempeo del proveedor son seguidos como se especifique en los acuerdos con el proveedor, y los acuerdos con el proveedor se revisan cada vez que sea apropiado. Las pruebas y revisiones de aceptacin son conducidas sobre el componente de producto producido por el proveedor. reas de proceso avanzadas de Administracin de Proyectos. Manejan actividades tales como, establecer un proceso definido que es obtenido manipulando el conjunto de procesos estndar de la organizacin, estableciendo el ambiente de trabajo del proyecto a partir de los estndares de ambiente de trabajo de la organizacin, coordinando y colaborando con los actores relevantes, formando y sosteniendo grupos para la conduccin de los proyectos, administrando cuantitativamente el proyecto y administrando los riesgos. La figura 4.4 proporciona una vista a vuelo de pjaro de las interacciones entre las reas de proceso avanzadas de Administracin de proyectos y las dems categoras de reas de proceso. Cada rea de proceso Avanzada de Administracin de proyectos depende de la habilidad para planear, monitorear y controlar el proyecto. Las reas de proceso bsicas de administracin de proyectos proporcionan esta habilidad.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA

Ilustracin 5 reas de Proceso Avanzadas de Admn. de Proyectos

El rea de proceso Administracin Integrada de proyectos (IPM) establece y mantiene los procesos definidos del proyecto que son obtenidos manipulando el conjunto de procesos estndar de la organizacin (Definicin de proceso organizacional). El proyecto es administrado usando los procesos definidos del proyecto. El proyecto usa y contribuye a los activos de procesos de la organizacin, el ambiente de trabajo del proyecto es establecido y mantenido a partir de los estndares de ambiente de trabajo de la organizacin, y los grupos son establecidos usando las reglas y guas de la organizacin. Los actores relevantes del proyecto coordinan sus esfuerzos de una manera sincronizada a travs de la identificacin, negociacin y seguimiento de dependencias crticas y la resolucin de temas de coordinacin. Aunque la identificacin y monitoreo de los riesgos son cubiertos en las reas de proceso Planeacin de Proyectosy Monitoreo y control de los procesos, el rea de procesos Administracin de los Riesgos toma un enfoque continuador de mirada adelantada para administrar los riesgos con actividades que incluyanidentificacin de parmetros de los riesgos, evaluacin de los riesgos y mitigacin de los riesgos. El rea de proceso administracin cuantitativa de proyectos QPM establece objetivos de calidad y desempeo de los procesos, componen proceso definido que puede ayudar a cumplir esos objetivos y administrar cuantitativamente el proyecto. Los objetivos de calidad y desempeo de los procesos se basan en los objetivos establecidos por la organizacin y los clientes.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Los procesos definidos del proyecto se componen usando estadsticas y otras tcnicas cuantitativas. Tal anlisis habilita al proyecto para predecir, si cumplir sus objetivos cuantitativos de calidad y desempeo. Con base en la prediccin, el proyecto puede ajustar sus procesos definidos o negociar cambios a los objetivos de calidad y desempeo del proceso. A medida que el proyecto progresa, el desempeo de subprocesos seleccionados es monitoreado cuidadosamente, para ayudar a evaluar si el proyecto que est en seguimiento cumplir sus objetivos.

INGENIERA:
Cubre las actividades de desarrollo y mantenimiento que se comparten a travs de la disciplina de ingeniera. Las reas de proceso de ingeniera fueron escritos usando una terminologa general de ingeniera de tal manera que cualquier disciplina tcnica involucrada en el desarrollo de los productos (ej.: Ingeniera de software, ingeniera mecnica) pueda usarlas para mejorar sus procesos. Las reas de proceso de ingeniera tambin integran los procesos asociados con diferentes disciplinas de ingeniera en un solo proceso de desarrollo de productos, soportando una estrategia de mejora de procesos orientada al producto. 30/08/2011 Tal estrategia apunta a objetivos esenciales del negocio en vez de apuntara las disciplinas tcnicas. Este enfoque hacia la efectividad de los procesos evita la tendencia hacia una mentalidad organizacional cuello de botella. Las reas de proceso de ingeniera aplica al desarrollo de cualquier producto o servicio en el dominio del desarrollo (ej. productos de software, productos de hardware, servicios, procesos). Las cinco reas de proceso de ingeniera en CMMI-DEV son: Integracin de Producto (PI). Desarrollo de Requerimientos (RD). Solucin Tcnica (TS). Validacin (VAL). Verificacin (VER).

La figura 4.5 proporciona una vista a vuelo de pjaro de las interacciones entre las cinco reas de proceso de ingeniera. El rea de proceso Desarrollo de Requerimientos (RD) identifica las necesidades del cliente y traduce estas necesidades en requerimientos del producto. El conjunto de requerimientos del

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA producto es analizado para producir una solucin conceptual de alto nivel. Este conjunto de requerimientos es entonces localizado para establecer un conjunto inicial de requerimientos de componentes del producto. Otros requerimientos que pueden ayudar a definir el producto son derivados y localizados en componentes del producto. Este conjunto de requerimientos del producto y de componentes del producto describe claramente el desempeo del producto, atributos de calidad, caractersticas de diseo, requerimientos de verificacin, etc. en trminos que el desarrollador comprende y usa. El rea de procesos de desarrollo de requerimientos suministra requerimientos al rea de proceso Solucin Tcnica (TS), donde los requerimientos con convertidos en la arquitectura del producto, diseo de componentes del producto (por codificacin fabricacin). Los requerimientos tambin son suministrados al rea de procesos Integracin del Proceso (PI), donde los componentes del producto son combinados y las interfaces son verificadas para asegurarse de que cumplan los requerimientos de interfaz suministrados por Desarrollo de Requerimientos. El rea de procesos SolucinTcnica (TS) desarrolla paquetes de datos tcnicos para los componentes del producto ser usados por Integracin del Producto Administracin de Acuerdos con Proveedores. Las soluciones alternativas son examinadas para seleccionar el diseo ptimo con base en los criterios establecidos. Estos criterios pueden ser significativamente diferentes a travs de los productos, dependiendo del tipo de producto, ambiente operacional, requerimientos de desempeo, requerimientos de soporte, costo y cronogramas de entrega. La tarea de seleccionar la solucin final hace uso de prcticas especficas en las reas de proceso Anlisis de Decisiones y Resolucin.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA

Ilustracin 6 reas de Proceso de Ingeniera

El rea de procesos SolucinTcnica (TS) descansa sobre las prcticasespecficas del rea de procesos de Verificacinpara realizar la verificacin del diseo y la revisin de pares durante el diseo y antes de construir el producto final. El rea de procesos Verificacin (VER) asegura que los productos de trabajo seleccionados cumplen los requerimientos especificados. El rea de procesos verificacin selecciona los productos de trabajo y mtodos de verificacin que sern usados para verificar los productos de trabajo contra los requerimientos especificados. La verificacin es generalmente un proceso incremental, comenzando con la verificacin de componentes del producto y usualmente concluyendo con la verificacin de los productos completamente ensamblados. La verificacin tambin maneja revisin de pares. Este es un mtodo probado para eliminar defectos temprano y proporciona valiosos conocimientos de los productos de trabajo y componentes del producto siendo desarrollados y mantenidos. El rea de procesos Validacin valida incrementalmente los productos contra las necesidades de los clientes. La validacin puede ser realizar en el ambiente operacional en un ambiente operacional simulado. La coordinacin con el cliente sobre los requerimientos de la validacin es un elemento importante dentro de esta rea de proceso. 02/09/2011 El alcance del rea de procesos Validacinincluye la validacin de productos, componentes de productos, productos de trabajo intermedio seleccionado, y proceso. Estos elementos

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA validados a menudo pueden requerir verificacin y revalidacin. Los temas descubiertos durante la validacin usualmente son resueltos en las reas de proceso desarrollo de requerimientos o solucin tcnica. El rea de procesos Integracin de Producto contiene las prcticasespecficas relacionadas con generar una estrategia de integracin, integrando componentes de productos, y entregando el producto al cliente. La integracin de productos usa prcticasespecficas de verificacin y validacin implementando el proceso de integracin de productos. Las prcticas de verificacin, verifican las interfaces y requerimientos de interfaz de los componentes del producto antes de la integracin. La verificacin del interfaz es un evento esencial en el proceso de integracin. Durante la integracin del producto en el ambiente operacional, se usan las prcticasespecficas de validacin.

RECURSINDE INTERACCIN EN EL PROCESO DE INGENIERA

La mayora de los estndares de procesos estn de acuerdo en que hay dos formas como se pueden aplicar los procesos. Estas dos formas se llaman iteracin y recursin. La recursin ocurre cuando un proceso es aplicado a niveles sucesivos de elementos del sistema dentro de la estructura de un sistema. Los resultados de una aplicacin son usados como entrada en el siguiente nivel en la estructura del sistema. Por ejemplo. El proceso de verificacin estdiseado para aplicarse al producto entero ensamblado, a los mayores componentes del producto, y aun a componentes de componentes. Que tan lejos dentro del producto usted aplica el proceso de verificacin depende enteramente del tamao y complejidad del producto final. La iteracin ocurre cuando los procesos son repetidos al mismo nivel des sistema. La nueva informacin que es creada por la implementacin de un proceso, retroalimenta informacin hacia a tras a un proceso relacionado. Requerimientos Diseo Construccin

Prueb as

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Esta nueva informacin, tpicamente origina preguntas que deben ser resueltas antes de terminar el proceso. Por ejemplo, la iteracin ocurre con mayor probabilidad entre en desarrollo de requerimientos y solucin tcnica. La re aplicacin del proceso puede resolver las preguntas que surgieron. La iteracin puede asegurar la calidad antes de aplicar al siguiente proceso. Los procesos de Ingeniera (ej. Desarrollo de Requerimientos, Verificacin) son implementados repetidamente sobre un producto. Para asegurar que estos procesos de ingeniera han sido adecuadamente manejados antes de la entrega al cliente. Es ms, los procesos de ingeniera son aplicados a componentes de los productos, por ejemplo, algunas preguntas surgieron por procesos asociados con la verificacin y la validacin, pueden ser resueltos por procesos asociados con desarrollo requerimientos o integracin de productos. La recusacin y la interaccin de estos procesos habilitan al proyecto para asegurar la calidad en todos los componentes del producto antes de que sea entregado al cliente. Las reas de proceso de administracin de proyectos podran tambin ser recursivas porque muchas veces los proyectos estn anidados dentro de proyectos.

SOPORTE
Cubre las actividades que soportan el desarrollo y mantenimiento del producto. Las reas de soporte manejan procesos que son usados en el contexto de realizar otros procesos. En general, las reas de proceso de soporte apuntan hacia el proyecto y pueden manejar procesos que se aplican generalmente a una organizacin. Por ejemplo, el Aseguramiento de la calidad del proceso y el producto (PPQA) pueden ser usados con todas las reas de proceso para proporcionar una evaluacin objetiva de los procesos y productos de trabajo descritos en todas las reas de proceso. Las cinco reas de proceso de soporte en CMMI-DEV son: Anlisis casual y resolucin (CAR). Administracin de la configuracin (CM). Anlisis de Decisiones y Resolucin (DAR). Medicin y Anlisis (MA). Aseguramiento de la calidad de proceso y el producto (PPQA).

AreasBsicas de Soporte. Manejan funciones de soporte fundamentales que son usadas por todas las reas de proceso. Aunque las reas de proceso de soporte se basan en las otras reas de proceso para la entrada, las reas de procesos bsicas de soporte proporcionan funciones de soporte que tambin ayudan a implementar varias prcticas genricas.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA La figura 4.6 proporciona una visita a vuelo de pjaro de las interacciones entre las reas de proceso bsicas de soporte y las otras reas deproceso. El reade proceso Medicin y Anlisis soporta a todas las PA (reas de proceso) proporcionando practicas especficas que guan a los proyectos y a las organizaciones a alinear sus necesidades de medicin y objetivos con un enfoque de medicin que es usado para soportar las necesidades de informacin de la admn. El resultado puede ser usado para tomar decisiones informadas y tomar las acciones correctivas apropiadas.

Ilustracin 7 reas Bsicas de soporte

El PA Aseguramiento de la calidad del proceso y el producto (PPQA) soporta a todas las PAS proporcionando prcticasespecficas para evaluar objetivamente los procesos realizados, productos de trabajo y servicios contra las descripciones de procesos aplicables, estndares y procedimientos y asegurando que cualquier tema que surja de estas evaluaciones ser manejado. PPQA soporta la entrega de productos de alta calidad y servicios, proporcionando al personal del proyecto y a toda la admn. la visibilidad apropiada adentro y la retroalimentacin de los procesos y productos de trabajo asociados a travs de la vida del proyecto.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA 05/09/2011 PPQA soporta la entrega de productos y servicios de alta calidad proporcionando al proyecto y a al personal de todos los niveles de la administracin la apropiada visibilidad adentro y la retroalimentacin de los procesos y productos de trabajo asociados a travs de la vida del proyecto. El PA Administracin de la configuracin soporta a todas las PA estableciendo y manteniendo la integridad de todos los productos de trabajo usando identificacin de la configuracin control de la configuracin contabilidad del estado de la configuracin y auditoras de la configuracin. Los productos de trabajo ubicados bajo la administracin de la configuracin incluyen los productos que son entregados al cliente, productos de trabajo diseados internamente, productos adquiridos, herramientas y otros tems que son usados al crear y describir estos productos de trabajo. Ejemplos de productos de trabajo que puedan ser ubicados bajo la administracin de la configuracin incluyen planes, descripcin de procesos, requerimientos, datos de diseo, diagramas especificaciones del producto, cdigo, compiladores, archivos de datos del producto, y publicaciones tcnicas del producto. PA Avanzadas de soporte proporcionan al proyecto y a organizacin una capacidad mejorada de soporte. Cada una de estas PA se basa en entradas especficas o practicas de otros PA.

Ilustracin VIII 4.7

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA La figura 4.7 proporciona una vista a vuelo de pjaro de las interacciones entre los PA avanzados de soporte y otros PA. Usando la PA Anlisis causal y resolucin (CAR), los miembros del proyecto identifican cusas de resultados seleccionados y toman acciones para prevenir los resultados negativos en el futuro o para nivelar resultados positivos. Mientras los procesos definidos del proyecto son inicialmente apuntados como la causa raz que se analiza y tomar planes de accin los cambios efectivos a los procesos pueden resultar en las propuestas de mejora enviados al conjunto de procesos estndar de la organizacin. El PA Anlisis de decisiones y resolucin (DAR) soporta a todas las reas de proceso determinando que temas deben ser sujetos a evaluacin formal y entonces aplicando el proceso de evaluacin formal a esos temas.

METAS GENRICAS Y PRCTICAS GENRICAS.

Panorama Esta seccin describe en detalle todas las metas y prcticas genricas de los componentes del modelo CMMI que manejan directamente la institucionalizacin de procesos. A medida que usted maneje cada rea de procero, refirase a esta seccin para los detalles de todas las prcticas genricas. Las elaboraciones de prcticas genricas aparecen despus de las practicas genricas para proporcionar una gua de cmo la practica genrica puede ser aplicada de manera individual a las reas de proceso. Institucionalizacin de procesos La institucionalizacin es un concepto importante en la mejora de procesos. Cuando se menciona en las metas genricas y practicas genricas, la institucionalizacin implica que el proceso esta engranado en la forma como el trabajo es realizado y hay compromisos y consistencia para realizar el proceso. Un proceso institucionalizado es ms probable que sea retenido durante los tiempos de estrs. Cuando los requerimientos y objetivos de los procesos cambian, sin embargo, la implementacin de los procesos podra tambin necesitar cambiar, para asegurarse de que permanece efectiva. Las prcticas genricas describen actividades que manejan estos aspectos de la institucionalizacin. El grado de institucionalizacin est encarnado en las metas genricas y es expresada en los nombres de los procesos asociados con cada meta como se indica en la tabla. Meta Genrica GG1 GG2 Progresin de Procesos Proceso Realizado Proceso Administrado

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA GG3 Proceso Definido (GG = GenericGoal)

La progresin de la institucionalizacin de procesos est caracterizada en las siguientes descripciones de cada proceso. Proceso realizado. Un proceso realizado es aquel que cumple con el trabajo necesario para satisfacer las metas especficas de una PA. Proceso administrado Un proceso administrado es un proceso realizado que es planeado y ejecutado de acuerdo con una poltica; emplea personas habilidosas que tiene recursos adecuados para producir salidas controladas, involucra a los actores relevantes; es monitoreado, controlado y revisado; y es evaluado para ver su adherencia a la descripcin del proceso. El proceso puede ser instanciado por un proyecto grupo o funcin organizacional la administracin del proceso se preocupa de la institucionalizacin y adquisicin de otros objetivos especficos establecidos por el proceso, tales como costo, cronograma y objetivos de calidad. El control proporcionado por un proceso administrado ayuda asegurar que el proceso establecido es retenido durante los tiempos de estrs. Los requerimientos y objetivos para el proceso son establecidos por la organizacin. El estado de los productos de trabajo y servicios son visibles para la administracin en puntos definidos. (Ej. Al terminar las mayores tareas). Se establecen compromisos entre aquellos que realizan el trabajo, y los actores relevantes, los cuales se revisan cuando sea necesario. Los productos de trabajo son revisados con los actores relevantes y son controlados. Los productos de trabajo y servicios satisfacen los requerimientos especificados. Una distincin entre un proceso realizado y un proceso administrado es la extensin con que el proceso es administrado. Un proceso administrado es planeado (el plan pueden ser parte de un plan mayor) y la ejecucin del proceso es administrada contra el plan. Se toma acciones correctivas cuando los resultados actuales de ejecucin se desvan significativamente del plan. Un proceso administrado cumple los objetivos del plan y esta institucionalizados por su ejecucin consistente. Proceso definido Un proceso definido es un proceso administrado que se obtuvo manipulando el conjunto de procesos estndar de la organizacin de acuerdo con las guas de manipulacin de la organizacin, ha mantenido la descripcin del proceso; y contribuye con experiencias relacionadas con el proceso, a las actividades de proceso, a los activos de proceso organizacionales. Los activos de proceso organizacionales son artefactos que se relacionan con describir, implementar y mejorar procesos. Estos artefactos son activos a causa de que son desarrollados adquiridos para cumplir los objetivos de negocios de la organizacin y ellos

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA representan inversiones que la organizacin hace en espera de proporcionar valor de negocios actuales y futuros. El conjunto de procesos estndar de la organizacin, que son la base de los procesos definidos, es establecido y mejorado con el tiempo. Los procesos estndar describen los elementos fundamentales del proceso que son esperados en el proceso definido. Los procesos estndar tambin describen las relaciones (ej. El orden y las interfaces) entre estos elementos del proceso. La infraestructura a nivel organizacional para soportar el uso actual y futuro del conjunto de procesos estndar de la organizacin es establecida y mejorada con el tiempo. Un proceso definido de un proyecto proporciona la base para planear, realizar y mejorar las tareas y actividades del proyecto. Un proyecto puede tener ms de un proceso definido (ej. Uno para desarrollar el producto y otro para robar el producto). Un proceso definido establece claramente lo siguiente: Propsito Entradas Criterios de entrada Actividades Roles Mediciones Pasos de verificacin Salidas Criterios de salida La administracin de los riesgos consta de las siguientes actividades: 1. Identificacin de los riesgos 2. Evaluacin de los riesgos 3. Seleccin de los riesgos 4. Planear la gestin de riesgos Hacemos referencia a la metodologa Delphi para riesgos. 1. Identificador de los riesgos Segn el mtodo Delphi, la mejor forma de identificar los riesgos de un proyecto de software consiste en reunir un grupo de 3-5 personas con experiencia en proyectos de software los cuales llamaremos los expertos. Entonces le pediremos a los expertos que cada uno entregue una lista de los riesgos a los cuales esta expuesto el proyecto.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA La lista de riesgos ser la unin de estas listas:

Lista A

Lista B

Lista C

Lista de Riesgos: (Lista A)U(Lista B)U(Lista C) A que riesgos esta expuesto un proyecto? Roger Pressman, en su famoso libro sobre ingeniera del software hace una taxonoma de los riesgos. Riesgos del Producto Defectos en el producto Obsolescencia temprana Cambio en los requerimientos Riesgos del Mercado Que los clientes dejen de necesitar el producto Un competidor que sea mejor y mas barato Problemas de imagen Riesgos del Cliente Se presentan en el caso de un producto a la medida Puede desaparecer el cliente El cliente se puede declarar en quiebra El cliente puede perder inters en el proyecto El cliente puede incumplir en los pagos Riesgos del Proyecto Sobrecostos Retrasos El retiro de un desarrollador en estado avanzado del proyecto

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Riesgos Naturales Que un rayo dae el disco duro del servidor Incendios Inundaciones Terremotos Riesgos Sociales Asonada Tomas guerrilleras Asalto Robo Hackers 2. Evaluacin de los riesgos Un riesgo tiene dos variables principales: Probabilidad de ocurrencia Es un numero real de 0 a 1 o un %. Probabilidad: Numero de casos positivos Numero total de casos Cuando la cantidad de casos considerados es un nmero estadsticamente significativo. Generalmente para proyectos de software, no tenemos un nmero de proyectos estadsticamente significativos y es imposible aplicar con rigor la definicin de probabilidad. Aqu es donde le mtodo Delphi nos dice que al menos podemos tener en cuenta la experiencia de los expertos, porque ellos han visto cierta cantidad de proyectos. Impacto Que pasa cuando el riesgos se hace realidad? El proyecto sufrir una perdida El impacto mide el tamao de la perdida. Generalmente se trabaja como un nmero entero del 1 al 4. Es una validez discreta. Significado de los impactos: 1. Despreciable: la prdida que genera el riesgo es muy pequea tanto que no importa. 2. Marginal: Aunque la prdida es ms apreciable, el proyecto se podr recuperar fcilmente. 3. Critico: El proyecto ha sufrido una gran perdida. A pesar de esto el proyecto puede terminar. 4. Catastrfico: La prdida es tan grande que el proyecto no se puede terminar.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Para evaluar la probabilidad de ocurrencia y el impacto para cada riesgo de lista, se pedir al experto que llenen los siguientes formatos: Riesgo Prob. % Impacto (1-4)

Los resultados se procesaran estadsticamente: La probabilidad: Obtenemos el promedio. Tambin se calcula la desviacin estndar que nos da una idea de la calidad del dato. Una desviacin pequea indica un acuerdo entre los expertos. Una desviacin grande indica desacuerdo entre los expertos y mayor incertidumbre del dato. El Impacto: Le podemos aplicar la moda. Tambin se puede usar la desviacin estndar para calificar la calidad del dato.

Riesgo

Prob. %

Impacto (1-4)

Riesgo

Prob. %

Impacto (1-4)

Riesgo

Prob. %

Impacto (1-4)

Riesgo

PA

PB PC P prom

Dp IA IB

IC

Mi Di

SELECCIN DE RIESGOS Calculamos la mtrica denominada: Conductor del riesgo as: Conductor del riesgo = impacto * probabilidad Es una medida de la importancia del riesgo. Se recomienda eliminar los riesgos cuyo impacto sea despreciable o marginal. Los riesgos que queden se ordenan en una tabla de mayor a menor conductor de riesgo:

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA RIESGO CONDUCTOR 20%

Se aplica el principio de Pareto: El 20 % de los riesgos es responsable del 80% de las perdidas. Esto permite que nos enfoquemos solo en los riesgos ms importantes. De esta manera se seleccionan los riesgos que sern gestionados. PLAN DE GESTION DE RIESGOS Para cada uno de los riesgos seleccionados en el paso anterior, se van a disear tres tipos de actividades. Actividades preventivas: Orientadas a evitar que el riesgo se presente o a disminuir la perdida. Actividades de Control: Orientadas a verificar si el riesgo se esta presentando. Actividades Correctivas (Plan de Contingencia): Orientadas a disminuir las perdidas despus de que el riesgo se ha hecho realidad. Suponen que el riesgo paso, se hizo realidad. Como vamos a actuar. ESTIMADO DE PROYECTOS DE SOFTWARE La estimacin es una actividad que se realiza antes de realizar el proyecto, cuando tenemos muy poca informacin sobre el proyecto. Pero este calculo tiene una gran incertidumbre, tpicamente de +- 50%. A medida que tengamos ms informacin debemos actualizar la estimacin para ir disminuyendo la incertidumbre. No se recomienda redactar un contrato solo con base en una estimacin. La probabilidad de cumplimiento puede ser muy baja. Las estimaciones se usan para verificar la viabilidad del proyecto. METODOS DE ESTIMACION DE LINEAS DE CODIGO Es el mtodo ms antiguo de estimacin. Se aplica desde la dcada de los 70s. Para contar las lneas de cdigo se deben filtrar las lneas en blanco y los comentarios.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Se debe tener una tabla de los datos histricos de proyectos realizados a los cuales se les ha medido su tamao en KLDC. KLDC=1000 Lneas de cdigo Se muestra un ejemplo hipottico de tal tabla.
PROYECTO Contabilidad Cartera Presupuesto Inventario SUMAS Mtricas/KLDC TAMAO (KLDC) 14 8 10 5 37 ESFUERZO P-MES) 8 4 6 2 20 0,54 P-MES/KLDC DOCUMENTACION (PAGINAS) 350 200 300 150 1000 27 PAG/KLDC ERRORES 35 20 27 8 90 243 ERROR/KLDC DEFECTOS 7 4 3 2 16 0,43 DEFECTOS/ KLDC COSTO (DOLARES) 11.700 6.700 8.500 4.100 31.000 837 DOL/KLDC

Como se ve en la tabla, primero se suman los datos y luego se calculan las mtricas orientadas al tamao en KLDC. UNA ESTIMACION Se dese hacer un software bancario. Preguntado a ingenieros de otros bancos, se estiman que este software tiene un tamao de 17 KLDC. Por favor estime el proyecto. COSTO = (837 dlares/KLDC) x 17 KLDC = 14.229 dlares ESFUERZO = (0,54 P-M/KLDC) x 17 KLDC = 9,18 P-M DOCUMENTACION = (27 PAG/KLDC) x 17 KLDC = 459 PAGINAS ERRORES = (243 ERRORES/KLDC) x 17 KLDC = 41 ERRORES DEFECTOS = (0,43 DEFECTOS/KLDC) x 17 KLDC = 7 DEFECTOS Tiempo = Esfuerzo/Personas Si dedicamos 3 personas: Tiempo = 9,18 P-M/ 3 Personas = 3,06 Meses El problema con grupos grandes es el tiempo gastado en comunicarse con los dems miembros del grupo:

1 6

10

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Lneas de comunicacin = Personas (Personas -1)/2 CRITICA DE ESTE METODO 1. El tamao del programa depende del lenguaje de programacin. Entonces la tabla y el nuevo proyecto deben estar en el mismo lenguaje. 2. El estilo personal tambin influye en el tamao. As la tabla y el nuevo proyecto deberan ser de los mismos desarrolladores. 3. Si no hemos realizado el proyecto. Cmo sabemos cuantas lneas de cdigo tendr el programa? Esta fue la principal fuente de incertidumbre. METODOS DE ESTIMACION POR PUNTOS DE FUNCION Fue propuesto por Albrecht en 1979. En lugar de usar el tamao en lneas de cdigo como estimador, Albrecht propone medir la funcionalidad del programa y usar este mtrica como estimador. Qu funciones hace un programa? - Entrada de datos: las pantallas de entrada. - Salidas de datos: Son los informes o reportes. - Control del programa: Mens, barras de herramientas. Albrecht las llama peticiones. - Almacena informacin: Archivos, hoy son tablas. - Comunicarse con otros programas: interfaces externas. Tambin se considera el grado de complejidad de cada funcin: simple, medio y complejo. FORMATO PARA PUNTOS DE FUNCION A PARAMETRO Entradas Salidas Peticiones Archivos Interfaces B C D E H=BxC+DxE+FxG F G H COMPLEJO SUBTOTAL CANTIDAD PESO X6 X7 X6 X 15 X 10 CUENTA TOTAL

SIMPLE CANTIDAD PESO X3 X4 X3 X7 X5

MEDIO CANTIDAD PESO X4 X5 X4 X 10 X7

Luego se deben tener en cuenta los 14 factores de complejidad, los cuales se valoran de 0 a 5, de acuerdo con la siguiente tabla: 0 sin influencia 1 incidental 2 moderado 3 medio 4 significativo 5 esencial

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA

*----------------------------------------------------------------------------* En la E. XXX desean aplicar el CMMI solamente al proceso de produccin: Deberan aplicar el modelo de niveles de madurez o el de niveles de capacidad? Capacidad. La E.XYZ tuvo una buena temporada, en la cual uno de sus productos tuvo gran xito comercial y ganaron mucho dinero. Luego de eso han intentado crear otro producto con xito similar pero no les ha funcionado. Que nivel de madurez demuestra esta empresa? Inicial. La E.ZXC tiene muy bien definidos sus procesos, todos sus proyectos utilizan procesos extrados de un conjunto de procesos estndar, tienen las buenas prcticas desarrolladas con los proyectos y los procesos, y recolectan mediciones de los proyectos, quieren comprender estadsticamente sus procesos al nivel del subproceso para tener modelos que les permitan predecir el desempeo de cada proceso y tratar de mejorarlo. Qu nivel de madurez exhibe esta empresa? Cuantitativamente Administrado. Una E. esta implementando el rea de proceso Integracin del producto (PI). Que otras reas de proceso debe tener implementadas para cumplir con su actual nivel de madurez? Nivel 3. __CAR- ODP-OT-PPQA-RSKM-VER-DAR-OPF-MA-__QPM-SAM-IPM-__OPM-PMC-RD-TS-OPD__OPP-PP-REQM-VAL Cul es el resultado del rea de proceso Desempeo de Proceso Organizacional? OPM es un rea de proceso correspondiente a las reas avanzadas de la administracin de procesos y es de nivel 5. Deriva objetivos cuantitativos para calidad y desempeo de los procesos a partir de los objetivos del negocio. Medicin de los procesos y calidad Objetivos de procesos y calidad Lneas base Objetivos de desempeo Modelos Una pequea E. de software considera que su xito se debe a que su programador principal es un genio y sin el estaran perdidos. Qu nivel de madurez demuestra este pensamiento? Inicial. En la E. SSS los proyectos funcionan muy bien, cada proyecto tiene sus procesos bien definidos y utilizan buenas prcticas, las cuales se mantienen aun en tiempos de crisis. El proyecto de software contable y financiero utiliza metodologa RUP (Rational Unified Process); el proyecto de software para hacienda ganadera esta usando XP (eXtreme Programming). Qu nivel de madurez exhibe la empresa? Administrado. La E. DFG hace software para administrar camiones, tiene sus proyectos perfectamente administrados, sus procesos definidos rigurosamente, utiliza un conjunto estndar de procesos, recolecta mediciones de todos los procesos clave y crea modelos estadsticos para comprender los procesos, pero adems utiliza la estadstica y los modelos cuantitativos para predecir el desempeo de toda empresa y mejorarlo utilizando innovacin y tecnologa. Qu nivel de madurez exhibe esta empresa? Optimizado.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Una E. esta implementado el rea de proceso Administracin Cuantitativa de Proyectos. Qu otras reas de proceso debe tener implementadas para cumplir con su actual nivel de madurez? __CAR-OPD-OT-PPQA-RSKM-VER-DAR-OPF-MA-PI-SAM-CM-IPM-__OPM-PMC-RDTS-OPD-OPP-PP-REQM-VAL Que informacin intercambian las categoras de rea de proceso de Administracin de Procesos y Administracin de Proyectos? La informacin que intercambian las distintas reas de proceso de Administracin de Procesos y administracin de proyectos son: Procesos estndar, estndares de trabajo y otros activos (OPDAdmin Proyectos) Informacin de mejora (lecciones aprendidas, datos, artefactos)(Admin proyectos-> OPD) Necesidad de entrenamiento (Admin proyectos -> OT) Entrenamiento para proyectos y grupos de soporte, en procesos estndar y activos (OTAdmin Proyectos) Propuesta de mejora de procesos, participacin en definir, evaluar y desplegar proceso (Admin proyectos OPF) Necesidad de objetivos de procesos de la organizacin (OPFAdmin proyectos) La anterior informacin se da entre las reas bsicas de administracin de procesos y la categora Admin de proyectos a continuacin se lista la informacin intercambiada entre las reas avanzadas de Admin de procesos y Admin de proyectos: Datos de calidad y desempeo (Admin proyectos-> OPP) Datos de costo y beneficio de pilotos de mejora (Admin proyectos OPM) La calidad y el proceso de las medidas, las lneas de base, los objetivos de desempeo y los modelos (OPP-> Admin de proyectos) Toda la informacin anterior tambin se intercambia con ingeniera y soporte a continuacin se encontrara la informacin explicita entre reas avanzadas de Admin de proyectos y las reas de Admin de procesos tano bsicos como avanzados: Visin compartida del proyecto Datos de desempeo del proyecto Taxonomas de riesgos y parmetros, estado de los riesgos. Planes de mitigacin y accin correctiva. Composicin del proyecto y procesos definidos Reglas de agrupacin y guas, lecciones aprendidas, datos de planeacin y desempeo Procesos estndar de la organizacin, estndares de ambientes de trabajo y activos de soporte Datos para Admin estadstica Objetivos de desempeo de procesos, lneas base y modelos

Una E. de desarrollo de software desea iniciar con la mejora de procesos CMMI, pero no se sabe como comenzar. Indcale por favor cuales reas de proceso debe implementar primero. Debe de seguir con el nivel de madurez 2 (administrado) debe de implementar las siguientes reas de procesos para pasar al nivel de madurez 2: REQM-PP-PMC-SAM-MA-PPQA-CM Cual es el resultado del rea de proceso Definicin de Proceso Organizacional?

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA OT Procesos estndar y otros activos ------------OPDD+IPPD ---procesos estndar, estndares de ambiente de trabajo --- PA de gestin de proyectos, soporte e ingeniera.

Qu informacin intercambian las categoras de rea de proceso Administracin y Administracin de Proyectos? Necesidades de procesos, objetivos de la organizacin. Entrenamiento para proyectos, grupos, soporte en procesos estndar y activo. Necesidad de entrenamiento. Procesos estndar, estndares de ambiente. Informacin de mejora. Propuestas de mejora de procesos; participacin y definicin, evaluacin y despliegue de procesos. Datos de costo beneficio de las mejoras pilotadas. Objetivos de calidad y desempeo de los procesos, mediciones, lnea base y modelos. Datos de desempeo de los procesos y capacidad. Qu informacin intercambian las categoras de proceso Administracin de Proyectos e ingeniera y soporte? Estado, temas y resultados de evaluaciones del proceso y el producto; mediciones y anlisis. Accin correctiva Que construir Que hacer Acuerdos Necesidades de medicin Requerimientos de componentes del producto, temas, tcnicas. Componentes del producto terminados, revisiones y pruebas de aceptacin. Objetivos de desempeo de los procesos lneas base y modelos. Datos de Admin estadstica Procesos estndar de la organizacin, estndares de ambiente de trabajo y activos de soporte. Lecciones aprendidas, planeacin y datos de desempeo. Reglas y guas IPPD Arquitectura del producto para estructuras de grupo Visin compartida del proyecto Datos de desempeo del proyecto Procesos definidos del proyecto y ambiente de trabajo coordinacin, acuerdos y temas a resolver. Grupos integrados para realizar procesos de ingeniera y soporte. Defina el proceso Desarrollo de Requerimientos: Propsito: disear un programa para lo que necesite el cliente Entradas: peticiones del cliente, que quiere que haga el programa Criterios de entrada: que no sean ambiguas, que estn bien definidos, que no estn en conflicto Actividades:..

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Indique en cuales reas de proceso pueden surgir propuestas de mejora de procesos: OPFOPM-CAR En que rea de proceso se le colocan los procesos definidos a los proyectos, adaptndolos a partir de los procesos estndar: IPM Empleado que no cumple con sus funciones y obvia procedimientos. Que rea de proceso esta fallando? PPAQ En que nivel de madurez la organizacin se pone a estudiar y medir los subprocesos para tratar de predecir el desempeo. CUANTITATIVAMENTE ADMINISTRADO. En cual rea de proceso se implementa la trazabilidad desde los productos hasta los requerimientos y necesidades del cliente. REQM En cual rea de proceso se predice si la empresa cumplir con sus objetivos de negocio. OPM En que nivel institucionalizado se asegura que las buenas practicas sern retenidas durante los tiempos de crisis. PROCESO ADMINISTRADO. En cuales reas de proceso se implementan las propuestas de mejora. OPF-OPM En cual rea de proceso se predice si el proyecto cumplir sus objetivos de calidad y desempeo. QPM Que rea de proceso realiza el anlisis causa raz a los procesos definidos del proyecto. CAR

EJEMPLO PARA PUNTOS DE CASOS DE USO Evaluaremos el caso de uso Retirar dinero del cajero automtico CASO DE USO: ACTORES: PROPOSITO: VISION GENERAL: Retirar dinero del cajero automtico Cliente Realizar un retiro de dinero, desde un cajero automtico Un cliente llega al cajero automtico, introduce la tarjeta, se identifica y solicita realizar un retiro de dinero. El cajero le da el dinero solicitado tras comprobar que la operacin puede realizarse. El cliente toma el dinero y se va.

CURSO NORMAL DE LOS EVENTOS ACCION DE LOS ACTORES RESPUESTA DEL SISTEMA 1. Este caso de uso empieza cuando n 2. El sistema pide la clave de cliente introduce la tarjeta en el identificacin. cajero. 3. El cliente introduce la clave 4. Presenta las opciones disponibles. 5. El cliente selecciona la operacin de 6. Pide la cantidad a retirar. retiro. 7. El cliente introduce la cantidad 8. El sistema procesa la peticin y requerida. eventualmente entrega el dinero solicitado. 9. Devuelve la tarjeta y genera un recibo.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA 10. El cliente recoge la tarjeta, el recibo y el dinero. Procede a retirarse. Paso 1. Calcular UUCP, los puntos de caso de uso sin ajustar. UUCP = UAW + UUCW Paso 1.1. Calcular UAW, el factor de peso de los actores sin ajustar. TIPO DE ACTOR SIMPLE MEDIO DESCRIPCION API PROTOCOLO, INTERFAZ DE TEXTO GUI FACTOR 1 2 CANTIDAD ACTORES 0 0 DE SUB TOTAL 0 0

COMPLEJO

1 UAW

3 3

Paso 1.2 Calcular UUCW, factor de peso de los casos de uso sin ajustar: lo haremos por transacciones. Se definen 2 transacciones. TIPO DE ACTOR SIMPLE MEDIO COMPLEJO DESCRIPCION TRANSACCIONES <= 3 4<=TRANSACCIONES <=7 TRANSACCIONES >7 FACTOR 5 10 15 CANTIDAD ACTORES 1 0 0 UUCW DE SUB TOTAL 5 0 0 5

UUCP = UAW + WCW =3+5 Paso 2: Calcular UCP, puntos de caso de uso ajustados. UCP = UUCP * TCF * EF Paso 2.1 Calcular TCF, factor de complejidad tcnica. FACTOR T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 PESO 2 1 1 1 1 0,5 0,5 2 1 1 VALOR 5 4 3 5 5 3 4 5 4 5 SUB TOTAL 10 4 3 5 5 1,5 2 10 4 5

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA T11 T12 T13 1 1 1 5 0 5 5 0 5 TFACTOR 59,5

TCF = 0,6 + (0,01 * TFACTOR) = 0,6 + 0,595 TCF = 1.195 Paso 2.2 Calcular EF, el factor ambiental. FACTOR E1 E2 E3 E4 E5 E6 E7 E8 PESO 1,5 0,5 1 0,5 1 2 -1(en contra proyecto) -1 VALOR 3 1 4 4 5 3 del 5 4 SUB TOTAL 4,5 0,5 4 2 5 6 -5 -4 EFFACTOR 13

EF = 1,4 0,03*EF = 1,4 -0,03 * 13 = 1,4 0,39 EF = 1.01 UCP = UUCP * TCF * EF = 8 * 1.195 * 1.01 UCP = 9,65 (Puntos de caso de Uso)

-----------------------------------**********************-------------------------------------------

09/11/2012
Ejercicio Desarrollar un despachador automtico de taxis. Al atender la llamada, usando el identificador busca BD al cliente. Coordenada geogrfica del cliente. Comunicacin digital con los taxis. Taxis con GPS.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Costo de Desarrollo Software $100.000.000 Hardware 1000 taxis X $ 1.000.000. $ 1.000.000.000 _________________ $ 1.100.000.000 Costo de Sostenimiento: Mantenimiento del Software $ 5.000.000 Mantenimiento del Hardware.. $ 20.000.000 Comunicaciones GPRS $ 70.000 X 1.000. $ 70.000.000 Comunicaciones de la Central. $ 5.000.000 ______________ $ 100.000.000 Beneficio: 50012 horas --------------entregas= 70.000 x 500$35.000.000 50024 horas---------------entregas= 140.000 x 500$70.000.000 --------------------$105.000.000 X 30 das --------------------Entrega antes $ 3.015.000.000 Con el nuevo sistema: sube la entrega$90.000/ 12 horas 500 x $90.000. $ 45.000.000 500 x $180.000.. $ 90.000.000 -------------------$ 135.000.000 x 30 das. $ 4.050.000.000 Nuevos ingresos = $ 1.035.000.000 mensuales P= A*[(1+i) - 1]/ i(1+i) i = 1.5% mes vencido n = 60 meses

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Llevemos a valor presente los beneficios: Bup = 1035 x 10 x *(1 + 0.015): - 1/ 0.015 x (1+ 0.015) :] Bup = + $ 40.758.578.296 El costo de sostenimiento Cup = -100 x 10 x [(1.015) : - 1/ 0.015 x(1.015) :] CSup = - $ 3.938.026.888 CDup = - $ 1.100.000.000 -----------------------------$ 37.720.551.408 a pesos de hoy

PLANIFICACION DETALLADA DEL PROYECTO Resultados que se esperan: Subdivisin del proyecto en actividades. Planificar los puntos de control (hitos). Cronograma o calendario. Planificacin de los costos. Recursos y uso de recursos. Propuesta o cotizacin. SUBDIVISION DEL PROYECTO EN ACTIVIDADES

WBS

Work Breakdown Structure

Estructura de Descomposicin del trabajo Primero tratemos de subdividir el producto. Subsistema A Subsistema B Subsistema C La siguiente dimensin es subdividida. El tiempo Ciclo de vida del proyecto Levantar Requerimientos Analizar Requerimientos Disear la solucin Construir la solucin Pruebas de Unidad Pruebas de Integracin Implantacin

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Para generar las WBS del proyecto, cruzamos los subsistemas con las etapas del ciclo de vida.
SUBSISTEMA LEVANTAR REQ ANALIZAR REQ DISEAR CICLO DE VIDA CONSTRUIR

PRUEBA DE UNIDAD

PRUEBA DE INTEGRACION

IMPLANTACIN O ENTREGAA

A B C

L ABC

AA AB AC

ARQ DA
ABC

CA CB CC

PA PB PC

IABC

EABC

DB DC

16/11/2012 DIAGRAMA DE GANTT Propuesto por Henry L. Gantt en 1918, es comnmente para mostrar el cronograma de un proyecto. Consta de 2 partes:

Descripcin de las Actividades

Calendario

Se hace usando los tiempos ms prontos. Se acostumbra resaltar la ruta critica con color naranja. La ejecucin de las tareas se muestra como una barra negra. El dia de hoy se resalta con una lnea vertical. CALENDARIO EN SEMANAS ACT 1 1 1 1 1 1 . DURAC. 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 A 3 B 5 C 3 D 4 E 8 F 2 G 4 H 2 I 5 J 3 Hoy

1 6

1 7

1 8

1 9

2 0

2 1

2 2

2 3

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA En este diagrama podemos observar que: El da de hoy es al final de la semana 6. Las actividades A y B se ejecutaran en un 100 %. La actividad C se ha ejecutado en una tercera parte o 33%. La actividad I esta retrasada. El diagrama de Gantt permite fcilmente hacer un monitoreo del proyecto. EL PRESUPUESTO DEL PROYECTO Para llegar al presupuesto que es el costo de cada actividad tenemos que estudiar los recursos del proyecto y su costo por unidad de tiempo. Esto se ve en la siguiente tabla: TABLA DE RECURSOS COD A R Q I O V C E RECURSO Administrador Jefe de Recursos Humanos ArQuitecto Ingeniero Civil Obrero Vehculo Camin Conductor Entrenador SALARIO 5.000.000 3.000.000 2.500.000 2.800.000 700.000 5.000.000 900.000 1.500.000 COSTO/MES 7.546.835 4.528.101 3.773.418 4.226.228 1.124.357 5.000.000 1.426.230 2.264.050 COSTO/SEMANA 1.886.709 1.132.025 943.355 1.056.557 281.089 1.250.000 356.558 566.013

Factores de Costo Salarial Salario Prima Vacaciones Sena ICBF Compensacin Familiar Salud Pensin ARP Cesantas Int. Cesantas

1 *1/12 *1/24 0.04 0.03 0.02 0.085 0.12 0.0052 *1/12 0.01/12 1.509.366 67.800

Subsidio Transp. Salario > 2 SMM

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA EL PROYECTO CON RECURSOS Y PRESUPUESTO ACT. DURAC. RECURSOS A 3 A B 5 A C 3 A,R D 4 A,Q E 8 I,5*O F 2 A,R G 4 R H 2 A,3*O,2*V,2*C I 5 A J 3 E TOTAL COSTO/SEMANA 1.886.709 1.886.709 3.018.734 2.830.063 2.462.002 3.018.734 1.132.025 5.792.154 1.886.709 566.012 PRESUPUESTO 5.660.127 9.433.545 9.056.202 11.320.252 19.696.016 6.037.468 4.528.100 11.584.308 9.433.545 1.698.036 88.447.599

LA COTIZACION Los ingenieros a menudo tienen que presentar la propuesta para un nuevo proyecto. La propuesta se suele dividir en dos partes: La propuesta tcnica Define el proyecto, el trabajo que debe realizar, los objetivos a lograr, etc. Bsicamente la propuesta tcnica dice que se va a hace. Contiene los siguientes tems: Contexto

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Antecedentes Justificacin Objetivos Delimitacin Viabilidad WBS o divisin en tareas CPM-PERT Cronograma Presupuesto

La propuesta Econmica A. COSTOS DIRECTOS Tienen relacin directa con la realizacin del trabajo. Ej.: Los que estn en el presupuesto A.1 Mano de obra directa A.2 Materiales A.3 Maquinaria y equipo A.4 Viticos y gastos de viaje B. COSTOS INDIRECTOS Aquellos que proporcionan la infraestructura para el proyecto: B.1 Arrendamiento de oficina B.2 Servicios pblicos B.3 Celadura, Admin. Edificio. B.4 Secretaria B.5 Contador y auxiliar B.6 Gerencia B.7 Seguros C. TOTAL COSTOS (A+B) D. AIU Administracin, Imprevistos, Utilidades. E. TOTAL ANTES DE IMPUESTOS ((C+D)) F. IMPUESTOS F.1 IVA (Impuesto al valor agregado) (16%) de E. F.2 Retefuente 10% E. Es un adelanto de los impuestos que debe pagar el productor. Debera salir del AIU y no cobrar esto al cliente. F.3 Impuestos Departamentales F.3.1 Estampillas pro Desarrollo de Risaralda (1%) F.3.2 Publicacin en la Gaceta Departamental (1-7%)

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA F.4 Impuestos Municipales F.4.1 Estampilla pro Deportes de Pereira (1%) F.4.2 ICA Impuesto de Industria y Comercio Es un impuesto del producto no del cliente (1%) F.5 Impuesto del timbre (1%) La cobran en la notaria por registrar el contrato. Es importante hablar con el tesorero del cliente sobre los impuestos que tiene el proyecto. G. TOTAL A PAGAR (E + F) Ejemplo:

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Public class movie { Public static final int CHILDRENS=2; Public static final int REGULAR=0; Public static final int NEW-RELEASE=1; Private String _title; Private int _price code; Public movie (String tittle, int price code) { _tittle=tittle; _price code=price code; } Public int getPrice code() { Return _pricecode; } Public void setprice code(int arg) { _pricecode=arg; } Public String getTittle() { Return _tittle; } } Class Rental { Private Movie _movie; Private int _daysRented; Pubic Rental (Movie movie, int daysRented) { _movie=movie; _daysRented=daysRented; }

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Public Movie getMovie () { Return _movie; } }

Class Customer Private String _name; Private Vector _rentals=new Vector; Public Customer (String name) { _name=name; } Public void addRental (Rental arg) { _rentals.addElement (arg); } Public String getName() { Return _name; } Public String statement () { Double totalAmount=0; Int frequent RenterPoints=0; Enumeration rentals= _rentals.elements(); String result= Rental Record for + getName()+\n; While (rentals.hasMoreElements()) {

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA

06/09/11 Una distincin crtica entre un proceso administrativo y un proceso definido es eplpl alcance de la aplicacin de las descripciones de procesos, estndares y procedimientos. Para un proceso administrativo, las descripciones de procesos, estndares y procedimientos son aplicables a un proyecto particular, grupo o funcin organizacional. Como resultado, los procesos administrados de dos proyectos en una organizacin pueden ser diferentes. Otra distincin crtica es que un proceso definido es descrito con ms detalle y es realizado ms rigurosamente que un proceso administrado. La distincin significa que la informacin de mejora es ms fcil de comprender, analizar y usar finalmente, la admn. Del proceso definido se basa en un entendimiento adicional proporcionado por una comprensin de las interrelaciones de las actividades de los procesos y mediciones detalladas de los procesos, productos de trabajo y servicios. (Desarrollo en orden cronolgico)

PRACTICAS Y METAS GENRICAS.

Esta seccin describe todas las metas y prcticas genricas, as como sus subprcticas asociadas, notas, ejemplos y referencias.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA GG1: cumplir las metas especficas. Las metas especficas de las PA son soportadas por los procesos transformados productos de trabajo de entrada identificables en productos de trabajo de salida identificables. (GG: genericgoal; GP: GenericPractice). GP 1.1 Realizar las practicas especficas. Realizar las prcticasespecficas de las PA para desarrollar productos de trabajo y proporcionas servicios para cumplir las metas especficas de PA el propsito de esta prctica genrica es producir los productos de trabajo y entregar los servicios que son esperados realizando los procesos. Estas prcticas pueden ser hechas informalmente sin seguir una descripcin de proceso documentada o plan. El rigor con el que se realizan estas prcticas depende de los individuos que administran y realizan el trabajo y pueden variar considerablemente. (Proceso realizado).

GG2: institucionalizar un proceso administrado. El proceso es institucionalizado como un proceso administrado. GP 2.1 Establecer una poltica organizacional. Establecer y mantener una poltica organizacional para planear y realizar los procesos. El propsito de esta prctica genrica es definir las expectativas organizacionales para los procesos y hacer estas expectativas visibles a aquellos miembros de la organizacin que son afectados por ellas. En general la admn. senior es responsable por establecer y comunicar los principios gua, direcciones y expectativas de la organizacin. No todas las directrices de la admn. senior tendr el rotulo de polticas. La existencia de una apropiada direccin organizacional es la expectativa de esta prctica genrica, sin importar como se llame o como se imparta.

Elaboracin CAR. Esta poltica establece las expectativas organizaciones para identificar y manejar sistemticamente el anlisis casual de los resultados seleccionados. GP 2.2 Planear los Procesos. Establecer y mantener el plan para realizar los procesos. El propsito de esta prctica genrica es determinar que necesita realizar el proceso para cumplir los objetivos establecidos, para preparar una descripcin del proceso y para conseguir acuerdos sobre el plan de los actores relevantes. Las implicaciones prcticas para aplicar una prctica genrica varan para cada rea de proceso.

Por ejemplo: la planeacin descrita por esta prctica genrica, como es aplicada en el rea de monitoreo y control de proyectos puede ser llevada a cabo completamente por los procesos asociados con el PA planeacin del proyecto. Sin embargo, esta prctica genrica, cuando se aplica al rea de planeacin de proyectos, coloca un expectativa de que el proceso de planear proyectos tambin debe ser planeado.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA

Entonces esta prctica genrica puede reforzar el conjunto de expectativas en cualquier parte del CMMI o crear nuevas expectativas que deben ser manejadas. Refirase al PA planeacin del proyecto para ms informacin acerca de establecer y mantener planes que definen las actividades del proyecto. Establecer un plan incluye documentar el plan y una descripcin de procesos. Mantener el plan incluye actualizarlo para reflejar las acciones correctivas o cambios en los requerimientos o en los objetivos El plan para realizar el proceso tpicamente incluye lo siguiente: Descripcin del proceso. Estndares y requerimientos para los productos de trabajo y servicios del proceso. Objetivos especficos para la ejecucin de los procesos y sus resultados (ej.: calidad, escala de tiempo, tiempo de ciclo, uso de recursos). Dependencia entre las actividades, productos de trabajo y servicios de proceso. Recursos (ej.: fondos, personas, herramientas) necesarias para realizar el proceso. Asignacin de responsabilidad y autoridad. Necesidades de entrenamiento para realizar y soportar los procesos. Productos de trabajo a ser controlados y el nivel de control a ser aplicados. Requerimientos de medicin para proporcionar un entendimiento de la ejecucin del proceso, sus productos de trabajo y sus servicios. Involucramiento de los actores relevantes. Actividades para monitorear y controlar el proceso. Evaluacin objetiva de las actividades del proceso. Actividades de revisin por parte de la admn., para el proceso y los productos de trabajo.

Subprcticas: 1. Definir y documentar el plan para realizar el proceso. El plan puede ser un documento solo, estar embebido dentro de un documento de mayor alcance, distribuido entre mltiples documentos. En el caso del plan siendo distribuido en mltiples documentos, asegrese de que se conserva una visin coherente de quien hace que, los documentos pueden estar en copia duro o en copia blanda. 2. Definir y documentar la descripcin del proceso. La descripcin del proceso incluye los estndares relevantes y procedimientos, puede ser incluida como parte del plan para realizar el proceso o puede ser incluida en el plan por referencia. 3. Revisar el plan con los actores relevantes y conseguir su acuerdo.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Esta revisin del plan incluye revisar que el proceso planeado satisfaga las polticas aplicables, planes, requerimientos y estndares para proporcionar aseguramiento para los actores relevantes. 4. Revisar el plan cuando sea necesario. GP 2.3 proporcionar Recursos. Proporcionar los recursos adecuados para realiza el proceso, desarrollar los productos de trabajo y proporcionar los servicios del proceso.

18/10/2011 Estimacin por lnea de cdigo. Primer intento de medir un programa: sus lneas de cdigo - Eliminar los cometarios y lneas en blanco. Toda estimacin se debe basar en datos histricos. Los datos histricos pertinentes son aquellos de proyectos similares al proyecto que estamos estimando. Tabla de proyectos anteriores: Proyecto KLDE Esfuerzo (p-m) A B

Costo (dlar) C

Documentacin (hoja) D

Errores E

Defectos F

Al final de la tabla se realizan las sumas A, B, C, D, E, F. Luego de obtener las sumas, se calculan las mtricas para estimacin:

Indica la cantidad de personas mes necesarias para construir mil lneas de cdigo.

Indica cuantos dlares cuestan hacer mil lneas de cdigo.

Indica cuantas hojas de documentacin se escriben para construir mil lneas de cdigo.

Indica la cantidad de errores encontrados en las pruebas para un KLDC.

Indica la cantidad de defectos que el cliente encuentra despus de la entrega, durante el primer ao, por cada KLDC.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Para estimar un nuevo proyecto solo se necesita decir el tamao en KLDC del nuevo software. Las mtricas se multiplican por el tamao en KLDC para a obtener la estimacin. Desventajas: 1. Cmo saber el tamao en KLDC de un nuevo software si no se ha construido? 2. Las KLDC dependen en gran medida del lenguaje de programacin. En los datos histricos no mezclar lenguajes. 3. El estilo personal, unos programadores escriben mas KLDC que otros, ojala los datos histricos pertenecieran al desarrollador del nuevo proyecto. Estimacin por puntos de funcin. El investigador Albrechten 1980 propuso un mtodo que no tena las desventajas del anterior. La idea esa medir la Funcionalidad del software y estimar el proyecto den base en esta medida. Albrecht determina 5 funcionalidades para el software: Entradas: la cantidad de pantallas ventanas para entrada de datos. Salidas: la cantidad de informes reportes a generar ya sea impresos o por pantalla. Archivos: las unidades de almacenamiento, hoy se usan las tablas (BD). Peticiones: son las unidades de control del programa. Men, barra de herramientas, dilogos. Interfaces externas: se refieren a la comunicacin del nuevo software con otros programas. Por lo tanto, se limita su aplicacin a software cuyo procesamiento interno sea sencillo. Por ejemplo, sw administracin. A Funcin Entradas Salidas Peticiones Archivos Interfaces Suma B Valor Simple Peso x3 x4 x3 x7 x5 C D Medio Valor Peso x4 x5 x4 x10 x7 E Complejo Valor F Peso x6 x7 x6 x15 x10 G Subtotal

Para calcular la columna H

De esta tabla obtenemos la cuenta total, un nmero que indica que tanta funcionalidad tiene el software. Este nmero ser afectado por 14 factores de complejidad que consideran mechas situaciones del proyecto.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Factores de Complejidad. Cada uno de estos factores ser valorado de 0-5 siendo 0 no importante oo no aplicable y 5 absolutamente esencial. Factor 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Descripcin El sistema requiere backup y recuperacin confiable? Se requieren comunicaciones de datos? Hay funciones de procesamiento distribuido? Es crtico el desempeo? El sistema correr en un ambiente operacional existente y fuertemente utilizado? El sistema requiere entrada de datos en lnea? La entrada de datos en lnea requiere que la entrada de transacciones se construya sobre mltiples pantallas u operaciones? Es multitarea? Los archivos maestros se actualizan en lnea? Son las entradas, las salidas, los archivos o las peticiones complejas? Es el procesamiento interno complejo? Cdigo diseado para ser reutilizado? Estn la conversin y la instalacin incluidas en el diseo? Mltiples instalaciones en diferentes organizaciones? Facilidad de cambio y facilidad de uso? Valor

PARCIAL HASTA ACA.

21/10/2011 Puntos de funcin = cuanta total * [0.6 + 0.01 * sumatoria desde i=1 hasta 14 de Fi] Para que los puntos de funcin tengan algn significado, se necesita una tabla de proyectos histricos valorados en sus puntos de funcin.

Proyecto

PF

Esfuerzo p-m

Costo dlares

Documentacin Errores Hojas

Defectos

Suma

Con las sumas calculamos las mtricas a parmetros de estimacin: Esfuerzo / PF = B / A Como los PF >> p-m esta mtrica da muy pequea, con decimales. Suele utilizarse el inverso.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA PF / Esfuerzo = A/B Indica la cantidad de puntos de funcin que hace una persona durante un mes. Es la productividad. De la experiencia: Ingeniero nuevo: 20 PF/p-m Promedio: 30 PF/p-m Excelente: 40 PF/p-m Costo / PF = C / A dlares / PF Indica cuantos dlares cuestan construir un punto de funcin. La idea es utilizar una moneda estable. El peso ha sido muy variable con los aos.

De la experiencia: Costo / PF = 50 dlares/PF Este valor depende de los costos fijos de la empresa Doc./PF = D / A pag/PF Indica cuantas pginas de documentacin se escriba por cada PF Errores / PF = E/A Indica la cantidad de errores que se encuentran a las pruebas por cada PF (<<1) Defectos / PF = F/A La cantidad de errores que se encuentran despus de la entrega (los encontr el cliente) durante el primer ao (<<1) Para poder hacer una estimacin por puntos de funciones (PF), primero hay que hacer un prediseoidentificando los elementos de la futura aplicacin. Entradas, salidas tablas, interfaces, mens. Luego de esto se puede aplicar el clculo de os PF. Luego se tener los PF, se aplican las mtricas y se hace la estimacin.

METODO DE ESTIMACION POR PUNTOS DE CASO DE USO.

Fue el resultado de modernizar el mtodo de los puntos de funcin, adaptndolo a la tecnologa orientada a objetos. En lugar de usar entradas, salidas, peticiones, archivos e interfaces, este mtodo usa caos de uso, acores, transacciones, clases. Pero los puntos de caso de uso resultantes son equivalentes a los puntos de funcin el mtodo lo creo el estudiante noruego Gustav Karneren su tesis de grado de 1993 presentada en la universidad de Linkoping y cuyo director fue Ivar Jacobson.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA El trabajo fue revisado y actualizado en la tesis de grado del estudiante noruego KirstenRibu presentada en la universidad de Oslo en 2001. Fuente: Wikipedia. Paso 1: calcular los casos de uso sin ajustar. UUCP (Unadjusted use Case Points) UUCP = UAW + UUCW Paso 1.1: Calcular el factor de peso de los actores sin ajustar UAW. (UnadjustedActorsWeight) Tiene en cuenta la complejidad y cantidad de los actores de un caso de uso. Usamos la tabla de los actores: A TIPO ACTOR Simple DE DESCRIPCION Otro sistema que interacta con el actual mediante un API o interfaz de programacin Otro sistema interactuando y a travs de un protocolo (TCP/IP) o una persona interactuando a travs de un interfaz en modo texto. Una persona que interacta con el sistema mediante una interaccin grafica GUI B C FACTOR D E CANTIDAD DE SUBTOTAL ACTORES C*D

Medio

C*D

Complejo

C*D

UAW = sumatoria de E

UAW = sum (cantidad de un tipo de actor * Factor) Se hace una tabla de estas por cada cado de uso. Luego sumamos los UAW de todos los casos de uso. Paso 1.2: calcular el peso de los casos de uso. Sin ajustar UUCW Tiene en cuenta la complejidad de casa caso de uso. Se puede hacer de dos maneras: usando las transacciones que genera un caso de uso usando las clases afectadas o que participan en el caso de uso. a) Mtodo de las transacciones. Transaccin: conjunto atmico de operaciones. Se realizan todas o no se realiza ninguna. A B C D E

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA TIPO DE CASO DE USO Simple Medio Complejo SUMA DESCRIPCION Transacciones <= 3 4 <= transacciones <= 7 Transacciones > 7 FACTOR 5 10 CANTIDAD SUBTOTAL C*D C*D C*D Sumatoria E = UUCW

b) Mtodo de las clases. Se contabiliza las clases que participan en el caso de uso. Se obtienen del diagrama de secuencias. A TIPO DE CASO DE USO Simple Medio Complejo SUMA B DESCRIPCION Clases < 5 5 <= clases <= 10 Clases > 10 C FACTOR 5 10 D CANTIDAD E SUBTOTAL C*D C*D C*D E = UUCW

Formula: UUCW = sum (cantidad de un tipo de caso de uso * factor) 24/10/11 Actores 1.1 UAW 1 UUCP = UAW+UUCW 1.2 Transacciones clases Paso 2: Calculo de los puntos de caso de uso ajustados UCP (Use Case Points). Para calcularlos se tiene en cuenta un factor de complejidad tcnica TCF y un factor ambiental EF, aplicndose la frmula: UCP: UUCP * TCF * EF Paso 2.1: evaluar los factores de complejidad tcnica TCF. Se tienen en cuenta 13 factores de complejidad tcnica.

C Peso 2

Factor Descripcin T1 Sistema Distribuido

D Valor 0-5

E Subtotal =C*D

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 T13 Objetivos de Desempeo o tiempo de respuesta Eficiencia del usuario final Procesamiento interno complejo El cdigo debe ser reutilizable facilidad de instalacin Facilidad de uso Portabilidad Facilidad de cambio Concurrencia incluye objetivos especiales de seguridad provee acceso directo a terceras partes Se requiere facilidades especiales de entrenamiento al usuario. 1 1 1 1 0, 5 0, 5 2 1 1 1 1 1

Paso 2.2: Evaluar los factores ambientales EFse tienen en cuenta 8 factores ambientales, los cuales se valoran de 0 5.

A Factor E1 E2 E3 E4 E5 E6 E7 E8

B Descripcin Familiaridad con el modelo de proyecto usado Experiencia en la aplicacin Experiencia en 0.0 Capacidad de analista lder Motivacin Estabilidad de los requerimientos Personal Part - Time (tiempo parcial) Dificultad del lenguaje de programacin

D Valor Peso 0 - 5 1, 5 0, 5 1 0, 5 1 2 -1 -1

E Subtotal C=C+D

Entre mas favorable el ambiente menos puntos de funcin. Paso 3: Calcular el esfuerzo en horas hombre (programador) es factor ms importante es CF, la cantidad de horas hombre que toma construir o realizar un punto de caso de uso. Esta estimacin es para la labor de programacin. El CF depende de los factores ambientales, especialmente aquellos que tengan valores por fuera de lo normal. Para esto se usa la siguiente tabla que se basa en la columna SUBTOTAL.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Factor E1 - E6 E7 - E8 Filtro Subtotal < 3 |Subtotal > 3| Cantidad

CF (Horas-Hombre/Ucp) 20 28 36

Descripcin Valor <= 2 3 <= valor <= 4 valor >= 5

Recomienda evaluar este factor a partir de los datos histricos de proyectos.

Una vez conocemos el CFcalculamos el esfuerzo de programacin del proyecto

E = Esfuerzo de programacin en horas-hombre. Se debe tener una distribucin del esfuerzo del proyecto en todas las fases del ciclo de vida. Se muestra una tabla inicial. Actividad Anlisis Diseo Programacin Pruebas Sobrecarga Total % 10 20 40 15 15 100 Esfuerzo (horas-hombre)

Luego calcular las dems actividades con su %. Cuando se tenga datos histricos de proyectos propios, se debe revaluar esta tabla para encontrar la distribucin real para nosotros. Con el esfuerzo total podemos estimar plazo y costo: Costo de la mano de obra. Luego se toma la decisin del nmero de personas de su equipo de trabajo. ( )

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA 21/11/2011

SG2 DESARROLLAR UN PLAN DEL PROYECTO. Pag 412

Un plan del proyecto en establecido y mantenido como base para administrar el proyecto. Un plan del proyecto es un documento formal, aprobado, usado para administrar y controlar la ejecucin del proyecto. Se basa en os requerimientos del proyecto y estimaciones establecidas. El plan del proyecto debe considerar todas las fases del ciclo de vida del proyecto. La planeacin del proyecto debe asegurar que todos los planes que afecten al proyecto sean consistentes con el plan del proyecto total. SP 2.1 establecer presupuesto y el cronograma. El presupuesto y el cronograma del proyecto se basan en las estimaciones desarrolladas y asegura que la localizacin del presupuesto, la complejidad de las tareas, y las dependencias entre las tareas sean manejadas apropiadamente. Los cronogramas manejados por eventos y limitados por los recursos han demostrado ser efectivos para manejar los riesgos del proyecto. Identificar los cumplimientos a ser demostrados antes de la iniciacin de un evento proporciona alguna flexibilidad en la programacin del evento, una comprensin comn de lo que se espera, una mejor visin del estado del proyecto y un estado ms preciso de las tareas. Ejemplo del producto de trabajo: 1. Cronograma del proyecto. 2. Dependencias del cronograma. 3. Presupuesto del proyecto. Subpraticas: 1. Identificar los mayores eventos (puntos de control). Son eventos pre-planeados o puntos en el tiempo en los cuales se revisa el estado para entender que tan bien se estn cumpliendo los requerimientos de los actores. (Si el proyecto incluye un control de desarrollo, entonces se hace la revisin para asegurar que las suposiciones y requerimientos asociados con el control, se cumplan). Estos puntos de control pueden estar asociados con el proyecto total o un servicio particular o instancia. Los controles pueden estar basados en eventos o en el calendario. Si se basa en el calendario una vez acordadas, las fechas de los controles son difciles de cambiar 2. Identificar las suposiciones del cronograma. Cuando los cronogramas se desarrollan la primera vez, es comn hacer su pociones acerca de la duracin de ciertas actividades. Estas suposiciones son hechas frecuentemente sobre tems en los que no hay datos disponibles para una estimacin.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Identificar estas suposiciones proporciona comprensin sobre el nivel de confianza (o incertidumbres) del cronograma total. 3. Identificar Restricciones. Factores que limitan la flexibilidad de las opciones de administracin, deben ser identificados tan pronto como sea posible. Elexamen de los atributos de los productos de trabajo y tareas a menudo traen estos temas a la superficie. Tales atributos pueden incluir duracin de las tareas, entradas y salidas. 4. Identificar las Dependencias de las Tareas. Frecuentemente, las tareas para un proyecto o servicio pueden ser cumplidas en alguna secuencia ordenada que minimiza la duracin. La secuencia involucra la identificacin de tareas predecesoras y sucesoras para determinar en orden ptimo. Ejemplos de herramientas y entradas que pueden ayudar a determinar el orden ptimo de las actividades incluye los siguientes: El mtodo de la ruta crtica (CPM). Tcnica de Revisin y Evaluacin de Programas (PERT). Cronogramas limitados por recursos. Caractersticasmercadeables. valor para el usuario final. 5. Establecer y mantener el presupuesto y el cronograma. Tpicamente incluye los siguientes: definir la disponibilidad comprometida o esperada de recurso e instalaciones. Determinar las fases de tiempo de las actividades. Determinar una divisin en cronogramas subordinados. Definir las dependencias entre actividades (relaciones predecesoras, sucesoras). Definir el cronograma de actividades y los puntos de control para soportar el monitoreo y control de proyecto. Identificar los puntos de control, liberaciones o incrementos para elenvi de productos al cliente. Definir actividades de duracin apropiada. Definir los puntos de control con la adecuada separacin en el tiempo. Definir una reserva de administracincon base en el nivel de confianza para cumplir el cronograma y el presupuesto. Usar los datos histricos apropiados para verificar el cronograma. Definir los requerimientos de fondos de manera incremental. Documentar las suposiciones y razonamientos del proyecto 6. Establecer criterios para acciones correctivas. Se establecen criterios para determinar que constituye una decisin significativa del plan del proyecto. Una base para medir tales problemas es necesaria para determinar cundo se debe tomar una accin correctiva.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Las acciones correctivas pueden llevar a replantear, lo que puede incluir revisar el plan original, establecer nuevos acuerdos, o incluir actividades de mitigacin en el plan. El plan del proyecto define cuando (bajo qu circunstancias, con qufrecuencia) los criterios sern aplicados y por quien. 22/11/2011

CPM (CRITICAL PATH METHOD)

Desarrollado en 1957 por J.E Kelly de remington Rand M.R Walker de DuPont Mtodo para programar un proyecto que se basa en la topologa de red. 1. Lista de las actividades COD A B C D E F G H I J ACTIVIDAD Elegir local de oficinas Crear plan financiero y de organizacin Determinar requerimientos de personal Disear local Construir el interior Elegir personal a mudar Contratar nuevos empleados Mudar registros, personal clave, etc Hacer arreglos financieros con instituciones de la nueva ciudad Entrenar personal nuevo PREDECESORES DURAC. (SEMANAS) 3 5 3 4 8 2 4 2 5 3

B A,C D C F F B H,E,G

2. Establecer las relaciones de predecesor sucesor entre actividades 3. Estimar la duracin de cada actividad. 4. Construir el grafo o diagrama de red a. Nodos: instantes en el tiempo b. Aristas: actividades Es un grafo orientado (flechas) Se hace con los predecesores

Ilustracin 9 Grafo Orientado a Flechas. (Est en el cuaderno)

5. Calcular los tiempos mas prontos que las actividades pueden empezar y terminar: PI= Punto de Inicio. PT= punto de terminacin d = duracin

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA PT = PI + d 6. Calcular los tiempos ms tardos que las actividades pueden empezar y terminar. TI = Tardo Inicio TT = TardoTerminacin d = duracin TI = TT d 7. Calcular la holgura: el tiempo que se puede retrasar la tarea H = TT Pt H = TI PI 8. Se determinar la ruta crtica como aquellas actividades que no tienen holgura. Es el camino ms largo para ir del inicio al final Ruta crtica: B-C-D-E-J Duracin proyecto: 23 semanas COD. DURA. PI PT TI TT H A 3 1 3 6 8 5 B 5 1 5 1 5 0 C 3 6 8 6 8 0 D 4 9 12 9 12 0 E 8 13 20 13 20 0 F 2 9 10 15 16 6 G 4 11 14 17 20 6 H 2 11 12 19 20 8 I 5 6 10 19 23 13 J 3 21 23 21 23 0 Lo que se entrega como CRONOGRAMA es el pronto inicio y la pronta terminacin de cada actividad.

El Diagrama de Gantt
Desarrollado por Henry L. Gantt en 1928, es una forma elegante y sencilla de mostrar un cronograma. Consta de dos partes: actividades, calendario

ACTIVIDAD A B C D E F G H I

3 4

9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA J Se acostumbra a marcar con una lnea gruesa horizontal la ejecucin de las actividades para mostrar el avance del proyecto en una fecha dada. 25/11/11 El presupuesto del proyecto. Es el clculo del costo de proyecto organizado por actividades (es decir el costo de cada actividad). Para ello es necesario establecer que recursos utiliza cada recucurso. Para el proyecto del traslado de una empresa a otra ciudad tenemos los siguientes recursos: Cd. A R Q I O V C E Recurso administrador jefe de recursos humanos arquitecto ingeniero civil obrero camin conductor entrenador Salario 5,000,000 3,000,000 2,500,000 2,800,000 700,000 5,000,000 900,000 1,500,000 Costo/mes 7,500,000 4,500,000 3,750,000 4,200,000 1,050,000 5,000,000 1,350,000 2,250,000 Costo/dia 312,500 187,500 156,250 175,000 43,750 208,333 56,250 93,750

A hora revisamos los recursos que utiliza cada actividad.

Cd. A B C D E F G H I J

Actividad Elegir local Plan financiero Req. De personal Disear local Construir el interior Elegir personal a mudar Contratar nuevos empleados Mudar todo Arreglos financieros Entrenar Personal nuevo

Semana 3 5 3 4 8 2 4 2 5 3

Dias 18 30 18 24 48 12 24 12 30 18

Recursos A A A+R A+Q I+50 A+R R A+30+2V+26 A E

Costo/da 312,500 312,500 500,000 468,750 393,750 500,000 187,500 947,916 312,500 43,750

Costo 5,625,000 93,750,000 9,000,000 11,250,000 18,900,000 6,000,000 4,500,000 11,374,992 9,375,000 1,687,000

El costo es el presupuesto del proyecto. Total costo = 87,087,488.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA

FLUJO DE CAJA
Es la necesidad de dinero del proyecto en cada periodo de tiempo. En este proyecto usaremos los meses. Se puede hacer fcil a partir del diagrama de gant Cd. A B C D E F G H I J PI 1 1 6 9 13 4 11 11 6 21 PT Costo/Sem 3 1,875,000 5 1,875,000 8 3,000,000 12 2,812,500 20 2,362,500 10 3,000,000 14 1,123,000 12 5,687,496 10 1,875,000 23 562,500

1 2 3 4 5 6 7 8

10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

3A+4B 1

B+3C+3I 2 4D+2F+26+24+2I 3

4E+26 4

4E 5

3J 6

1. 2. 3. 4. 5. 6.

13,125,000 16,500,000 34,624,992 11,700,000 9,450,000 1,687,500

19/11/2012

PERT COSTO

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA As como existe incertidumbre en la duracin de las actividades, tambin hay incertidumbre en el costo de cada actividad habiendo una tendencia general hacia el sobrecosto. El estudio de la incertidumbre en el costo del proyecto involucra a todas las actividades, no solo a la ruta crtica. PREGUNTA Cul es la probabilidad de que este proyecto cueste menos de $ 95.000.000?

Comentarios: 1. El factor laboral es el factor que se le aplica al salario para obtener el costo mensual para la empresa. Tiene en cuenta todas las presentaciones sociales y los para fiscales. Es aproximadamente 1.50. 2. Das laborados/semana, son 6 de acuerdo con la legislacin laboral. 3. Das laborados al mes, suponemos que el mes consta de 4 semanas, as que se labora 24 das al mes. 4. En el lugar de aceptar un anticipo de 50% al inicio y 50% al final, es mejor factor el flujo de caja y tener cada mes con que pagarle al personal.

ACELERACION DE PROYECTOS.
Muchas veces la programacin de un proyecto no satisface las necesidades o urgencias del cliente en cuanto a las fechas de entrega. Otras veces sucede que los costos fijos del proyecto son muy grandes y ameritan reducir el plazo del mismo. Hay dosenfoques a la hora de acelerar un proyecto. Enfoque estratgico: consiste en revisar de manera crtica las relaciones entre las tareas y restricciones del proyecto. Enfoque tctico: trabajar ms horas cada da para hacer el proyecto ms rpido. En desarrollo de software no es tan factible hacer varios turnos. La misma persona tiene que trabajar ms horas al da lo que nos lleva al pago de horas extras. 28/11/11

Enfoque Estratgico
Ilustracin 10 grafo de actividades

Una mirada crtica al proyecto nos puede indicar que para realizar la actividad J entrenar personal nuevo debe terminar demasiadas actividades: E construir el interior del local G Contratar nuevos empleados H Mudar

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA De las anteriores actividades, la nica que realmente tiene una relacin de causalidad es la G. Para poder entrenar el personal nuevo, primero hay que contratarlo. Las otras actividades E y H suponen que vamos a entrenar el nuevo personal, en el nuevo local, pero esto no tiene que ser as. Podemos entrenar el nuevo personal en un saln alquilado y as no hay que esperar a que terminen de construir el nuevo local. Surge una nueva actividad K alquilar saln para capacitacin
Ilustracin 11 Nueva actividad

Como puede observarse, con el cambio propuesto, al sacar la actividad J de la ruta crtica, el proyecto ahora tiene una duracin de 20 semanas y hemos ahorrado as semanas a cambio de hacer pequeas inversiones en el alquiler de un saln para capacitar a los nuevos empleados.

ENFOQUE TACTICO
Consiste en acelerar el proyecto trabajado ms horas al da. El cdigo laboral indica el mx.De horas que una persona puede laborar cada da. Un trabajador puede laborar mximo 12 horas cada ida, de las cuales 8 horas pueden corresponder a su jornada normal y 4 horas sern extras adems segn el cdigo laboral, se pueden pagar las horas extras (hasta las 10 pm) a 1.25 el valor de la hora normal. Adems en la mayora de las empresas, el personal que se considera de manejo y confianza no tiene derecho a horas extras, normalmente se trata de gerentes y jefes. Para el proyecto de ejemplo los recursos tienen los siguientes costos:
A COD A R Q I O V C E B RECURSO Administrador Jefe recursos humanos Arquitecto Ing. civil Obrero Comisin Conductor Entrenador C SALARIO 5.000.000 3.000.000 2.500.000 2.800.000 700.000 5.000.000 900.000 1.500.000 D E F COSTO/HORA 39.063 23.438 19.531 21.875 5.469 39.063 7.031 11.719 E/8 F*1,35 G COSTO HORA EXTRA NOCTURNA 52734 31641 26367 29531 7383 52734 9492 15820 H COSTO HORA EXTRA DIURNA 48828 29297 24414 27344 6836 48828 8789 14648 F*1,25

COSTO/MES COSTO/DIA 7.500.000 4.500.000 3.750.000 4.200.000 1.050.000 7.500.000 1.350.000 2.250.000 C*1,50 312.500 187.500 156.250 175.000 43.750 312.500 56.250 93.750 D/24

Comentarios 1. El camin no tiene factor salarial porque no es una persona y tampoco se le incrementa la hora extra. 2. El administrador y el jefe de recursos humanos se consideran empleados de manejo y confianza y no se les incrementa el valor de la hora extra.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Cuando es negocio pagar horas extras? Solamente a las actividades de la ruta crtica que son las que pueden acostar la duracin del proyecto. Todo proyecto tiene unos Costos indirectos los cuales no tienen relacin directa con el trabajo sino q son parte de una infraestructura recesara. Ej.Secretaria, contador, arrendamiento, servicios pblicos, celadura, etc. Son costos administrativos. Si el valor por hora de los costos indirectos es mayor que el invertido en hora sextas, es negocio acelerar (inversin es la diferencia entre hora normal y extra) En el presente ejemplo, supondremos que el valor de los costos indirectos es de 100000 $/hora. Segn la legislacin laboral, se dentrabajar 48 hora/semana.

COD SEM A B C D E F G H I J IND 3 5 3 4 8 2 4 2 5 3 23

REC A A A+R A+Q I+50 A+R R A+30+2V+2C A E

$/H $/H NORMAL EXTRA 39.062 39.062 46.876 58.593 32.814 46.876 23.438 77.345 39.062 11.719 100.000 39.062 39.062 46.876

DIF 0 0

TOTAL HORAS HORAS COSTO/HORA COSTO/HORA COSTO TOTAL HORAS NORMALES EXTRAS NORMAL EXTRA 144 240 144 192 384 96 192 96 240 144 1104 B*48 G-I 144 240 144 192 384 96 192 96 240 144 1104 0 0 0 0 0 0 0 0 0 0 0 5.624.928 9.374.880 6.750.144 11.249.856 12.600.576 4.500.096 4.500.096 7.425.120 9.374.880 1.687.536 110.400.000 D*H E*I 0 0 0 0 0 0 0 0 0 0 5.624.928 9.374.880 6.750.144 11.249.856 12.600.576 4.500.096 4.500.096 7.425.120 9.374.880 1.687.536 110.400.000 183.488.112 J+K

0 63.476 4883 41.016 8202 46.876 23.438 0 0

86.914 9569 39.062 0 14.649 2930 E-D

29/11/2011
Ilustracin 12, GRAFO 2
$/H NORMA L 39,062 39,062 62,500 58,593 49,220

COD A B C D E

SEM RECURSOS 3 5 3 4 8 A A A+R A+Q I+50

$/H EXTRA 39,062 39,062 62,500 63,476 61,524

DIF 0 0 0 4883 12304

TOTAL H. 144 240 144 192 384

H. NORMALES 144 160 96 192 384

H.EXTRA $ S NORMALES 5,624,928 80 48 6,249,920 6,000,000 11,249,856 18,900,480

$ EXTRAS

$ TOTAL 5,624,928

3,124,960 3,000,000

9,374,880 9,000,000 11,249,856 18,900,480

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA

F G H I J IND 2 4 2 5 3 23 A+R R A+30+2V+2 C A E 62,500 23,438 121,615 39,062 11,719 100,000 62,500 23,438 129,232 39,062 14,649 0 0 7617 0 2930 96 192 96 240 144 96 192 96 240 144 1104 6,000,000 4,500,096 11,675,040 9,374,880 1,687,536 97,600,000 6,000,000 4,500,096 11,675,040 9,374,880 1,687,536 97,600,000 184,987,69 6

Para acelerar: 1. Acelerar tareas criticas 2. Primero la menos costosa de acelerar 3. Podemos colocar como horas extras hasta la tercera parte de la duracin IT EXPLICACION 1. B : 80 HE C: 48 HE 2. J: 48 HE 3. D: 64 E: 128 COMENTARIOS: 1. La tarea que obtenga el mximo de horas extras debe marcarse como sutura (=) 2. Hay que verificar que no se formen nuevas rutas crticas. Si se forman entonces debo igualar los dos caminos y luego, en otra iteracin tratar de acelerar ambos. 3. Hay que verificar que la inversin por hora (diferencia) sea menos que una hora de costos indirectos, para que sea negocio y el costo disminuye. 4. Cuando el proyecto ya no se puede acelerar mas, decimos que esta optimizado. 5. La duracin de 736 horas equivalen a: 15.33 semanas.

P.E.R.T PROGRAM EVALUATION AND REVIEW TECHNIQUE.

HISTORIA: Desarrollado en 1950 por la NavySpartialProjects Office, para el proyecto del misil polaris. Este proyecto tenia gran incertidumbre porque nunca haban construido un misil. Contrataron cpnBozz, allen y Hamilton una metodologa para proyectos con incertidumbre. Los consultores estudiaron miles de proyectos para obtener un modelo estadstico de la duracin de una actividad. Llegaron a la conclusin de que era ms probable que una actividad se retrasase a que se adelantase y que la duracin real de una actividad responde a una distribucin beta

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA

PARA TRABAJAR CON LA DISTRIBUCION BETA, CADA ACTIVIDAD NECESITA TRES DURACIONES: A = duracin optimista M = duracin ms probable B = duracin pesimista 02/12/2011 Una vez considerada la tendencia de cada actividad individual a retrasarse, nos preguntamos, Qu paso con la duracin total del proyecto? Esta duracin est dada por las actividades de la ruta crtica. Cul de las actividades de la ruta crtica se va a alejar del valor medio? En este caso no hay una tendencia puede ser cualquiera por lo tanto podemos considerar que la duracin del proyecto es una variable aleatoria que sigue la distribucin normal de probabilidades. Generalmente la duracin de una actividad es independiente de la duracin de las otras actividades. Si no fuera si, habra que considerar la probabilidad condicional. Pero una de las suposiciones del mtodo PERT es la independencia de la duracin de la actividad. As, no hay probabilidades condicionales y podemos calcular la varianza de la ruta crtica como la suma de las varianzas de las actividades individuales. Sacndole raz cuadrada a la varianza, obtenemos la desviacin estndar de la ruta crtica. Sumando las duraciones de las actividades que pertenecen a la ruta crtica, obtenemos la duracin media del proyecto. Teniendo la media y la desviacin estndar de la duracin del proyecto podemos usar una tabla de probabilidades de la distribucin normal y obtener la probabilidad de cumplir para cualquier desviacin a partir de la media.

B 50% A

media

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Los libros de estadstica suelen tener varios tipos de tablas, segn el rea considerada.

B 50% A

A continuacin se muestra un proyecto con el mtodo PERT.

Ilustracin 15 Grafo actividad PERT.

D. Act a m b ESPERADA A 1 3 5 3 B 3 4.5 9 5 C 2 3 4 3 D 2 4 6 4 E 4 7 16 8 F 1 1.5 5 2 G 2.5 3.5 7.5 4 H 1 2 3 2 I 4 5 6 5 J 1.5 3 4.5 3 K 1 3 5 3 (a+4m+b)/6

D. ESTNDAR 2/3 1 1/3 2/3 2 2/3 5/6 1/3 1/3 1/2 2/3 (b-a)/6

VARIANZA 4/9 1 1/9 4/9 4 4/9 2/3 1/9 1/9 4/9 [(b-a)/6]^2

Se obtiene de las duraciones esperadas de la ruta crtica.

Se obtiene sumando la varianza de la ruta crtica.

LA PREGUNTA DEL PROBLEMA

El mtodo PERT lo que hace es dar la probabilidad de cumplir en cierta fecha.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Para este problema preguntamos cual es la probabilidad de terminar antes de 22 semanas?

En las tablas de la distribucin normal la desviacin (X) est en unidades de desviaciones estndar.

X = 0.84 Prb= 0.7995

0.85 0.8023

Como necesitamos la probabilidad para x = 0.8485 toca interpolar P = 0.80188 Respuesta, la probabilidad de terminar antes de 22 semanas es de 80.188% Nuevo problema: Entonces dgame cual es la duracin para una probabilidad de cumplimiento del 95% 1.64 0.9495 ( ) 1.65 0.9505

Ah que equivalen 1.645 dev estndar en semanas?

Plazo, R/ para una probabilidad de cumplimiento del 95% la duracin del proyecto debe ser de 23.877 semanas.

05/12/2011 En la clase anterior vimos cmo usar e mtodo PERT para manejar la incertidumbre en la duracin de las actividades y la duracin del proyecto. Hoy veremos las incertidumbres relacionadas con el costo del proyecto.

P.E.R.T COSTO
LOS COSTOS del proyecto heredan la incertidumbre de la duracin del proyecto. La diferencia en que todas las actividades participan en los costos. El costo de la mano de obra depende de la duracin de las actividades, pues tenemos el costo por hora. Si las horas cambian, cambia el costo. Veamos el ejemplo.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA A ACT A B C D E F G H I J K C D SEMANAS a m b 1 3 5 3 4.5 9 2 3 4 2 4 6 4 7 16 1 1.5 5 2.5 3.5 7.5 1 2 3 4 5 6 1.5 3 4.5 1 3 5 B E COSTO / HORA 39,062 39,062 62,500 52,593 49,220 62,500 23,438 121,615 39,062 11,719 20,000 F A 1,874,976 5,624,928 6,000,000 5,048,928 9,450,240 3,000,000 2,812,560 5,837,520 7,499,904 843,768 960,000 B*E*48 G M 5,624,928 8,437,392 9,000,000 10,097,856 16,537,920 4,500,000 3,937,584 11,675,040 9,374,880 1,687,536 2,880,000 C*E*48 H I J COSTO ACTIVIDAD b ESPERADO VARIANZA 9,374,880 5,624,928 1,562,460,000,256 16,874,784 9,374,880 3,515,535,000,576 12,000,000 9,000,000 1,000,000,000,000 15,146,784 10,097,856 2,832,408,216,576 37,800,960 18,900,480 22,326,759,014,400 15,000,000 6,000,000 4,000,000,000,000 8,437,680 4,500,096 878,943,750,400 17,512,560 11,675,040 3,786,293,305,600 11,249,856 9,374,880 390,615,000,064 2,531,304 1,687,536 79,104,937,536 4,800,000 2,880,000 409,600,000,000 D*E*48 89,115,696 40,781,719,225,408 (a+4m+b)/6 [(b-a)/6]^2

PREGUNTA: Cul es la probabilidad de que el proyecto cueste $100,000,000?

De la tabla de distribucin normal tenemos: 1.70 0.9554 1.71 0.9564

( ( ( RESPUESTA: )

) )

La probabilidad de que el proyecto cueste $100,000,000 es de 95.584% PREGUNTA 2: Cual sera el costo del este proyecto para una probabilidad de cumplimiento del 98%?

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA De la tabla de la distribucin normal tenemos: Z P 2.05 0.9798 2.06 0.9803

Debemos interpolar:

RESPUESTA 2: Para que la probabilidad de cumplimiento sea del 98%, el costo del proyecto debe ser de 102,232,657.

LA COTIZACIN
Todo el planeamiento del proyecto debera realizarse antes de comprometerse firmando un contrato. Luego de hacer la planificacin hay que presentarle al cliente una oferta que se denomina COTIZACIN. La idea es mostrarle al cliente con total trasparencialos detalles del proyecto. Se acostumbra dividir la oferta comercial en dos partes. 1. PROPUESTA TCNICA: Esta propuesta debe indicar nuestra comprensin del proyecto: Contexto Antecedentes Justificacin Viabilidad Objetivos Requerimientos tenidos en cuenta. Cronograma Restricciones tenidas en cuenta para el cronograma Presupuesto Suposiciones para el presupuesto 2. PROPUESTA ECONMICA: Esta propuesta debe contener un resumen de los costos, las utilidades del contratista y los impuestos que hay que pagar. A. Costos (a+b) $ 128,500,000

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA a. Costos directos $ 108,000,000 Los que participan de manera directa en el trabajo. i. Mano de obra $ 100,000,000 ii. Materiales $ 5,000,000 iii. Equipos $ 3,000,000 b. Costos Indirectos $ 20,500,000 Mantienen la infraestructura necesaria para el proyecto i. Oficina (5 meses) $ 10,000,000 ii. Admn. y Celadura $ 2,500,000 iii. Secretaria $ 5,000,000 iv. Contador $ 3,000,000 A.I.U (Administracin, Imprevistos, Utilidades) $ 38,550,000 30% de a+b $ 38,550,000 TOTAL ANTES DE IMPUESTOS (a+d) $ 147,050,000 IMPUESTOS $ 27,786,670 a. I.V.A (16%) $ 23,528,000 b. Timbre (1.5%) $ 2,558,670 c. Estampilla Pro Desarrollo (1%) $ 1,700,000 TOTAL DEL PROYECTO $ 174,836,670

B. C. D.

E.

12/12/2011

Fenmeno de la Contratacin.
Debemos solicitar en el contrato algunas clusulas que nos protejan. 1. Incumplimiento por parte del cliente en los pagos: No es suficiente colocar el cobro de inters. En este incumplimiento el proyecto se debera parar, y reanudarse cuando el cliente decida continuar con los pagos. 2. Fecha para congelar requerimientos Se debe establecer de acuerdo con el cronograma, la fecha en la cual termina la fase de requerimientos. Hasta esta fecha se acepta cambios en los requerimientos sin impacto adicional en el proyecto. Los cambios y nuevos requerimientos que surjan despus de esta fecha tendrn un impacto en la duracin (fecha de entrega) y costo del proyecto. 3. Arbitramiento en caso de conflictos Si sucede un conflicto, se nombra un rbitro. Las partes se comprometen a hacer lo que diga el rbitro se recomienda que el rbitro sea alguien que conozca de proyectos de ingeniera de software (una autoridad acadmica). 4. Casos Fortuitos En caso de: Asonadas Tomas guerrilleras o sucesos que alteren el orden publico Catstrofes naturales: terremotos, inundaciones, etc.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA El contratista puede llegar a incumplir con las fechas pactadas e incluso con el presupuesto y no ser su culpa. Debe analizarse con el cliente y llegar a un acuerdo sobre los nuevos plazos y presupuestos.

Sobre Impuestos 1. La retencin en la fuente (10%) se considera un adelanto a la declaracin de renta del contratista. No es factible cobrarle esto al cliente. Se supone que al hacer la declaracin de renta, de los impuestos a pagar, le contratista resta las retenciones en la fuete. Es posible que la Dian le quede debiendo dinero y el contratista se haga merecedor a una DEVOLUCION. Solamente si la contabilidad es perfecta, y tiene todos los soportes, se podra cobrar este dinero. La inmensa mayora de las veces, las devoluciones son incobrables. 2. Antes de hacer la cotizacin, hay que averiguar exactamente las tasas de impuestos a pagar, como se calculan y cul es su soporte legal. Cualquier equivocacin la terminara pagando el contratista. Sobre el AIU Teniendo en cuenta que el gobierno ya se va a quedar con el 10% de rete fuente, el AIU debe ser mayor del 10%. La verdadera utilidad es AIU menos el 10%. Teniendo en cuenta que el gobierno se queda con aprox el 30% del dinero del proyecto sin hacer ningn esfuerzo, porque el contratista, que est corriendo riesgos, no puede ganar ms que esta? Teniendo en cuenta los riesgos seria justos para el contratista un AIU del 50%. Pero casi ningn cliente acepta esta utilidad. Por esta razn generalmente al contratista termina preguntndole al cliente cuanto pagara de AIU y el resto suele distribuirse como un mayor valor en los sueldos del personal. Por esta razn generalmente los sueldos que aparecen en el proyecto que se presenta al cliente no son los sueldos reales. Dentro del contrato de cada persona se le hace firma una CLAUSULA DE CONFINCIALIDAD en la cual se compromete a no divulgar su salario. Sobre los Anticipos 1. El dinero del anticipo no es del contratista y no se le debe gastar en casos que no sean del proyecto. 2. Se requiere gran disciplina para manejar el anticipo. 3. Si pagan 50% de anticipo y 50% al terminar, es posible que el anticipo no alcance para terminar el proyecto. En este caso, necesitamos un crdito bancario y podemos usar el dinero del anticipo para Apalancar el crdito. El anticipo nos da la oportunidad del negociar unas buenas condiciones para el crdito. 4. Si en la vida del proyecto es necesario hacer un crdito la cotizacin debera incluir estos intereses para que los pague el cliente.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA 5. En lugar de aspirar a un gran anticipo el contratista debera aspirar a pactar el flujo de caja del proyecto. Que cada mes le den lo necesario para cubrir los gastos de este mes.

MANTENIMIENTO DEL SOFTWARE

Se puede hablar como mnimo de tres tipos de mantenimiento: 1. Correctivo: Se trata de corregir errores que trae el producto de software. Es tipo de mantenimiento est incluido en la garanta del producto. El cdigo del comercio pide una garanta mnima de 6 meses para cualquier producto suministrado. 2. Cambios en los requerimientos. 3. Nuevos requerimientos En caso de cambios o nuevos requerimientos el desarrollador debe poder hacerlo pero cobrando su trabajo. Se acostumbra ofrecerle al cliente un contrato de mantenimiento o una oferta de servicios informndole de los precios, por ejemplo, el valor por hora del trabajo. Es muy comn que quieren hace el mantenimiento no participo en el desarrollo del programa. En estos casos es muy importante la documentacin que el cliente tenga del programa. En proyectos grandes y complejos, los cambios al proyecto para el mantenimiento pueden tener efectos colaterales los cuales son errores difciles de atrapar y que se van acumulando. Los errores acumulados generan ms mantenimiento y el costo del mantenimiento se puede disparar.

13/12/2011

REFACTORING
Tomado del libro: Refactoring: Improving the Design of Existing Code Autor: Martin Fowler. Qu es Refactoring? Refactoring es el proceso de cambiar un sistema de software en tal forma que no se altere el comportamiento externo del cdigo pero que mejore su estructura interna. Es una forman disciplinada para limpiar el cdigo que minimiza la probabilidad de introducir errores. En esencia, cuando usted realiza refactoring, est mejorando el diseo del cdigo despus de que ha sido escrito.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA

CAPITULO 1: Ejemplo de Refactoring

Suponga que el cdigo que se va a mostrar forma parte de un sistema mucho ms grande. El ejemplo trata de una tienda de video y el programa debe mostrar e imprimir los cobros de un cliente que se origina en las pelculas que el ah alquilado. Al programa se le dice que pelculas ha rentado el cliente y por cuanto tiempo. Entonces calcula los cobros que dependen del tiempo que rento la pelcula y del tipo de pelcula. Hay clases de pelculas: para nios (children), regulares y estrenos (new releases). Adems de los cobros el programa calcula los puntos de renta frecuente que varan dependiendo de si la pelcula es un estreno o no. Las clases relacionadas con el problema son:

Movie 1 * Rental * 1 PriceCode: int <------------- daysRented: int <--------------

Customer statement()

Ahora veamos el cdigo para cada clase: Public class Movie { public static final int CHILDRENS = 2; public static final int REGULAR = 0; public static final int NEW_RELEASE = 1; privateString_title; privateint_priceCode; public Movie (String title, int priceCode) { _title = title; _priceCode = priceCode; } publicintgetPriceCode() { Return _priceCode; } public void setPriceCode (int org) { _priceCode = arg; } public String getTitle()

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA { return _title; } } Class Rental { private Movie _movie; privateint _dayRented; public Rental (Movie movie, intdaysRented) { _movie = movie; _daysRented = daysRented; } Public intgetDaysRented() { return _daysRented; } Public Movie getMovie() { Return _movie; } } Class Customer { Private String _name; private Vector _rentals = new Vector(); public Customer (String name) { _name = name; } Public void addRental (Rental arg) { _rentals.addElement(arg); } Public String getName () { Return _name; } public String statement () { Double totalAmount = 0; IntfrequenRentedPoints = 0;

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Enumeration rentals = _rentals.elements(); String result = Rental Record for + getName() + \n; while (rentals.hasMoreElemets()) { Double thisAmount = 0; Rental each = (Rental) rentals.nextElement(); // Determina el monto para cada linea switch (each.getMovie().getPriceCode()) { caseMovie.REGULAR: thisAmount += 2; if (each.getDaysRented () > 2) thisAmount += (each.getDaysRented() -2) *1.5; break; caseMovie.NEW_RELEASE: thisAmount += each.getDaysRented()*3; break; case MOVE.CHILDRENS: thisAmount += 1.5; if (each.getDaysRented () > 3) thisAmount += (each.getDaysRented() -3) * 1.5; break; } // switch // Agrega los puntos de renta frecuente frequentRenterPoint ++; // Agregabonus por rentar un estreno dos das If ((each.getMovie().getPriceCode()==Movie.NEW_RELEASE) &&each.getDaysRented() > 1) frequentRentedPoint ++; //Muestra los datos para esta renta Result += \++ each.getMovie().getTitle()+\+ + String.valueOf(thisAmount) + \+totalAmount += thisAmount; } //while // agregalineas de pie de pagina Result += Amount owed is + String.valueOf(totalAmount) + \n; Result += you earned + String.valueOf(RequesterPoints) +frequent renter point; Return result; } }
Ilustracin 16 Interacciones del mtodo Statemet()

Podemos observar que todo el trabajo del programa esta recargado en el mtodo statement. Se supone que en un diseo orientado a objetos. Los comportamientos del sistema son el resultado de la colaboracin entre las diferentes clases, lo cual no pasa en este programa, pues el comportamiento principal est en un solo mtodo.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Si el cdigo fuera a quedarse esttico, a pesar de ser feo, funciona y se podra quedar as. Pero en el momento de hacer un mantenimiento el ser humano que lo haga se enfrentar a graves problemas. Los clientes les gustara hacer un cambio. Que adems de imprimir la factura esta pueda verse en la web. Es decir en formato HTML Obsrvese la implicacin del cdigo para suplir esta necesidad. No parece haber partes reutilizables en el clculo. Lo nico que podemos hacer es sacar una copia, darle otro nombre de mtodo (htmlStatement)y modificar este mtodo para generar la factura en la web. Y que pasara si se cambia las reglas para los clculos? Habr que hacer los cambios en Statement y en htmlStatement, es decir, doble trabajo. En este punto debemos decir que los clientes desean hacer u segundo cambio sobre la clasificacin de las pelculas, pero aun no terminan de decir cmova a quedar. Esto va a afectar la forma como se calculan los cobros y los puntos de renta frecuente. Lo nico que sabemos es que esto va a cambiar en los siguientes seis meses. Los cambios habrn de hacerse a los dos programas y asegurarse de que estos dos sean consistentes. Existe la tentacin a no hacer nada, esperar a que los cambios lleguen para enfrentarlos. Pero cuando estos cambios lleguen, tendremos graves problemas. Podemos facilitar los mantenimientos futuros mediante el refactoring del programa. Que hacer algn cambio sea algo sencillo en lugar de traumtico.

16/12/2011

EL PRIMER PASO DEL REFACTORING

El primer paso siempre es la construccin de un conjunto de pruebas que nos ayuden a verificar si el programa ha cambiado su comportamiento al realizar los cambios de refactoring. En el caso presente, hay que crear un conjunto inicial de datos: algunos clientes, algunas pelculas y algunos alquileres o rentals. Como resultado de statement es una cadena podemos generar la cadena antes de hacer cualquier cambio y luego comprara el resultado producido cuando se hagan cambios contra la cadena original. Automatizamos la forma de llamar a la prueba de tal manera que la comparacin de la cadena la haga el computador y si son iguales nos salga un mensaje ok. Si son diferentes, debe incluir un informe de las lneas que han cambiado. Si la prueba es fcil y eficiente de hacer, llamarla repetidamente no representa una carga para el desarrollo.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA A medida que hagamos refactoring, confiamos en que la prueba nos dijo si introdujimos algn error. Si desea ms informacin sobre pruebas, vaya capitulo 4. Descomponer y Redistribuir el Mtodo Statement () El primer objetivo obvio del refactoring es el mtodo Statement () el cual es muy largo. Este mtodo es un caso de baja cohesin porque sus partes: el clculo de cobro, el clculo de los puntos de renta frecuente y la impresin de las facturas son requerimientos distintos pero estn entre mezclados en el mtodo statement (). Una meta es distribuir las partes del mtodo para hacerlo ms pequeo. Al distribuir estas partes a clases ms adecuadas, ser ms fcil construir el mtodo htmlstatement (). Aplicaremos un procedimientos de refactoring llamado ExtractMethod(Extraer Mtodo). Una parte factible para aplicar el procedimiento es en la instruccin switch. Queremos extraer cada rama de la instruccin switch como un mtodo aparte. Pero para poder hacerlo, debemos pensar en que puede ir mal, para no introducir un error. Lo primero que tenemos que hacer para extraer un fragmento de cdigo y convertirlo en un mtodo es mirar sus variables. Estas variables se convertirn en los parmetros y variables locales del mtodo. El segmento de cdigo usa las variables each y thisAmount. De estas dos, eachno se modifica para thisAmount si es modificada. Las variables no modificadas se pueden pasar como parmetros. Las variables modificadas hay que mirarlas con ms cuidado. Si solo hay una variable modificada, se puede retornar. Es importante mirar con que valor inicia la variable modificada. En nuestro caso inicia con 0 para cada iteracin del while. Asi que solo tenemos que asignarle el resultado. Cdigo antes: While (rentals.hasMoreElements ()) { Double thisAmount = 0; Rental each = (Rental) rentals.nextElement (); // Determina el monto para cada lnea switch (each.getMovie().getPriceCode()) { caseMovie.REGULAR: thisAmount += 2; if (each.getDaysRented () > 2) thisAmount += (each.getDaysRented() -2) *1.5; break;

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA caseMovie.NEW_RELEASE: thisAmount += each.getDaysRented()*3; break; case MOVE.CHILDRENS: thisAmount += 1.5; if (each.getDaysRented () > 3) thisAmount += (each.getDaysRented() -3) * 1.5; break; } // switch Luego de aplicar el procedimiento para extraer mtodos, el programa quedo asi: public String statement () { Doubl totalAmount = 0 Int frequent Renter Points = 0; Enumeration rentals = _rentals.elements(); String result = Rental Record for+ genName () + \n; While (rentals.hasMoreElements () ) { double thisAmount = 0; Rental each = (Rental) rentals.nextElement(); thisAmount = amountFor (each); // agregar puntos de renta frecuete frequentRenterPoints ++; // agregarbonus por renta de dos dias: If ( (each.getMovie ().getPriceCode () == Movie.NEW_RELEASE) &&each.getDaysRented()> 1) frequentRenterPoints ++; // muestra los resultados para esta renta Result += \+ + each.getMovie ().getTitle () + \+ + StringvalueOf (thisAmount) + \n; totalAmount += thisAmount; } // agregarlineas al pre Result += Amount owed is+ String.valueOf (totalAmount) + \n; Return result; } private in amountFor (Rental each) { Int thisAmount = 0; switch (each.getMovie().getPriceCode()) { caseMovie.REGULAR:

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA thisAmount += 2; if (each.getDaysRented () > 2) thisAmount += (each.getDaysRented() -2) *1.5; break; caseMovie.NEW_RELEASE: thisAmount += each.getDaysRented()*3; break; case MOVE.CHILDRENS: thisAmount += 1.5; if (each.getDaysRented () > 3) thisAmount += (each.getDaysRented() -3) * 1.5; break; } // switch return thisAmount; } El autor luego de realizar este cambio corro las pruebas. Al corregir el programa nos enteramos de que la variable thisAmount es de tipo double y en los cambios queda de tipo int. Se debe corregir el nuevo mtodo para que quede double. Private double amountFor (Rental each) { Double thisAmount = 0; }

19/12/11 El siguiente paso en renombrar las variables de amountforpara que el mtodo sea mas legible. private double amountFor(Rental aRental) { doubleresult = 0; switch (aRental.getMovie().getPriceCode()) { caseMovie.REGULAR: result+= 2; if (aRental.getDaysRented() > 2) result+= (aRental.getDaysRented() - 2) * 1.5; break; caseMovie.NEW_RELEASE: result+= aRental.getDaysRented() * 3;

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA break; caseMovie.CHILDRENS: result+= 1.5; if (aRental.getDaysRented() > 3) result+= (aRental.getDaysRented() - 3) * 1.5; break; } returnresult; }

Moviendo el clculo del monto: Actualmente el mtodo amountFor esta dentro de la clase Customer pero observe que no utiliza los atributos ni los mtodos de esta clase. Esta es una indicacin de que el mtodo amountFor esta dentro de la clase incorrecta. Debido a que utiliza el parmetro aRental que es de tipo Rental, parece mas largo que el mtodo amountFor pertenezca a la clase Rental. El procedimiento de refactoring que permite mover un mtodo de una clase a otra se llama movemethod. Aplicando el procedimiento el mtodo amountFor queda as: class Rental { ... doublegetCharge() { double result = 0; switch (getMovie().getPriceCode()) { caseMovie.REGULAR: result += 2; if (getDaysRented() > 2) result += (getDaysRented() - 2) * 1.5; break; caseMovie.NEW_RELEASE: result += getDaysRented() * 3; break; caseMovie.CHILDRENS: result += 1.5; if (getDaysRented() > 3) result += (getDaysRented() - 3) * 1.5; break; } return result; } } En la clase Customer la invocacin al mtodo cambia.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA class Customer { Private double amountFor (Rental aRental) { ReturnaRental.getcharge(); } } Al hacer esto, no tenemos que cambiar el mtodo statement. Asi, los cambios, si generan algn error, quedan limitados a las metas Customer.amountFor() y Rental.getcharge(). Luego de hacer estos cambios se corren las pruebas. Si todo funciona bien, estamos listos para el siguiente paso: Cambiar cualquier referencia al mtodo amountFor () por una referencia al mtodo getcharge(). Solo se afecta una lnea del programa statement Lnea anterior thisAmount = amountFor (each); Esta lnea se cambia por: thisAmount = each.getcharge(); Luego de hacer esto se elimina el mtodo amountFor porque ya nadie lo llama. El siguiente diagrama de clases refleja el cambio: movie Price Code: int 1 Rental daysRented: int getcharge() * * Customer Statement() 1

En este momento, la variable thisAmount en el mtodo statement tiene el mismo valor que el retornado por el mtodo Rental.getcharge().Para una mayor claridad del programa, podemos hacer desaparecer la variable thisAmount, cambindola por invocaciones a getcharge (). El programa ser mas simple, pues tiene una variable menos, pero el desempeo del programa ser peor, pues llamamos varias veces a getcharge (). Si este mtodo no es pesado esto es tolerable. Si el tiempo que tarda getcharge() es apreciable, entonces esto no se debe hacer. El mtodo statemente () queda de a siguiente manera: class Customer... public String statement() { double totalAmount = 0; int frequentRenterPoints = 0;

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Enumeration rentals = _rentals.elements(); String result = "Rental Record for " + getName() + "\n"; while (rentals.hasMoreElements()) { Rental each = (Rental) rentals.nextElement(); // suma puntos de renta frecuente frequentRenterPoints ++; // agregar bonificacin por rentar un estreno dos das if ((each.getMovie().getPriceCode() Movie.NEW_RELEASE)&&each.getDaysRented() > 1) frequentRenterPoints ++; // muestra los datos para esta renta result += "\t" + each.getMovie().getTitle()+ +String.valueOf(thisAmount) + "\n"; totalAmount += each.getcharge (); } // Agrega lneas de pie result += "Amount owed is " + String.valueOf(totalAmount) +"\n"; result += "You earned " +String.valueOf(frequentRenterPoints) +" frequent renter points"; return result; } Se debe reducir al mnimo el uso de variables temporales. Son un problema a la hora de extraer el cdigo, hay que pasarlas como parmetro y retornarlas, adems hacen ms difcil entender el programa, especialmente en mtodos muy largos. cualquiera puede escribir cdigo que la maquina entienda. Solo los buenos programadores escriben cdigos que los humanos entiendan Lo mismo que hicimos con el clculo del monto a pagar, lo podemos hacer con los puntos de renta frecuente. Queremos usar el procedimiento extractMethod para el clculo de los frequentRenterPoints. Analizando las variables, vemos que: Each se usa pero no se modifica frequentRenterPoints se modifica y adems va acumulando en cada iteracin del while. ==

"\t"

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Por lo tanto each es un parmetro mientras que frequentRenterPoints se pasa como parmetro y tambin se retorna el segmento a extraer no utiliza campos de la clase Customer sino de la clase Rental. As que lo extraemos y los ponemos en la clase Rental. class Customer { public String statement() { double totalAmount = 0; int frequentRenterPoints = 0; Enumeration rentals = _rentals.elements(); String result = "Rental Record for " + getName() + "\n"; while (rentals.hasMoreElements()) { Rental each = (Rental) rentals.nextElement(); frequentRenterPoints = each.getFrequentRenterPoints (); // Muestra los datos para esta renta; result += "\t" + each.getMovie().getTitle()+ +String.valueOf(thisAmount) + "\n"; totalAmount += thisAmount; // agregalineas de pie "\t"

result += "Amount owed is " + String.valueOf(totalAmount) +"\n"; result += "You earned " +String.valueOf(frequentRenterPoints) +" frequent renter points"; return result; } } class Rental { IntgetFrequentRenterPoints() { If (getMovie().getPriceCode == Movie.NEW_RELEASE) &&getDaysRented () > 1) Return 2; else return 1; } }

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA 20/12/11 El diagrama de clases mostrando los cambios: movie Price Code: int Rental daysRented: int getcharge() getFrequentRenter () * * Customer

1
Ilustracin 17 diagrama

Statement() 1

Eliminar Variables Temporales Son tiles dentro de su propia rutina pero hacen mas complejo a un programa. Fowler sugiere remplazar las variables temporales por consultas (querys). Refactoring tiene un procedimiento llamado ReplaceTempwithQuerypara hacer esto, el programa statement ( ) tiene las variables temporales totalAmount y frequentRenterPoints. El primer paso es remplazar totalAmount con un mtodo. Class Customer { public String statement() { int frequentRenterPoints = 0; Enumeration rentals = _rentals.elements(); String result = "Rental Record for " + getName() + "\n"; while (rentals.hasMoreElements()) { Rental each = (Rental) rentals.nextElement(); frequentRenterPoints = each.getFrequentRenterPoints (); // Muestra los datos para esta renta; result += "\t" + each.getMovie().getTitle()+ +String.valueOf(thisAmount) + "\n"; } // agregalineas de pie result += "Amount owed is " + String.valueOf(totalAmount) +"\n"; result += "You earned " +String.valueOf(frequentRenterPoints) +" frequent renter points"; return result; } } "\t"

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Private double get totalcharge () { Double result = 0; Enumeration rentals = rentals.elements (); While (rentals.hasMoreElements ()) { Rental each = (Rental) rental.nextElement (); Result += each.getCharge (); } Return result; } Ahora hacemos lo mismo con frequentRenterPoints: Public String Statement () { Enumeration rentals = _rentals.elements (); String result = "Rental Record for " + getName() + "\n"; while (rentals.hasMoreElements()) { Rental each = (Rental) rentals.nextElement(); // muestra los datos para esta renta result += "\t" + each.getMovie().getTitle()+ "\t" +String.valueOf (each.getCharge()) + "\n"; } //agregalineas de pie; result += "Amount owed is " + String.valueOf(getTotalCharge ()) +"\n"; result += "You earned " + String.valueOf(getTotalFrequentRenterPoints())+ \n return result; } } Private getTotalFrequentRenterPoints () { Int result = 0; Enumeration rentals = _rentals.elements(); While (rentals.hasMoreElements()) { Rental each = (Rental) rentals.nextElement (); result += each.getFrequentRenterPoints (); }

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Return result; } El diagrama de clases ha cambiado: movie Price Code: int Rental daysRented: int getcharge() getFrequentRenter () * * Customer Statement() getTotaCharge () getTotalFrequentRenterPoint 1

1
Ilustracin 18 diagrama

El anterior cambio ha generado un programammas grande si sumamos las lneas de cdigo de todos los mtodos. Esto se debe a la sintaxis de java en la cual un ciclo de sumar toma alrededor de seis lneas. Antes el While se ejecuta una sola vez y ahora se ejecuta tres veces. Hay preocupacin por el desempeo del programa. Al final del refactoring se optimiza el programa. As que no nos preocupamos del desempeo todava. Una buena noticia es que todos los mtodos extrados se pueden reutilizar se ha logrado aislar los clculos d la impresin de facturas y estamos en posicin de crear la versin HTML de la factura. public String htmlStatement() { Enumeration rentals = _rentals.elements(); String result = "<H1>Rentals for <EM>" + getName() + "</EM></H1><P>\n"; while (rentals.hasMoreElements()) { Rental each = (Rental) rentals.nextElement(); //muestra los datos para esta renta result += each.getMovie().getTitle()+ ": " +String.valueOf(each.getCharge()) + "<BR>\n"; } //agregalineas de pie result += "<P>You owe <EM>" + String.valueOf(getTotalCharge()) +"</EM><P>\n"; result += "On this rental you earned <EM>" +String.valueOf(getTotalFrequentRenterPoints()) +"</EM> frequent renter points<P>"; return result; }

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA El mtodo htmlstatement resulto relativamente pequeo y sencillo debido a que reutiliza todos los clculos que fueron extrados de statement y colocados en mtodos a parte. Tiene la ventaja de que si se modifica las reglas para los clculos, se hace en un solo lugar y esto tiene efecto en ambas facturas. 17/01/12 Se ha creado el mtodo htmlstatement que reutiliza los clculos que habamos usado para construir statement. Estos clculos se hacen es un solo lugar, de tal manera que si cabian, solo es necesario hacer el cambio una vez. El refactoring permitio separar la fucnion de clacular da la funcin de imprimir la factura. Actualmente los clientes estn a punto de cambiar la forma de hacer los clculos introduciendo nuevas clasificaciones de las pelculas. En este momento, hacer estos cambios seria feo porque implica modificar las caondicionales tanto para calcular los puntos de renta frecuente como los cargos. Lssiguietenes pasos de refactoring permititan facilitar este tipo de cambios. Refactoring de la Lgica Condicional Sobre el Tipo de Pelcula (pricecode) con Polimorfismos. El principal problema es la sentencia switch con base en un atributo de otro objeto. Trate que las sentencias switch se basen en atributos o datos del objeto local. class Rental... doublegetCharge() { double result = 0; switch (getMovie().getPriceCode()) { caseMovie.REGULAR: result += 2; if (getDaysRented() > 2) result += (getDaysRented() - 2) * 1.5; break; caseMovie.NEW_RELEASE: result += getDaysRented() * 3; break; caseMovie.CHILDRENS: result += 1.5; if (getDaysRented() > 3) result += (getDaysRented() - 3) * 1.5; break; } } Lo que se ah obtenido con este movimiento es uqe ahora la condicin del switch depende de la clase local. Como el cambio que viene es de nuevos tipos de pelculas,

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA veremos que esto facilita los cambios. Parece que los tipos de pelculas tienden a ser voltiles y por eso es mejor que el clculo del cargo lo haga MOVIE. El diagrama de clases ha cambiado:

Para invocar el nuevo mtodo getchargede Movie, por ahora se hace desde Rental: Class Rental { Double getcharge () { Return.movie.getcharge (.daysRented); } } Con esto podemos compilar y probar el mtodo getchargesin que el resto del programa se entere del cambio.

Lo que hicimos con getFrequentRenterPoints. Inicialmentetenemos:

getchargetambin

hay

que

hacerlo

con

class Rental... intgetFrequentRenterPoints() { if ((getMovie().getPriceCode() == Movie.NEW_RELEASE) &&getDaysRented() > 1) return 2; else return 1;

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA } Pasando el metodogetFrequentRenterPointsa la clase Movie el cdigo queda asi: Class rental... intgetFrequentRenterPoints() { return _movie.getFrequentRenterPoints(_daysRented); } class movie... intgetFrequentRenterPoints(intdaysRented) { if ((getPriceCode() == Movie.NEW_RELEASE) &&daysRented> 1) return 2; else return 1; } Al fin la herencia Tenemos varios tipos de pelculas y para cada tipo se deben hacer los clculos de cierta manera. Este es un trabajo para las subclases. Podemos tener tres subclases de Movie, cada una con su propia versin de getchargey de getFrequentRenterPoints.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Esto permitir eliminar la orden SWITCH. Tristemente, esto no trabaja. El problema esta en que las pelculas, con el tiempo, pueden cambiar de clasificacin, pero los objetos no pueden hacerlo. Hay una solucin aplicando un patrn de diseo denominado state o Gang of Four. El diagrama de clases queda:

Observe que Movie.getCharge lo que hace es direccionar a Price.getcharge. El tipo de pelcula ahora es un objeto de tipo Price. En cualquier momento podemos reclasificar la pelcula, sustituyendo el objeto por alguna de las subclases de Price. En este momento podemos preguntarnos si Price representa un estado de Movie o representa una estrategia de calculo? En este momento el autor piensa que es un estado. Estado: Valores de los atributos. Para introducir el patrn State (estado) hay que hacer tres cambios: 1. mover el comportamiento del cdigo de tipo al patrn state con el refactoring ReplaceTypeCodewithstate/strategy. 2. Mover el mtodo a la clase Pricecon el refactoring MoveMethod. 3. Finalmente eliminamos las sentencias switch con el refactoring ReplaceConditionalwithPolymophism. ComencemoshaciendoReplace Conditional with Polymophism.El primer paso es hacer self Encapsule Fieldspara asegurarse de que todos usan el cdigo con los mtodos get y set. Como la mayora del cdigo viene de otras clases, ya usan get y set. Sin embargo, el constructor de la clase Movie si accede al atributo. Actualmente se ve as: class Movie...

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA { public Movie(String name, int priceCode) { _name = name; _priceCode = priceCode; } } Debemoscambiarlo a: class Movie { public Movie(String name, int priceCode) { _name = name; setPriceCode(priceCode); } } Compilamos y probamos. Debe funcionar. Ahora introducimos las nuevas clases: abstract class Price { abstractintgetPriceCode(); } classChildrensPrice extends Price { intgetPriceCode() { returnMovie.CHILDRENS; } } classNewReleasePrice extends Price { intgetPriceCode() { returnMovie.NEW_RELEASE; } } classRegularPrice extends Price {

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA intgetPriceCode() { returnMovie.REGULAR; } } 18/01/12 Vamos a hacer el cambio en el atributo de la clase Movie, lo mismo que los mtodos get y set. Actualmenteestaasi: publicintgetPriceCode() { return _priceCode; } public setPriceCode (intarg) { _priceCode = arg; } privateint _priceCode; El atributo _priceCodese va a convertir en un objeto de tipo Price lo cual afecta a los mtodos get y set. Este cambio se ve as: class Movie... { publicintgetPriceCode() { return _price.getPriceCode(); } public void setPriceCode(intarg) { switch (arg) { case REGULAR: _price = new RegularPrice(); break; case CHILDRENS: _price = new ChildrensPrice(); break; case NEW_RELEASE: _price = new NewReleasePrice(); break; default: throw new IllegalArgumentException("Incorrect Price Code");

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA } } private Price _price; } En este momento se compila y se prueba el programa. Ahora hay que mover el mtodo getcharge, de la clase Movie a la clase Price aplicando el refactoring denominado MoveMethod. Actualmente esta asi: class Movie... doublegetCharge(intdaysRented) { double result = 0; switch (getPriceCode()) { caseMovie.REGULAR: result += 2; if (daysRented> 2) result += (daysRented - 2) * 1.5; break; caseMovie.NEW_RELEASE: result += daysRented * 3; break; caseMovie.CHILDRENS: result += 1.5; if (daysRented> 3) result += (daysRented - 3) * 1.5; break; } return result; } Luego del cambio queda asi: class Movie... doublegetCharge(intdaysRented) { return _price.getCharge(daysRented); } class Price... doublegetCharge(intdaysRented) { double result = 0;

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA switch (getPriceCode()) { caseMovie.REGULAR: result += 2; if (daysRented> 2) result += (daysRented - 2) * 1.5; break; caseMovie.NEW_RELEASE: result += daysRented * 3; break; caseMovie.CHILDRENS: result += 1.5; if (daysRented> 3) result += (daysRented - 3) * 1.5; break; } return result; } En este momento se compila y prueba el cambio. El siguiente paso es que el mtodo getchargequede implementado en las subclases de Price. Se utiliza el refactoring denominado ReplaceConditionalwithPolymorphism Primero lo hacemos en la subclase RegularPrice: classRegularPrice... doublegetCharge(intdaysRented) { double result = 2; if (daysRented> 2) result += (daysRented - 2) * 1.5; return result; } Si en este momento compilara y probrara, par un RegularPricese ejecutara, el mtodo de su superclase Price. classChildrensPrice doublegetCharge(intdaysRented) { double result = 1.5; if (daysRented> 3) result += (daysRented - 3) * 1.5; return result; }

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA classNewReleasePrice... doublegetCharge(intdaysRented) { returndaysRented * 3; } Ahora el mtodo getchargede Price se puede volver abstracto. class Price... abstract double getCharge(intdaysRented); aqui terminamos el patron estado para getchargealgo similar getfrequentRenterPoint. Actualmente se encuentra en la clase Movie: class Rental... intgetFrequentRenterPoints(intdaysRented) { if ((getPriceCode() == Movie.NEW_RELEASE) &&daysRented> 1) return 2; else return 1;
} Primero lo movemos a Price:

se

hace

con

Class Movie... intgetFrequentRenterPoints(intdaysRented) { return _price.getFrequentRenterPoints(daysRented); } Class Price... intgetFrequentRenterPoints(intdaysRented) { if ((getPriceCode() == Movie.NEW_RELEASE) &&daysRented> 1) return 2; else return 1; } Class NewReleasePrice intgetFrequentRenterPoints(intdaysRented) { return (daysRented> 1) ? 2: 1; } Si el tipo de pelcula es NEW_RELEASE, se ejecuta el mtodo de la subclase NewReleasePrice. De lo contrario se ejecuta el mtodo de la superclase Price.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA El resultado es que ahora es mucho mas fcil introducir nuevos tipos de pelculas o cambiar la forma de hacer los clculos. El beneficio ser mayor cuanto mas grande sea el programa. La versin final de los diagramas es la siguiente: Diagrama de secuencia:

Diagrama de clases:

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA

23/01/12

Capitulo 3: Malos Olores en el Cdigo

LOS MALOS OLORES DEL SOFTWARE
Se trata de identificar aquellos segmentos de cdigo que necesitan un refactoring. Cdigo Duplicado Si el programa presenta cdigo repetido, puede estar seguro de que le programa estara mejor si se busca alguna forma de unificarlo. Si el cdigo repetido esta en mtodos distintos que pertenecen a la misma clase, se puede usar el refactoring denominado extractmethod e invocar el cdigo, el cual se coloca como un nuevo mtodo. Si el cdigo repetido esta en 2 subclases hermanas se usa el extractmethodpero el nuevo mtodo se coloca en la superclase de ambas subclases. Si los cdigos son similares pero no iguales, hay que separar la parte que es igual antes de hacer el extractmethodsi dos mtodos hacen lo mismo pero con distinto algoritmo, hay que elegir el algoritmo mas claro y eliminar el otro. Si se tiene cdigo repetido en dos clases no relacionados, considere usar el refactoring Extract class y usar en objeto de la nueva clase para acceder al nuevo mtodo.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Mtodo muy largo Los programas mas longeros son aquellos que tienen mtodos cortos. Los programadores recin llegador a los objetos sienten que este estilo es una infinita delegacin, un mtodo delega en otro, que delega en otro, etc. Pero todas las ventajas de la indireccion (explicacin, compartir, eleccin) se soportan por medio de pequeos mtodos. En POO no se trata de que un solo objeto haga todo el trabajo sino qu el trabajo se obtiene por la colaboracin entre muchos objetos especializados. Desde los primeros das de la computacin la gente establecio que mientras mas largo es un procedimiento, mas difcil es de entender. Los lenguajes antiguos tienen una sobrecarga de trabajo en el encabezado de cada procedimiento lo cual desmotivaba el uso de muchos procedimientos. Los modernos lenguajes OO han eliminado toda la sobrecarga de trabajo de tal manera que usar muchos procedimientos ya no es problema. Hay una sobrecarga para la persona que lee un programa y encuentra una llamada a procedimiento porque tiene que saltar a otra parte del programa y pierde de visita el contexto de la llamada. Hay ambientes de desarrollo que permiten ver dos procedimientos a la vez y presentan en sitio de la llamada y el procedimiento invocado. Esto ayuda pero lo que realmente nos permite comprender mejor los procedimientos es el uso de buenos nombres. Un buen nombre puede evitar que tengamos que saltar a mirar el procedimiento invocado. El resultado neto es que debemos ser mucho mas agresivos al mtodo de descomponer un procedimiento. Una heurstica de trabajo es que si usted siente la necesidad de poner un comentario, debe escribir un nuevo mtodo. El cdigo con el comentario se coloca a parte pero se le da un nombre adecuado que indique cuales son las inteciones del programador. Este nombre proporciona una semntica que ayuda a comprender el programa, no hay que temerle a los nombres largos. El 99% del tiempo lo que se hace es extraer trazos de cdigo para hacer nuevos mtodos. Es posible que al extraer un trozo de cdigo como un nuevo mtodo nos demos cuenta que maneja muchas variables y datos temporales los cuales se convertirn en parmetros y resulte una cantidad excesiva de parmetros. Se puede usar el refactoring ReplaceTempwithQuerypara eliminar las variables temporales. Las largas listas de parmetros pueden ser reducidas con el refactoring Introduce Objecty Preserve wholeObject. Si usted use todo eso y aun tiene muchas temporales y parmetros, es hora de usar la artillera pesad, ReplaceMethodwithMethodObject. Cmo identificar los pedazos de cdigo a extraer? Un buen mtodo es mirar los comentarios. A menudo ellos marcan este tipo de distancia semntica. Un bloque de cdigo con un

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA comentario que dice lo que esta haciendo, puede ser reemplazado por un mtodo cuyo nombre este basado en el comentario. Aun una sola lnea puede ser extrada si necesita mucha explicacin. Los comandos condicionales y las iteraciones tambin dan una dea de que extraer. Use el refactoring DecomposeConditionalpara manejar las expresiones condicionales. Con las iteraciones puede extraer la iteracin o el cuerpo de la misma forma para formar un nuevo mtodo. Clase Muy Grande. Cuando una clase esta tratando de hacer mucho, a menudo tiene muchas variables de instancia (atributos). Si una clase tiene muchos atributos, generalmente se encuentra cdigo repetido. Usted puede usar el refactoring extrac class para dividir los atributos. Aquellos atributos que queden juntos deben estarlo porque ello tiene sentido, es decir, se relacionan entre si. Por ejemplo depositAmounty depositCurrencyes probable que queden juntas. De manera mas general los prefijos o sufijos comunes pueden indicar que esas varibales van juntas en un componente. Si el nuevo componente tiene sentido como una subclase, use el refactoring ExtractSubclass. Algunas veces una clase no usa todos sus atributos todo el tiempo. Si es asi. Puede usar extract class o ExtractSubclassmuchas veces. Una clase con mucho cdigo se debe revisar primero buscando duplicando, catico o que no se use. La solucin ms simple es eliminar la redundancia en la clase misma. Si usted tiene mtodos de quinientas lneas con montones de cdigo en comn, podra ser posible cambiarlas en cinco mtodos de diez lneas con otros diez mtodos de dos lneas extrados del original. La solucin usual para una clase con mucho cdigo es usar Extract class o ExtractSubclass. un truco til es determinar como los clientes usan la clase y usar el refactoring Extract Interface para cada uno de estos usos. Esto le podra dar ideas sobre como partir la clase si su clase es una GUI, podra necesitar mover datos y compartimientos a objetos de dominios separados. Esto requiere mantener algunos datos duplicados en cada lugar y mantener los datos sincronizados. Elrefactoring DuplicatedObserved Data sugiere como hacer esto. Si usted esta usando el viejo AWT, podra hacer esto al tiempo que remplaza las clases por componentes SWING. 24/01/12 FALTA ESTA CLASE 25/01/12

OBSESION PRIMITIVA
Los lenguajes de programacin suelen tener al menos dos clases de datos, los de tipo registroque permiten agrupar datos relacionados y los tipos primitivos que son los bloques de construccin para los registros.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Los registros siempre tienen un poco de sobrecarga pero se usan para representar cosas como tablas de una base de datos. A veces usan de manera torpe para agrupar pocos datos que no tienen relacin . Una ventaja de los objetos es que se pueden crear clases fcilmente que luego son indistinguibles de las tipos primitivos, las clases actan como nuevos tipos de datos. Java tiene primitivas para los nmeros, pero las cadenas y las fechas, que en otros lenguajes son tipos primitivas, aqu son clases. Las personas nuevas en objetos tienden a no usar pequeas clases para pequeas tareas, tal como el dinero, que combinan nmeros, rangos superior e inferior, y cadenas especiales tales como los nmeros telefnicos o las direcciones. Usted puede salir de estas obsesiones usando el refactoring Replace Data ValueWithObjectsobre valores individuales de datos. Si el valor el algn cdigo use el refactoring Replace Data ValueWith Class, si el valor no afecta al comportamiento. Si usted tiene condicionales que dependen de algn tipo ReplaceTypeCodewithSubclasseso ReplaceTypeCodewithState/Strategy. de cdigo use

Si usted tiene un grupo de campos que debn ir juntos use extract class. Si usted ve estas primitivas en listas de parmetros, trate de civilizarlas usando Introduce ParameterObject. Si usted se encuentra desmenuzando un arreglo, use ReplaceArraywithObject.

SENTENCIAS SWITCH
Uno de los sntomas mas obvios del cdigo orientado a objetos es comparar las sentencias switch (o de casos). El problema del switch es el de la duplicacin, a menudo usted encuentra la misma sentencia switch esperada por todo el programa, en diferentes lugares. Si usted agrega unanueva clausula al switch, tendra ue buscar todas estas sentencias switch y cambiarlas. El concepto O.O de polimorfismos le brinda una solucin elegante para esto. La mayora de las veces una sentencia switch, considere el polimorfismo. A menudo la sentencia switch opera sobre un cdigo. Usted desea el mtodo para cada cdigo use ExtractMethodpara extraer la sentencia switch como un nuevo mtodo. Luego use MoveMethod en la nueva clase donde se piensa implementar el polimorfismo. En estepuntousted decide siReplace Type Code with Subclasses o Replace Type Code with State/Strategy. Cuando usted haya colocado la estructura de herencia use ReplaceConditionalwithPolymorphism. Si usted tiene unos pocos casos que afectan a un solo mtodo y no espera que ellos cambien, entonces el polimorfismo es excesivo. En este caso use ReplaceParameterwithExplicitMethods, lo que es una buena opcin si uno de los casos es un nulo, trate Introduce NullObject.

JERARQUIAS DE HERENCIA PARALELAS

Realmente es un caso especial de la ciruga por disparo. En este caso, cada vez que usted crea una subclase de una clase, tambin tiene que crear una. Subclase de otra clase. Usted puede reconocer este olor porque los prefijos de los nombres de clase en una jerarqua son los

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA mismos de la otra jerarqua. La estrategia general para eliminar esta duplicidad es asegurar que instancias de una jerarqua. Se refiere a instancias de la otra. Si usa MOveMethody Move Field y la jerarqua en la clase relacionada desaparece.

CLASE PEREZOSA
Cada clase que usted crea cuesta dinero para mantenerla y comprenderla. Una clase que no esta haciendo lo suficiente para justificar este dinero, debe desaparecer. A menudo esta era una clase importante que ha sido disminuida con el refactoring o puede ser una clase que fue agregada a causa de unos cambios que planeaba hacer, pero que no se hicieron. De todas maneras permita que la clase muera con dignidad. Si usted tiene subclases que no estn haciendo lo suficiente, use CollapseHierorchy. Los componentes casi intiles deben ser manejados con In Line Class.

GENERALIDAD ESPECULATIVA
SUCEDE cuando la gente dice oh! Yo creo que necesitaremos la habilidad para hacer este tipo de cosas algn da, y entonces se colocan toda clase de referencias y casos especiales para manejar cosas que no son requeridas. El resultado a menudo es difcil de comprender y de mantener. Si toda esta maquinaria se estuviera usando seria valiosa. Pero si no se usa debe desaparecer. Si usted tiene clases abstractas que no estn haciendo mucho, use CollapseHierarchy. La delegacin innecesaria puede ser removida con In line class. Los mtodos con parmetros no usados deben ser sometidos a RemoveParameter. Los mtodos nombrados con nombres singularmente abstractos deben ser aterrizados con RenameMethod. La generalidad especulativa puede ser encontrada cuando los nicos usuarios de un mtodo o clase son los casos de prueba. Si usted encuentra tales mtodos o clases, brrelas y al caso de prueba que los ejercita. Si usted encuentra un mtodo o clase que es un ayudante para un caso de prueba, que ejercita una funcionalidadlegitima usted tiene que dejarlo quieto, por supuesto.

CAMPO TEMPORAL
Algunas veces usted ve un objeto con un atributo que es usado solo bajo ciertas circunstancias. Tal cdigo es difcil de comprender porque usted espera que un objeto necesite todos sus atributos. Tratando de comprender porque un atributo esta ah y cuando parece no ser usado, le ayuda a desenredar el nudo. Tratando de comprender porque un atributo esta ah y cuando parece no ser usado, le ayuda a desenredar el nudo. Use Extract Class para crear un hogar para los pobres atributos. Coloque todo el cdigo que tenga que ver con el atributo en este componente. Tambin tiene que ser hbil para eliminar el cdigo condicional usando Introduce NullObject para crear un componente alternativo para cuando los atributos no sean validos.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Un caso comn de campo temporal ocurre cuando un algoritmo complejo necesita varias variables. Como en la implementacin no se desea pasar enormes listas de parmetros se colocan como atributos. Pero estos atributos solo son variables durante el algoritmo. En otros contextos son solo alimentos para la confusin. En este caso puede usar Extract Class con estas variables como atributos y los mtodos que las requieren. El nuevo objeto es un Objeto Mtodo. 30/01/12

CADENA DE MENSAJES
Vemos una cadena de mensajes cuando un objeto le pregunta a otro, que a su vez le pregunta a otro quien a su vez le pregunto a otro, etc. Se van estas largas cadenas, generalmente de mtodos get. Esto significa que los objetos estn acoplados a la estructura de navegacin. Cualquier cambio en la estructura de navegacin intermedia, implica cambios en le programa. Aqu se debe usar un refactoring llamado HideDelegate. Se puede hacer esto en varios puntos de la cadena. Si se hace en todos los objetivos de la cadena, estos se volvern hombre en la mitad a menudo una solucin mejor es ver para que se usa el objeto resultante. Mire si puede usar ExtractMethodpara cortar la parte de cdigo que se usa y luego MoveMethod para ubicarlo ms cerca de la cadena. FALTA UNA PARTE Si hay solo unos pocos mtodos que no hacen mucho, use In line Methodpara incluir este cdigo dentro del llamador. Si hay comportamiento adicional, usted puede usar ReplaceDelegationwithInheritancepara volver al hombre en la mitad una subclase del objeto que realmente hace el trabajo. Esto le permite a usted extender el comportamiento sin cambiar toda la estructura de delegacin.

INTIMIDAD INAPROPIADA
Algunas veces las clases llegan a ser demasiado intimas y gastan demasiado tiempo hurgando en las partes privadas de la otra. Tratndose de clases debemos ser muy puritanos. Las clases demasiado ntimas necesitan ser separadas. Use MoveMethod y Move Field para separar las piezas y reducir la intimidad. Mire si usted puede organizar un ChangeBidirectionalAssociationtoUnidirectional. Si las clases tienen intereses comunes use Extract classpara colocar lo comn en un lugar seguro y hacer a las clases mas honestas. O use HideDelegate para hacer que otra clase actuar como intermediario. La herencia a menudo lleva a la sobre intimidad. Las subclases siempre van a saber ms de sus padres, de lo que los padres saben de ellas. Es tiempo de dejar la casa, aplique replaceDlegatewithInheritance.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA

CLASES ALTERNATIVAS CON DIFERENTES INTERFACES.

Use RenameMethod para renombrar mtodos que hagan la misma casa pero con diferente firma para lo que ellos hacen. A menudo esto no va muy lejos. En estos casos las clases no estn haciendo suficiente. Use MoveMethodpara mover los comportamientos a las clases hasta que las interfaces sean iguales. Si usted tiene que mover cdigo de manera redundante para cumplir esto, podra tener que usar ExtractSuperclass.

LIBRERIAS DE CLASES INCOMPLETAS.

Se ha argumentado bastante cerca de reutilizar el cdigo lo cual motiva la construccin de libreras de clases. Generalmente estas libreras no son diseadas desde cero sino que resulta, del afn de reutilizar algunos programas que hicieron. A menudo es malo, sino imposible, modificar una librera. Una vez que varias plicaciones la estn usando. En las libreras, refactoring como MoveMethodno se puede aplicar. Si usted que la librera tuviese algunos mtodos adicionales puede usar Introduce ForeignMethod. Si hay mucho comportamiento extra para agregar, use Introduce local Extension.

CLASES DE DATOS
Estas son clases que tienen atributos, mtodos get y set para esos atributos y nada ms. Estas clases solo se ocupan de almacenar datos y seguramente estn siendo extensamente manipuladas por otras clases. A veces se encuentran que estas clases tienen atributos pblicos. Si este es el caso, inmediatamente tiene que usar Encapsule Fieldantes de hacer otros refactoring. Si usted tiene una coleccin de campos, verifique si estn apropiadamente encapsulados y aplique Encapsulecollectionsi no lo estn. Use RemoveSettingMethoda todo campo que no necesite ser cambiado. Mire si estos mtodos get y set son usados por otras clases. Trate de usar MoveMethodpara mover comportamientos a la clase de datos. Si usted no puede mover un mtodo entero use ExtractMethodpara separar trozos de cdigo que si se pueden mover a la clase de datos. Luego de un tiempo usted puede empezar a usar HideMethod a los que llaman a los get y set. Las clases son como nios. Estn bien en el punto de arranque pero a medida que crecen hay que darles responsabilidades.

REHUSAR EL LEGADO.
Las subclases heredan atributos y mtodos de sus padres. Pero que tal si ellas no necesitan todo lo que los padres les ofrecen? De todo lo que les dan ellas escogen las pocas cosas que van a usar. La historia tradicional indica que la jerarqua esta equivocada.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Usted necesita crear una clase hermana y mover a la hermana todo lo que las subclases no usaran. Use Para esto los refactoring Push Down Method y Push Down Field. Esa forma el padre solo se queda con la que es comn a todas las subclases a menudo usted ..las superclases deben ser abstractas. Los autores del libro, no apoya a lo tradicional. Ellos subclasifican para usar un pedacito del comportamiento, todo el tiempo, y encuentran que esto esta perfectamente bien. No se puede negar que hay un poco de mal olor pero no es muy fuerte. As que si se rehsa el legado causa confusin y problemas, no siento que debe seguir siempre las tradiciones. El mal olor de rehusar el legado es mucho ms fuerte si la subclase esta reutilizando el comportamiento pero no desea soportar la interfaz de la superclase. N o creemos que sea problema rehusar las implementaciones pero rehusar las interfaces nos mete en grandes problemas. Este caso, sin embargo, no tiene que ver con la jerarqua. Usted puede manejarlo aplicandoReplaceInheritancewithDelegation. 31/01/12

COMENTARIOS
En nuestro anlisis de los malos olores, los comentarios tienen un olor dulce. El problema es que a menudo la gente usa los comentarios como un desodorante. Muy a menudo se encuentra en cdigos fuertemente comentados que los comentarios estn all porque el cdigo es malo. Si este es el caso, analice el cdigo con los malos olores que ya hemos visto y haga refactoring para mejorarlo. Cuando termine posiblemente encuentre que los comentarios son superfluos. Si usted necesita cometarios para explicar que hace un bloqueo de texto, trate extractmethod. Si necesita establecer algunas reglas acerca del estado del sistema requerido, use Introduce Assertion. Cuando sienta que necesita un comentario primero trate de refactorizar el cdigo para ver si el comentario se vuelve superfluo. Un buen tiempo para usar un comentario es cuando usted no sabe que hacer. Adems de indicar lo que va a hacer, el comentario puede indicar reas de las cuales usted no esta seguro. Un cometario es un buen lugar para decir porque usted hizo algo esta clase de informacin ayuda a los futuros modificadores, especialmente a los olvidadizos.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA

Capitulo 6
METODOS DE COMPOSICION
Una gran parte del refactoring son mtodos de composicin para empacar el cdigo apropiadamente, casi todo el tiempo los problemas vienen de mtodos que son muy largos estos mtodos son problemticos porque a menudo contienen montones de informacin que esta enterrada en una lgica compleja que las ha arrastrado..El refactoring clave es ExtraxtMethodque toma una porcin de cdigo y la convierte en un mtodo. Inline Method es esencialmente lo opuesto. Toma una llamada a mtodo y la remplaza por el cuerpo del mtodo. Necesitamos Inline Method si luego de hacer varias extracciones de cdigo vemos que no nos ha quedado muy bn y necesitamos reorganizar la forma como repartimos el cdigo en mtodos. El principal problema de ExtractMethodes manejar las variables locales y temporales que son una de las principales fuentes de este tema. Cuando trabajamos con un mtodo, es bueno ReplaceTempwithQuerypara atrapar cualquier variable temporal que se puede remplazar. Si la variable temporal es usada para muchas cosas, entonces use Split Temporary Variableprimero para hacer la variable temporal ms fcil de manejar pueda remplazar. Si la variable temporal es usada para muchas cosas, entonces use Split Temporary Variableprimero para hacer la variable temporal ms fcil de manejar. Algunas veces sin embargo, las variables temporales estn demasiado enredadas para remplazar se necesita ReplaceMethodwithMethodObject. Esto permite dividir los mtodos mas enredados al costo de introducir nuevas clases para el trabajo. Los parmetros son menos problema que las variables temporales, dada que no se les asigna si usted lo hace, entonces necesita usar RemoveAssingmentstoParameters. Una vez que el mtodo es dividido, su puede comprender mejor como trabaja. Tambin se puede encontrar que el algoritmo puede ser mejorado para hacerlo mas claro. Entonces use subtituteAlgorithmpara introducir un algoritmo mas claro.

EXTRACT METHOD
Usted tiene un fragmento de cdigo que puede ser agrupado aparte. Cambie el fragmento en un mtodo cuyo nombre explique el propsito del mtodo. voidprintOwing(double amount) { printBanner(); //Imprimedetalles System.out.println ("name:" + _name); System.out.println ("amount" + amount); }

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA || \/ voidprintOwing(double amount) { printBanner(); printDetails(amount); } voidprintDetails (double amount) {
System.out.println ("name:" + _name); System.out.println ("amount" + amount); }

MOTIVACION
ExtractMethod es uno delos refactoring mas comunes. Miro un cdigo que es demasiado largo o miro un cdigo que necesita un comentario para comprender su propsito entonces cambio ese fragmento de cdigo en un mtodo. Prefiero los mtodos cortos y bien nombrados por varias razones. Primero, incrementa la oportunidad de que otros mtodos pueden usar un mtodo, cuando el mtodo ha sido desgranado, segundo, permite que los mtodos de nivel ms alto se vean mas como una serie de cometarios. Sobrescribir tambin es ms fcil cuando los mtodos estn desgranados. Toma un poco de trabajo usar este refactoring si usted esta a acostumbradoa ver mtodos largos. Los pequeos mtodos trabajan solamente cuando tienen buenos nombres, as que necesita poner atencin a los nombres. La gente a veces pregunta de que longitud debe ser un mtodo. La longitud no es punto. La clave es la distancia semntica entre el nombre y el cuerpo del mtodo. Si extraer mejora la claridad, hgalo, aun si el nombre es mas largo que el cdigo que usted ha extrado.

MECANICA
Crear un nuevo mtodo y nombrarlo luego con la intencin del mtodo (nombrarlo por lo que hace no por como lo hace). Si el cdigo que usted desea extraer es muy simple, tal como un solo mensaje o llamada a funcin, debera extraerlo si el nombre del nuevo mtodo revelara la intencin del cdigo de una mejor manera. Si usted no puede encontrar un nombre ms significativo, no extraiga el cdigo. Copiar el cdigo extrado del mtodo fuente en el nuevo mtodo destino. Busque en el cdigo extrado referencias a cualquier variable local, que sea local en el alcance del mtodo fuente. Estos mtodos variables locales y parmetros para el mtodo destino. Mire si una variable temporal se usa solamente dentro del cdigo extrado. Si es as, declrela dentro del mtodo destino, como variables temporal.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Mire si alaguna de las variables de alcance local es modificada, mire si puede tratar el cdigo como una consulta (query) y asignarle el resultado a la variable en cuestin. Si es feo o hay ms de una de tales variables siendo modificadas, usted no puede extraer el cdigo como esta. Puede necesitar usar el refactoring Split Temporary Variable y tratar de nuevo. Usted puede eliminar las variablestemporales usando ReplaceTempwithQuery(ver la discusin del ejemplo). Pasar al mtodo destino las variables del alcance local que son ledas del mtodo extrado, como parmetros. Compile cuando haya manejado todas las variables en el alcance local. Remplace el cdigo extrado en el mtodo fuente, por una llamada al mtodo destino. si usted ha movido cualquier variable temporal sobre el mtodo destino, mire si fue declarada por fuera en el mtodo fuente. Si es as, usted puede eliminar la declaracin. Compile y pruebe.

01/02/2012 En el caso trivial, ExtractMethodes muy fcil: voidprintOwing() { Enumeration e = _orders.elements(); double outstanding = 0.0; // imprime el banner System.out.println ("**************************"); System.out.println ("***** Customer Owes ******"); System.out.println ("**************************"); // calcula outstanding while (e.hasMoreElements()) { Order each = (Order) e.nextElement(); outstanding += each.getAmount(); } //imprimedetalles System.out.println ("name:" + _name); System.out.println ("amount" + outstanding); } Es fcil extraer el cdigo que imprime el banner, solo corte y pegue. voidprintOwing() { Enumeration e = _orders.elements(); double outstanding = 0.0; printBanner(); // calcula outstanding while (e.hasMoreElements())

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA { Order each = (Order) e.nextElement(); outstanding += each.getAmount(); } //imprimedetalles System.out.println ("name:" + _name); System.out.println ("amount" + outstanding); } voidprintBanner() { // print banner System.out.println ("**************************"); System.out.println ("***** Customer Owes ******"); System.out.println ("**************************"); } Ejemplo Usando Variables locales. Entonces cual es el problema?Son las variables locales? Parmetros pasados al mtodo original y variables temporales declaradas dentro del mtodo original. Las variables locales estn solamente dentro del alcance del mtodo, as que usamos ExtractMethodestas variables causan trabajo extra. En algunos casos, hasta evita que se pueda hacer refactoring. El caso mas fcil con las variables locales sucede cuando son ledas pero no cambiadas. A partir del ltimo cdigo, vamos a extraer la parte que imprime detalles.
voidprintOwing() { Enumeration e = _orders.elements(); double outstanding = 0.0; printBanner(); // calculate outstanding while (e.hasMoreElements()) { Order each = (Order) e.nextElement(); outstanding += each.getAmount(); } //print details System.out.println ("name:" + _name); System.out.println ("amount" + outstanding); }

Se puede usar esto con tontas variables locales como desee. Lo mismo es verdad si la variable local es un objeto y usted invoca un mtodo modificador sobre la variable. De nuevo, usted puede pasar el objeto como parmetro. Solo tiene que hacer algo diferente si asigna a la variable local.

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA Ejemplo: Reasignando la Variable Local Es la asignacin a variables locales lo que llega a ser complicado. En este caso solo hablamos de variables temporales. Se ve una asignacin a un parmetro, inmediatamente use removeAssigmentstoParameters. Para variables temporales que son asignadas, hay dos casos, el caso mas simple es cuando la variable temporal es usada solamente dentro del cdigo extrado. El otro caso es cuando la variable se usa afuera del cdigo extrado. Si la variable no es usada despus del cdigo extrado, sencillamente puede hacer el cambio dentro del cdigo extrado. Si la variable se usa despus, necesita hacer que le cdigo extrado retorne el valor cambiado de la variable se puede ilustrar esto con el siguiente cdigo, que extrae la parte de los clculos: voidprintOwing() { printBanner(); double outstanding = getOutstanding(); printDetails(outstanding); } doublegetOutstanding() { Enumeration e = _orders.elements(); double outstanding = 0.0; while (e.hasMoreElements()) { Order each = (Order) e.nextElement(); outstanding += each.getAmount(); } return outstanding; } La variable de la enumeracin (e) solo es usada dentro del clculo que es el cdigo extrado, as que se puede mover enteramente al nuevo mtodo. La variable outstanding es usada en ambos lugares, as que se necesita retornarla desde el mtodo extrado. Una vez compila y prueba la extraccin, se renombra el valor retornado siguiendo la convencin: doublegetOutstanding() { Enumeration e = _orders.elements(); doubleresult = 0.0; while (e.hasMoreElements()) { Order each = (Order) e.nextElement(); result= each.getAmount(); } returnresult;

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA } En el presente cdigo la variable outstanding es inicializada a un solo valor conocido (0.0), asi que se puede inicializar en el cdigo extrado, si la variable se inicializa en un valor no trivial, entonces hay que pasarle al mtodo el valor anterior de la variable. El cdigo inicial para este ejemplo: voidprintOwing(double previousAmount) { Enumeration e = _orders.elements(); double outstanding = previousAmount * 1.2; printBanner(); // calculate outstanding while (e.hasMoreElements()) { Order each = (Order) e.nextElement(); outstanding += each.getAmount(); } printDetails(outstanding); } En este caso la extraccin se veriaasi: voidprintOwing(double previousAmount) { double outstanding = previousAmount * 1.2; printBanner(); outstanding = getOutstanding(outstanding); printDetails(outstanding); } doublegetOutstanding(double initialValue) { double result = initialValue; Enumeration e = _orders.elements(); while (e.hasMoreElements()) { Order each = (Order) e.nextElement(); result += each.getAmount(); } return result; } Despus de compilar y comprobar esto, podemos aclarar la forma como se inicializa la variable outstandig: voidprintOwing(double previousAmount)

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA { printBanner(); double outstanding = getOutstanding(previousAmount * 1.2); printDetails(outstanding); } En este momento usted se podra estar preguntando: Que pasara si necesitamos retornar mas de una variable? aqu usted tiene varias opciones: La mejor opcin generalmente es escoger un cdigo diferente para extraer. Se prefiere que un mtodo retorne un solo valor, de tal manera que se puedan organizar mltiples mtodos para mltiples valores. (si su lenguaje permite parmetros de salida, se puede usar. Por claridad se prefiere retornar un solo valor tanto como sea posible). Las variables temporales se usan tanto que puedan hacer muy difcil la extraccin. En estos casos trataremos de reducir las variables temporales con ReplaceTempwithQuery. Si cualquier cosa que haga sigue siendo difcil, use ReplaceMethodwithMthosObject. A este refactoring no le importa la cantidad de variables temporales. FALTA CLASE 6 Y 7 08/02/2012 Ejemplo: ExtractMethod Comenzamos con el siguiente cdigo doubleprice () { // el precio es preciobase descuento + embarque return _quantity * _itemPrice -Math.max(0, _quantity - 500) * _itemPrice * 0.05 + Math.min(_quantity * _itemPrice * 0.1, 100.0); } Esta vez extraeremos el mtodo para el precio base: double price() { // el precio es preciobase descuento + embarque returnbasePrice -Math.max(0, _quantity - 500) Math.min(basePrice* 0.1, 100.0); } private double basePrice() { return _quantity * _itemPrice; } Se deben manejar uno a la vez. Al terminar tenemos

_itemPrice

0.05

INGENIERA DE SOFTWARE II GR 1. JORGE ALBERTO GLVEZ CORREA double price() { returnbasePrice() - quantityDiscount() + shipping(); } private double quantityDiscount() { returnMath.max(0, _quantity - 500) * _itemPrice * 0.05; } private double shipping() { returnMath.min(basePrice() * 0.1, 100.0); } private double basePrice() { return _quantity * _itemPrice; } Se prefiere usar ExtractMethodporque ahora estos mtodos estn disponibles para cualquiera otro objeto que los necesite. Inicialmente se manejan Privatepero luego se puede relajar este tipo de acceso si otros necesitan el mtodo. El esfuerzo de hacer ExtractMethodno es mayor que el de hacer Introduce Explaining Variable. Y cuando usamos Introduce Explaining Variable? Cuando ExtractMethod implique un mayor esfuerzo. Si el algoritmo maneja un monton de variables locales, no ser tan fcil usar ExtractMethod. En este caso usamos Introduce Explaining Variable, para ayudar a comprender la expresin. Si la lgica no es muy enredada, mas tarde podramos usar ReplaceTempwithQuery. La variable temporal tambin es valiosa si terminamos usando ReplaceMethodwithMethodObject. http://sourcemaking.com/refactoring/replace-method-with-method-object madurez para toda la empresa capacidad uno en especifico