Cuaderno IngeSoft II V5.0

163
INGENIERÍA DE SOFTWARE II GR 1. JORGE ALBERTO GÁLVEZ CORREA Tabla de contenido CAPITULO 1: INTRODUCCIÓN.......................................7 ISO 9000..................................................... 7 SIX SIGMA.................................................... 7 NORMA CMMI FOR DEVELOPMENT...................................8 CMMI FOR DEVELOPMENT (CMMI-DEV).............................8 ÁREAS DE PROCESO POR CATEGORÍA...............................8 ADMINISTRACIÓN DE PROCESOS..................................8 ADMINISTRACIÓN 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................................15 NIVEL DE MADURES 4: CUANTITATIVAMENTE ADMINISTRADO..........16 NIVEL DE MADUREZ 5: OPTIMIZADO..............................16 DISTRIBUCIÓN 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

Transcript of Cuaderno IngeSoft II V5.0

Page 1: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Tabla de contenidoCAPITULO 1: INTRODUCCIÓN.......................................................................................................7

ISO 9000...................................................................................................................................7

SIX SIGMA.................................................................................................................................7

NORMA CMMI FOR DEVELOPMENT.........................................................................................8

CMMI FOR DEVELOPMENT (CMMI-DEV)..............................................................................8

ÁREAS DE PROCESO POR CATEGORÍA......................................................................................8

ADMINISTRACIÓN DE PROCESOS.........................................................................................8

ADMINISTRACIÓN 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...........................................................................................15

NIVEL DE MADURES 4: CUANTITATIVAMENTE ADMINISTRADO............................................16

NIVEL DE MADUREZ 5: OPTIMIZADO......................................................................................16

DISTRIBUCIÓN 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 AÉREAS DE PROCESO..............................................................................17

ADMINISTRACIÓN DE PROCESOS:..........................................................................................18

AÉREAS AVANZADAS DE ADMINISTRACIÓN DE PROCESOS....................................................20

Page 2: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

ADMINISTRACIÓN DE PROYECTOS.........................................................................................21

AÉREAS BÁSICAS DE ADMINISTRACIÓN DE PROYECTOS.....................................................22

INGENIERÍA:...........................................................................................................................25

RECURSIÓN DE INTERACCIÓN EN EL PROCESO DE INGENIERÍA..............................................28

SOPORTE................................................................................................................................29

Aéreas Básicas de Soporte..................................................................................................29

METAS GENÉRICAS Y PRÁCTICAS GENÉRICAS.........................................................................32

Panorama...........................................................................................................................32

Institucionalización de procesos.........................................................................................32

Proceso realizado...............................................................................................................33

Proceso administrado.........................................................................................................33

Proceso definido.................................................................................................................33

PRACTICAS Y METAS GENÉRICAS............................................................................................35

GG1: cumplir las metas específicas....................................................................................35

GG2: institucionalizar un proceso administrado.................................................................35

Elaboración CAR.................................................................................................................35

Estimación por línea de código...........................................................................................37

Estimación por puntos de función......................................................................................38

Factores de Complejidad....................................................................................................39

METODO DE ESTIMACION POR PUNTOS DE CASO DE USO....................................................41

SG 2 DESARROLLAR UN PLAN DEL PROYECTO. Pag 412.........................................................45

SP 2.1 establecer presupuesto y el cronograma.................................................................46

Subpraticas:........................................................................................................................46

1. Identificar los mayores eventos (puntos de control)..................................................46

2. Identificar las suposiciones del cronograma...............................................................46

3. Identificar Restricciones.............................................................................................46

4. Identificar las Dependencias de las Tareas.................................................................47

5. Establecer y mantener el presupuesto y el cronograma............................................47

6. Establecer criterios para acciones correctivas............................................................47

CPM (CRITICAL PATH METHOD).............................................................................................48

El Diagrama de Gantt..............................................................................................................49

El presupuesto del proyecto...............................................................................................50

FLUJO DE CAJA.......................................................................................................................51

Comentarios:......................................................................................................................52

Page 3: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

ACELERACION DE PROYECTOS................................................................................................52

Enfoque Estratégico...............................................................................................................52

ENFOQUE TACTICO.................................................................................................................53

P.E.R.T....................................................................................................................................55

PROGRAM EVALUATION AND REVIEW TECHNIQUE...............................................................55

HISTORIA:...........................................................................................................................55

LA PREGUNTA DEL PROBLEMA...............................................................................................57

Nuevo problema:................................................................................................................58

P.E.R.T COSTO........................................................................................................................58

LA COTIZACIÓN.......................................................................................................................60

Fenómeno de la Contratación................................................................................................61

1. Incumplimiento por parte del cliente en los pagos:...................................................61

2. Fecha para congelar requerimientos..........................................................................61

3. Arbitramiento en caso de conflictos...........................................................................61

4. Casos Fortuitos...........................................................................................................61

Sobre Impuestos.................................................................................................................61

Sobre el AIU........................................................................................................................62

Sobre los Anticipos.............................................................................................................62

MANTENIMIENTO DEL SOFTWARE.........................................................................................62

1. Correctivo:..................................................................................................................62

2. Cambios en los requerimientos..................................................................................63

3. Nuevos requerimientos..............................................................................................63

REFACTORING........................................................................................................................63

¿Qué es Refactoring?.........................................................................................................63

CAPITULO 1: Ejemplo de Refactoring.........................................................................................63

EL PRIMER PASO DEL REFACTORING......................................................................................67

Descomponer y Redistribuir el Método Statement ().........................................................67

Moviendo el cálculo del monto:.........................................................................................71

Eliminar Variables Temporales...........................................................................................75

Refactoring de la Lógica Condicional Sobre el Tipo de Película (pricecode) con Polimorfismos.....................................................................................................................78

Capitulo 3: Malos Olores en el Código.......................................................................................88

LOS MALOS OLORES DEL SOFTWARE.....................................................................................88

Código Duplicado...............................................................................................................88

Page 4: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Método muy largo..............................................................................................................88

Clase Muy Grande..............................................................................................................89

OBSESION PRIMITIVA.............................................................................................................90

SENTENCIAS SWITCH..............................................................................................................91

JERARQUIAS DE HERENCIA PARALELAS..................................................................................91

CLASE PEREZOSA....................................................................................................................91

GENERALIDAD ESPECULATIVA................................................................................................91

CAMPO TEMPORAL................................................................................................................92

CADENA DE MENSAJES...........................................................................................................92

INTIMIDAD INAPROPIADA......................................................................................................93

CLASES ALTERNATIVAS CON DIFERENTES INTERFACES..........................................................93

LIBRERIAS DE CLASES INCOMPLETAS......................................................................................93

CLASES DE DATOS...................................................................................................................93

REHUSAR EL LEGADO.............................................................................................................94

COMENTARIOS.......................................................................................................................94

Capitulo 6...................................................................................................................................95

METODOS DE COMPOSICION.................................................................................................95

EXTRACT METHOD.................................................................................................................96

MOTIVACION..........................................................................................................................96

MECANICA..............................................................................................................................97

Ejemplo Usando Variables locales......................................................................................98

Ejemplo: Reasignando la Variable Local.............................................................................99

Page 5: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Ilustración I – 3 Dimensiones criticas.........................................................................................10Ilustración 2- Figura 4.1 Áreas Básicas de Admón. de Procesos.................................................19Ilustración 3 – Áreas Avanzadas de Admón. De procesos..........................................................20Ilustración 4 – Áreas Básicas de Admón. de Proyectos..............................................................22Ilustración 5 – Áreas de Proceso Avanzadas de Admón. de Proyectos.......................................24Ilustración 6 – Áreas de Proceso de Ingeniería...........................................................................27Ilustración 7 – Áreas Básicas de soporte....................................................................................30Ilustración VIII – 4.7....................................................................................................................31Ilustración 9 – Grafo Orientado a Flechas. (Está en el cuaderno)...............................................48Ilustración 10 – grafo de actividades..........................................................................................52Ilustración 11 – Nueva actividad................................................................................................53Ilustración 12, GRAFO 2..............................................................................................................54Ilustración 13: DISTRIBUCIÓN BETA...........................................................................................55Ilustración 14: DISTRIBUCION NORMAL.....................................................................................55Ilustración 15 – Grafo actividad PERT.........................................................................................57Ilustración 16 Interacciones del método Statemet()..................................................................66Ilustración 17 – diagrama...........................................................................................................75Ilustración 18 diagrama..............................................................................................................77

Page 6: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

09/08/2011

Swebok

Áreas de conocimiento IngeSoft I IngeSoft II Lab. Otras Materias

Requerimientos del sw X

Diseño del sw X

Construcción del sw X

Prueba del sw X

Mantenimiento del sw X

Gestión de la configuración del sw X

Administración de la ingeniería sw X

Proceso de la ingeniería de sw X X

Herramientas y métodos de ingsw X

Calidad del sw X

KA de disciplinas relacionadas X

Libro guía:SwebokCMMI DevelopmentRefactoring – Martin FowlerIng del software – Pressman

Parciales:1. Introducción de calidad.2. Planificación del proyecto.3. Refactoring.

CalidadEdward 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 función) Capacitación / Entrenamiento

2. La mejora continua (optimizar el proceso).

Page 7: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ 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? (ergonómica) Usabilidad del sw.

4. Qué más podemos hacer con lo q sabemos?Innovación (interdisciplinaridad)

CAPITULO 1: INTRODUCCIÓN

ISO 9000Fue creada por fábricas europeas (Enfoque 2)

SIX SIGMACreado por fabricas americanas (enfoque 2)ISO 9001 IndustriaISO 9002 ServiciosISO 9003 ComercioISO 9000-3 Software

Universidad Carnegie MellonSEI: Software Engineering InstituteCMMI: Capacity Maturity ModelIncosesecam.EIA 731 secm.CMM for adquisition.CMM system engineering

CMM for servicesCMM integratedproductdevelopment

Todos se integraron en una sola:CMMI: Capacity Maturity Model IntegrationCMMI for adquisitionCMMI fordevelopmentCMMI for servicios (prestación de servicios).

12/08/2011

NORMA CMMI FOR DEVELOPMENT

Ahora más que nunca las empresas desean entregar productos y servicios mejores másrápidos y más baratos.

Page 8: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Al mismo tiempo, en los ambientes de alta tecnología del siglo 21 casi todas las organizaciones se encuentras construyendo productos y servicios incrementalmente más complejo. Comúnmente, 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 hábiles 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 administración 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 adquisición de sus objetivos de negocio.En los mercados actuales existen modelos de madures estándares metodologías y guías que pueden ayudar a los organizaciones a mejorar la forma de cómo hacen negocios. Sin embargo los enfoques de mejora más disponibles se concretan en partes específicas del negocio y no toman un enfoque sistemático de los problemas que están afectando a la mayoría de las organizaciones. Enfocándose 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 prácticas para mejorar las actividades de desarrollo aplicadas a productos y servicios. Maneja prácticas que cubren el ciclo de vida desde la concepción 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 núcleo, 1 es un área de proceso compartida y 5 son áreas de proceso específicas de desarrollo.

Todas las prácticas del modelo CMMI-DEV se enfocan en las actividades de la organización desarrolladora. Cinco áreas de proceso se enfocan en prácticas específicas para el desarrollo: manejando el desarrollo de requerimientos, solución técnica, integración del producto, verificación y validación.

ÁREAS DE PROCESO POR CATEGORÍA

ADMINISTRACIÓN DE PROCESOSOPD: Organizational Process Definition.OPF: Organizational Process Focus.OPM: Organizational Performance Management.OPP: Organizational Process Performance.OT: Organizational Training.

ADMINISTRACIÓN DEPROYECTOSIPM: Integrated Project Management.PMC: Project Monitoring and Control.PP: Project Planning.QPM: Quantitative Project Management.

Page 9: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

REQM: Requirement Management.RSKM: Risk Management.SAM: SupliréAgrieement Management.

INGENIERIAPI: Product Integration.RD: Requirement Development.TS: Technical Solution.VAL: Validation.VER: Verification.

SOPORTECAR: CasualAnálisis and Resolution.CM: Configuration Management.DAR:DeasionAnálisis and Resolution.MA: Measurement and Análisis.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 más importantes de un proceso son:

Las personas. Procedimientos y métodos. Herramientas y equipos.

Los procesos son los que mantienen unidos las diferentes partes de la organización.

Proyecto Requería Diseño Construcción

Prueba

A

B

C

D

Pensar en los procesos (y no en los proyectos) tiene ventajas. Se puede pensar en la escalabilidad del proceso ¿Cómo vamos a atender más proyectos? Se puede pensar en las tendencias mundiales en proceso, ¿Cómo hacer el proceso?, ¿Cómo ahorrar recursos o hacer lo más rápido? Las mejores empresas del mundo, las más exitosas, se han enfocado en mejorar sus procesos.

Page 10: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Las normas de calidad como ISO 9000 y CMMItambién 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 MEJORAEn su búsqueda 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.

Ilustración I – 3 Dimensiones criticas.

La Figura 1.1 ilustra 3 dimensiones críticas en las que las organizaciones típicamente se enfocan: gente, procedimientos y métodos, 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 cómo 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 tecnología y las personas no sean importantes. Estamos viviendo en un mundo donde la tecnología está cambiando a una increíble velocidad. Similarmente, es típico que las personas trabajen para muchas empresas a lo largo de sus carreras. Vivimos en un mundo dinámico. 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 tecnología para ser competitivas.

Page 11: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

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 ayudándoles a trabajar más inteligentemente, no más duro y con una consistencia mejorada. Los procesos efectivos también proporcionan un vehículo para introducir y usar la nueva tecnología en una forma que cumple mejor los objetivos de los negocios de la organización.

ACERCA DE LOS MODELOS DE MADUREZ.

CAPACIDAD.Un modelo de madurez capacidad (CMM), incluyendo el CMMI, es una representación 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 década de 1930 Walter Schewhartcomenzó a trabajar en mejora de procesos con sus principios de control estadístico 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 másallá y comenzaron a aplicarlos en su trabajo en IBM y el SEI el libro de humphreyManagingthe software Process, proporciona una descripción de los principios y conceptos en los que se basan muchos de los modelos de madurez capacidad.

El SEI ha tomado la premisa de administración de procesos “La calidad de un sistema o producto está altamente influenciado por la calidad del proceso usado para desarrollarlo y mantenerlo”y 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 Comisión. (ISO/IEC) y su cuerpo de estándares.

Los CMMs se enfocan en la mejora de procesos en una organización. Ellos cuentan con los elementos esenciales de los procesos efectivos de una o más 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 diseñado para organizaciones de software y publicado en un libro. The Capability Maturity Model: Guidelines for improving the software process.

Hoy, CMMI es una aplicación 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 incrementadas, tiempo de ciclo mejorado y cronogramas y presupuestos más predecibles y precisos.

Page 12: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

CAPITULO 3: PEGANDO TODO JUNTO

CMMI-DEV no especifica que un proyecto u organización deba seguir un flujo de proceso o particular o que cierto número se productos sean desarrollados por día o que se adquieran los objetivos específicos de desempeño.

El modelo especifica que un proyecto u organización debe tener procesos que manejan las prácticas de desarrollo relacionadas. Para determinar si estos procesos están en su lugar, un proyecto u organización mapea sus procesos a las áreas de proceso de este modelo.

El mapeo de procesos a áreas de procesos habilita a la organización 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 organización o proyecto.

COMPRENDIENDOLOSNIVELES.

Los niveles son usados en CMMI-DEV para describir un camino evolutivo recomendado para una organización que desea mejorar sus procesos que usa para desarrollar productos y servicios. Los niveles también pueden ser el resultado de la actividad de pronóstico en las evoluciones. Las evaluaciones se pueden aplicar a la organización entera o a pequeños grupos tales como una división o proyecto.

El CMMI soporta 2 caminos de mejora usando niveles un camino le permite a la organización mejorar los procesos correspondientes a un área de procesos individual (O grupo de área de proceso) seleccionadas por la organización. 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 representación continua usted queda habilitado para alcanzar “niveles de capacidad”. Usando la representación por etapas usted puede alcanzar “niveles de madurez”.

19/08/2011

En este curso solo estudiaremos la representación por etapas.

COMPRENDIENDO LOS NIVELES DE MADUREZ

Para soportar aquellos que usan representación por etapas, todos los modelos CMMI reflejan niveles de madures en su diseño y contenido.

Page 13: Cuaderno IngeSoft II V5.0

Niveles de madurez

Área deProceso

*

**

MetasGenéricas

Metas especificas

Practicas Genéricas

Practicas Específicas

* *

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Un nivel de madurez consiste de prácticasespecíficas y genéricas relacionadas para un conjunto de áreas de proceso predefinidos que mejoran el desempeño total de la organización.

El nivel de madurez de una organización proporciona una forma para caracterizar su desempeño. 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 sofisticación a medida que la organización 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 organización para moverse al siguiente nivel.

Los niveles de madurez son medidas por la adquisición (cumplimiento) de las metas específicas y genéricas 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 ejecución, esta designación por un número del 1 al 5.

1. inicial.2. administrado.3. definido.4. cuantitativo / administrado.5. optimizado.

Page 14: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

NIVEL DE MADUREZ 1: INICIAL

En este nivel los procesos son usualmente ad doc y caóticos. La organización usualmente no proporciona un ambiente estable para soportar los procesos. El éxito en estas organizaciones depende de la competencia y heroísmo de las personas de la organización 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 inhábiles 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 política los proyectos emplean a personas habilidosas quienes tienen recursos adecuados para producir salidas controlados; involucran actores relevantes son monitoreados, controlados y revisados, y se evalúa su adherencia a la descripción de los procesos. La disciplina de procesos reflejada por el nivel de madurez ayuda a asegurar que las prácticas existentes sean retenidas durante los tiempos difíciles.

Cuando estas prácticas están en su lugar los proyectos son realizados y administrados de acuerdo con sus planes documentados.

También en el nivel de madurez 2 el estado de los productos de trabajo es visible para es la administración 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 especificación, estándares y procedimientos.

NIVEL DE MADUREZ 3: DEFINIDO

En el nivel de madurez 3 los procesos son bien caracterizados y comprendidos y descritos con estándares, procedimientos, herramientas y métodos.

El conjunto de procesos estándar de la organización que es la base para el nivel de madurez 3 es establecido y mejorado a través del tiempo.

Estos procesos estándar son usados para establecer consistencias a través de toda la organización, los proyectos establecen sus procesos definidos manipulando el conjunto de procesos estándar de la organización de acuerdo con unas gulas de manipulación.

Una distincióncrítica entre los niveles de madurez 2 y 3 es el alcance de los estándares, descripciones de procesos y procedimientos.

Page 15: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

El nivel de madurez 2 los estándares, 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 estándares, descripción de procesos y procedimientos para un proyecto son obtenidos a partir del conjunto de procesos estándar de la organización para adaptarlos al proyecto en particular o unidad organizacional y ser entonces más consistentes excepto por las diferencias permitidas en las guías de manipulación.

Otra distinción critica en que en el nivel de madurez 3 los procesos se describen de una manera más rigurosa que en el nivel de madurez 2, un proceso definido claramente establece:

el propósito. Entradas. Criterios de entrada. Actividades. Roles. Mediciones. Pasos de verificación. Salidas y criterios de salida.

En el nivel de madurez 3 los procesos son administrados más proactivamente usando una comprensión 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 organización mejora mucho más los procesos que están relacionados con el nivel de madurez 2, las practicas genéricas asociadas con las metas genéricas 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 organización y los proyectos establecen objetivos cuantitativos para la calidad y el desempeño 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 organización y los implementadores del proceso.

La calidad y el desempeño de los procesos son comprendidos en términos estadísticos y se administran a lo largo de la vida del proyecto.

Para subprocesos seleccionados se coleccionan mediciones específicas del desempeño del proceso y se analizan estadísticamente. Cuando seleccionar subprocesos para análisis es clave para comprender las relaciones entre diferentes subprocesos y su impacto en el alcance de los objetivos de calidad y desempeño de los procesos. Tal enfoque ayuda a asegurar que los subprocesos se monitorean usando estadísticas y otras técnicas cuantitativas y que esto se aplica donde tiene más valor para la empresa.

Page 16: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Las líneas base y modelos de desempeño de los procesos pueda ser usados para ayudar a colocar los objetivos de calidad y desempeño de los procesos que ayudan a alcanzar los objetivos de negocios.

Una distinción crítica entre los niveles de madurez 3 y 4 es la predictibilidad del desempeño de los procesos. En el nivel de madurez 4, el desempeño de los proyectos y subprocesos seleccionados es controlado usando estadísticas y otras técnicas cuantitativas y las predicciones se basan en parte, en el análisis estadístico de grano fino de los datos de los procesos.

NIVEL DE MADUREZ 5: OPTIMIZADO

En el nivel de madurez 5, una organización mejora continuamente sus procesos con base en una comprensión cuantitativa de sus objetivos de negocios y necesidades de desempeño. La organización usa un enfoque cuantitativo para comprender la variación inherente de los procesos y las causas de los resultados de los procesos.

El nivel de madurez cinco se enfoca en mejorar continuamente el desempeño de los procesos a través de mejoras incrementales de los procesos e innovaciones tecnológicas. Los objetivos de calidad de la organización y de desempeño de los procesos son establecidos y revisados continuamente para reflejar los cambiantes objetivos de los negocios y desempeño organizacional, y usados como criterios en la administración de procesos de mejora. Los efectos de desplegar las mejoras de los procesos usando estadísticas y otras técnicas cuantitativas miden y compran con los objetivos de calidad y desempeño de los procesos.

Los procesos definidos del proyecto, el conjunto de procesos estándar de la organización y el soporte tecnológico son objeto de actividades de mejoras medibles.

Una distinción crítica entre los niveles de madurez 4 y 5 es el enfoque en administrar y mejorar el desempeño organizacional. En el nivel de madurez 4 la organización y los proyectos se enfocan en comprender y controlar el desempeño a nivel de subprocesos y usar los resultados para administra los proyectos. En el nivel de madurez 5 la organización se preocupa por el desempeño organizacional total usando datos coleccionados de múltiples proyectos.

El análisis de los datos identifica caídas ó grietas en el desempeño. Estas grietas son usadas para manejar el proceso de mejora organizacional para generar mejoras medibles en el desempeño.

DISTRIBUCIÓN DE LAS ÁREAS DE PROCESO ENTRE NIVELES DE MADUREZ

NIVEL DE MADUREZ 2: ADMINISTRADOCM: Gestión de la configuración.MA: Medición y Análisis.PMC: Monitoreo y Control de Procesos.PP: Planeación de Proyectos.PPQA: Aseguramiento de la Calidad del Proceso y el Producto.REQM: Administración de Requerimientos.SAM: Administración de Acuerdos con los Proveedores.

Page 17: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

NIVEL DE MADUREZ 3: DEFINIDO.DAR: Análisis de Decisiones y Resolución.IPM: Administración Integrada del Proyecto.OPD: Definición de Proceso Organizacional.OPF: Enfoque del proceso Organizacional.OT: Entrenamiento Organizacional.PI: Integración del Producto.RD: Desarrollo de RequerimientosRSKM: Administración del Riesgo.TS: Solución Técnica.VAL: Validación.VER: Verificación.

NIVEL DE MADUREZ 4: CUANTITATIVAMENTE ADMINISTRADO.OPP: Desempeño de Proceso Organizacional.QPM: Administración Cuantitativa de Proyectos.

NIVEL DE MADUREZ 5: OPTIMIZADO.CAR: Análisis Causal y Resolución.OPM: Administración de Desempeño Organizacional.

23/08/2011

CAPITULO 4

RELACIONES ENTRE AÉREAS DE PROCESOEn este capítulo describimos las relaciones clave entre áreas de proceso para ayudar a ver la visión de la organización, de las aéreas de proceso y su mejora, y cómo las áreas de proceso dependen de la implementación de las otras aéreas de proceso.

Las relaciones entre múltiples aéreas de proceso, incluyendo la información y artefactos que fluyen de un área de proceso a otra – ilustradas por figuras y descripciones en este capítulo – le ayudaran a ver un panorama de la implementación y mejora de los procesos.

Las iniciativas de mejora de procesos exitosas deben ser manejadas por los objetivos de negocios de la organización. Por ejemplo, un objetivo de negocios común es reducir el tiempo que toma poner un producto en el mercado. El objetivo de mejora de procesos derivado de este podría ser mejorar el proceso de administrar el proyecto para asegurar una entrega a tiempo; estas mejoras se basan en las mejores prácticas de las áreas de proceso planeación de proyectos y monitoreo y control de proyectos.

Aunque en este capítulo agrupamos las áreas de proceso para simplificar la discusión de sus interrelaciones, las áreas de proceso a menudo interactúan y tienen un efecto unas sobre otras, sin importar su grupo, categoría o nivel. Por ejemplo, el área de procesos Análisis de Decisiones y Resolución (un área de proceso de soporte, del nivel de madurez 3) contiene prácticas específicas que manejan el proceso de evaluación formal usado en el área de

Page 18: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

procesos solución técnica para seleccionar una solución técnica de conjunto de alternativas de solución.

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 categorías:1. Administración de Procesos.2. Administración de Proyectos.3. Ingeniería.4. Soporte.

Además dentro de cada categoría, las áreas de proceso se dividen en dos grupos:a. Áreas Básicas.b. Áreas Avanzadas.

ADMINISTRACIÓN DE PROCESOS:

Las áreas de proceso de la administración 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 Administración de Procesos en CMMI-DEV son las siguientes: Definición de Proceso Organizacional (OPD). Enfoque de Proceso Organizacional (OPF). Administración del Desempeño Organizacional (OPM). Entrenamiento Organizacional (OT). Desempeño de Proceso Organizacional (OPP).

Áreas básicas de administración de procesos proporcionan a la organización la capacidad para documentar y compartir las mejores prácticas, activos de procesos organizacionales y aprendizaje a lo ancho de toda la organización.

La figura 4.1 proporciona una vista a vuelo de pájaro de las interacciones entre las áreas básicas de administración de procesos y las otras categorías de áreas de proceso.

Como se ilustra en la figura 4.1, el área de proceso Enfoque de Proceso Organizacional (OPF) ayuda a la organización a planear, implementar y desplegar mejoras de procesos organizacionales basadas en una comprensión de las fortalezas y debilidades de los procesos y activos de procesos de la organización.

Page 19: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Ilustración 2- Figura 4.1 Áreas Básicas de Admón. de Procesos.

Los candidatos a mejora de procesos de la organización se obtienen a partir de varias fuentes. Estas actividades incluyen propuestas de mejora de procesos, medición de los procesos, lecciones aprendidas en la implementación de los procesos y resultados de la evaluación de los procesos y de los productos.

El área de procesos Definición de Procesos Organizacional establece y mantiene el conjunto de procesos estándares de la organización, estándares de ambiente de trabajo y otros activos basados en las necesidades de los procesos y objetivos de la organización. Estos otros activos incluyen descripciones de modelo de ciclo de vida, guías de manipulación de procesos, documentación y datos relacionados con los procesos.

Los proyectos manipulan el conjunto de procesos estándar de la organización para crear sus procesos definidos. Los otros activos soportan la manipulación así como la implementación 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 incorporados de la manera apropiada dentro del conjunto de procesos estándar de la organización y otros activos.

El área de procesos Entrenamiento Organizacional identifica las necesidades estratégicas de entrenamiento de la organización, así como las necesidades tácticas de entrenamiento que son comunes a través de los proyectos y grupos de soporte. En particular el entrenamiento es

Page 20: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

desarrollado u obtenido para desarrollar las habilidades requeridas para realizar el conjunto de procesos estándar de la organización. 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

AÉREAS AVANZADAS DE ADMINISTRACIÓN DE PROCESOS

Ilustración 3 – Áreas Avanzadas de Admón. De procesos.

Las áreas avanzadas de administración de procesos proporcionan a la organización una capacidad mejorada para alcanzar los objetivos cuantitativos de calidad y desempeño de los procesos.

La figura 4.2 proporciona una vista a vuelo de pájarode las interacciones entre las áreas avanzadas de administración de procesos y las otras categorías de áreas de proceso. Cada una de las áreas avanzadas de administración de procesos depende de la habilidad para desarrollar y desplegar procesos y activos de soporte. Las áreas básicas de administración de procesos proporciona esta habilidad.

Page 21: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Como se ilustra en la figura 4.2 el área de proceso Desempeño de Procesos Organizacional (OPP) deriva objetivos cuantitativos para la calidad y desempeño de los procesos a partir de los objetivos de negocio de la organización. La organización proporciona a los proyecto y grupos de soporte mediciones comunes, líneas base para desempeño de los procesos y modelos de desempeño de los procesos

Estos activos adicionales de la organización son de soporte y componen un proceso definido que puede alcanzar los objetivos de calidad y desempeño del proceso y soportar la administración cuantitativa. La organización analiza los datos de desempeño de los procesos coleccionados a partir de estos procesos cuantitativa de la calidad del producto, calidad del servicio y desempeño del proceso del conjunto de procesos estándar de la organización.

En la Administración del Desempeño Organizacional (OPM), las líneas base y modelos del desempeño de los procesos son analizadas para comprender la habilidad de la organización para cumplir sus objetivos de negocios y para derivar los objetivos de calidad y desempeño de los procesos.

Con base en esta comprensión la organización selecciona y despliega proactivamente mejoras incrementales e innovadoras que mejoran mensurablemente el desempeño de la organización. La selección de las mejoras a desplegar se basa en una comprensión cuantitativa de los probables beneficios y costos predichos de las mejoras candidatas a ser desplegadas la organización también puede ajustar objetivos de negocios y los objetivos de calidad y desempeño de los procesos como sea apropiado.

ADMINISTRACIÓN DE PROYECTOS.

Las áreas de proceso de administración de proyectos cubren las actividades de administración de los proyectos relacionadas con planear, monitoreas y controlar el proyecto.

Las siete áreas de proceso de Administración de Proyectos en el CMMI-DEV son las siguientes:

Administración Integrada de Proyectos (IPM). Control y Monitoreo de Proyectos (PMC). Planeación de Proyectos (PP). Administración cuantitativa de proyectos (QPM). Administración de Requerimientos (REQM). Administración de los Riesgos (RSKM). Administración de Acuerdos con Proveedores (SAM).

AÉREAS BÁSICAS DE ADMINISTRACIÓN DE PROYECTOSManejan 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 pájaro de las interacciones entre las áreas de proceso de Administración de Proyectos y las otras categorías de áreas de proceso. Como se ilustro en la figura 4.3 el área de proceso. Planeación de Proyectos incluye el desarrollo del

Page 22: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

plan del proyecto, involucrar a los actores relevantes, obtener compromisos para el plan y mantener el plan.

La planeación 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 administración 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.

Ilustración 4 – ÁreasBásicas de Admón. de Proyectos

Por ejemplo, estos planes cubren la administración de la configuración verificación, mediciones y análisis.

El área de proceso Monitoreo y Control de Proyectos contiene prácticas 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 desvía significativamente de los valores esperados se toman las acciones correctivas apropiadas. De estas acciones puede influir el replanteamiento, lo que requiere usar prácticas de planeación de los proyectos.

29/08/2011

Page 23: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

El área de procesos Administración 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 administración 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 administración de requerimientos es y dinámica y a menudo una secuencia recursiva de eventos. El área de proceso de Administración de requerimientos es fundamental para controlar y disciplinar el proceso de ingeniería. El área de procesos Administración 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 prácticamente.

El proveedor es seleccionado y acuerdos con el proveedor son establecidos para administrar al proveedor.

El progreso y desempeño 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 aceptación son conducidas sobre el componente de producto producido por el proveedor.

Áreas de proceso avanzadas de Administración de Proyectos.

Manejan actividades tales como, establecer un proceso definido que es obtenido manipulando el conjunto de procesos estándar de la organización, estableciendo el ambiente de trabajo del proyecto a partir de los estándares de ambiente de trabajo de la organización, coordinando y colaborando con los actores relevantes, formando y sosteniendo grupos para la conducción de los proyectos, administrando cuantitativamente el proyecto y administrando los riesgos.

La figura 4.4 proporciona una vista a vuelo de pájaro de las interacciones entre las áreas de proceso avanzadas de Administración de proyectos y las demás categorías de áreas de proceso. Cada área de proceso Avanzada de Administración de proyectos depende de la habilidad para planear, monitorear y controlar el proyecto. Las Áreas de proceso básicas de administración de proyectos proporcionan esta habilidad.

Page 24: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Ilustración 5 – Áreas de Proceso Avanzadas de Admón. de Proyectos

El área de proceso Administración Integrada de proyectos (IPM) establece y mantiene los procesos definidos del proyecto que son obtenidos manipulando el conjunto de procesos estándar de la organización (Definición 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 organización, el ambiente de trabajo del proyecto es establecido y mantenido a partir de los estándares de ambiente de trabajo de la organización, y los grupos son establecidos usando las reglas y guías de la organización. Los actores relevantes del proyecto coordinan sus esfuerzos de una manera sincronizada a través de la identificación, negociación y seguimiento de dependencias críticas y la resolución de temas de coordinación.

Aunque la identificación y monitoreo de los riesgos son cubiertos en las áreas de proceso Planeación de Proyectosy Monitoreo y control de los procesos, el área de procesos Administración de los Riesgos toma un enfoque continuador de mirada adelantada para administrar los riesgos con actividades que incluyanidentificación de parámetros de los riesgos, evaluación de los riesgos y mitigación de los riesgos.

El área de proceso administración cuantitativa de proyectos QPM establece objetivos de calidad y desempeño de los procesos, componen proceso definido que puede ayudar a cumplir esos objetivos y administrar cuantitativamente el proyecto. Los objetivos de calidad y desempeño de los procesos se basan en los objetivos establecidos por la organización y los clientes.

Page 25: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Los procesos definidos del proyecto se componen usando estadísticas y otras técnicas cuantitativas. Tal análisis habilita al proyecto para predecir, si cumplirá sus objetivos cuantitativos de calidad y desempeño.

Con base en la predicción, el proyecto puede ajustar sus procesos definidos o negociar cambios a los objetivos de calidad y desempeño del proceso.

A medida que el proyecto progresa, el desempeño de subprocesos seleccionados es monitoreado cuidadosamente, para ayudar a evaluar si el proyecto que está en seguimiento cumplirá sus objetivos.

INGENIERÍA:

Cubre las actividades de desarrollo y mantenimiento que se comparten a través de la disciplina de ingeniería.

Las áreas de proceso de ingeniería fueron escritos usando una terminología general de ingeniería de tal manera que cualquier disciplina técnica involucrada en el desarrollo de los productos (ej.: Ingeniería de software, ingeniería mecánica) pueda usarlas para mejorar sus procesos.

Las áreas de proceso de ingeniería también integran los procesos asociados con diferentes disciplinas de ingeniería 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 técnicas. Este enfoque hacia la efectividad de los procesos evita la tendencia hacia una mentalidad organizacional cuello de botella.

Las áreas de proceso de ingeniería 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 ingeniería en CMMI-DEV son:

Integración de Producto (PI). Desarrollo de Requerimientos (RD). Solución Técnica (TS). Validación (VAL). Verificación (VER).

La figura 4.5 proporciona una vista a vuelo de pájaro de las interacciones entre las cinco áreas de proceso de ingeniería.

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

Page 26: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

producto es analizado para producir una solución 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 desempeño del producto, atributos de calidad, características de diseño, requerimientos de verificación, etc. en términos que el desarrollador comprende y usa.

El área de procesos de desarrollo de requerimientos suministra requerimientos al área de proceso Solución Técnica (TS), donde los requerimientos con convertidos en la arquitectura del producto, diseño de componentes del producto (por codificación ó fabricación). Los requerimientos también son suministrados al área de procesos Integración 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 SoluciónTécnica (TS) desarrolla paquetes de datos técnicos para los componentes del producto ser usados por Integración del Producto ó Administración de Acuerdos con Proveedores. Las soluciones alternativas son examinadas para seleccionar el diseño óptimo con base en los criterios establecidos. Estos criterios pueden ser significativamente diferentes a través de los productos, dependiendo del tipo de producto, ambiente operacional, requerimientos de desempeño, requerimientos de soporte, costo y cronogramas de entrega. La tarea de seleccionar la solución final hace uso de prácticas específicas en las áreas de proceso Análisis de Decisiones y Resolución.

Page 27: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Ilustración 6 – Áreas de Proceso de Ingeniería

El área de procesos SoluciónTécnica (TS) descansa sobre las prácticasespecíficas del área de procesos de Verificaciónpara realizar la verificación del diseño y la revisión de pares durante el diseño y antes de construir el producto final.

El área de procesos Verificación (VER) asegura que los productos de trabajo seleccionados cumplen los requerimientos especificados. El área de procesos verificación selecciona los productos de trabajo y métodos de verificación que serán usados para verificar los productos de trabajo contra los requerimientos especificados. La verificación es generalmente un proceso incremental, comenzando con la verificación de componentes del producto y usualmente concluyendo con la verificación de los productos completamente ensamblados.

La verificación también maneja revisión de pares. Este es un método 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 Validación valida incrementalmente los productos contra las necesidades de los clientes. La validación puede ser realizar en el ambiente operacional ó en un ambiente operacional simulado. La coordinación con el cliente sobre los requerimientos de la validación es un elemento importante dentro de esta área de proceso.

02/09/2011

El alcance del área de procesos Validaciónincluye la validación de productos, componentes de productos, productos de trabajo intermedio seleccionado, y proceso. Estos elementos

Page 28: Cuaderno IngeSoft II V5.0

Requerimientos ConstrucciónDiseño

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

validados a menudo pueden requerir verificación y revalidación. Los temas descubiertos durante la validación usualmente son resueltos en las áreas de proceso desarrollo de requerimientos o solución técnica.

El área de procesos Integración de Producto contiene las prácticasespecíficas relacionadas con generar una estrategia de integración, integrando componentes de productos, y entregando el producto al cliente.

La integración de productos usa prácticasespecíficas de verificación y validación implementando el proceso de integración de productos. Las prácticas de verificación, verifican las interfaces y requerimientos de interfaz de los componentes del producto antes de la integración. La verificación del interfaz es un evento esencial en el proceso de integración. Durante la integración del producto en el ambiente operacional, se usan las prácticasespecíficas de validación.

RECURSIÓNDE INTERACCIÓN EN EL PROCESO DE INGENIERÍA

La mayoría de los estándares de procesos están de acuerdo en que hay dos formas como se pueden aplicar los procesos. Estas dos formas se llaman iteración y recursión.

La recursión ocurre cuando un proceso es aplicado a niveles sucesivos de elementos del sistema dentro de la estructura de un sistema.

Los resultados de una aplicación son usados como entrada en el siguiente nivel en la estructura del sistema.

Por ejemplo. El proceso de verificación estádiseñado 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 verificación depende enteramente del tamaño y complejidad del producto final.

La iteración ocurre cuando los procesos son repetidos al mismo nivel des sistema. La nueva información que es creada por la implementación de un proceso, retroalimenta información hacia a tras a un proceso relacionado.

Pruebas

Page 29: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Esta nueva información, típicamente origina preguntas que deben ser resueltas antes de terminar el proceso.

Por ejemplo, la iteración ocurre con mayor probabilidad entre en desarrollo de requerimientos y solución técnica. La re aplicación del proceso puede resolver las preguntas que surgieron. La iteración puede asegurar la calidad antes de aplicar al siguiente proceso.

Los procesos de Ingeniería (ej. Desarrollo de Requerimientos, Verificación) son implementados repetidamente sobre un producto. Para asegurar que estos procesos de ingeniería han sido adecuadamente manejados antes de la entrega al cliente. Es más, los procesos de ingeniería son aplicados a componentes de los productos, por ejemplo, algunas preguntas surgieron por procesos asociados con la verificación y la validación, pueden ser resueltos por procesos asociados con desarrollo requerimientos o integración de productos. La recusación y la interacción 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 administración de proyectos podrían también ser recursivas porque muchas veces los proyectos están 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 organización.

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 evaluación 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:

Análisis casual y resolución (CAR). Administración de la configuración (CM). Análisis de Decisiones y Resolución (DAR). Medición y Análisis (MA). Aseguramiento de la calidad de proceso y el producto (PPQA).

AéreasBásicas 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 básicas de soporte proporcionan funciones de soporte que también ayudan a implementar varias prácticas genéricas.

Page 30: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

La figura 4.6 proporciona una visita a vuelo de pájaro de las interacciones entre las áreas de proceso básicas de soporte y las otras áreas deproceso.

El áreade proceso Medición y Análisis soporta a todas las PA (áreas de proceso) proporcionando practicas específicas que guían a los proyectos y a las organizaciones a alinear sus necesidades de medición y objetivos con un enfoque de medición que es usado para soportar las necesidades de información de la admón. El resultado puede ser usado para tomar decisiones informadas y tomar las acciones correctivas apropiadas.

Ilustración 7 – Áreas Básicas de soporte

El PA Aseguramiento de la calidad del proceso y el producto (PPQA) soporta a todas las PAS proporcionando prácticasespecíficas para evaluar objetivamente los procesos realizados, productos de trabajo y servicios contra las descripciones de procesos aplicables, estándares 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 admón. la visibilidad apropiada adentro y la retroalimentación de los procesos y productos de trabajo asociados a través de la vida del proyecto.

Page 31: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ 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 administración la apropiada visibilidad adentro y la retroalimentación de los procesos y productos de trabajo asociados a través de la vida del proyecto.

El PA Administración de la configuración soporta a todas las PA estableciendo y manteniendo la integridad de todos los productos de trabajo usando identificación de la configuración control de la configuración contabilidad del estado de la configuración y auditorías de la configuración. Los productos de trabajo ubicados bajo la administración de la configuración incluyen los productos que son entregados al cliente, productos de trabajo diseñados 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 administración de la configuración incluyen planes, descripción de procesos, requerimientos, datos de diseño, diagramas especificaciones del producto, código, compiladores, archivos de datos del producto, y publicaciones técnicas del producto.

PA Avanzadas de soporte proporcionan al proyecto y a organización una capacidad mejorada de soporte. Cada una de estas PA se basa en entradas específicas o practicas de otros PA.

Ilustración VIII – 4.7

Page 32: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

La figura 4.7 proporciona una vista a vuelo de pájaro de las interacciones entre los PA avanzados de soporte y otros PA.

Usando la PA Análisis causal y resolución (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 raíz que se analiza y tomar planes de acción los cambios efectivos a los procesos pueden resultar en las propuestas de mejora enviados al conjunto de procesos estándar de la organización.

El PA Análisis de decisiones y resolución (DAR) soporta a todas las áreas de proceso determinando que temas deben ser sujetos a evaluación formal y entonces aplicando el proceso de evaluación formal a esos temas.

METAS GENÉRICAS Y PRÁCTICAS GENÉRICAS.

PanoramaEsta sección describe en detalle todas las metas y prácticas genéricas de los componentes del modelo CMMI que manejan directamente la institucionalización de procesos. A medida que usted maneje cada área de procero, refiérase a esta sección para los detalles de todas las prácticas genéricas.

Las elaboraciones de prácticas genéricas aparecen después de las practicas genéricas para proporcionar una guía de cómo la practica genérica puede ser aplicada de manera individual a las áreas de proceso.

Institucionalización de procesosLa institucionalización es un concepto importante en la mejora de procesos. Cuando se menciona en las metas genéricas y practicas genéricas, la institucionalización 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 más probable que sea retenido durante los tiempos de estrés (crisis). Cuando los requerimientos y objetivos de los procesos cambian, sin embargo, la implementación de los procesos podría también necesitar cambiar, para asegurarse de que permanece efectiva. Las prácticas genéricas describen actividades que manejan estos aspectos de la institucionalización.

El grado de institucionalización está encarnado en las metas genéricas y es expresada en los nombres de los procesos asociados con cada meta como se indica en la tabla.

Meta Genérica Progresión de ProcesosGG1 Proceso RealizadoGG2 Proceso Administrado

Page 33: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

GG3 Proceso Definido(GG = GenericGoal)

La progresión de la institucionalización 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 específicas de una PA.

Proceso administradoUn proceso administrado es un proceso realizado que es planeado y ejecutado de acuerdo con una política; 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 descripción del proceso.

El proceso puede ser instanciado por un proyecto grupo o función organizacional la administración del proceso se preocupa de la institucionalización y adquisición de otros objetivos específicos 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 estrés.

Los requerimientos y objetivos para el proceso son establecidos por la organización. El estado de los productos de trabajo y servicios son visibles para la administración 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 distinción entre un proceso realizado y un proceso administrado es la extensión con que el proceso es administrado. Un proceso administrado es planeado (el plan pueden ser parte de un plan mayor) y la ejecución del proceso es administrada contra el plan. Se toma acciones correctivas cuando los resultados actuales de ejecución se desvían significativamente del plan. Un proceso administrado cumple los objetivos del plan y esta institucionalizados por su ejecución consistente.

Proceso definidoUn proceso definido es un proceso administrado que se obtuvo manipulando el conjunto de procesos estándar de la organización de acuerdo con las guías de manipulación de la organización, ha mantenido la descripción 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 organización y ellos

Page 34: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

representan inversiones que la organización hace en espera de proporcionar valor de negocios actuales y futuros.

El conjunto de procesos estándar de la organización, que son la base de los procesos definidos, es establecido y mejorado con el tiempo. Los procesos estándar describen los elementos fundamentales del proceso que son esperados en el proceso definido. Los procesos estándar también 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 estándar de la organización 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 más de un proceso definido (ej. Uno para desarrollar el producto y otro para robar el producto).

Un proceso definido establece claramente lo siguiente: Propósito Entradas Criterios de entrada Actividades Roles Mediciones Pasos de verificación Salidas Criterios de salida

La administración de los riesgos consta de las siguientes actividades:1. Identificación de los riesgos 2. Evaluación de los riesgos 3. Selección de los riesgos4. Planear la gestión de riesgos

Hacemos referencia a la metodología Delphi para riesgos.

1. Identificador de los riesgosSegún el método 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.

Page 35: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

La lista de riesgos será la unión de estas listas:

A que riesgos esta expuesto un proyecto?

Roger Pressman, en su famoso libro sobre ingeniería del software hace una taxonomía 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 interés 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

Riesgos Naturales

A B C

Lista A Lista B Lista A

Lista C Lista A

Lista de Riesgos:(Lista A)U(Lista B)U(Lista C)

Page 36: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Que un rayo dañe el disco duro del servidor Incendios Inundaciones Terremotos

Riesgos Sociales Asonada Tomas guerrilleras Asalto Robo Hackers

2. Evaluación de los riesgosUn riesgo tiene dos variables principales:

Probabilidad de ocurrencia Es un numero real de 0 a 1 o un %.Probabilidad:

Numero de casos positivosNumero total de casos

Cuando la cantidad de casos considerados es un número estadísticamente significativo.

Generalmente para proyectos de software, no tenemos un número de proyectos estadísticamente significativos y es imposible aplicar con rigor la definición de probabilidad.

Aquí es donde le método Delphi nos dice que al menos podemos tener en cuenta la experiencia de los expertos, porque ellos han visto cierta cantidad de proyectos.

ImpactoQue pasa cuando el riesgos se hace realidad?

El proyecto sufrirá una perdida El impacto mide el tamaño de la perdida.Generalmente se trabaja como un número entero del 1 al 4. Es una validez discreta.

Significado de los impactos:1. Despreciable: la pérdida que genera el riesgo es muy pequeña tanto que no importa.2. Marginal: Aunque la pérdida es más apreciable, el proyecto se podrá recuperar

fácilmente. 3. Critico: El proyecto ha sufrido una gran perdida. A pesar de esto el proyecto puede

terminar.4. Catastrófico: La pérdida es tan grande que el proyecto no se puede terminar.

Para evaluar la probabilidad de ocurrencia y el impacto para cada riesgo de lista, se pedirá al experto que llenen los siguientes formatos:

Page 37: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Riesgo Prob. % Impacto(1-4)

Los resultados se procesaran estadísticamente:La probabilidad:Obtenemos el promedio. También se calcula la desviación estándar que nos da una idea de la calidad del dato.

Una desviación pequeña indica un acuerdo entre los expertos. Una desviación grande indica desacuerdo entre los expertos y mayor incertidumbre

del dato.El Impacto:Le podemos aplicar la moda.También se puede usar la desviación estándar 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

SELECCIÓN DE RIESGOS

Calculamos la métrica 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:

A BC

Page 38: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

RIESGO CONDUCTOR

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 más importantes.De esta manera se seleccionan los riesgos que serán gestionados.

PLAN DE GESTION DE RIESGOSPara cada uno de los riesgos seleccionados en el paso anterior, se van a diseñar 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 después 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 estimación es una actividad que se realiza antes de realizar el proyecto, cuando tenemos muy poca información sobre el proyecto. Pero este calculo tiene una gran incertidumbre, típicamente de +- 50%.

A medida que tengamos más información debemos actualizar la estimación para ir disminuyendo la incertidumbre.No se recomienda redactar un contrato solo con base en una estimación. 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 método más antiguo de estimación. Se aplica desde la década de los 70’s. Para contar las líneas de código se deben filtrar las líneas en blanco y los comentarios.Se debe tener una tabla de los datos históricos de proyectos realizados a los cuales se les ha medido su tamaño en KLDC.

20%

Page 39: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

KLDC=1000 Líneas de código

Se muestra un ejemplo hipotético de tal tabla.PROYECTO TAMAÑO

(KLDC)ESFUERZO

P-MES)DOCUMENTACION

(PAGINAS)ERRORES DEFECTOS COSTO

(DOLARES)Contabilidad 14 8 350 35 7 11.700Cartera 8 4 200 20 4 6.700Presupuesto 10 6 300 27 3 8.500Inventario 5 2 150 8 2 4.100SUMAS 37 20 1000 90 16 31.000Métricas/KLDC 0,54

P-MES/KLDC27 PAG/KLDC 243

ERROR/KLDC0,43

DEFECTOS/KLDC

837 DOL/KLDC

Como se ve en la tabla, primero se suman los datos y luego se calculan las métricas orientadas al tamaño en KLDC.

UNA ESTIMACIONSe dese hacer un software bancario. Preguntado a ingenieros de otros bancos, se estiman que este software tiene un tamaño de 17 KLDC. Por favor estime el proyecto.

COSTO = (837 dólares/KLDC) x 17 KLDC = 14.229 dólaresESFUERZO = (0,54 P-M/KLDC) x 17 KLDC = 9,18 P-MDOCUMENTACION = (27 PAG/KLDC) x 17 KLDC = 459 PAGINASERRORES = (243 ERRORES/KLDC) x 17 KLDC = 41 ERRORESDEFECTOS = (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 demás miembros del grupo:

1

6

10

Líneas de comunicación = Personas (Personas -1)/2

Page 40: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

CRITICA DE ESTE METODO1. El tamaño del programa depende del lenguaje de programación. Entonces la tabla y el

nuevo proyecto deben estar en el mismo lenguaje.2. El estilo personal también influye en el tamaño. Así la tabla y el nuevo proyecto

deberían ser de los mismos desarrolladores.3. Si no hemos realizado el proyecto. ¿Cómo sabemos cuantas líneas de código 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 tamaño en líneas de código como estimador, Albrecht propone medir la funcionalidad del programa y usar este métrica 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: Menús, barras de herramientas. Albrecht las llama peticiones.- Almacena información: Archivos, hoy son tablas.- Comunicarse con otros programas: interfaces externas.

También se considera el grado de complejidad de cada función: simple, medio y complejo.

FORMATO PARA PUNTOS DE FUNCION

A B C D E F G HPARAMETR

OSIMPLE MEDIO COMPLEJO SUBTOTAL

CANTIDAD PESO CANTIDAD PESO CANTIDAD PESOEntradas X 3 X 4 X 6Salidas X 4 X 5 X 7

Peticiones X 3 X 4 X 6Archivos X 7 X 10 X 15

Interfaces X 5 X 7 X 10CUENTA TOTAL

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 influencia1 incidental2 moderado3 medio4 significativo5 esencial

H = B x C + D x E + F x G

Ʃ H

Page 41: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

*----------------------------------------------------------------------------*En la E. XXX desean aplicar el CMMI solamente al proceso de producción: ¿Deberían 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 extraídos de un conjunto de procesos estándar, tienen las buenas prácticas desarrolladas con los proyectos y los procesos, y recolectan mediciones de los proyectos, quieren comprender estadísticamente sus procesos al nivel del subproceso para tener modelos que les permitan predecir el desempeño de cada proceso y tratar de mejorarlo. ¿Qué nivel de madurez exhibe esta empresa? Cuantitativamente Administrado.Una E. esta implementando el área de proceso Integración 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¿Cuál es el resultado del área de proceso Desempeño de Proceso Organizacional?OPM es un área de proceso correspondiente a las áreas avanzadas de la administración de procesos y es de nivel 5. Deriva objetivos cuantitativos para calidad y desempeño de los procesos a partir de los objetivos del negocio.Medición de los procesos y calidad Objetivos de procesos y calidadLíneas baseObjetivos de desempeño ModelosUna pequeña E. de software considera que su éxito se debe a que su programador principal es un genio y sin el estarían 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 prácticas, las cuales se mantienen aun en tiempos de crisis. El proyecto de software contable y financiero utiliza metodología 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 estándar de procesos, recolecta mediciones de todos los procesos clave y crea modelos estadísticos para comprender los procesos, pero además utiliza la estadística y los modelos cuantitativos para predecir el desempeño de toda empresa y mejorarlo utilizando innovación y tecnología. ¿Qué nivel de madurez exhibe esta empresa? Optimizado.Una E. esta implementado el área de proceso Administración Cuantitativa de Proyectos. ¿Qué otras áreas de proceso debe tener implementadas para cumplir con su actual nivel de

Page 42: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

madurez? __CAR-OPD-OT-PPQA-RSKM-VER-DAR-OPF-MA-PI-SAM-CM-IPM-__OPM-PMC-RD-TS-OPD-OPP-PP-REQM-VAL¿Que información intercambian las categorías de área de proceso de Administración de Procesos y Administración de Proyectos? La información que intercambian las distintas áreas de proceso de Administración de Procesos y administración de proyectos son:Procesos estándar, estándares de trabajo y otros activos (OPDAdmin Proyectos)Información de mejora (lecciones aprendidas, datos, artefactos)(Admin proyectos-> OPD)Necesidad de entrenamiento (Admin proyectos -> OT)Entrenamiento para proyectos y grupos de soporte, en procesos estándar y activos (OTAdmin Proyectos) Propuesta de mejora de procesos, participación en definir, evaluar y desplegar proceso (Admin proyectos OPF)Necesidad de objetivos de procesos de la organización (OPFAdmin proyectos)La anterior información se da entre las áreas básicas de administración de procesos y la categoría Admin de proyectos a continuación se lista la información intercambiada entre las áreas avanzadas de Admin de procesos y Admin de proyectos:Datos de calidad y desempeño (Admin proyectos-> OPP)Datos de costo y beneficio de pilotos de mejora (Admin proyectos OPM)La calidad y el proceso de las medidas, las líneas de base, los objetivos de desempeño y los modelos (OPP-> Admin de proyectos)Toda la información anterior también se intercambia con ingeniería y soporte a continuación se encontrara la información explicita entre áreas avanzadas de Admin de proyectos y las áreas de Admin de procesos tano básicos como avanzados:Visión compartida del proyecto Datos de desempeño del proyectoTaxonomías de riesgos y parámetros, estado de los riesgos. Planes de mitigación y acción correctiva.Composición del proyecto y procesos definidosReglas de agrupación y guías, lecciones aprendidas, datos de planeación y desempeño Procesos estándar de la organización, estándares de ambientes de trabajo y activos de soporte Datos para Admin estadísticaObjetivos de desempeño de procesos, líneas base y modelos

Una E. de desarrollo de software desea iniciar con la mejora de procesos CMMI, pero no se sabe como comenzar. Indícale 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 Definición de Proceso Organizacional?OT Procesos estándar y otros activos ------------OPDD+IPPD ---procesos estándar, estándares de ambiente de trabajo --- PA de gestión de proyectos, soporte e ingeniería.

Page 43: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

¿Qué información intercambian las categorías de área de proceso Administración y Administración de Proyectos?Necesidades de procesos, objetivos de la organización.Entrenamiento para proyectos, grupos, soporte en procesos estándar y activo.Necesidad de entrenamiento.Procesos estándar, estándares de ambiente.Información de mejora.Propuestas de mejora de procesos; participación y definición, evaluación y despliegue de procesos.Datos de costo beneficio de las mejoras pilotadas.Objetivos de calidad y desempeño de los procesos, mediciones, línea base y modelos.Datos de desempeño de los procesos y capacidad.¿Qué información intercambian las categorías de proceso Administración de Proyectos e ingeniería y soporte?Estado, temas y resultados de evaluaciones del proceso y el producto; mediciones y análisis.Acción correctivaQue construirQue hacerAcuerdosNecesidades de mediciónRequerimientos de componentes del producto, temas, técnicas. Componentes del producto terminados, revisiones y pruebas de aceptación.Objetivos de desempeño de los procesos líneas base y modelos.Datos de Admin estadísticaProcesos estándar de la organización, estándares de ambiente de trabajo y activos de soporte.Lecciones aprendidas, planeación y datos de desempeño.Reglas y guías IPPDArquitectura del producto para estructuras de grupoVisión compartida del proyectoDatos de desempeño del proyectoProcesos definidos del proyecto y ambiente de trabajo coordinación, acuerdos y temas a resolver. Grupos integrados para realizar procesos de ingeniería y soporte.

Defina el proceso Desarrollo de Requerimientos:Propósito: diseñar un programa para lo que necesite el clienteEntradas: peticiones del cliente, que quiere que haga el programaCriterios de entrada: que no sean ambiguas, que estén bien definidos, que no estén en conflictoActividades:…..

Indique en cuales áreas de proceso pueden surgir propuestas de mejora de procesos: OPF-OPM-CAR

Page 44: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

En que área de proceso se le colocan los procesos definidos a los proyectos, adaptándolos a partir de los procesos estándar: IPMEmpleado que no cumple con sus funciones y obvia procedimientos. ¿Que área de proceso esta fallando? PPAQEn que nivel de madurez la organización se pone a estudiar y medir los subprocesos para tratar de predecir el desempeño. CUANTITATIVAMENTE ADMINISTRADO.En cual área de proceso se implementa la trazabilidad desde los productos hasta los requerimientos y necesidades del cliente. REQMEn cual área de proceso se predice si la empresa cumplirá con sus objetivos de negocio. OPMEn que nivel institucionalizado se asegura que las buenas practicas serán retenidas durante los tiempos de crisis. PROCESO ADMINISTRADO.En cuales áreas de proceso se implementan las propuestas de mejora. OPF-OPMEn cual área de proceso se predice si el proyecto cumplirá sus objetivos de calidad y desempeño. QPMQue área de proceso realiza el análisis causa raíz a los procesos definidos del proyecto. CAR

EJEMPLO PARA PUNTOS DE CASOS DE USO

Evaluaremos el caso de uso“Retirar dinero del cajero automático”

CASO DE USO: Retirar dinero del cajero automáticoACTORES: ClientePROPOSITO: Realizar un retiro de dinero, desde un cajero automáticoVISION GENERAL: Un cliente llega al cajero automático, introduce la tarjeta, se identifica y

solicita realizar un retiro de dinero.El cajero le da el dinero solicitado tras comprobar que la operación puede realizarse.El cliente toma el dinero y se va.

CURSO NORMAL DE LOS EVENTOS

ACCION DE LOS ACTORES RESPUESTA DEL SISTEMA1. Este caso de uso empieza cuando n

cliente introduce la tarjeta en el cajero.

2. El sistema pide la clave de identificación.

3. El cliente introduce la clave 4. Presenta las opciones disponibles.5. El cliente selecciona la operación de

retiro.6. Pide la cantidad a retirar.

7. El cliente introduce la cantidad requerida.

8. El sistema procesa la petición y eventualmente entrega el dinero solicitado.

9. Devuelve la tarjeta y genera un recibo.

10. El cliente recoge la tarjeta, el recibo y el dinero. Procede a retirarse.

Page 45: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

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 DESCRIPCION FACTOR CANTIDAD DE ACTORES

SUB TOTAL

SIMPLE API 1 0 0MEDIO PROTOCOLO,

INTERFAZ DE TEXTO

2 0 0

COMPLEJO GUI 3 1 3UAW 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 DESCRIPCION FACTOR CANTIDAD DE ACTORES

SUB TOTAL

SIMPLE TRANSACCIONES <= 3

5 1 5

MEDIO 4<=TRANSACCIONES <=7

10 0 0

COMPLEJO TRANSACCIONES >7 15 0 0UUCW 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 técnica.

FACTOR PESO VALOR SUB TOTALT1 2 5 10T2 1 4 4T3 1 3 3T4 1 5 5T5 1 5 5T6 0,5 3 1,5T7 0,5 4 2T8 2 5 10T9 1 4 4T10 1 5 5T11 1 5 5T12 1 0 0

Page 46: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

T13 1 5 5TFACTOR 59,5

TCF = 0,6 + (0,01 * TFACTOR) = 0,6 + 0,595TCF = 1.195

Paso 2.2 Calcular EF, el factor ambiental.

FACTOR PESO VALOR SUB TOTALE1 1,5 3 4,5E2 0,5 1 0,5E3 1 4 4E4 0,5 4 2E5 1 5 5E6 2 3 6E7 -1(en contra del

proyecto)5 -5

E8 -1 4 -4EFFACTOR 13

EF = 1,4 – 0,03*EF = 1,4 -0,03 * 13 = 1,4 – 0,39EF = 1.01

UCP = UUCP * TCF * EF = 8 * 1.195 * 1.01UCP = 9,65 (Puntos de caso de Uso)

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

09/11/2012Ejercicio

Desarrollar un despachador automático de taxis.

Al atender la llamada, usando el identificador busca BD al cliente. Coordenada geográfica del cliente. Comunicación digital con los taxis. Taxis con GPS.

Costo de Desarrollo

Page 47: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Software………………………………………………………………………… $100.000.000Hardware 1000 taxis X$ 1.000.000………………………………………………………………………. $ 1.000.000.000

_________________ $ 1.100.000.000

Costo de Sostenimiento:

Mantenimiento del Software………………………………………… $ 5.000.000Mantenimiento del Hardware……………………………………….. $ 20.000.000Comunicaciones GPRS$ 70.000 X 1.000……………………………………………………………………………. $ 70.000.000

Comunicaciones de la Central………………………………………. $ 5.000.000______________ $ 100.000.000

Beneficio:

500…………12 horas --------------entregas= 70.000 x 500…………………$35.000.000500…………24 horas---------------entregas= 140.000 x 500………………$70.000.000

--------------------- $105.000.000

X 30 días---------------------

Entrega antes………………………………………………………………………… $ 3.015.000.000

Con el nuevo sistema: sube la entrega……………$90.000/ 12 horas

500 x $90.000………………. $ 45.000.000500 x $180.000…………….. $ 90.000.000

--------------------$ 135.000.000 x 30 días………………………. $ 4.050.000.000

Nuevos ingresos = $ 1.035.000.000 mensuales

P= A*[(1+i)ᵑ - 1]/ i(1+i)ᵑi = 1.5% mes vencidon = 60 meses

Llevemos a valor presente los beneficios:

Page 48: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

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: Subdivisión del proyecto en actividades. Planificar los puntos de control (hitos). Cronograma o calendario. Planificación de los costos. Recursos y uso de recursos. Propuesta o cotización.

SUBDIVISION DEL PROYECTO EN ACTIVIDADES

WBS Work Breakdown StructureEstructura de Descomposición del trabajo

Primero tratemos de subdividir el producto. Subsistema A Subsistema B Subsistema C

La siguiente dimensión es subdividida.El tiempo Ciclo de vida del proyecto

Levantar Requerimientos Analizar Requerimientos Diseñar la solución Construir la solución Pruebas de Unidad Pruebas de Integración Implantación

Para generar las WBS del proyecto, cruzamos los subsistemas con las etapas del ciclo de vida.

SUBSISTEMA CICLO DE VIDA

Page 49: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

LEVANTAR REQ

ANALIZAR REQ

DISEÑAR CONSTRUIR PRUEBA DE UNIDAD

PRUEBA DE INTEGRACION

IMPLANTACIÓN O ENTREGAA

A L ABC AA ARQ ABC

DA CA PA IABC EABC

B AB DB CB PB

C AC DC CC PC

16/11/2012

DIAGRAMA DE GANTTPropuesto por Henry L.

Gantt en 1918, es comúnmente para mostrar el cronograma de un proyecto. Consta de 2 partes:

Descripción de las Actividades Calendario

Se hace usando los tiempos más prontos. Se acostumbra resaltar la ruta critica con color naranja.La ejecución de las tareas se muestra como una barra negra.El dia de hoy se resalta con una línea vertical.

CALENDARIO EN SEMANASACT

.DURAC

. 1 2 3 4 5 6 7 8 910

11

12

13

14

15

16

17

18

19

20

21

22

23

A 3 B 5 C 3 D 4 E 8 F 2 G 4 H 2 I 5 J 3

Hoy

En este diagrama podemos observar que: El día de hoy es al final de la semana 6.

Page 50: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

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 fácilmente hacer un monitoreo del proyecto.

EL PRESUPUESTO DEL PROYECTOPara 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 RECURSO SALARIO COSTO/MES COSTO/SEMANAA Administrador 5.000.000 7.546.835 1.886.709R Jefe de Recursos Humanos 3.000.000 4.528.101 1.132.025Q ArQuitecto 2.500.000 3.773.418 943.355I Ingeniero Civil 2.800.000 4.226.228 1.056.557O Obrero 700.000 1.124.357 281.089V Vehículo Camión 5.000.000 5.000.000 1.250.000C Conductor 900.000 1.426.230 356.558E Entrenador 1.500.000 2.264.050 566.013

Factores de Costo SalarialSalario 1Prima *1/12

Vacaciones *1/24Sena 0.04ICBF 0.03

Compensación Familiar 0.02Salud 0.085

Pensión 0.12ARP 0.0052

Cesantías *1/12Int. Cesantías 0.01/12

1.509.366

Subsidio Transp.67.800

Salario > 2 SMM

EL PROYECTO CON RECURSOS Y PRESUPUESTO

ACT.

DURAC. RECURSOS

COSTO/SEMANA PRESUPUESTO

Page 51: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

A 3 A 1.886.709 5.660.127B 5 A 1.886.709 9.433.545C 3 A,R 3.018.734 9.056.202D 4 A,Q 2.830.063 11.320.252E 8 I,5*O 2.462.002 19.696.016F 2 A,R 3.018.734 6.037.468G 4 R 1.132.025 4.528.100H 2 A,3*O,2*V,2*C 5.792.154 11.584.308I 5 A 1.886.709 9.433.545J 3 E 566.012 1.698.036

TOTAL 88.447.599

LA COTIZACIONLos ingenieros a menudo tienen que presentar la propuesta para un nuevo proyecto. La propuesta se suele dividir en dos partes:

La propuesta técnica

Define el proyecto, el trabajo que debe realizar, los objetivos a lograr, etc. Básicamente la propuesta técnica dice que se va a hace. Contiene los siguientes ítems:

Contexto Antecedentes Justificación Objetivos Delimitación

Page 52: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Viabilidad WBS o división en tareas CPM-PERT Cronograma Presupuesto

La propuesta Económica

A. COSTOS DIRECTOSTienen relación directa con la realización del trabajo. Ej.:Los que están en el presupuestoA.1 Mano de obra directaA.2 MaterialesA.3 Maquinaria y equipoA.4 Viáticos y gastos de viaje

B. COSTOS INDIRECTOSAquellos que proporcionan la infraestructura para el proyecto:B.1 Arrendamiento de oficinaB.2 Servicios públicosB.3 Celaduría, Admin. Edificio.B.4 SecretariaB.5 Contador y auxiliarB.6 GerenciaB.7 Seguros

C. TOTAL COSTOS (A+B)

D. AIUAdministración, Imprevistos, Utilidades.

E. TOTAL ANTES DE IMPUESTOS ((C+D))

F. IMPUESTOSF.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. Debería 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 Publicación en la Gaceta Departamental (1-7%)

F.4 Impuestos MunicipalesF.4.1 Estampilla pro Deportes de Pereira (1%)F.4.2 ICA Impuesto de Industria y ComercioEs un impuesto del producto no del cliente (1%)

Page 53: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

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:

Public class movie

{

Page 54: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

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;

}Public Movie getMovie ()

{Return _movie;

Page 55: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

}}

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())

{

Page 56: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Page 57: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

06/09/11

Una distinción crítica entre un proceso administrativo y un proceso definido es eñplpl alcance de la aplicación de las descripciones de procesos, estándares y procedimientos.

Para un proceso administrativo, las descripciones de procesos, estándares y procedimientos son aplicables a un proyecto particular, grupo o función organizacional. Como resultado, los procesos administrados de dos proyectos en una organización pueden ser diferentes.

Otra distinción crítica es que un proceso definido es descrito con más detalle y es realizado más rigurosamente que un proceso administrado. La distinción significa que la información de mejora es más fácil de comprender, analizar y usar finalmente, la admón. Del proceso definido se basa en un entendimiento adicional proporcionado por una comprensión de las interrelaciones de las actividades de los procesos y mediciones detalladas de los procesos, productos de trabajo y servicios. (Desarrollo en orden cronológico)

PRACTICAS Y METAS GENÉRICAS.Esta sección describe todas las metas y prácticas genéricas, así como sus subprácticas asociadas, notas, ejemplos y referencias.

GG1: cumplir las metas específicas.Las metas específicas 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).

Page 58: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

GP 1.1 Realizar las practicas específicas.Realizar las prácticasespecíficas de las PA para desarrollar productos de trabajo y proporcionas servicios para cumplir las metas específicas de PA el propósito de esta práctica genérica es producir los productos de trabajo y entregar los servicios que son esperados realizando los procesos. Estas prácticas pueden ser hechas informalmente sin seguir una descripción de proceso documentada o plan. El rigor con el que se realizan estas prácticas 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 política organizacional.Establecer y mantener una política organizacional para planear y realizar los procesos.El propósito de esta práctica genérica es definir las expectativas organizacionales para los procesos y hacer estas expectativas visibles a aquellos miembros de la organización que son afectados por ellas.En general la admón. senior es responsable por establecer y comunicar los principios guía, direcciones y expectativas de la organización.No todas las directrices de la admón. senior tendrá el rotulo de “políticas”. La existencia de una apropiada dirección organizacional es la expectativa de esta práctica genérica, sin importar como se llame o como se imparta.

Elaboración CAR. Esta política establece las expectativas organizaciones para identificar y manejar sistemáticamente el análisis casual de los resultados seleccionados.

GP 2.2 Planear los Procesos.Establecer y mantener el plan para realizar los procesos.El propósito de esta práctica genérica es determinar que necesita realizar el proceso para cumplir los objetivos establecidos, para preparar una descripción del proceso y para conseguir acuerdos sobre el plan de los actores relevantes.Las implicaciones prácticas para aplicar una práctica genérica varían para cada área de proceso.

Por ejemplo: la planeación descrita por esta práctica genérica, 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 planeación del proyecto.

Sin embargo, esta práctica genérica, cuando se aplica al área de planeación de proyectos, coloca un expectativa de que el proceso de planear proyectos también debe ser planeado.

Page 59: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Entonces esta práctica genérica puede reforzar el conjunto de expectativas en cualquier parte del CMMI o crear nuevas expectativas que deben ser manejadas. Refiérase al PA planeación del proyecto para más información acerca de establecer y mantener planes que definen las actividades del proyecto.Establecer un plan incluye documentar el plan y una descripción 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 típicamente incluye lo siguiente: Descripción del proceso. Estándares y requerimientos para los productos de trabajo y servicios del proceso. Objetivos específicos para la ejecución 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. Asignación 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 medición para proporcionar un entendimiento de la ejecución del

proceso, sus productos de trabajo y sus servicios. Involucramiento de los actores relevantes. Actividades para monitorear y controlar el proceso. Evaluación objetiva de las actividades del proceso. Actividades de revisión por parte de la admón., para el proceso y los productos de

trabajo.

Subprácticas:

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 múltiples documentos. En el caso del plan siendo distribuido en múltiples documentos, asegúrese de que se conserva una visión coherente de quien hace que, los documentos pueden estar en copia duro o en copia blanda.

2. Definir y documentar la descripción del proceso. La descripción del proceso incluye los estándares 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. Esta revisión del plan incluye revisar que el proceso planeado satisfaga las

políticas aplicables, planes, requerimientos y estándares para proporcionar aseguramiento para los actores relevantes.

4. Revisar el plan cuando sea necesario.

GP 2.3 proporcionar Recursos.

Page 60: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Proporcionar los recursos adecuados para realiza el proceso, desarrollar los productos de trabajo y proporcionar los servicios del proceso.

18/10/2011

Estimación por línea de código.Primer intento de medir un programa: sus líneas de código

- Eliminar los cometarios y líneas en blanco.Toda estimación se debe basar en datos históricos.Los datos históricos pertinentes son aquellos de proyectos similares al proyecto que estamos estimando.

Tabla de proyectos anteriores:Proyecto KLDE

AEsfuerzo (p-m)

BCosto (dólar)

CDocumentación (hoja)

DErrores

EDefectos

F

Al final de la tabla se realizan las sumas A, B, C, D, E, F.

Luego de obtener las sumas, se calculan las métricas para estimación:

Esfuerzo= BA

P−mKLDC

Indica la cantidad de personas – mes necesarias para construir mil líneas de código.

Costo=CAdolaresKLDC

Indica cuantos dólares cuestan hacer mil líneas de código.

Documentacion=DA

hojasKLDC

Indica cuantas hojas de documentación se escriben para construir mil líneas de código.

Errores= EAerroresKLDC

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

Defecto s= FA

defectosKLDC

Indica la cantidad de defectos que el cliente encuentra después de la entrega, durante el primer año, por cada KLDC.

Para estimar un nuevo proyecto solo se necesita decir el tamaño en KLDC del nuevo software.

Las métricas se multiplican por el tamaño en KLDC para a obtener la estimación.

Page 61: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Desventajas:1. ¿Cómo saber el tamaño en KLDC de un nuevo software si no se ha construido?2. Las KLDC dependen en gran medida del lenguaje de programación. En los datos

históricos no mezclar lenguajes.3. El estilo personal, unos programadores escriben mas KLDC que otros, ojala los datos

históricos pertenecieran al desarrollador del nuevo proyecto.

Estimación por puntos de función.El investigador Albrechten 1980 propuso un método que no tenía 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, diálogos.Interfaces externas: se refieren a la comunicación del nuevo software con otros programas.

Por lo tanto, se limita su aplicación a software cuyo procesamiento interno sea sencillo. Por ejemplo, sw administración.

A B C D E F GFunción Simple Medio Complejo Subtotal

Valor Peso Valor Peso Valor PesoEntradas x3 x4 x6Salidas x4 x5 x7Peticiones x3 x4 x6Archivos x7 x10 x15Interfaces x5 x7 x10Suma

Para calcular la columna H

H B∗C+D∗E+F∗G

De esta tabla obtenemos la cuenta total, un número que indica que tanta funcionalidad tiene el software.

Este número será afectado por 14 factores de complejidad que consideran mechas situaciones del proyecto.

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 Descripción Valor

Page 62: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

1 ¿El sistema requiere backup y recuperación confiable?2 ¿Se requieren comunicaciones de datos?3 ¿Hay funciones de procesamiento distribuido?4 ¿Es crítico el desempeño?5 ¿El sistema correrá en un ambiente operacional existente y fuertemente

utilizado?6 ¿El sistema requiere entrada de datos en línea?7 ¿La entrada de datos en línea requiere que la entrada de transacciones se

construya sobre múltiples pantallas u operaciones? Es multitarea?8 ¿Los archivos maestros se actualizan en línea?9 ¿Son las entradas, las salidas, los archivos o las peticiones complejas?

10 ¿Es el procesamiento interno complejo?11 ¿Código diseñado para ser reutilizado?12 ¿Están la conversión y la instalación incluidas en el diseño?13 ¿Múltiples instalaciones en diferentes organizaciones?14 ¿Facilidad de cambio y facilidad de uso?

PARCIAL HASTA ACA.

21/10/2011

Puntos de función = cuanta total * [0.6 + 0.01 * sumatoria desde i=1 hasta 14 de Fi]

Para que los puntos de función tengan algún significado, se necesita una tabla de proyectos históricos valorados en sus puntos de función.

Proyecto PF Esfuerzop-m

Costodólares

DocumentaciónHojas

Errores Defectos

Suma A B C D E F

Con las sumas calculamos las métricas a parámetros de estimación:

Esfuerzo / PF = B / A

Como los PF >> p-m esta métrica da muy pequeña, con decimales.Suele utilizarse el inverso.

PF / Esfuerzo = A/B

Indica la cantidad de puntos de función que hace una persona durante un mes. Es la productividad.

De la experiencia:

Page 63: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Ingeniero nuevo: 20 PF/p-mPromedio: 30 PF/p-mExcelente: 40 PF/p-m

Costo / PF = C / A dólares / PFIndica cuantos dólares cuestan construir un punto de función. La idea es utilizar una moneda estable. El peso ha sido muy variable con los años.

De la experiencia:

Costo / PF = 50 dólares/PF

Este valor depende de los costos fijos de la empresa

Doc./PF = D / A pag/PF

Indica cuantas páginas de documentación 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 después de la entrega (los encontró el cliente) durante el primer año (<<1)

Para poder hacer una estimación por puntos de funciones (PF), primero hay que hacer un prediseñoidentificando los elementos de la futura aplicación. Entradas, salidas tablas, interfaces, menús. Luego de esto se puede aplicar el cálculo de os PF.Luego se tener los PF, se aplican las métricas y se hace la estimación.

METODO DE ESTIMACION POR PUNTOS DE CASO DE USO.Fue el resultado de modernizar el método de los puntos de función, adaptándolo a la tecnología orientada a objetos. En lugar de usar entradas, salidas, peticiones, archivos e interfaces, este método usa caos de uso, acores, transacciones, clases.

Pero los puntos de caso de uso resultantes son equivalentes a los puntos de función el método 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.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)

Page 64: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

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 B C D ETIPO DE ACTOR

DESCRIPCION FACTOR CANTIDAD DE ACTORES

SUBTOTAL

SimpleOtro sistema que interactúa con el actual mediante un API o interfaz de programación

1 C*D

Medio

Otro sistema interactuando y a través de un protocolo (TCP/IP) o una persona interactuando a través de un interfaz en modo texto.

2 C*D

Complejo Una persona que interactúa con el sistema mediante una interacción grafica GUI

3 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 UUCWTiene 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) Método de las transacciones.Transacción: conjunto atómico de operaciones. Se realizan todas o no se realiza ninguna.

A B C D ETIPO DE CASO

DE USODESCRIPCION FACTOR CANTIDAD SUBTOTAL

Simple Transacciones <= 3 5 C*DMedio 4 <= transacciones <= 7 10 C*DComplejo Transacciones > 7 C*DSUMA Sumatoria

Page 65: Cuaderno IngeSoft II V5.0

1.1 UAW

1.2 UUCW

1 UUCP = UAW+UUCW

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

E = UUCW

b) Método de las clases.Se contabiliza las clases que participan en el caso de uso. Se obtienen del diagrama de secuencias.

A B C D ETIPO DE CASO

DE USODESCRIPCION FACTOR CANTIDAD SUBTOTAL

Simple Clases < 5 5 C*DMedio 5 <= clases <= 10 10 C*DComplejo Clases > 10 C*DSUMA ∑E = UUCW

Formula:UUCW = sum (cantidad de un tipo de caso de uso * factor)

24/10/11

Actores

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 técnica TCF y un factor ambiental EF, aplicándose la fórmula:

UCP: UUCP * TCF * EF

Paso 2.1: evaluar los factores de complejidad técnica TCF. Se tienen en cuenta 13 factores de complejidad técnica.

A B C D E

Factor DescripciónPeso

Valor 0 - 5 Subtotal

T1 Sistema Distribuido 2 = C * D

T2Objetivos de Desempeño o tiempo de respuesta 1

T3 Eficiencia del usuario final 1 T4 Procesamiento interno complejo 1 T5 El código debe ser reutilizable 1

Page 66: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

T6 facilidad de instalación 0, 5 T7 Facilidad de uso 0, 5 T8 Portabilidad 2 T9 Facilidad de cambio 1

T10 Concurrencia 1 T11 incluye objetivos especiales de seguridad 1 T12 provee acceso directo a terceras partes 1

T13Se requiere facilidades especiales de entrenamiento al usuario. 1

∑ E=T factor

T CF=0,6+0,01∗Factor

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

A B C D E

Factor DescripciónPeso

Valor 0 - 5 Subtotal

E1 Familiaridad con el modelo de proyecto usado 1, 5 C = C + DE2 Experiencia en la aplicación 0, 5 E3 Experiencia en 0.0 1 E4 Capacidad de analista líder 0, 5 E5 Motivación 1 E6 Estabilidad de los requerimientos 2 E7 Personal Part - Time (tiempo parcial) -1 E8 Dificultad del lenguaje de programación -1

∑ E=T factor

EF=1,4−0,03∗Efactor

Entre mas favorable el ambiente menos puntos de función.

Paso 3: Calcular el esfuerzo en horas – hombre (programador) es factor más importante es CF, la cantidad de horas – hombre que toma construir o realizar un punto de caso de uso.Esta estimación es para la labor de programación.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.

A B CFactor Filtro CantidadE1 - E6 Subtotal < 3 E7 - E8 |Subtotal > 3|

Page 67: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

∑C=Valor

CF (Horas-Hombre/Ucp) Descripción20 Valor <= 228 3 <= valor <= 436 valor >= 5

Recomienda evaluar este factor a partir de los datos históricos de proyectos.

CF=Horas−Hombredel proyectoPuntos de casosdeuso

Una vez conocemos el CFcalculamos el esfuerzo de programación del proyectoE=UCP∗CF

E = Esfuerzo de programación en horas-hombre.

Se debe tener una distribución del esfuerzo del proyecto en todas las fases del ciclo de vida. Se muestra una tabla inicial.

Actividad % Esfuerzo (horas-hombre)Análisis 10 Diseño 20

Programación 40 EPruebas 15

Sobrecarga 15 Total 100

EsfuerzoTotal= E0,40

Luego calcular las demás actividades con su %.

Cuando se tenga datos históricos de proyectos propios, se debe revaluar esta tabla para encontrar la distribución real para nosotros.

Con el esfuerzo total podemos estimar plazo y costo:Costototal=esfuerzoTotal∗Valor hora−hombℜ

Costo de la mano de obra.

Luego se toma la decisión del número de personas de su equipo de trabajo.

Plazo (horas )=EsfuerzoTotalPersonas

21/11/2011

Page 68: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

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 ejecución 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 planeación 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 localización 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 iniciación de un evento proporciona alguna flexibilidad en la programación del evento, una comprensión común de lo que se espera, una mejor visión del estado del proyecto y un estado más 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 están cumpliendo los requerimientos de los actores. (Si el proyecto incluye un control de desarrollo, entonces se hace la revisión 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 difíciles de cambiar

2. Identificar las suposiciones del cronograma.Cuando los cronogramas se desarrollan la primera vez, es común hacer su pociones acerca de la duración de ciertas actividades. Estas suposiciones son hechas frecuentemente sobre ítems en los que no hay datos disponibles para una estimación. Identificar estas suposiciones proporciona comprensión sobre el nivel de confianza (o incertidumbres) del cronograma total.

Page 69: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

3. Identificar Restricciones.Factores que limitan la flexibilidad de las opciones de administración, 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 duración 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 duración. La secuencia involucra la identificación 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 método de la ruta crítica (CPM). Técnica de Revisión y Evaluación de Programas (PERT). Cronogramas limitados por recursos. Característicasmercadeables. valor para el usuario final.

5. Establecer y mantener el presupuesto y el cronograma.Típicamente incluye los siguientes:

definir la disponibilidad comprometida o esperada de recurso e instalaciones. Determinar las fases de tiempo de las actividades. Determinar una división 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 duración apropiada. Definir los puntos de control con la adecuada separación en el tiempo. Definir una reserva de administracióncon base en el nivel de confianza para

cumplir el cronograma y el presupuesto. Usar los datos históricos 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 decisión significativa del plan del proyecto. Una base para medir tales problemas es necesaria para determinar cuándo se debe tomar una acción correctiva.

Las acciones correctivas pueden llevar a replantear, lo que puede incluir revisar el plan original, establecer nuevos acuerdos, o incluir actividades de mitigación en el plan.

Page 70: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

El plan del proyecto define cuando (bajo qué circunstancias, con quéfrecuencia) los criterios serán aplicados y por quien.

22/11/2011CPM (CRITICAL PATH METHOD)Desarrollado en 1957 por

J.E Kelly de remington Rand

M.R Walker de DuPont

Método para programar un proyecto que se basa en la topología de red.

1. Lista de las actividades

COD ACTIVIDAD PREDECESORES DURAC. (SEMANAS)A Elegir local de oficinas 3B Crear plan financiero y de

organización5

C Determinar requerimientos de personal

B 3

D Diseñar local A,C 4E Construir el interior D 8F Elegir personal a mudar C 2G Contratar nuevos empleados F 4H Mudar registros, personal clave,

etcF 2

I Hacer arreglos financieros con instituciones de la nueva ciudad

B 5

J Entrenar personal nuevo H,E,G 3

2. Establecer las relaciones de predecesor – sucesor entre actividades3. Estimar la duración de cada actividad.4. Construir el grafo o diagrama de red

a. Nodos: instantes en el tiempob. Aristas: actividades

Es un grafo orientado (flechas)Se hace con los predecesores

Ilustración 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 terminaciónd = duración

PT = PI + d

Page 71: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

6. Calcular los tiempos más tardíos que las actividades pueden empezar y terminar.TI = Tardío InicioTT = TardíoTerminaciónd = duración

TI = TT – d7. Calcular la holgura: el tiempo que se puede retrasar la tarea

H = TT – PtH = TI – PI

8. Se determinar la ruta crítica como aquellas actividades que no tienen holgura.Es el camino más largo para ir del inicio al final Ruta crítica: B-C-D-E-JDuración proyecto: 23 semanas

COD.

DURA. PI PT TI TT H

A 3 1 3 6 8 5B 5 1 5 1 5 0C 3 6 8 6 8 0D 4 9 12 9 12 0E 8 13 20 13 20 0F 2 9 10 15 16 6G 4 11 14 17 20 6H 2 11 12 19 20 8I 5 6 10 19 23 13J 3 21 23 21 23 0

Lo que se entrega como CRONOGRAMA es el pronto inicio y la pronta terminación de cada actividad.

El Diagrama de GanttDesarrollado por Henry L. Gantt en 1928, es una forma elegante y sencilla de mostrar un cronograma.

Consta de dos partes: actividades, calendario

ACTIVIDAD 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23A B C D E F G H

Page 72: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

I J

Se acostumbra a marcar con una línea gruesa horizontal la ejecución de las actividades para mostrar el avance del proyecto en una fecha dada.

25/11/11

El presupuesto del proyecto.Es el cálculo 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:

Cód. Recurso Salario Costo/mes Costo/diaA administrador 5,000,000 7,500,000 312,500R jefe de recursos humanos 3,000,000 4,500,000 187,500Q arquitecto 2,500,000 3,750,000 156,250I ingeniero civil 2,800,000 4,200,000 175,000O obrero 700,000 1,050,000 43,750V camión 5,000,000 5,000,000 208,333C conductor 900,000 1,350,000 56,250E entrenador 1,500,000 2,250,000 93,750

A hora revisamos los recursos que utiliza cada actividad.

Cód. Actividad Semana Dias Recursos Costo/día CostoA Elegir local 3 18 A 312,500 5,625,000B Plan financiero 5 30 A 312,500 93,750,000C Req. De personal 3 18 A+R 500,000 9,000,000D Diseñar local 4 24 A+Q 468,750 11,250,000E Construir el interior 8 48 I+50 393,750 18,900,000F Elegir personal a mudar 2 12 A+R 500,000 6,000,000G Contratar nuevos empleados 4 24 R 187,500 4,500,000

H Mudar todo 2 12A+30+2V+2

6 947,916 11,374,992I Arreglos financieros 5 30 A 312,500 9,375,000J Entrenar Personal nuevo 3 18 E 43,750 1,687,000

El costo es el presupuesto del proyecto.

Total costo = 87,087,488.

Page 73: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

FLUJO DE CAJAEs la necesidad de dinero del proyecto en cada periodo de tiempo. En este proyecto usaremos los meses. Se puede hacer fácil a partir del diagrama de gant

Cód. PI PT Costo/SemA 1 3 1,875,000B 1 5 1,875,000C 6 8 3,000,000D 9 12 2,812,500E 13 20 2,362,500F 4 10 3,000,000G 11 14 1,123,000H 11 12 5,687,496I 6 10 1,875,000J 21 23 562,500

1 2 3 4 5 6 7 8 9 10 11 1213

14

15

16

17

18

19

20

21

22

23

24

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

4E+26 4E 3J

1 2 3 4 5 6

1. 13,125,0002. 16,500,0003. 34,624,9924. 11,700,0005. 9,450,0006. 1,687,500

19/11/2012

Page 74: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

PERT COSTO

Así como existe incertidumbre en la duración de las actividades, también 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 crítica.

PREGUNTA

¿Cuál 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. Días laborados/semana, son 6 de acuerdo con la legislación laboral.3. Días laborados al mes, suponemos que el mes consta de 4 semanas, así que se labora

24 días 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 programación 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 estratégico: consiste en revisar de manera crítica las relaciones entre las tareas y restricciones del proyecto.

Enfoque táctico: trabajar más horas cada día para hacer el proyecto más rápido.

En desarrollo de software no es tan factible hacer varios turnos. La misma persona tiene que trabajar más horas al día lo que nos lleva al pago de horas extras.

28/11/11

Enfoque Estratégico

Ilustración 10 – grafo de actividades

Una mirada crítica al proyecto nos puede indicar que para realizar la actividad J “entrenar personal nuevo” debe terminar demasiadas actividades:

E construir el interior del local

Page 75: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

G Contratar nuevos empleadosH Mudar

De las anteriores actividades, la única que realmente tiene una relación 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 salón alquilado y así no hay que esperar a que terminen de construir el nuevo local.

Surge una nueva actividad

K alquilar salón para capacitación

Ilustración 11 – Nueva actividad

Como puede observarse, con el cambio propuesto, al sacar la actividad J de la ruta crítica, el proyecto ahora tiene una duración de 20 semanas y hemos ahorrado así semanas a cambio de hacer pequeñas inversiones en el alquiler de un salón para capacitar a los nuevos empleados.

ENFOQUE TACTICOConsiste en acelerar el proyecto trabajado más horas al día. El código laboral indica el máx.De horas que una persona puede laborar cada día. Un trabajador puede laborar máximo 12 horas cada ida, de las cuales 8 horas pueden corresponder a su jornada normal y 4 horas serán extras además según el código laboral, se pueden pagar las horas extras (hasta las 10 pm) a 1.25 el valor de la hora normal. Además en la mayoría 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 B C D E F G H

COD RECURSO SALARIO

COSTO/MES COSTO/DIA

COSTO/HORA

COSTO HORA EXTRA NOCTURNA

COSTO HORA EXTRA DIURNA

A Administrador 5.000.000 7.500.000 312.500 39.063 52734 48828

R Jefe recursos humanos 3.000.000 4.500.000 187.500 23.438 31641 29297

Q Arquitecto 2.500.000 3.750.000 156.250 19.531 26367 24414

I Ing. civil 2.800.000 4.200.000 175.000 21.875 29531 27344

O Obrero 700.000 1.050.000 43.750 5.469 7383 6836

V Comisión 5.000.000 7.500.000 312.500 39.063 52734 48828

C Conductor 900.000 1.350.000 56.250 7.031 9492 8789

E Entrenador 1.500.000 2.250.000 93.750 11.719 15820 14648

C*1,50 D/24 E/8 F*1,35 F*1,25

Comentarios

1. El camión no tiene factor salarial porque no es una persona y tampoco se le incrementa la hora extra.

Page 76: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

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.

Cuando es negocio pagar horas extras?

Solamente a las actividades de la ruta crítica que son las que pueden acostar la duración del proyecto.

Todo proyecto tiene unos Costos indirectos los cuales no tienen relación directa con el trabajo sino q son parte de una infraestructura recesaría. Ej.Secretaria, contador, arrendamiento, servicios públicos, celaduría, etc. Son costos administrativos. Si el valor por hora de los costos indirectos es mayor que el invertido en hora sextas, es negocio acelerar (inversión es la diferencia entre hora normal y extra)

En el presente ejemplo, supondremos que el valor de los costos indirectos es de 100000 $/hora. Según la legislación laboral, se dentrabajar 48 hora/semana.

COD SEM REC $/H

NORMAL$/H

EXTRA DIFTOTAL HORA

S

HORAS NORMALES

HORAS EXTRAS

COSTO/HORA

NORMAL

COSTO/HORA EXTRA COSTO TOTAL

A 3 A 39.062 39.062 0 144 144 0 5.624.928 0 5.624.928

B 5 A 39.062 39.062 0 240 240 0 9.374.880 0 9.374.880

C 3 A+R 46.876 46.876 0 144 144 0 6.750.144 0 6.750.144

D 4 A+Q 58.593 63.476 4883 192 192 0 11.249.856 0 11.249.856

E 8 I+50 32.81441.01

6 8202 384 384 0 12.600.576 0 12.600.576

F 2 A+R 46.876 46.876 0 96 96 0 4.500.096 0 4.500.096

G 4 R 23.438 23.438 0 192 192 0 4.500.096 0 4.500.096

H 2 A+30+2V+2C 77.345 86.914 9569 96 96 0 7.425.120 0 7.425.120

I 5 A 39.06239.06

2 0 240 240 0 9.374.880 0 9.374.880

J 3 E 11.71914.64

9 2930 144 144 0 1.687.536 0 1.687.536IND 23 100.000 1104 1104 0 110.400.000 110.400.000

E-D B*48 G-I D*H E*I 183.488.112J+K

29/11/2011

Page 77: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

COD SEM

RECURSOS

$/H NORMA

L$/H

EXTRA DIFTOTAL

H.H.

NORMALESH.EXTR

AS

$ NORMALE

S $ EXTRAS $ TOTAL

A 3 A 39,062 39,062 0 144 144 5,624,928 5,624,928

B 5 A 39,062 39,062 0 240 160 80 6,249,920 3,124,960 9,374,880

C 3 A+R 62,500 62,500 0 144 96 48 6,000,000 3,000,000 9,000,000

D 4A+Q 58,593 63,476 4883 192 192 11,249,856

11,249,856

E 8I+50 49,220 61,524

12304 384 384 18,900,480

18,900,480

F 2 A+R 62,500 62,500 0 96 96 6,000,000 6,000,000

G 4 R 23,438 23,438 0 192 192 4,500,096 4,500,096

H 2 A+30+2V+2C 121,615 129,232 7617 96 96 11,675,040

11,675,040

I 5 A 39,062 39,062 0 240 240 9,374,880 9,374,880

J 3 E 11,719 14,649 2930 144 144 1,687,536 1,687,536

IND 23 100,000 1104 97,600,000

97,600,000

184,987,6

96

Para acelerar:1. Acelerar tareas criticas2. Primero la menos costosa de acelerar3. Podemos colocar como horas extras hasta la tercera parte de la duración

IT EXPLICACION

1. B : 80 HEC: 48 HE

2. J: 48 HE3. D: 64

E: 128

COMENTARIOS:

1. La tarea que obtenga el máximo de horas extras debe marcarse como sutura (=)2. Hay que verificar que no se formen nuevas rutas críticas. Si se forman entonces debo

igualar los dos caminos y luego, en otra iteración tratar de acelerar ambos.3. Hay que verificar que la inversión 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 duración de 736 horas equivalen a: 15.33 semanas.

P.E.R.TPROGRAM EVALUATION AND REVIEW TECHNIQUE.

Ilustración 12, GRAFO 2

Page 78: Cuaderno IngeSoft II V5.0

a m b

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

HISTORIA:Desarrollado en 1950 por la NavySpartialProjects Office, para el proyecto del misil polaris.Este proyecto tenia gran incertidumbre porque nunca habían construido un misil.Contrataron cpnBozz, allen y Hamilton una metodología para proyectos con incertidumbre.Los consultores estudiaron miles de proyectos para obtener un modelo estadístico de la duración de una actividad. Llegaron a la conclusión de que era más probable que una actividad se retrasase a que se adelantase y que la duración real de una actividad responde a una distribución beta

PARA TRABAJAR CON LA DISTRIBUCION BETA, CADA ACTIVIDAD NECESITA TRES DURACIONES:A = duración optimistaM = duración más probableB = duración pesimista

02/12/2011

Una vez considerada la tendencia de cada actividad individual a retrasarse, nos preguntamos, ¿Qué paso con la duración total del proyecto?Esta duración está dada por las actividades de la ruta crítica.

Cuál de las actividades de la ruta crítica se va a alejar del valor medio? En este caso no hay una tendencia puede ser cualquiera por lo tanto podemos considerar que la duración del proyecto es una variable aleatoria que sigue la distribución normal de probabilidades.

Generalmente la duración de una actividad es independiente de la duración de las otras actividades. Si no fuera si, habría que considerar la probabilidad condicional.Pero una de las suposiciones del método PERT es la independencia de la duración de la actividad.

Así, no hay probabilidades condicionales y podemos calcular la varianza de la ruta crítica como la suma de las varianzas de las actividades individuales.Sacándole raíz cuadrada a la varianza, obtenemos la desviación estándar de la ruta crítica.Sumando las duraciones de las actividades que pertenecen a la ruta crítica, obtenemos la duración media del proyecto.

Ilustración 13: DISTRIBUCION NORMAL

Ilustración 14: DISTRIBUCIÓN BETA

Page 79: Cuaderno IngeSoft II V5.0

50% AB

media

50% AB

X

B

X

B

X

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Teniendo la media y la desviación estándar de la duración del proyecto podemos usar una tabla de probabilidades de la distribución normal y obtener la probabilidad de cumplir para cualquier desviación a partir de la media.

Los libros de estadística suelen tener varios tipos de tablas, según el área considerada.

A continuación se muestra un proyecto con el método PERT.

Ilustración 15 – Grafo actividad PERT.

Act a m b

D. ESPERADA

D. ESTÁNDAR VARIANZA

A 1 3 5 3 2/3 4/9

B 34.5 9 5 1 1

C 2 3 4 3 1/3 1/9D 2 4 6 4 2/3 4/9E 4 7 16 8 2 4

F 11.5 5 2 2/3 4/9

G2.5

3.5

7.5 4 5/6 2/3

H 1 2 3 2 1/3 1/9I 4 5 6 5 1/3 1/9

J1.5 3

4.5 3 1/2 ¼

K 1 3 5 3 2/3 4/9(a+4m+b)/6 (b-a)/6 [(b-a)/6]^2

Page 80: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

DuracionMediadel Proyecto=5+3+4+8=20

Se obtiene de las duraciones esperadas de la ruta crítica.

Varianzadel Proyecto=1+ 19+ 49+4=50

9

Se obtiene sumando la varianza de la ruta crítica.

Desviaci on Estandar del Proyecto=√ 509 =2.357 Semanas

LA PREGUNTA DEL PROBLEMAEl método PERT lo que hace es dar la probabilidad de cumplir en cierta fecha. Para este problema preguntamos cual es la probabilidad de terminar antes de 22 semanas?

Desviacion=22−20=2Semanas

En las tablas de la distribución normal la desviación (X) está en unidades de desviaciones estándar.

z ò x=2 semanas2.357 semanas

¿0.8485desv . estand .

X = 0.84 0.85

Prb= 0.7995 0.8023

Como necesitamos la probabilidad para x = 0.8485 toca interpolar P = 0.80188Respuesta, la probabilidad de terminar antes de 22 semanas es de 80.188%

Nuevo problema:Entonces dígame cual es la duración para una probabilidad de cumplimiento del 95%

1.64 1.650.9495 0.9505

P (1.645 )=95%

Ah que equivalen 1.645 dev estándar en semanas?

Desviacion=1.645∗2.357=3.877 semanas

Plazo, Duracion=20 sem+3.877 sem=23.877 sem

R/ para una probabilidad de cumplimiento del 95% la duración del proyecto debe ser de 23.877 semanas.

Page 81: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

05/12/2011

En la clase anterior vimos cómo usar e método PERT para manejar la incertidumbre en la duración de las actividades y la duración del proyecto. Hoy veremos las incertidumbres relacionadas con el costo del proyecto.

P.E.R.T COSTOLOS COSTOS del proyecto heredan la incertidumbre de la duración del proyecto.

La diferencia en que todas las actividades participan en los costos. El costo de la mano de obra depende de la duración de las actividades, pues tenemos el costo por hora. Si las horas cambian, cambia el costo. Veamos el ejemplo.

A B C D E F G H I J SEMANAS COSTO / COSTO ACTIVIDAD

ACT a m b HORA A M b ESPERADO VARIANZAA 1 3 5 39,062 1,874,976 5,624,928 9,374,880 5,624,928 1,562,460,000,256B 3 4.5 9 39,062 5,624,928 8,437,392 16,874,784 9,374,880 3,515,535,000,576C 2 3 4 62,500 6,000,000 9,000,000 12,000,000 9,000,000 1,000,000,000,000D 2 4 6 52,593 5,048,928 10,097,856 15,146,784 10,097,856 2,832,408,216,576E 4 7 16 49,220 9,450,240 16,537,920 37,800,960 18,900,480 22,326,759,014,400F 1 1.5 5 62,500 3,000,000 4,500,000 15,000,000 6,000,000 4,000,000,000,000G 2.5 3.5 7.5 23,438 2,812,560 3,937,584 8,437,680 4,500,096 878,943,750,400H 1 2 3 121,615 5,837,520 11,675,040 17,512,560 11,675,040 3,786,293,305,600I 4 5 6 39,062 7,499,904 9,374,880 11,249,856 9,374,880 390,615,000,064J 1.5 3 4.5 11,719 843,768 1,687,536 2,531,304 1,687,536 79,104,937,536K 1 3 5 20,000 960,000 2,880,000 4,800,000 2,880,000 409,600,000,000

B*E*48 C*E*48 D*E*48 89,115,696 40,781,719,225,408(a+4m+b)/6 [(b-a)/6]^2

PREGUNTA:

¿Cuál es la probabilidad de que el proyecto cueste $100,000,000?

Media=89,115,697

Desviacion=100,000,00−89,115,697=10,884,304

Desviacion Estandar=√40,781,719,225,408=6,386,057

Z= DesviacionDesviacion Estandar

=10,884,3046,386,057

=1.7044

De la tabla de distribución normal tenemos:

1.70 1.71

0.9554 0.9564

Page 82: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

P (1.7044 )=0.95584

¿=0.0044∗(0.9564−0.9554 )

0.01=0.00044

P (1.7044 )=0.9554+0.00044

RESPUESTA:

La probabilidad de que el proyecto cueste $100,000,000 es de 95.584%

PREGUNTA 2:

Cual sería el costo del este proyecto para una probabilidad de cumplimiento del 98%?

De la tabla de la distribución normal tenemos:

Z 2.05 2.06

P 0.9798 0.9803

Debemos interpolar:

¿0.0002

= 0.010.0005

¿=0.0002+0.010.0005

=0.004

Z=2.05+0.004=2.054

Desviacion=Z∗Desviacion Estandar=2.054∗6,386,057=13,116,961

Costo del Proyecto=Media+Desviacion=89,115,696+13,116,961=102,232,657

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

LA COTIZACIÓNTodo el planeamiento del proyecto debería realizarse antes de comprometerse firmando un contrato.Luego de hacer la planificación hay que presentarle al cliente una oferta que se denomina COTIZACIÓN.La idea es mostrarle al cliente con total trasparencialos detalles del proyecto.Se acostumbra dividir la oferta comercial en dos partes.

1. PROPUESTA TÉCNICA:Esta propuesta debe indicar nuestra comprensión del proyecto:

Contexto

Page 83: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Antecedentes Justificación Viabilidad Objetivos Requerimientos tenidos en cuenta. Cronograma Restricciones tenidas en cuenta para el cronograma Presupuesto Suposiciones para el presupuesto

2. PROPUESTA ECONÓMICA: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,000a. 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,000iii. Equipos $ 3,000,000

b. Costos Indirectos $ 20,500,000Mantienen la infraestructura necesaria para el proyecto

i. Oficina (5 meses) $ 10,000,000ii. Admón. y Celaduría $ 2,500,000

iii. Secretaria $ 5,000,000iv. Contador $ 3,000,000

B. A.I.U (Administración, Imprevistos, Utilidades) $ 38,550,00030% de a+b $ 38,550,000

C. TOTAL ANTES DE IMPUESTOS (a+d) $ 147,050,000D. IMPUESTOS $ 27,786,670

a. I.V.A (16%) $ 23,528,000b. Timbre (1.5%) $ 2,558,670c. Estampilla Pro Desarrollo (1%) $ 1,700,000

E. TOTAL DEL PROYECTO $ 174,836,670

12/12/2011

Fenómeno de la Contratación.Debemos solicitar en el contrato algunas cláusulas que nos protejan.

1. Incumplimiento por parte del cliente en los pagos:No es suficiente colocar el cobro de interés. En este incumplimiento el proyecto se debería parar, y reanudarse cuando el cliente decida continuar con los pagos.

2. Fecha para congelar requerimientosSe 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

Page 84: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

después de esta fecha tendrán un impacto en la duración (fecha de entrega) y costo del proyecto.

3. Arbitramiento en caso de conflictosSi 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 ingeniería de software (una autoridad académica).

4. Casos FortuitosEn caso de:

Asonadas Tomas guerrilleras o sucesos que alteren el orden publico Catástrofes naturales: terremotos, inundaciones, etc.

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 Impuestos1. La retención en la fuente (10%) se considera un adelanto a la declaración de renta del

contratista. No es factible cobrarle esto al cliente.Se supone que al hacer la declaración 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 podría cobrar este dinero. La inmensa mayoría de las veces, las devoluciones son incobrables.

2. Antes de hacer la cotización, hay que averiguar exactamente las tasas de impuestos a pagar, como se calculan y cuál es su soporte legal. Cualquier equivocación la terminara pagando el contratista.

Sobre el AIUTeniendo 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 ningún esfuerzo, porque el contratista, que está corriendo riesgos, no puede ganar más que esta?

Teniendo en cuenta los riesgos seria justos para el contratista un AIU del 50%.

Pero casi ningún cliente acepta esta utilidad. Por esta razón generalmente al contratista termina preguntándole al cliente cuanto pagara de AIU y el resto suele distribuirse como un mayor valor en los sueldos del personal.

Por esta razón generalmente los sueldos que aparecen en el proyecto que se presenta al cliente no son los sueldos reales.

Page 85: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

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 Anticipos1. 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 crédito bancario y podemos usar el dinero del anticipo para Apalancar el crédito.El anticipo nos da la oportunidad del negociar unas buenas condiciones para el crédito.

4. Si en la vida del proyecto es necesario hacer un crédito la cotización debería incluir estos intereses para que los pague el cliente.

5. En lugar de aspirar a un gran anticipo el contratista debería 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 SOFTWARESe puede hablar como mínimo 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 garantía del producto.El código del comercio pide una garantía mínima 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 informándole de los precios, por ejemplo, el valor por hora del trabajo.

Es muy común que quieren hace el mantenimiento no participo en el desarrollo del programa.

En estos casos es muy importante la documentación 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 difíciles de atrapar y que se van acumulando.

Los errores acumulados generan más mantenimiento y el costo del mantenimiento se puede disparar.

13/12/2011

Page 86: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

REFACTORINGTomado del libro:

Refactoring: Improving the Design of Existing CodeAutor:

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 código pero que mejore su estructura interna. Es una forman disciplinada para limpiar el código que minimiza la probabilidad de introducir errores. En esencia, cuando usted realiza refactoring, está mejorando el diseño del código después de que ha sido escrito.

CAPITULO 1: Ejemplo de Refactoring

Suponga que el código que se va a mostrar forma parte de un sistema mucho más 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 películas que el ah alquilado.

Al programa se le dice que películas ha rentado el cliente y por cuanto tiempo.Entonces calcula los cobros que dependen del tiempo que rento la película y del tipo de película. Hay clases de películas: para niños (children), regulares y estrenos (new releases).

Además de los cobros el programa calcula los puntos de renta frecuente que varían dependiendo de si la película es un estreno o no.

Las clases relacionadas con el problema son:

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

statement()

Ahora veamos el código 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)

Page 87: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

{_title = title;_priceCode = priceCode;

}publicintgetPriceCode(){

Return _priceCode;}public void setPriceCode (int org){

_priceCode = arg;}public String getTitle(){

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;

Page 88: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

}Public void addRental (Rental arg){

_rentals.addElement(arg);}Public String getName (){

Return _name;}public String statement (){

Double totalAmount = 0;IntfrequenRentedPoints = 0;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 lineaswitch (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 frecuentefrequentRenterPoint ++;// Agregabonus por rentar un estreno dos díasIf ((each.getMovie().getPriceCode()==Movie.NEW_RELEASE)

&&each.getDaysRented() > 1)frequentRentedPoint ++;

//Muestra los datos para esta rentaResult += “\+”+ each.getMovie().getTitle()+“\+” + String.valueOf(thisAmount) +

“\+”totalAmount += thisAmount;

Page 89: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

} //while// agregalineas de pie de paginaResult += “Amount owed is ”+ String.valueOf(totalAmount) + “\n”;Result += “you earned ”+ String.valueOf(RequesterPoints) +“frequent renter point”;Return result;}

}

Ilustración 16 Interacciones del método Statemet()

Podemos observar que todo el trabajo del programa esta recargado en el método statement. Se supone que en un diseño orientado a objetos. Los comportamientos del sistema son el resultado de la colaboración entre las diferentes clases, lo cual no pasa en este programa, pues el comportamiento principal está en un solo método.

Si el código fuera a quedarse estático, a pesar de ser feo, funciona y se podría quedar así.

Pero en el momento de hacer un mantenimiento el ser humano que lo haga se enfrentará a graves problemas.

Los clientes les gustaría hacer un cambio. Que además de imprimir la factura esta pueda verse en la web. Es decir en formato HTML

Obsérvese la implicación del código para suplir esta necesidad. No parece haber partes reutilizables en el cálculo. Lo único que podemos hacer es sacar una copia, darle otro nombre de método (htmlStatement)y modificar este método para generar la factura en la web.

Y que pasara si se cambia las reglas para los cálculos? 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 clasificación de las películas, pero aun no terminan de decir cómova 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 habrán de hacerse a los dos programas y asegurarse de que estos dos sean consistentes. Existe la tentación 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 algún cambio sea algo sencillo en lugar de traumático.

16/12/2011

EL PRIMER PASO DEL REFACTORINGEl primer paso siempre es la construcción de un conjunto de pruebas que nos ayuden a verificar si el programa ha cambiado su comportamiento al realizar los cambios de refactoring.

Page 90: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

En el caso presente, hay que crear un conjunto inicial de datos: algunos clientes, algunas películas 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 comparación 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 líneas que han cambiado.

Si la prueba es fácil y eficiente de hacer, llamarla repetidamente no representa una carga para el desarrollo.

A medida que hagamos refactoring, confiamos en que la prueba nos dijo si introdujimos algún error. Si desea más información sobre pruebas, vaya capitulo 4.

Descomponer y Redistribuir el Método Statement ()El primer objetivo obvio del refactoring es el método Statement () el cual es muy largo. Este método es un caso de “baja cohesión” porque sus partes: el cálculo de cobro, el cálculo de los puntos de renta frecuente y la impresión de las facturas son requerimientos distintos pero están entre mezclados en el método statement ().

Una meta es distribuir las partes del método para hacerlo más pequeño. Al distribuir estas partes a clases más adecuadas, será más fácil construir el método htmlstatement ().

Aplicaremos un procedimientos de refactoring llamado ExtractMethod(Extraer Método).

Una parte factible para aplicar el procedimiento es en la instrucción switch.

Queremos extraer cada rama de la instrucción switch como un método 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 código y convertirlo en un método es mirar sus variables. Estas variables se convertirán en los parámetros y variables locales del método.

El segmento de código 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 parámetros. Las variables modificadas hay que mirarlas con más 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 iteración del while. Asi que solo tenemos que asignarle el resultado.

Código antes:

Page 91: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

…While (rentals.hasMoreElements ()){

Double thisAmount = 0;Rental each = (Rental) rentals.nextElement ();// Determina el monto para cada líneaswitch (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

Luego de aplicar el procedimiento para extraer métodos, el programa quedo asi:

public String statement (){

Doublé totalAmount = 0Int 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 frecuetefrequentRenterPoints ++;// agregarbonus por renta de dos dias:If ( (each.getMovie ().getPriceCode () == Movie.NEW_RELEASE)

&&each.getDaysRented()> 1)frequentRenterPoints ++;// muestra los resultados para esta rentaResult += “\+” + each.getMovie ().getTitle () + “\+” + StringvalueOf

(thisAmount) + “\n”;

Page 92: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

totalAmount += thisAmount;}// agregarlineas al preResult += “Amount owed is”+ String.valueOf (totalAmount) + “\n”;Return result;

}

private in amountFor (Rental each){

Int thisAmount = 0;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;

} // switchreturn 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 método 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 método sea mas legible.

Page 93: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

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;break;caseMovie.CHILDRENS:

result+= 1.5;if (aRental.getDaysRented() > 3)result+= (aRental.getDaysRented() - 3) * 1.5;

break;}returnresult;

}

Moviendo el cálculo del monto:Actualmente el método amountFor esta dentro de la clase Customer pero observe que no utiliza los atributos ni los métodos de esta clase. Esta es una indicación de que el método amountFor esta dentro de la clase incorrecta.

Debido a que utiliza el parámetro aRental que es de tipo Rental, parece mas largo que el método amountFor pertenezca a la clase Rental.

El procedimiento de refactoring que permite mover un método de una clase a otra se llama movemethod. Aplicando el procedimiento el método 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:

Page 94: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

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 invocación al método cambia.

class Customer{…

Private double amountFor (Rental aRental){

ReturnaRental.getcharge();}

}

Al hacer esto, no tenemos que cambiar el método statement. Asi, los cambios, si generan algún 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 método amountFor () por una referencia al método getcharge().

Solo se afecta una línea del programa statementLínea anterior

thisAmount = amountFor (each);Esta línea se cambia por:

thisAmount = each.getcharge();

Luego de hacer esto se elimina el método amountFor porque ya nadie lo llama.El siguiente diagrama de clases refleja el cambio:

movie Rental CustomerPrice Code: int daysRented: int

getcharge() Statement() 1 * * 1

Page 95: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

En este momento, la variable thisAmount en el método statement tiene el mismo valor que el retornado por el método Rental.getcharge().Para una mayor claridad del programa, podemos hacer desaparecer la variable thisAmount, cambiándola por invocaciones a getcharge (). El programa será mas simple, pues tiene una variable menos, pero el desempeño del programa será peor, pues llamamos varias veces a getcharge (). Si este método no es pesado esto es tolerable. Si el tiempo que tarda getcharge() es apreciable, entonces esto no se debe hacer.

El método statemente () queda de a siguiente manera:

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();

// suma puntos de renta frecuentefrequentRenterPoints ++;// agregar bonificación por rentar un estreno dos días

if ((each.getMovie().getPriceCode() == Movie.NEW_RELEASE)&&each.getDaysRented() > 1)frequentRenterPoints ++;

// muestra los datos para esta rentaresult += "\t" + each.getMovie().getTitle()+ "\t" +String.valueOf(thisAmount) + "\n";totalAmount += each.getcharge ();

}// Agrega líneas 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 mínimo el uso de variables temporales. Son un problema a la hora de extraer el código, hay que pasarlas como parámetro y retornarlas, además hacen más difícil entender el programa, especialmente en métodos muy largos.

Page 96: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

“cualquiera puede escribir código que la maquina entienda. Solo los buenos programadores escriben códigos que los humanos entiendan”

Lo mismo que hicimos con el cálculo del monto a pagar, lo podemos hacer con los puntos de renta frecuente.

Queremos usar el procedimiento extractMethod para el cálculo de los frequentRenterPoints.

Analizando las variables, vemos que: Each se usa pero no se modifica frequentRenterPoints se modifica y además va acumulando en cada iteración del

while.

Por lo tanto each es un parámetro mientras que frequentRenterPoints se pasa como parámetro y también 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()+ "\t" +String.valueOf(thisAmount) + "\n";totalAmount += thisAmount;// agregalineas de pie

result += "Amount owed is " + String.valueOf(totalAmount) +"\n";result += "You earned " +String.valueOf(frequentRenterPoints) +" frequent renter points";return result;

}}

Page 97: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

class Rental{

…IntgetFrequentRenterPoints(){

If (getMovie().getPriceCode == Movie.NEW_RELEASE) &&getDaysRented () >1)

Return 2;else

return 1;}

}

20/12/11El diagrama de clases mostrando los cambios:

movie Rental CustomerPrice Code: int daysRented: int

getcharge()

getFrequentRenter () Statement() 1 * * 1

Ilustración 17 – diagrama

Eliminar Variables TemporalesSon ú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 método.

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;

Page 98: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

result += "\t" + each.getMovie().getTitle()+ "\t" +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;

}

}

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 rentaresult += "\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;

Page 99: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

}}

Private getTotalFrequentRenterPoints (){

Int result = 0;Enumeration rentals = _rentals.elements();

While (rentals.hasMoreElements()){

Rental each = (Rental) rentals.nextElement ();result += each.getFrequentRenterPoints ();

}Return result;

}

El diagrama de clases ha cambiado:

movie Rental CustomerPrice Code:

int daysRented: int

getcharge()getFrequentRent

er ()

Statement()getTotaCharge ()

getTotalFrequentRenterPoint

1 * * 1

Ilustración 18 diagrama

El anterior cambio ha generado un programammas grande si sumamos las líneas de código de todos los métodos. Esto se debe a la sintaxis de java en la cual un ciclo de sumar toma alrededor de seis líneas.

Antes el While se ejecuta una sola vez y ahora se ejecuta tres veces. Hay preocupación por el desempeño del programa.

Al final del refactoring se optimiza el programa. Así que no nos preocupamos del desempeño todavía. Una buena noticia es que todos los métodos extraídos se pueden reutilizar se ha logrado aislar los cálculos dé la impresión de facturas y estamos en posición de crear la versión 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())

Page 100: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

{Rental each = (Rental) rentals.nextElement();//muestra los datos para esta rentaresult += each.getMovie().getTitle()+ ": " +String.valueOf(each.getCharge()) + "<BR>\n";

}//agregalineas de pieresult += "<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;}

El método htmlstatement resulto relativamente pequeño y sencillo debido a que reutiliza todos los cálculos que fueron extraídos de statement y colocados en métodos a parte.

Tiene la ventaja de que si se modifica las reglas para los cálculos, se hace en un solo lugar y esto tiene efecto en ambas facturas.

17/01/12 Se ha creado el método htmlstatement que reutiliza los cálculos que habíamos usado para construir statement. Estos cálculos 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 función de imprimir la factura.Actualmente los clientes están a punto de cambiar la forma de hacer los cálculos introduciendo nuevas clasificaciones de las películas. 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 Lógica Condicional Sobre el Tipo de Película (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;

Page 101: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

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 condición del “switch” depende de la clase local. Como el cambio que viene es de nuevos tipos de películas, veremos que esto facilita los cambios. Parece que los tipos de películas tienden a ser volátiles y por eso es mejor que el cálculo del cargo lo haga MOVIE.

El diagrama de clases ha cambiado:

Para invocar el nuevo método getchargede Movie, por ahora se hace desde Rental:Class Rental{ …

Double getcharge (){

Return.movie.getcharge (.daysRented);}

}

Con esto podemos compilar y probar el método getchargesin que el resto del programa se entere del cambio.

Page 102: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Inicialmentetenemos:

class Rental...intgetFrequentRenterPoints() {

if ((getMovie().getPriceCode() == Movie.NEW_RELEASE) &&getDaysRented() > 1)return 2;

elsereturn 1;

}

Pasando el metodogetFrequentRenterPointsa la clase Movie el código queda asi:

Class rental...intgetFrequentRenterPoints() {

return _movie.getFrequentRenterPoints(_daysRented);}

class movie...intgetFrequentRenterPoints(intdaysRented){

if ((getPriceCode() == Movie.NEW_RELEASE) &&daysRented> 1)return 2;

elsereturn 1;

}

Al fin… la herencia

Tenemos varios tipos de películas y para cada tipo se deben hacer los cálculos de cierta manera.

Este es un trabajo para las subclases.

Podemos tener tres subclases de Movie, cada una con su propia versión de getchargey de getFrequentRenterPoints.

Lo que hicimos con getchargetambién hay que hacerlo con getFrequentRenterPoints.

Page 103: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Esto permitirá eliminar la orden SWITCH. Tristemente, esto no trabaja. El problema esta en que las películas, con el tiempo, pueden cambiar de clasificación, pero los objetos no pueden hacerlo.Hay una solución aplicando un patrón de diseño 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 película ahora es un objeto de tipo Price. En cualquier momento podemos reclasificar la película, 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.

Page 104: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Para introducir el patrón State (estado) hay que hacer tres cambios:1. mover el comportamiento del código de tipo al patrón state con el refactoring

ReplaceTypeCodewithstate/strategy.2. Mover el método 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 código con los métodos get y set.

Como la mayoría del código 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...{ …

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 {

Page 105: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

intgetPriceCode() {returnMovie.CHILDRENS;}

}

classNewReleasePrice extends Price {

intgetPriceCode() {

returnMovie.NEW_RELEASE;}

}

classRegularPrice extends Price{

intgetPriceCode() {

returnMovie.REGULAR;}

}

18/01/12Vamos a hacer el cambio en el atributo de la clase Movie, lo mismo que los métodos 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 métodos get y set.Este cambio se ve así:

class Movie...{

publicintgetPriceCode() {

return _price.getPriceCode();

Page 106: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

}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");

}}private Price _price;

}

En este momento se compila y se prueba el programa.Ahora hay que mover el método 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;

Page 107: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

break;}return result;

}

Luego del cambio queda asi:

class Movie...doublegetCharge(intdaysRented) {

return _price.getCharge(daysRented);}class Price...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;}

En este momento se compila y prueba el cambio.El siguiente paso es que el método 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;

Page 108: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

if (daysRented> 2)result += (daysRented - 2) * 1.5;return result;

}

Si en este momento compilara y probrara, par un RegularPricese ejecutara, el método de su superclase Price.

classChildrensPricedoublegetCharge(intdaysRented){

double result = 1.5;if (daysRented> 3)result += (daysRented - 3) * 1.5;return result;

}

classNewReleasePrice...doublegetCharge(intdaysRented){

returndaysRented * 3;}

Ahora el método getchargede Price se puede volver abstracto.

class Price...abstract double getCharge(intdaysRented);

aqui terminamos el patron estado para getchargealgo similar se hace con getfrequentRenterPoint. Actualmente se encuentra en la clase Movie:

class Rental...intgetFrequentRenterPoints(intdaysRented){

if ((getPriceCode() == Movie.NEW_RELEASE) &&daysRented> 1)return 2;elsereturn 1;

}

Primero lo movemos a Price:

Class Movie...intgetFrequentRenterPoints(intdaysRented){

return _price.getFrequentRenterPoints(daysRented);}

Page 109: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Class Price...intgetFrequentRenterPoints(intdaysRented) {

if ((getPriceCode() == Movie.NEW_RELEASE) &&daysRented> 1)return 2;

elsereturn 1;

}

Class NewReleasePriceintgetFrequentRenterPoints(intdaysRented) {

return (daysRented> 1) ? 2: 1;}

Si el tipo de película es NEW_RELEASE, se ejecuta el método de la subclase NewReleasePrice. De lo contrario se ejecuta el método de la superclase Price.

El resultado es que ahora es mucho mas fácil introducir nuevos tipos de películas o cambiar la forma de hacer los cálculos.

El beneficio será mayor cuanto mas grande sea el programa. La versión final de los diagramas es la siguiente:

Diagrama de secuencia:

Diagrama de clases:

Page 110: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

23/01/12

Capitulo 3: Malos Olores en el Código

LOS MALOS OLORES DEL SOFTWARESe trata de identificar aquellos segmentos de código que necesitan un refactoring.

Código DuplicadoSi el programa presenta código repetido, puede estar seguro de que le programa estaría mejor si se busca alguna forma de unificarlo.

Si el código repetido esta en métodos distintos que pertenecen a la misma clase, se puede usar el refactoring denominado extractmethod e invocar el código, el cual se coloca como un nuevo método.

Si el código repetido esta en 2 subclases hermanas se usa el extractmethodpero el nuevo método se coloca en la superclase de ambas subclases.

Si los códigos son similares pero no iguales, hay que separar la parte que es igual antes de hacer el extractmethodsi dos métodos hacen lo mismo pero con distinto algoritmo, hay que elegir el algoritmo mas claro y eliminar el otro. Si se tiene código repetido en dos clases no relacionados, considere usar el refactoring Extract class y usar en objeto de la nueva clase para acceder al nuevo método.

Page 111: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Método muy largoLos programas mas longeros son aquellos que tienen métodos cortos.

Los programadores recién llegador a los objetos sienten que este estilo es una infinita delegación, un método delega en otro, que delega en otro, etc. Pero todas las ventajas de la indireccion (explicación, compartir, elección) se soportan por medio de pequeños métodos.

En POO no se trata de que un solo objeto haga todo el trabajo sino qu el trabajo se obtiene por la colaboración entre muchos objetos especializados.

Desde los primeros días de la computación la gente establecio que mientras mas largo es un procedimiento, mas difícil 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 método de descomponer un procedimiento. Una heurística de trabajo es que si usted siente la necesidad de poner un comentario, debe escribir un nuevo método.

El código 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 semántica 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 código para hacer nuevos métodos.

Es posible que al extraer un trozo de código como un nuevo método nos demos cuenta que maneja muchas variables y datos temporales los cuales se convertirán en parámetros y resulte una cantidad excesiva de parámetros. Se puede usar el refactoring ReplaceTempwithQuerypara eliminar las variables temporales.

Las largas listas de parámetros pueden ser reducidas con el refactoring Introduce Objecty Preserve wholeObject. Si usted use todo eso y aun tiene muchas temporales y parámetros, es hora de usar la artillería pesad, ReplaceMethodwithMethodObject.

¿Cómo identificar los pedazos de código a extraer? Un buen método es mirar los comentarios. A menudo ellos marcan este tipo de distancia semántica. Un bloque de código con un

Page 112: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

comentario que dice lo que esta haciendo, puede ser reemplazado por un método cuyo nombre este basado en el comentario.

Aun una sola línea puede ser extraída si necesita mucha explicación.

Los comandos condicionales y las iteraciones también dan una dea de que extraer. Use el refactoring DecomposeConditionalpara manejar las expresiones condicionales.

Con las iteraciones puede extraer la iteración o el cuerpo de la misma forma para formar un nuevo método.

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 código 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 código se debe revisar primero buscando duplicando, caótico o que no se use. La solución más simple es eliminar la redundancia en la clase misma. Si usted tiene métodos de quinientas líneas con montones de código en común, podría ser posible cambiarlas en cinco métodos de diez líneas con otros diez métodos de dos líneas extraídos del original.

La solución usual para una clase con mucho código 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 podría dar ideas sobre como partir la clase si su clase es una GUI, podría 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, podría hacer esto al tiempo que remplaza las clases por componentes SWING.

24/01/12

FALTA ESTA CLASE

25/01/12

OBSESION PRIMITIVALos lenguajes de programación 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 construcción para los registros.

Page 113: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ 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 relación ¿. Una ventaja de los objetos es que se pueden crear clases fácilmente que luego son indistinguibles de las tipos primitivos, las clases actúan como nuevos tipos de datos.

Java tiene primitivas para los números, 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 pequeñas clases para pequeñas tareas, tal como el dinero, que combinan números, rangos superior e inferior, y cadenas especiales tales como los números telefónicos o las direcciones. Usted puede salir de estas obsesiones usando el refactoring Replace Data ValueWithObjectsobre valores individuales de datos. Si el valor el algún código use el refactoring Replace Data ValueWith Class, si el valor no afecta al comportamiento.

Si usted tiene condicionales que dependen de algún tipo de código use ReplaceTypeCodewithSubclasseso ReplaceTypeCodewithState/Strategy.

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

SENTENCIAS SWITCHUno de los síntomas mas obvios del código orientado a objetos es comparar las sentencias switch (o de casos). El problema del switch es el de la duplicación, a menudo usted encuentra la misma sentencia switch esperada por todo el programa, en diferentes lugares. Si usted agrega unanueva clausula al switch, tendría ue buscar todas estas sentencias switch y cambiarlas.

El concepto O.O de polimorfismos le brinda una solución elegante para esto. La mayoría de las veces una sentencia switch, considere el polimorfismo. A menudo la sentencia switch opera sobre un código. Usted desea el método para cada código use ExtractMethodpara extraer la sentencia switch como un nuevo método. 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 método y no espera que ellos cambien, entonces el polimorfismo es excesivo. En este caso use ReplaceParameterwithExplicitMethods, lo que es una buena opción si uno de los casos es un nulo, trate Introduce NullObject.

JERARQUIAS DE HERENCIA PARALELASRealmente es un caso especial de la cirugía por disparo. En este caso, cada vez que usted crea una subclase de una clase, también tiene que crear una. Subclase de otra clase. Usted puede reconocer este olor porque los prefijos de los nombres de clase en una jerarquía son los

Page 114: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

mismos de la otra jerarquía. La estrategia general para eliminar esta duplicidad es asegurar que instancias de una jerarquía. Se refiere a instancias de la otra. Si usa MOveMethody Move Field y la jerarquía en la clase relacionada desaparece.

CLASE PEREZOSACada 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 están haciendo lo suficiente, use CollapseHierorchy. Los componentes casi inútiles deben ser manejados con In Line Class.

GENERALIDAD ESPECULATIVASUCEDE cuando la gente dice “oh! Yo creo que necesitaremos la habilidad para hacer este tipo de cosas algún día”, y entonces se colocan toda clase de referencias y casos especiales para manejar cosas que no son requeridas. El resultado a menudo es difícil 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 están haciendo mucho, use CollapseHierarchy. La delegación innecesaria puede ser removida con In line class. Los métodos con parámetros no usados deben ser sometidos a RemoveParameter. Los métodos nombrados con nombres singularmente abstractos deben ser aterrizados con RenameMethod.

La generalidad especulativa puede ser encontrada cuando los únicos usuarios de un método o clase son los casos de prueba. Si usted encuentra tales métodos o clases, bórrelas y al caso de prueba que los ejercita. Si usted encuentra un método o clase que es un ayudante para un caso de prueba, que ejercita una funcionalidadlegitima usted tiene que dejarlo quieto, por supuesto.

CAMPO TEMPORALAlgunas veces usted ve un objeto con un atributo que es usado solo bajo ciertas circunstancias. Tal código es difícil 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 código que tenga que ver con el atributo en este componente. También tiene que ser hábil para eliminar el código condicional usando Introduce NullObject para crear un componente alternativo para cuando los atributos no sean validos.

Page 115: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Un caso común de campo temporal ocurre cuando un algoritmo complejo necesita varias variables. Como en la implementación no se desea pasar enormes listas de parámetros se colocan como atributos. Pero estos atributos solo son variables durante el algoritmo. En otros contextos son solo alimentos para la confusión. En este caso puede usar Extract Class con estas variables como atributos y los métodos que las requieren. El nuevo objeto es un Objeto Método.

30/01/12

CADENA DE MENSAJESVemos 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 métodos get. Esto significa que los objetos están acoplados a la estructura de navegación. Cualquier cambio en la estructura de navegación 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 volverán hombre en la mitad a menudo una solución mejor es ver para que se usa el objeto resultante. Mire si puede usar ExtractMethodpara cortar la parte de código que se usa y luego MoveMethod para ubicarlo más cerca de la cadena.

FALTA UNA PARTE

Si hay solo unos pocos métodos que no hacen mucho, use In line Methodpara incluir este código 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 delegación.

INTIMIDAD INAPROPIADAAlgunas veces las clases llegan a ser demasiado intimas y gastan demasiado tiempo hurgando en las partes privadas de la otra. Tratándose 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 común 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 más de sus padres, de lo que los padres saben de ellas. Es tiempo de dejar la casa, aplique replaceDlegatewithInheritance.

Page 116: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

CLASES ALTERNATIVAS CON DIFERENTES INTERFACES.Use RenameMethod para renombrar métodos 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 están haciendo suficiente. Use MoveMethodpara mover los comportamientos a las clases hasta que las interfaces sean iguales. Si usted tiene que mover código de manera redundante para cumplir esto, podría tener que usar ExtractSuperclass.

LIBRERIAS DE CLASES INCOMPLETAS.Se ha argumentado bastante cerca de reutilizar el código lo cual motiva la construcción de librerías de clases. Generalmente estas librerías no son diseñadas desde cero sino que resulta, del afán de reutilizar algunos programas que hicieron.

A menudo es malo, sino imposible, modificar una librería. Una vez que varias plicaciones la están usando. En las librerías, refactoring como MoveMethodno se puede aplicar.

Si usted que la librería tuviese algunos métodos adicionales puede usar Introduce ForeignMethod. Si hay mucho comportamiento extra para agregar, use Introduce local Extension.

CLASES DE DATOSEstas son clases que tienen atributos, métodos get y set para esos atributos y nada más.

Estas clases solo se ocupan de almacenar datos y seguramente están siendo extensamente manipuladas por otras clases.

A veces se encuentran que estas clases tienen atributos públicos. Si este es el caso, inmediatamente tiene que usar Encapsule Fieldantes de hacer otros refactoring.

Si usted tiene una colección de campos, verifique si están apropiadamente encapsulados y aplique Encapsulecollectionsi no lo están.

Use RemoveSettingMethoda todo campo que no necesite ser cambiado.

Mire si estos métodos 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 método entero use ExtractMethodpara separar trozos de código 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 niños. Están bien en el punto de arranque pero a medida que crecen hay que darles responsabilidades.

REHUSAR EL LEGADO.Las subclases heredan atributos y métodos 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 jerarquía esta equivocada.

Page 117: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ 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 común 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 rehúsa el legado causa confusión y problemas, no siento que debe seguir siempre las tradiciones.

El mal olor de rehusar el legado es mucho más 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 jerarquía. Usted puede manejarlo aplicandoReplaceInheritancewithDelegation.

31/01/12

COMENTARIOSEn nuestro análisis 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 códigos fuertemente comentados que los comentarios están allí porque el código es malo.

Si este es el caso, analice el código 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 código para ver si el comentario se vuelve superfluo.

Un buen tiempo para usar un comentario es cuando usted no sabe que hacer. Además 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 información ayuda a los futuros modificadores, especialmente a los olvidadizos.

Page 118: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Capitulo 6

METODOS DE COMPOSICIONUna gran parte del refactoring son métodos de composición para empacar el código apropiadamente, casi todo el tiempo los problemas vienen de métodos que son muy largos estos métodos son problemáticos porque a menudo contienen montones de información que esta enterrada en una lógica compleja que las ha arrastrado..El refactoring clave es ExtraxtMethodque toma una porción de código y la convierte en un método.

Inline Method es esencialmente lo opuesto. Toma una llamada a método y la remplaza por el cuerpo del método.

Necesitamos Inline Method si luego de hacer varias extracciones de código vemos que no nos ha quedado muy bn y necesitamos reorganizar la forma como repartimos el código en métodos.

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 método, 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 más fácil de manejar pueda remplazar. Si la variable temporal es usada para muchas cosas, entonces use Split Temporary Variableprimero para hacer la variable temporal más fácil de manejar.

Algunas veces sin embargo, las variables temporales están demasiado enredadas para remplazar se necesita ReplaceMethodwithMethodObject. Esto permite dividir los métodos mas enredados al costo de introducir nuevas clases para el trabajo.

Los parámetros 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 método es dividido, su puede comprender mejor como trabaja. También se puede encontrar que el algoritmo puede ser mejorado para hacerlo mas claro. Entonces use subtituteAlgorithmpara introducir un algoritmo mas claro.

EXTRACT METHODUsted tiene un fragmento de código que puede ser agrupado aparte.

Cambie el fragmento en un método cuyo nombre explique el propósito del método.

voidprintOwing(double amount) {

printBanner();//ImprimedetallesSystem.out.println ("name:" + _name);System.out.println ("amount" + amount);

}

Page 119: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

|| \/

voidprintOwing(double amount) {

printBanner();printDetails(amount);

}

voidprintDetails (double amount){

System.out.println ("name:" + _name);System.out.println ("amount" + amount);

}

MOTIVACIONExtractMethod es uno delos refactoring mas comunes. Miro un código que es demasiado largo o miro un código que necesita un comentario para comprender su propósito entonces cambio ese fragmento de código en un método. Prefiero los métodos cortos y bien nombrados por varias razones. Primero, incrementa la oportunidad de que otros métodos pueden usar un método, cuando el método ha sido desgranado, segundo, permite que los métodos de nivel más alto se vean mas como una serie de cometarios. Sobrescribir también es más fácil cuando los métodos están desgranados.

Toma un poco de trabajo usar este refactoring si usted esta a acostumbradoa ver métodos largos. Los pequeños métodos trabajan solamente cuando tienen buenos nombres, así que necesita poner atención a los nombres. La gente a veces pregunta de que longitud debe ser un método. La longitud no es punto. La clave es la distancia semántica entre el nombre y el cuerpo del método. Si extraer mejora la claridad, hágalo, aun si el nombre es mas largo que el código que usted ha extraído.

MECANICA Crear un nuevo método y nombrarlo luego con la intención del método (nombrarlo

por lo que hace no por como lo hace).¿Si el código que usted desea extraer es muy simple, tal como un solo mensaje o llamada a función, debería extraerlo si el nombre del nuevo método revelara la intención del código de una mejor manera. Si usted no puede encontrar un nombre más significativo, no extraiga el código.

Copiar el código extraído del método fuente en el nuevo método destino. Busque en el código extraído referencias a cualquier variable local, que sea local en el

alcance del método fuente. Estos métodos variables locales y parámetros para el método destino.

Mire si una variable temporal se usa solamente dentro del código extraído. Si es así, declárela dentro del método destino, como variables temporal.

Mire si alaguna de las variables de alcance local es modificada, mire si puede tratar el código como una consulta (query) y asignarle el resultado a la variable en cuestión.

Page 120: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Si es feo o hay más de una de tales variables siendo modificadas, usted no puede extraer el código como esta. Puede necesitar usar el refactoring Split Temporary Variable y tratar de nuevo. Usted puede eliminar las variablestemporales usando ReplaceTempwithQuery(ver la discusión del ejemplo).

Pasar al método destino las variables del alcance local que son leídas del método extraído, como parámetros.

Compile cuando haya manejado todas las variables en el alcance local. Remplace el código extraído en el método fuente, por una llamada al método destino.

¿si usted ha movido cualquier variable temporal sobre el método destino, mire si fue declarada por fuera en el método fuente. Si es así, usted puede eliminar la declaración.

Compile y pruebe.

01/02/2012

En el caso trivial, ExtractMethodes muy fácil:

voidprintOwing() {

Enumeration e = _orders.elements();double outstanding = 0.0;// imprime el bannerSystem.out.println ("**************************");System.out.println ("***** Customer Owes ******");System.out.println ("**************************");// calcula outstandingwhile (e.hasMoreElements()) {

Order each = (Order) e.nextElement();outstanding += each.getAmount();

}//imprimedetallesSystem.out.println ("name:" + _name);System.out.println ("amount" + outstanding);}

Es fácil extraer el código que imprime el banner, solo corte y pegue.

voidprintOwing() {

Enumeration e = _orders.elements();double outstanding = 0.0;printBanner();// calcula outstandingwhile (e.hasMoreElements()) {Order each = (Order) e.nextElement();

Page 121: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

outstanding += each.getAmount();}

//imprimedetallesSystem.out.println ("name:" + _name);System.out.println ("amount" + outstanding);}voidprintBanner() {

// print bannerSystem.out.println ("**************************");System.out.println ("***** Customer Owes ******");System.out.println ("**************************");

}

Ejemplo Usando Variables locales.Entonces cual es el problema?Son las variables locales? Parámetros pasados al método original y variables temporales declaradas dentro del método original. Las variables locales están solamente dentro del alcance del método, así que usamos ExtractMethodestas variables causan trabajo extra. En algunos casos, hasta evita que se pueda hacer refactoring.

El caso mas fácil con las variables locales sucede cuando son leídas pero no cambiadas.

A partir del último código, vamos a extraer la parte que imprime detalles.

voidprintOwing() {

Enumeration e = _orders.elements();double outstanding = 0.0;printBanner();// calculate outstandingwhile (e.hasMoreElements()) {

Order each = (Order) e.nextElement();outstanding += each.getAmount();

}//print detailsSystem.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 método modificador sobre la variable.

De nuevo, usted puede pasar el objeto como parámetro. Solo tiene que hacer algo diferente si asigna a la variable local.

Page 122: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

Ejemplo: Reasignando la Variable LocalEs la asignación a variables locales lo que llega a ser complicado. En este caso solo hablamos de variables temporales. Se ve una asignación a un parámetro, 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 código extraído. El otro caso es cuando la variable se usa afuera del código extraído.

Si la variable no es usada después del código extraído, sencillamente puede hacer el cambio dentro del código extraído. Si la variable se usa después, necesita hacer que le código extraído retorne el valor cambiado de la variable se puede ilustrar esto con el siguiente código, que extrae la parte de los cálculos:

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 enumeración (e) solo es usada dentro del cálculo que es el código extraído, así que se puede mover enteramente al nuevo método. La variable outstanding es usada en ambos lugares, así que se necesita retornarla desde el método extraído. Una vez compila y prueba la extracción, se renombra el valor retornado siguiendo la convención:

doublegetOutstanding(){

Enumeration e = _orders.elements();doubleresult = 0.0;while (e.hasMoreElements()) {

Order each = (Order) e.nextElement();result= each.getAmount();

}returnresult;

Page 123: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

}

En el presente código la variable outstanding es inicializada a un solo valor conocido (0.0), asi que se puede inicializar en el código extraído, si la variable se inicializa en un valor no trivial, entonces hay que pasarle al método el valor anterior de la variable.El código inicial para este ejemplo:

voidprintOwing(double previousAmount) {

Enumeration e = _orders.elements();double outstanding = previousAmount * 1.2;printBanner();// calculate outstandingwhile (e.hasMoreElements()) {

Order each = (Order) e.nextElement();outstanding += each.getAmount();

}printDetails(outstanding);

}

En este caso la extracción 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;

}

Después de compilar y comprobar esto, podemos aclarar la forma como se inicializa la variable outstandig:

voidprintOwing(double previousAmount)

Page 124: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ CORREA

{printBanner();double outstanding = getOutstanding(previousAmount * 1.2);printDetails(outstanding);

}

En este momento usted se podría estar preguntando: “Que pasaría si necesitamos retornar mas de una variable?” aquí usted tiene varias opciones:La mejor opción generalmente es escoger un código diferente para extraer. Se prefiere que un método retorne un solo valor, de tal manera que se puedan organizar múltiples métodos para múltiples valores. (si su lenguaje permite parámetros 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 difícil la extracción. En estos casos trataremos de reducir las variables temporales con ReplaceTempwithQuery. Si cualquier cosa que haga sigue siendo difícil, use ReplaceMethodwithMthosObject. A este refactoring no le importa la cantidad de variables temporales.

FALTA CLASE 6 Y 7

08/02/2012Ejemplo: ExtractMethod

Comenzamos con el siguiente código

doubleprice (){

// el precio es preciobase – descuento + embarquereturn _quantity * _itemPrice -Math.max(0, _quantity - 500) * _itemPrice * 0.05 +Math.min(_quantity * _itemPrice * 0.1, 100.0);

}

Esta vez extraeremos el método para el precio base:

double price() {

// el precio es preciobase – descuento + embarquereturnbasePrice -Math.max(0, _quantity - 500) * _itemPrice * 0.05 +Math.min(basePrice* 0.1, 100.0);

}

private double basePrice() {

return _quantity * _itemPrice;}

Se deben manejar uno a la vez. Al terminar tenemos

Page 125: Cuaderno IngeSoft II V5.0

INGENIERÍA DE SOFTWARE II GR 1.JORGE ALBERTO GÁLVEZ 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 métodos están disponibles para cualquiera otro objeto que los necesite. Inicialmente se manejan Privatepero luego se puede relajar este tipo de acceso si otros necesitan el método. 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 fácil usar ExtractMethod.En este caso usamos Introduce Explaining Variable, para ayudar a comprender la expresión. Si la lógica no es muy enredada, mas tarde podríamos usar ReplaceTempwithQuery. La variable temporal también es valiosa si terminamos usando ReplaceMethodwithMethodObject.

http://sourcemaking.com/refactoring/replace-method-with-method-object

madurez para toda la empresa capacidad uno en especifico