Resumen Parte 4 Ingenieria Del Software

o n a l p i t l A l e d l a n o i c a N d a d i s r e v i n U

e a d m s e t o t s i c S e y o r P e d n ó i c a u l a v E y n ó i c a c i f i n a l P

I I 5 1 0 2 e r t s e m e S

Ingeniería del Software: Un enfoque práctico. RESUMEN Objetivos de la UNIDAD IV “ Administración de Proyectos de Software”:      

Capítulo 24: Conceptos de Administración de Proyecto. Capítulo 25: Métricas de Proceso y de Proyecto. Capítulo 26: Estimación Para Proyectos de Software. Capítulo 27: Calendarización del Proyecto. Capítulo 28: Administración del Riesgo. Capítulo 29: Mantenimiento y Reingeniería.

Integrantes:  Dennis Martin G. Chipana Aza.  Cristhian Abad Anchapuri Ruelas.  Sleyther Giulio Calsin Pacsi.

Universidad Nacional del Altiplano Planificación y Evaluación de Proyectos de Sistema Ingeniería del Software: Un enfoque práctico.

Ingeniería del Software: Un enfoque práctico.

Contenido INTRODUCCION INTRODUCCION ............................... ................................................ .................................. .................................. .................................. ........................ ....... 7 CAPITULO 24: CONCEPTOS DE ADMINISTRACION DE PROYECTOS ................. ... 8

24.1 : EL ESPECTRO ADMINISTRATIVO ...................................................................................... ...................................................................................... 9 24.1.1: EL PERSONAL P ERSONAL ....................................................................................... ............................................................................................................. ...................... 9 24.1.2: EL PRODUCTO............................................................... ............................................................................................................ ............................................. 9 24.1.3: EL PROCESO ................................................................... ............................................................................................................... ............................................ 9 24.1.4: EL PROYECTO ................................................................. ........................................................................................................... .......................................... 10 24.2: EL PERSONAL P ERSONAL ................................................................................... .................................................................................................................. ............................... 10 24.2.1: LOS LO S PARTICIPANTES ................................................................................................ 10 24.2.2: LIDERES DE EQUIPO.................................................................. ................................................................................................. ............................... 11 24.2.3: EL EQUIPO DE SOFTWARE ................................................................... ....................................................................................... .................... 11 24.2.4: EQUIPOS AGILES ........................................................... ...................................................................................................... ........................................... 11 24.2.5: CONFLICTOS CONFL ICTOS DE COORDINACION Y COMUNICACIÓN ............................................. ............................................. 12 24.3: EL PRODUCTO........................................................... ................................................................................................................. ...................................................... 12 24.3.1: AMBITO DEL SOFTWARE ......................................................................................... ......................................................................................... 12 24.3.2: DESCOMPOSICION DEL PROBLEMA ........................................................................ 13 24.4: EL PROCESO .............................................................. .................................................................................................................... ...................................................... 13 2.4.1: FUSION DE PRODUCTO Y PROCESO .......................................................................... 13 2.4.2 DESCOMPOSICION DEL PROCESO .............................................................................. 13 24.5: EL PROYECTO ............................................................ .................................................................................................................. ...................................................... 14 24.6: EL PRINCIPIO W5HH ....................................................................................................... ....................................................................................................... 14 CAPITULO 25. METRICAS DE PROCESO Y DEL PROYECTO .............. .................. .......... ........ 16

25.1: METRICA EN LOS DOMINIOS DE PROCESO Y PROYECTO P ROYECTO ............................................... 16 25.1.1: LAS METRICAS DEL PROCESO Y LA MEJORA DEL PROCESO DE SOFTWARE SO FTWARE ............ 16 25.1.2: METRICAS DE PROYECTO ........................................................................................ 16

Ingeniería de Sistemas

Página 2 de 61


25.2 MEDICION DEL SOFTWARE ............................................................................................. 17 25.2.1: METRICAS ORIENTADAS A TAMAÑO .............................................................. ....................................................................... ......... 17 25.2.2: METRICAS ORIENTADAS A FUNCION ...................................................................... 17 25.2.3: METRICAS ORIENTADAS A OBJETO ......................................................................... 18 25.2.4: METRICAS ORIENTADAS A CASO DE USO ................................................................ 18 25.2.6: METRICAS DE PROYECTO WEBAPP ......................................................................... 18 ADMINISTRACION DE RIESGO: ................... ......... ................... ................... ................... .................. .................. ................... .............. .... 19

ESTRATEGIAS REACTIVAS DE RIESGO FRENTE A ESTRATEGIAS PROACTIVAS DE RIESGO ...... 20 RIESGOS DE SOFTWARE: ......................................................................................................... ......................................................................................................... 20 4. IDENTIFICACION I DENTIFICACION DE RIESGOS: ............................................................................................. ............................................................................................. 21 - Riesgos Genéricos ............................................................................................................. ............................................................................................................. 21 - Riesgos Específicos: ................................................................. ........................................................................................................... .......................................... 21 -Tamaño del producto .............................................................. ......................................................................................................... ........................................... 21 5. PROYECCION DE RIESGO: .................................................................................................... .................................................................................................... 22 5.1. VALORACION DE IMPACTO .......................................................................................... 22 5.2. ELABORACION DE UNA TABLA DE RIESGOS: ................................................................ ................................................................ 23 5.3. VALORACION DE IMPACTO DE RIESGO: ....................................................................... ....................................................................... 24 6. REFINAMIENTO R EFINAMIENTO DE RIESGO: ................................................................................................ ................................................................................................ 24 7. MITIGACIÓN, MONITOREO Y MANEJO DE RIESGO: RI ESGO: ............................................................ ............................................................ 25 8. EL PLAN MMMR: ................................................................................................................. ................................................................................................................. 25 MANTENIMIENTO Y REINGENIERA: ........................................................................ 26

MANTENIMIENTO DE SOFTWARE: .......................................................................................... .......................................................................................... 27 SOPORTABILIDAD DEL SOFTWARE: ................................................................................ ......................................................................................... ......... 27 REINGENIERIA: ................................................................... ........................................................................................................................ ..................................................... 27 REINGENIERA DE PROCESOS DE EMPRESA: ............................................................................ ............................................................................ 28 PROCESOS EMPRESARIALES: ............................................................................................... ............................................................................................... 28 MODELO RPE: ............................................................................................................. ...................................................................................................................... ......... 28 28 REINGENIERIA DE SOFTWARE: ................................................................................................ ................................................................................................ 29 Un modelo de proceso de reingeniería de software: ............................................................. 30 Actividades de reingeniería de software:............................................................................ 31 INGENIERA INGENIERA INVERSA: INVERSA: ................................. ................................................. ................................. .................................. ............................ ........... 32

Ingeniería inversa para comprender datos: ...................................................................... ............................................................................ ...... 34 Ingeniería inversa para entender el procesamiento: .............................................................. .............................................................. 34 Ingeniería inversa de interfaces de usuario: ........................................................................... ........................................................................... 34


Página 3 de 61


REESTRUCTURACION: .............................................................................................................. 34 Reestructuración de código: ............................................................................................... 34 Reestructuración de datos: ................................................................................................. 35 INGENIERÍA HACIA ADELANTE: ............................................................................................... 35 Ingeniería hacia adelante para arquitecturas cliente-servidor: .......................................... 35 Ingeniería hacia adelante para arquitecturas orientadas a objetos: .................................. 35 ECONOMÍA DE LA REINGENIERÍA: ........................................................................................... 35 CAPITULO 26: ESTIMACION PARA PROYECTOS DE SOFTWARE ............ ............ 37

26.1 Observaciones acerca de las estimaciones ..................................................................... 37 26.2 El proceso de planificación del proyecto ........................................................................ 37 26.3 Ámbito y factibilidad del software .................................................................................. 37 26.4 Recursos .......................................................................................................................... 38 26.4.1 Recursos Humanos ................................................................................................... 38 26.4.2 Recursos de software Reutilizable ........................................................................... 38 26.4.3 Recursos Ambientales .............................................................................................. 39 26.5 Estimación de proyectos de software ............................................................................. 39 26.6 Técnicas de descomposición ........................................................................................... 39 26.6.1 Dimensionamiento de software ............................................................................... 39 26.6.2 Estimación basada en el problema .......................................................................... 39 26.6.3 Estimación basada en proceso ................................................................................. 40 CAPITULO 27: CALENDARIZACION DE PROYECTO ............................................... 41

27.1 Conceptos básicos .......................................................................................................... 41 27.2 Calendarización de proyecto .......................................................................................... 41 27.2.1 Principios básicos ..................................................................................................... 41 27.4 Definición de una red de tareas ..................................................................................... 41 27.5 Calendarización .............................................................................................................. 42 27.5.1 Cronograma.............................................................................................................. 42 27.5.2 Seguimiento de Calendario ...................................................................................... 43 27.5.3 Seguimiento de procesos para un proyecto ............................................................ 43 CAP 28 : ADMINITRACION DE RIESGO ................................................................. 45

28.1 ADMINISTRACION DE RIESGO: ........................................................................................ 45 28.4 ESTRATEGIAS REACTIVAS DE RIESGO FRENTE A ESTRATEGIAS PROACTIVAS DE RIESGO ................................................................................................................................................. 45 28.3 RIESGOS DE SOFTWARE: ................................................................................................. 45


Página 4 de 61


28.4 IDENTIFICACION DE RIESGOS: ......................................................................................... 46 28.4.1 Riesgos Genéricos: ................................................................................................... 46 28.4.2 Riesgos Específicos: .................................................................................................. 46 28.4.3 Tamaño del producto: .............................................................................................. 46 28.4.4 Impacto empresarial: ............................................................................................... 46 28.4.5 Características de los participantes:......................................................................... 46 28.5.6 Definición del proceso:............................................................................................. 46 28.5.7 Entorno de desarrollo: ............................................................................................. 46 28.5.8 Tecnología por construir: ......................................................................................... 47 28.5.9 Tamaño y experiencia del personal: ........................................................................ 47 28.5 PROYECCION DE RIESGO: ................................................................................................ 47 28.5 .1. VALORACION DE IMPACTO: ................................................................................... 48 28.5.2. ELABORACION DE UNA TABLA DE RIESGOS: ........................................................... 48 28.5 .3. VALORACION DE IMPACTO DE RIESGO: ................................................................. 49 28.6 REFINAMIENTO DE RIESGO: ............................................................................................ 50 28.7 MITIGACIÓN, MONITOREO Y MANEJO DE RIESGO: ....................................................... 50 28.8 EL PLAN MMMR: ............................................................................................................. 51 CAP 29: MANTENIMIENTO Y REINGENIERIA .......................................................... 52

29.2 MANTENIMIENTO DE SOFTWARE: .................................................................................. 52 29.3 SOPORTABILIDAD DEL SOFTWARE: ................................................................................. 53 29.4 REINGENIERIA:................................................................................................................. 53 29.5 REINGENIERA DE PROCESOS DE EMPRESA: .................................................................... 53 29.5.1 PROCESOS EMPRESARIALES: .................................................................................... 53 29.6

MODELO RPE: .............................................................................................................. 54

29.7

REINGENIERIA DE SOFTWARE: .................................................................................... 55

29.8 Un modelo de proceso de reingeniería de software: ..................................................... 55 29.9Actividades de reingeniería de software: ........................................................................ 56 29.9.1 Análisis de inventarios.............................................................................................. 56 29.9.2 Reestructuración de documentos: ............................................................................... 56 29.10 INGENIERA INVERSA: ..................................................................................................... 57 29.11 Ingeniería inversa para comprender datos: .................................................................. 59 29.12 Ingeniería inversa para entender el procesamiento: .................................................... 59 29. 13 Ingeniería inversa de interfaces de usuario: ................................................................ 59 29.14 REESTRUCTURACION:.................................................................................................... 59


Página 5 de 61


29.14.1

Reestructuración de código: ........................................................................... 59

29.14.2 Reestructuración de datos: .................................................................................... 60 29.15 INGENIERÍA HACIA ADELANTE: ..................................................................................... 60 29.15.1 Ingeniería hacia adelante para arquitecturas cliente-servidor: .................... 60 29.15.2 Ingeniería hacia adelante para arquitecturas orientadas a objetos: ..................... 60 29.30 ECONOMÍA DE LA REINGENIERÍA: ................................................................................. 60


Página 6 de 61


INTRODUCCION En esta parte de Ingeniería del software. Un enfoque práctico, aprenderemos, sobre las técnicas de administración requeridas para planificar, organizar, monitorear y controlar proyectos de software. En el desarrollo de los capítulos de esta unidad del libro abordaremos muchas cuestiones como: o

¿Cómo debe administrarse el personal, el proceso y el problema durante un proyecto de software?

o

¿Cómo pueden usarse las métricas del software para administrar un proyecto y el proceso de software?

o

¿Cómo genera un equipo de software estimaciones confiables de esfuerzo, costo y duración del proyecto?

o

¿Qué técnicas pueden usarse para valorar los riesgos que pueden tener impacto sobre el éxito del proyecto?

o

¿Cómo selecciona un gerente de proyecto de software un conjunto de tareas laborales para los ingenieros del software?

o

¿Cómo se crea un calendario de proyecto?

o

¿Por qué el mantenimiento y la reingeniería son importantes para los gerentes de ingeniería de software y para los profesionales?


Página 7 de 61


CAPITULO 24: CONCEPTOS ADMINISTRACION DE PROYECTOS

DE

La administración del proyecto involucra planificación, monitoreo y control del personal, procesos y acciones que ocurren conforme el software evoluciona desde un concepto preliminar hasta su despliegue operativo completo. Todo el mundo “ Administra ” , cada una de las personas realiza actividades

concernientes a este temas, pero en el desarrollo de un Proyecto de Software es el Ingeniero de Software quien realizara esta actividad deberá realizar las tareas diarias y cotidianas de planificar, monitorear y controlar todos los aspectos técnicos en el desarrollo del Proyecto. Para un efectivo manejo y desarrollo del Proyecto se debe tener en cuenta las cuatro P: Personal, Producto, Proceso y Proyecto. El personal debe organizarse para realizar el trabajo de software de manera efectiva. La comunicación con el cliente y con otros participantes debe ocurrir de modo que el ámbito del producto y los requerimientos sean comprensibles. Debe seleccionarse un proceso que sea adecuado para el personal y el producto. El proyecto debe planificarse, estimándose el esfuerzo y el cronograma necesarios para concluir las tareas. En cuanto se hayan iniciado las actividades para el desarrollo del proyecto debe tenerse en cuenta la planificación que se haya realizado el cronograma establecido deberá ser cumplido tal y como se acordó, durante el desarrollo cada uno de los participantes debe cumplir con las actividades que se le han designado hacer y también los tiempos establecidos serán la medida para ver la efectividad de la planificación. Una vez cumplida todas las actividades, es difícil determinar si el producto cumple con las expectativas trazadas pero esta incertidumbre ha de darse casi siempre y solo será resuelta en la practica del proyecto con el producto final, y de haber alguna modificación o modificaciones estas deberán ser hechas cuanto antes en plena comunicación entre personal y cliente.


Página 8 de 61


24.1 : EL ESPECTRO ADMINISTRATIVO La administración de un Proyecto de Software será efectivo poniendo su enfoque en las cuatro P. Un gerente que involucre a su personal una buena comunicación entre ellos y el cliente estará desarrollando una solución elegante ante sucesos que lo requieran, asi tendrá un producto que sufra muchos riesgos, además de no tener en cuenta buenas metodologías para la evolución del proyecto se pone en riesgo que los procesos sean efectivos y asi el proyecto pueda que no resulte de acuerdo a las

expectativas trazadas.

24.1.1: EL PERSONAL Desde la década de 1960 se estudia la formación de personal de software motivado y enormemente calificado. De hecho, el “factor humano” es tan importante que el

Software Engineering Institute desarrolló un Modelo de madurez de capacidades del personal (People-CMM, por sus Siglas en inglés), en reconocimiento al hecho de que “toda organización requiere mejorar continuamente su habilidad para atraer,

desarrollar, motivar, organizar y conservar la fuerza de trabajo necesaria a fin de lograr sus objetivos empresariales estratégicos”.

24.1.2: EL PRODUCTO Antes de planear un Proyecto debemos establecer los objetivos y el ámbito del producto, como desarrolladores de Software, todos los participantes involucrados debe reunirse para poder definir los objetivos y el ámbito del producto. Los objetivos definen e identifican las metas globales para el producto, el ámbito ayudara a identificar los datos, funciones y comportamientos principales que caracterizan al producto.

24.1.3: EL PROCESO Un proceso de software proporciona el marco conceptual el cual puede ser establecido por un plan completo para el desarrollo de software, algunos procesos pueden definirse como un conjunto de tareas como: tareas, hitos, productos operativos y puntos de aseguramientos de calidad, esto permite que las actividades del marco conceptual se adapte a las características de nuestro producto.


Página 9 de 61


24.1.4: EL PROYECTO Los proyectos de software se planean y controlan debido a una razón principal: es la única forma conocida para manejar la complejidad. E incluso así, los equipos de software todavía batallan. En un estudio de 250 grandes proyectos de software desarrollados entre 1998 y 2004, Capers Jones encontró que “alrededor de 25 se consideraron exitosos por haber

logrado sus objetivos de calendario, costo y calidad. Aproximadamente 50 tuvieron demoras o excesos por abajo de 35 por ciento, mientras que más o menos 175 experimentaron grandes demoras y excesos, o se dieron por concluidos sin completarse”. Aunque actualmente la tasa de éxi to para los proyectos de software

puede haber mejorado un poco, la tasa de falla de proyecto sigue siendo mucho más alta de lo que debiera.

24.2: EL PERSONAL El personal es la herramienta mas importante, el factor humano ha determinado muchas veces el éxito de un proyecto, según testimonios en los EEUU muchos de los Vice Presidentes encargados de grandes proyectos de software, declaran que la selección de un buen personal para el desarrollo del proyecto es un buen índice para medir el éxito del mismo, además de que debe saberse manejar al a grupo de forma unida esto producirá soluciones a problemas de formas efectivas e inteligentes, para que todo esto fluya sin muchos conflictos , debe proporcionarse también un buen ambiente para que estos desarrollen sus actividades de maneras aun mas creativas.

24.2.1: LOS PARTICIPANTES El proceso de software involucra muchos participantes, pero podemos diferenciarlos de acuerdo a sus tareas o actividades como: 

GERENTES EJECUTIVOS,

quienes definen los temas empresariales,

generalmente ellos son los que tiene un myor influencia sobre el proyecto. 

GERENTES DE PROYECTOS (tecnicos), quienes planifican, motivan,

organizan y controlan a los profesionales que hacen el trabajo de software. 

CLIENTES , quienes especifican los requerimientos para el software.



USUARIOS FINALES, quienes interactúan con el software una vez que se

haya lanzado para su uso.


Página 10 de 61


24.2.2: LIDERES DE EQUIPO Para que la administración de un proyecto sea efectiva y se desarrolle con mucha sinergia, debe considerarse que no todos tiene la habilidad de dirigir las actividades con tal diligencia, a veces resulta que la persona encargada suele toparse con el puesto de gerente quizás por el hecho de cumplir con las características para el puesto, pero que en la practica , no suele tener éxito en el manejo del grupo involucrado. Un excelente libro acerca de liderazgo técnico, Jerry Weinberg sugiere un modelo MOI ( Motivación, organización e Innovación de ideas), una visión de las caraterisitca que definen a un gerente de proyecto eficaz enfatiza cuatro rasgos como claves : 1. Resolución de Problemas 2. Identidad Administrativa 3. Logro 4. Influencia y construcción del equipo

24.2.3: EL EQUIPO DE SOFTWARE Existen muchos modelos y estructuras de organización humana para el desarrollo de un proyecto de software, las consecuencias practicas que se desarrollan entorno al desarrollo a veces no suelen ser del todo exitosas, esto a veces depende del estilo administrativo de la organización, sin embargo Mantei describe site factores de proyecto que deben considerarse cuando se planee la estructura de los equipos de ingeniería de software: 

Dificultad del problema que se va a resolver.



“Tamaño” del programa resultante en líneas de código o puntos de función.



Tiempo que el equipo permanecerá unido (vida del equipo).



Grado en el que puede dividirse en módulos el problema.



Calidad y confiabilidad requeridas por el sistema que se va a construir.



Rigidez de la fecha de entrega.



Grado de sociabilidad (comunicación ) requerido para el proyecto.

24.2.4: EQUIPOS AGILES Para hacer uso efectivo de las competencias de cada miembro del equipo y fomentar la colaboración efectiva a través de un proyecto de software, los equipos ágiles son auto organizados. Ingeniería de Sistemas

Página 11 de 61


Muchos modelos de proceso ágil (por ejemplo, Scrum) dan al equipo ágil significativa autonomía para tomar las decisiones administrativas y técnicas del proyecto necesarias para hacer que el trabajo se cumpla. La planificación se mantiene al mínimo y al equipo se le permite seleccionar su propio enfoque (por ejemplo, proceso, métodos, herramientas), restringido únicamente por los requerimientos empresariales y los estándares de la organización.

24.2.5: CONFLICTOS DE COORDINACION Y COMUNICACIÓN La interoperabilidad se ha convertido en una característica clave de muchos sistemas. El software nuevo debe comunicarse con el software existente y ajustarse a las restricciones predefinidas impuestas por el sistema o por el producto. Tales características del software moderno (escala, incertidumbre e interoperabilidad) son hechos de la vida. Para lidiar con ellos de manera efectiva, deben implantarse métodos efectivos a fin de coordinar al personal que hace el trabajo.

24.3: EL PRODUCTO Se requieren estimaciones cuantitativas y un plan organizado, pero no hay información sólida disponible. Un análisis detallado de los requerimientos del software proporcionaría la información necesaria para las estimaciones, pero el análisis usualmente tarda semanas o incluso meses en completarse. Peor aún, los requerimientos pueden ser fluidos y cambiar con regularidad conforme avanza el proyecto.

24.3.1: AMBITO DEL SOFTWARE Esta es una de las primeras actividades en la administración del proyecto de software, esto se define al solucionar ciertas cuestiones que respondan al: contexto, objetivos de información y función y desempeño. No debe haber ambigüedades ni se incomprensibles en los niveles administrativo técnico, debe ser preciso y consistente. Debe acotar un enunciado , es decir, los datos cuantitativos (Numero de usuarios, entorno objetivo, máximo de tiempo, etc),


Página 12 de 61


enunciados de manera explicita , se anotan las restricciones y/o limitaciones (por ejemplo , el costo del producto restringe el tamaño de la memoria) y se reflejan en factores mitigantes (por ejemplo , los algoritmos deseados están bien entendidos y disponibles en java).

24.3.2: DESCOMPOSICION DEL PROBLEMA Se suele aplicar una estrategia muy conocida “ divide y venceras ” cuando se q uiere resolver un problema complejo, de esta manera podemos dividir el problema complejo en problemas mas pequeños y estos carecerán de complejidad y será mucho mas manejables.

24.4: EL PROCESO Una de las actividades que caracterizan al proceso de software se tornan alrededor del marco conceptual, el problema es seleccionar el modelo de proceso que sea adecuado para el software y que el equipo del proyecto se encargara de ejecutarlo.

2.4.1: FUSION DE PRODUCTO Y PROCESO La planificación del proyecto comienza con la fusión de producto y proceso, en esencia se crea una matriz cada función de producto principal se menciona en la columna izquierda , las actividades del marco conceptual se mencionan en la fila superior, la labor del gerente a cargo del proyecto es estimar los recursos necesarios que se utilizaran en el desarrollo del proyecto además de ver las actividades que se realizaran asociadas a cada celda.

2.4.2 DESCOMPOSICION DEL PROCESO La descomposición del proceso beneficiara al desarrollo de las actividades involucradas en el proyecto de esta manera se le estará quitando la complejidad en conjunto para poder desglosarlo en problemas o actividades mas sencillas de cumplir, por ejemplo un proyecto simple y relativamente pequeño puede requerir las siguientes tareas para la actividad de comunicación: 

Revisar la solicitud del cliente.


Página 13 de 61

Universidad Nacional del Altiplano Planificación y Evaluación de Proyectos de Sistema Ingeniería del Software: Un enfoque práctico. 

Planificar y calendarizar una reunión formal facilitada con todos los participantes.



Realizar una investigación para especificar la solución propuesta y los enfoques existentes.



Preparar un “documento de trabajo” y una agenda para la reunión formal.



Realizar la reunión.

24.5: EL PROYECTO Para que un proyecto de software tenga éxito, debemos entender que pueden salir mal muchas cosas, de modo que algunos de ellos pueden evitarse. Jhon Reel define 10 señales que indican que un proyecto de sistemas de información esta en peligro. 1. El personal del software no entiende las necesidades del cliente. 2. El ámbito del producto esta pobremente definido. 3. Los cambios se gestionan pobremente. 4. Cambia la tecnología elegida. 5. Las necesidades empresariales cambian o están mal definidas. 6. Las fechas limite son irreales. 7. Los usuarios son resistentes. 8. Perdida de patrocinio o nunca obtenido adecuadamente. 9. El equipo del proyecto carece de personal con habilidades adecuadas. 10. Los gerentes y profesionales evitan mejores practicas y lecciones aprendidas.

24.6: EL PRINCIPIO W5HH Es un excelente ensayo acerca del proceso de software, Barry Boehm plantea las siguientes preguntas para desarrollar un proyecto de software sin importar la complejidad o tamaño del mismo: -. ¿Por qué (why) se desarrollará el sistema? Todos los participantes deben valorar la validez de las razones empresariales para el trabajo de software. ¿El propósito de la empresa justifica el gasto de personal, tiempo y dinero? -. ¿Qué (what) se hará? Defina el conjunto de tareas requeridas para el proyecto. -. ¿Cuándo (when) se hará? El equipo establece un calendario de proyecto al identificar cuándo se realizarán las tareas del proyecto y cuándo se alcanzarán los hitos. -. ¿Quién (who) es responsable de cada función? Defina el papel y la responsabilidad de cada miembro del equipo de software. Ingeniería de Sistemas

Página 14 de 61


-. ¿Dónde (where) se ubicarán en la organización? No todos los roles y responsabilidades residen dentro de los profesionales del software. Clientes, usuarios y otros participantes también tienen responsabilidades. -. ¿Cómo (how) se hará el trabajo, técnica y organizativamente? Una vez establecido el ámbito del producto, debe definirse una estrategia técnica para el proyecto. -. ¿Cuánto (how much) se necesita de cada recurso? La respuesta a esta pregunta se deriva al desarrollar estimaciones (capítulo 26) con base en las respuestas a las preguntas anteriores.


Página 15 de 61


CAPITULO 25. METRICAS DE PROCESO Y DEL PROYECTO Tener una medición permite ganar compresión acerca del proceso y del proyecto, al proporcionar un mecanismo de evaluación objetiva, además la medición puede usarse a través de un proyecto de software para auxiliar la estimación, control de calidad, valoración de productividad y control de proyecto.

25.1: METRICA EN LOS DOMINIOS DE PROCESO Y PROYECTO Las medidas que recopila un equipo de proyecto y que convierte en métricas para uso durante un proyecto pueden ser transmitidos a los participantes para que haya mejoras en el desarrollo de los procesos.

25.1.1: LAS METRICAS DEL PROCESO Y LA MEJORA DEL PROCESO DE SOFTWARE La eficacia de un proceso de software no puede medirse de manera directa , esto quiere decir que es posible derivar un conjunto de métricas con base en los resultados que pueden derivarse del proceso, los resultados incluyen medidas de los errores descubiertos antes liberar el software, defectos entregados a y reportados por usuarios finales. Conforme una organización se siente más cómoda

con la recolección y uso de

métricas de proceso, la derivación de los indicadores simples da lugar a un enfoque mas riguroso llamado mejora estadística de proceso de software ( MEPS ), este enfoque utiliza un análisis de falla de software para recopilar información acerca de todos los errores y defectos que se encuentren conforme se desarrolle y use una aplicación, sistema o producto.

25.1.2: METRICAS DE PROYECTO La diferencia entre métricas de proceso de software que se usaron con propósitos estratégicos, las métricas de proyecto son mas tácticos, es decir el gerente de proyecto y un equipo de software usan las métricas de proyecto y los indicadores para adaptar el flujo de trabajo del proyecto y las actividades técnicas. Las métricas de proyecto son de doble intención , primero para minimizar el calendario de desarrollo haciendo ajustes necesarios para evitar demoras y lidiar probables Ingeniería de Sistemas

Página 16 de 61


problemas y riesgos, segundo se usan para valorar la calidad del producto sobre una base en marcha, y de ser necesario modificar el enfoque técnico para mejorar la calidad.

25.2 MEDICION DEL SOFTWARE Para un mejor entendimiento, ilustraremos con un ejemplo simple, los individuos que trabajan en dos equipos de proyecto diferentes registran y categorizan todos los errores que encuentran durante el proceso de software, las medidas individuales luego se combinan para desarrollar medidas de equipo. Si un equipo encuentra mas errores que el otro durante el proceso de desarrollo, esto no quiere decir que uno es mejor que el otro en la detección de los errores de proceso, sin embargo debe tomarse en cuenta puntos fuertes como la complejidad y tamaño del proyecto, pero esto ayuda a tener estimaciones de como va desarrollándose el proyecto antes de su liberación para los usuarios finales.

25.2.1: METRICAS ORIENTADAS A TAMAÑO Las métricas orientadas a tamaño no se aceptan por lo general como algo para medir el proceso de software, la mayor de la incertidumbre gira en torno del uso de códigos de líneas de código como medida clave. Con la finalidad de desarrollar métricas que puedan compararse con otros proyectos, pueden elegirse líneas de códigos como un valor de normalización, a partir de los datos rudimentarios pueden desarrollarse métricas simples orientados a tamaño para cada proyecto.

25.2.2: METRICAS ORIENTADAS A FUNCION Una de las métricas orientada a función de mayor uso es Punto de Funcion (PF), el calculo del punto de función se bas en características del dominio y de la complejidad de información del software. El método requiere de cierta “maña ” ya que dicho calculo solo representa un numero y

esta basado mas en datos subjetivos que objetivos, y esto no afecta de manera física, por ser solo un numero.


Página 17 de 61


25.2.3: METRICAS ORIENTADAS A OBJETO A diferencia de las métricas orientadas a tamaño y orientadas a función, las métricas orientadas a objeto proporcionan suficiente granularidad para los ajustes de calendario y esfuerzo que se requiere en un proceso evolutivo. Lorenz y Kidd sugieren el siguiente conjunto de métricas para proyectos Orientado a Objeto: 

Numero de guiones de escenario: interacción entre usuario y aplicación.



Numero de clases clave: son los componentes enormemente independientes.



Numero de clases de apoyo: se requieren para implementar el sistemas.



Numero promedio de clases de apoyo por clase clave.



Numero de subsistemas.

Para usarse de manera efectiva , es necesario recopilar métricas similares a las descritas anteriormente, junto con medidas del proyecto tales como esfuerzo empleado, errores y defectos descubiertos.

25.2.4: METRICAS ORIENTADAS A CASO DE USO Los casos de uso se utilizan como un método para describir los requerimientos en el dominio en el nivel del cliente o empresarial. Los investigadores sugieren puntos de caso de uso (PCU) como un mecanismo para estimar el esfuerzo del proyecto y otras características, los PCU además es una función del numero de actores y transacciones implicados por los modelos de caso de uso.

25.2.6: METRICAS DE PROYECTO WEBAPP El objetivo principal en los proyectos webapp es de entregar al usuario final una combinación entre contenido y funcionalidad, sin embargo es posible desarrollar una base de datos que permita el acceso a medidas productivas y de calidad, entre las medidas que pueden recopilarse están: 

Numero de paginas web estáticas.



Numero de paginas web dinámicas.



Numero de vínculos de pagina internos.



Numero de objetos de datos persistentes.



Numero de sistemas externos puestos en interfaz.


Página 18 de 61

Universidad Nacional del Altiplano Planificación y Evaluación de Proyectos de Sistema Ingeniería del Software: Un enfoque práctico. 

Numero de objetos de contenido estatico.



Numero de funciones ejecutables.

ADMINISTRACION DE RIESGO: -

El análisis y la administración del riesgo son acciones que ayudan al equipo de software a entender y manejar la incertidumbre. Muchos problemas pueden


Página 19 de 61


-

-

-

-

plagar un proyecto de software. Un riesgo es un problema potencial: puede ocurrir, puede no ocurrir. Pero, sin importar el resultado, realmente es una buena idea identificarlo, valorar su probabilidad de ocurrencia, estimar su impacto y establecer un plan de contingencia para el caso de que el problema realmente ocurra. Todos los involucrados en el proceso de software (gerentes, ingenieros de software y otros interesados) participan en el análisis y la administración del riesgo. El software es una empresa difícil. Muchas cosas pueden salir mal y, francamente, muchas con frecuencia lo hacen. Por esta razón es que estar preparado, comprender los riesgos y tomar medidas proactivas para evitarlos o manejarlos son elementos clave de una buena administración de proyecto de software. Reconocer qué puede salir mal es el primer paso, llamado “identificación de riesgos”. A continuación, cada riesgo se analiza para determinar la probabilidad de que ocurra y el daño que causará si ocurre. Una vez establecida esta información se clasifican los riesgos, por probabilidad e impacto. Finalmente, se desarrolla un plan para manejar aquellos que tengan alta probabilidad y alto impacto. Se produce un plan para mitigar, monitorear y manejar el riesgo (MMMR) o un conjunto de hojas de información de riesgo. El MMMR debe revisarse conforme avance el proyecto para asegurarse de que los riesgos se mantienen actualizados. Los planes de contingencia para administración del riesgo deben ser realistas.

ESTRATEGIAS REACTIVAS DE RIESGO FRENTE

A ESTRATEGIAS

PROACTIVAS DE RIESGO -

Una estrategia considerablemente más inteligente para la administración del riesgo es ser proactivo. Una estrategia proactiva comienza mucho antes de iniciar el trabajo técnico. Los riesgos potenciales se identifican, su probabilidad e impacto se valoran y se clasifican por importancia. Luego, el equipo de software establece un plan para gestionar el riesgo. El objetivo principal es evitarlo, pero, dado que no todos los riesgos son evitables, el equipo trabaja para desarrollar un plan de contingencia que le permitirá responder en forma controlada y efectiva.

RIESGOS DE SOFTWARE: -

-

-

Los riesgos del proyecto amenazan el plan del proyecto, es decir, si los riesgos del proyecto se vuelven reales, es probable que el calendario del proyecto se deslice y que los costos aumenten. Los riesgos del proyecto identifican potenciales problemas de presupuesto, calendario, personal (tanto técnico como en la organización), recursos, participantes y requisitos, así como su impacto sobre un proyecto de software. Los riesgos empresariales amenazan la viabilidad del software que se va a construir y con frecuencia ponen en peligro el proyecto o el producto. Los candidatos para los cinco principales riesgos empresariales son: 1) Construir un producto o sistema excelente que realmente no se quiere (riesgo de mercado).


Página 20 de 61


2) Construir un producto que ya no encaje en la estrategia empresarial global de la compañía (riesgo estratégico). 3) Construir un producto que el equipo de ventas no sabe cómo vender (riesgo de ventas). 4) Perder el apoyo de los administradores debido a un cambio en el enfoque o en el personal (riesgo administrativo). 5) Perder apoyo presupuestal o de personal (riesgos presupuestales).

4. IDENTIFICACION DE RIESGOS: - Existen dos tipos de Riesgos:

- Riesgos Genéricos: Son una amenaza potencial a todo proyecto de software. - Riesgos Específicos: Solo pueden identificarse solamente por quienes tienen clara comprensión de la tecnología, el personal y el entorno específico del software que se construye. - Un método para identificar riesgos es crear una lista de verificación de ítem de riesgo. La lista de verificación puede usarse para identificación del riesgo y así enfocarse sobre algún subconjunto de riesgos conocidos y predecibles en las siguientes subcategorías genéricas:

-Tamaño del producto : riesgos asociados con el tamaño global del software que se va a construir o a modificar. -Impacto empresarial: riesgos asociados con restricciones impuestas por la administración o por el mercado. -Características de los participantes: riesgos asociados con la sofisticación de los participantes y con la habilidad de los desarrolladores para comunicarse con los participantes en forma oportuna. -Definición del proceso: riesgos asociados con el grado en el que se definió el proceso de software y la manera como se sigue por parte de la organización desarrolladora. -Entorno de desarrollo : riesgos asociados con la disponibilidad y calidad de las herramientas por usar para construir el producto. -Tecnología por construir : riesgos asociados con la complejidad del sistema que se va a construir y con lo “novedoso” de la tecnología que se incluye en el

sistema. -Tamaño y experiencia del personal : riesgos asociados con la experiencia técnica y de proyecto global de los ingenieros de software que harán el trabajo.


Página 21 de 61


5. PROYECCION DE RIESGO: -La proyección del riesgo, también llamada estimación del riesgo, intenta calificar cada riesgo en dos formas: 1) la posibilidad o probabilidad de que el riesgo sea real y 2) las consecuencias de los problemas asociados con el riesgo, en caso de que ocurra. Usted trabaja junto con otros gerentes y personal técnico para realizar cuatro pasos de proyección de riesgo: 1. Establecer una escala que refleje la probabilidad percibida de un riesgo. 2. Delinear las consecuencias del riesgo. 3. Estimar el impacto del riesgo sobre el proyecto y el producto. 4. Valorar la precisión global de la proyección del riesgo de modo que no habrá malos entendidos.

5.1. VALORACION DE IMPACTO:


Página 22 de 61

Universidad Nacional del Altiplano Planificación y Evaluación de Proyectos de Sistema Ingeniería del Software: Un enfoque práctico. Nota: 1) La consecuencia potencial de errores o fallos de software no detectados. 2) La consecuencia potencial si el resultado deseado no se alcanza.

5.2. ELABORACION DE UNA TABLA DE RIESGOS: - Una tabla de riesgos proporciona una técnica simple para proyección de riesgos. - Comenzamos en elaborar una lista de todos los riesgos en la columna de la tabla. Esto puede lograrse con la ayuda de listas de verificación. - Las categorías para cada uno de los cuatro componentes de riesgo (rendimiento, apoyo, costo y calendario).Una vez completadas las primeras

cuatro columnas de la tabla de riesgos, la tabla se ordena por probabilidad y por impacto.

-

Los riesgos de alta probabilidad y alto impacto se ubican en la parte superior de la tabla y los riesgos de baja probabilidad se ubican en el fondo. Esto logra una priorización de riesgo de primer orden.


Página 23 de 61


5.3. VALORACION DE IMPACTO DE RIESGO: -Identificación de riesgo: De hecho, sólo 70 por ciento de los componentes de software calendarizados para reusó se integrarán en la aplicación. La funcionalidad restante tendrá que desarrollarse a la medida. -Probabilidad del riesgo: Un 80 por ciento (probable). -Impacto del riesgo: Se planificaron 60 componentes de software reutilizables. Si sólo puede usarse 70 por ciento, tendrán que desarrollarse 18 componentes desde cero (además de otro software a la medida que se calendarizó para desarrollo). Dado que el componente promedio es de 100 LOC y que los datos locales indican que el costo de la ingeniería del software para cada LOC es US$14.00, el costo global (impacto) para desarrollar los componentes sería 18 X 100 X 14 = US$25 200. Exposición al riesgo. ER X 0.80 X 25 200 ~ US$20 200. - La exposición al riesgo puede calcularse para cada riesgo en la tabla de riesgo, una vez hecha la estimación del costo del riesgo. La exposición al riesgo total para todos los riesgos (arriba del corte en la tabla de riesgos) puede proporcionar los medios para ajustar la estimación del costo final para un proyecto. También puede usarse para predecir el aumento probable en recursos de personal requeridos en varios puntos durante el calendario del proyecto.

6. REFINAMIENTO DE RIESGO: - Durante las primeras etapas de la planificación del proyecto, un riesgo puede enunciarse de manera muy general. Conforme pasa el tiempo y se aprende más acerca del proyecto y de los riesgos, es posible refinar el riesgo en un conjunto de riesgos más detallados, cada uno un poco más sencillo de mitigar, monitorear y manejar. - Dado que todos los componentes de software reutilizables deben apegarse a estándares de diseño específicos y dado que algunos no se apegan, entonces existe preocupación de que (posiblemente) sólo 70 por ciento de los módulos reutilizables planeados puedan realmente integrarse en el sistema que se va a construir, lo que da como resultado la necesidad de ingeniería a la medida del restante 30 por ciento de los componentes. Esta condición general puede refinarse en la forma siguiente: Subcondición 1.- Ciertos componentes reutilizables los desarrolló una tercera persona sin conocimiento de los estándares de diseño internos.


Página 24 de 61


Subcondición 2.- El estándar de diseño para interfaces de componente todavía no se consolida y puede no apegarse a ciertos componentes reutilizables existentes. Subcondición 3.-Ciertos componentes reutilizables se implementaron en un lenguaje que no se so- porta en el entorno blanco.

7. MITIGACIÓN, MONITOREO Y MANEJO DE RIESGO: - Todas las actividades de análisis de riesgos presentadas hasta el momento tienen una sola meta: auxiliar al equipo del proyecto a desarrollar una estrategia para lidiar con el riesgo. Una estrategia efectiva debe considerar tres temas: 1) evitar el riesgo, 2) monitorear el riesgo y 3) manejar el riesgo y planificar la contingencia.

Para mitigar este riesgo se desarrollará una estrategia a fin de reducir la rotación. Entre los posibles pasos por tomar están:

-

-

-

Reunirse con el personal actual para determinar las causas de la rotación (por ejemplo, pobres condiciones laborales, salario bajo, mercado laboral competitivo). Mitigar aquellas causas que están bajo su control antes de comenzar el proyecto. Una vez iniciado el proyecto, suponer que la rotación ocurrirá y desarrollar técnicas para asegurar la continuidad cuando el personal se vaya. Organizar equipos de trabajo de modo que la información acerca de cada actividad de desarrollo se disperse ampliamente. Definir estándares de producto operativo y establecer mecanismos para asegurar que todos los modelos y documentos se desarrollen en forma oportuna. Realizar revisiones de pares de todo el trabajo (de modo que más de una persona “se ponga al día”). Asignar un miembro de personal de respaldo para cada técnico crítico.

8. EL PLAN MMMR: - En el plan de proyecto del software puede incluirse una estrategia de administración del riesgo, o los pasos de administración del riesgo pueden organizarse en un plan de mitigación, monitoreo y manejo de riesgo (MMMR) por separado. El plan MMMR documenta todo el trabajo realizado como parte del análisis de riesgos y el gerente del proyecto lo usa como parte del plan de proyecto global.


Página 25 de 61


MANTENIMIENTO Y REINGENIERA: -

-

-

-

-

-

-

-

-

Sin importar su dominio de aplicación, su tamaño o su complejidad, el software de computadora evolucionará con el tiempo. El cambio impulsa este proceso. Para el software de computadora, el cambio ocurre cuando se corrigen los errores, cuando el software se adapta a un nuevo entorno, cuando el cliente solicita nuevas características o funciones y cuando la aplicación se somete a reingeniería para ofrecer beneficio en un contexto moderno. Ley de cambio continuo (1974): El software que se implementó en un contexto de cómputo del mundo real y que, por tanto, evolucionará con el tiempo (llamados sistemas tipo E) debe adaptarse continuamente o de otro modo se volverá progresivamente menos satisfactorio. Ley de complejidad creciente (1974): Conforme un sistema tipo E evoluciona, su complejidad aumenta, a menos que se haga trabajo para mantenerlo o reducirlo. Ley de autorregulación (1974): El proceso de evolución del sistema tipo E es autorregulable con medidas de distribución de producto y de proceso cercanas a lo normal. Ley de conservación de estabilidad organizativa (1980): La tasa de actividad global efectiva promedio en un sistema tipo E en evolución no varía durante el tiempo de vida del producto. Ley de conservación de familiaridad (1980): Conforme un sistema tipo E evoluciona, todo lo asociado con él: desarrolladores, personal de ventas, usuarios, etc., deben mantener el dominio de su contenido y comportamiento para lograr evolución satisfactoria. El crecimiento excesivo disminuye dicho dominio. Por tanto, el crecimiento incremental promedio permanece sin variación conforme el sistema evoluciona. Ley de crecimiento continuo (1980): El contenido funcional de los sistemas tipo E debe aumentar continuamente para mantener la satisfacción del usuario durante su tiempo de vida. Ley de declive de la calidad (1996): La calidad de los sistemas tipo E declinará, a menos que se mantengan y adapten rigurosamente a los cambios del entorno operativo. Ley de realimentación del sistema (1996): Los procesos evolutivos tipo E constituyen sistemas de realimentación multinivel, multibucle y multiagente, y


Página 26 de 61


deben tratarse como tales para lograr mejora significativa sobre cualquier base razonable.

MANTENIMIENTO DE SOFTWARE: -

-

El mantenimiento comienza de inmediato una vez liberado el software a los usuarios finales y en cuestión de días reportan los errores que encontraron para inmediatamente se corrijan esos errores. En semanas, una clase de usuarios indica que el software debe cambiarse de modo que pueda ajustarse a las necesidades especiales de su entorno. Y en meses, otro grupo corporativo, que no quería saber nada del software cuando se liberó, ahora reconoce que puede ofrecerle beneficios inesperados. Necesitará algunas mejoras para hacer que funcione en su mundo.

SOPORTABILIDAD DEL SOFTWARE: -

-

Con la finalidad de dar soporte efectivo al software de grado industrial, su organización (o su encargado) deben poder realizar las correcciones, adaptaciones y mejoras que son parte de la actividad de mantenimiento. Pero, además, la organización debe proporcionar otras importantes actividades de soporte que incluyen soporte operativo en marcha, soporte al usuario final y actividades de reingeniería durante el ciclo de vida completo del software. Una definición razonable de soportabilidad del software es la capacidad de dar soporte a un sistema de software durante toda la vida del producto. Esto implica satisfacer cualquier necesidad o requisito, pero también provisión de equipo, infraestructura de soporte, software adicional, instalaciones, mano de obra o cualquier otro recurso requerido para mantener el software operativo y capaz de satisfacer su función [SSO08]. En esencia, la soportabilidad es uno de los muchos factores de calidad que deben considerarse durante las acciones de análisis y diseño que son parte del proceso de software. Deben abordarse como parte del modelo (o especificación) de requisitos y considerarse conforme el diseño evoluciona y comienza la construcción.

REINGENIERIA: -

En la actualidad, las principales compañías tienen decenas de miles de programas de cómputo que soportan las “antiguas reglas empresariales”. Conforme los administradores trabajan para modificar las reglas a fin de lograr mayor efectividad y competitividad, el software debe seguir- les el paso. En algunos casos, esto significa la creación de grandes y novedosos sistemas basados en cómputo. Pero en muchos otros, significa la modificación o reconstrucción de las aplicaciones existentes. En las secciones que siguen, se examina la reingeniería en una forma descendente, comenzando con un breve panorama de la reingeniería de los procesos de empresas y avanzando hacia un análisis más detallado de las actividades técnicas que ocurren cuando el software se somete a reingeniería.


Página 27 de 61


REINGENIERA DE PROCESOS DE EMPRESA: -

La reingeniería de procesos de empresa (RPE) se extiende más allá del ámbito de las tecnologías de la información y de la ingeniería de software. Entre las muchas definiciones (la mayoría un tanto abstractas) que se han sugerido para la RPE, “la búsqueda, e implementación, de cambios radicales en los procesos de las empresas para logr ar resultados innovadores”.

PROCESOS EMPRESARIALES: -

Un proceso empresarial es “un conjunto de tareas lógicamente relacionadas, que se realizan para lograr un resultado empresarial definido”. Dentro del

proceso empresarial, personal, equipo, recursos materiales y procedimientos empresariales se combinan para producir un resultado específico. Empresa → sistemas empresariales → procesos empresariales →

subprocesos empresariales.

-

-

Cada sistema empresarial (también llamado función empresarial) está compuesto de uno o más procesos empresariales, y cada proceso empresarial se define mediante un conjunto de subprocesos. La RPE puede aplicarse en cualquier nivel de la jerarquía, pero conforme se ensancha su ámbito (es decir, conforme se avanza hacia arriba en la jerarquía), los riesgos asociados con la RPE crecen de manera dramática. Por esta razón, la mayoría de los esfuerzos RPE se enfocan en procesos o subprocesos individuales.

MODELO RPE: -

Como la mayoría de las actividades de ingeniería, la reingeniería de procesos de empresa es iterativa. Las metas de la empresa y los procesos que los logran deben adaptarse a un entorno empresarial cambiante. Por esta razón, no hay inicio ni fin de la RPE: es un proceso evolutivo.


Página 28 de 61


REINGENIERIA DE SOFTWARE: -

-

Una aplicación que atendió las necesidades empresariales de una compañía durante 10 o 15 años. Durante ese tiempo se corrigió, adaptó y mejoró muchas veces un software. El software sin mantenimiento no es un problema nuevo. De hecho, el énfasis ampliado acerca de la reingeniería de software se produjo por los problemas de mantenimiento de software que se acumularon durante más de cuatro décadas.


Página 29 de 61


Un modelo de proceso de reingeniería de software: -

-

-

-

La reingeniería toma tiempo, cuesta cantidades significativas de dinero y absorbe recursos que de otro modo pueden ocuparse en preocupaciones inmediatas. Por todas estas razones, la reingeniería no se logra en pocos meses o incluso en algunos años. La reingeniería de los sistemas de información es una actividad que absorberá recursos de tecnología de la información durante muchos años. Por esto, toda organización necesita una estrategia pragmática para la reingeniería de software. En realidad nunca ha visto la propiedad, pero la adquirió a un precio sorprendentemente bajo, con la advertencia de que es posible que deba reconstruirla por completo. ¿Cómo procedería? Antes de comenzar a reconstruir, parecería razonable inspeccionar la casa. Para determinar si necesita reconstruirse, usted (o un inspector profesional) crea una lista de criterios, de modo que su inspección sea sistemática. Antes de demoler y reconstruir toda la casa, asegúrese de que la estructura es débil. Si la casa es estructuralmente sólida, acaso sea posible “remodelar” sin reconstruir (a un costo mucho más bajo y en mucho menos tiempo).

-

Antes de comenzar a reconstruir, asegúrese de entender cómo se construyó la original. Eche un vistazo detrás de las paredes. Entienda cómo están el alambrado, la plomería y la estructura interna. Incluso si tira todo a la basura, la comprensión que obtenga le servirá cuando comience la construcción.

-

Si comienza a reconstruir, use solamente los materiales más modernos y más duraderos. Esto puede costar un poco más ahora, pero le ayudará a evitar costos y tardados mantenimientos posteriores.

-

Si decide reconstruir, sea disciplinado en ello. Use prácticas que resultarán en alta calidad, hoy y en el futuro.

-

Aunque estos principios se enfocan en la reconstrucción de una casa se


Página 30 de 61


aplican igualmente bien a la reingeniería de los sistemas y aplicaciones basados en cómputo.

Actividades de reingeniería de software: -

-

Análisis de inventarios: Toda organización de software debe tener un

inventario de todas las aplicaciones. El inventario puede ser nada más que un modelo de hojas de cálculo que contenga información que ofrezca una descripción detallada (por ejemplo, tamaño, edad, importancia empresarial) de cada aplicación activa. Reestructuración de documentos: La documentación débil es el distintivo de muchos sistemas heredados. Pero, ¿qué puede hacer con ella? ¿Cuáles son sus opciones? 1. La creación de documentación consume demasiado tiempo. Si el sistema funciona puede elegir vivir con lo que tiene. En algunos casos, éste es el enfoque correcto. No es posible volver a crear documentación para cientos de programas de cómputo. 2. La documentación debe actualizarse, pero su organización tiene recursos limitados. Use un enfoque “documente cuando toque”. Acaso no sea necesario

volver a documentar por completo una aplicación. En vez de ello, aquellas porciones del sistema que en el momento experimenten cambio se documentan por completo. 3. El sistema tiene importancia empresarial y debe volver a documentarse por completo. - Ingeniera Inversa: - La ingeniería inversa para software es el proceso de analizar un programa con la intención de crear una representación del mismo en un nivel superior de abstracción que el código fuente. La ingeniería inversa es un proceso de recuperación de diseño. Las herramientas de ingeniería inversa extraen información de diseño de datos, arquitectónico y procedimental de un programa existente. - Reestructuración de código: - Para realizar esta actividad se analiza el código fuente con una herramienta de reestructuración. Las violaciones a los constructos de programación estructurada se anotan y luego el código se reestructura (esto puede hacerse automáticamente) o incluso se reescribe en un lenguaje de programación más moderno. El código reestructurado resultante se revisa y pone a prueba para garantizar que no se introdujeron anomalías. La documentación de código interna se actualiza. - Reestructuración de datos:


Página 31 de 61


- Un programa con arquitectura de datos débil será difícil de adaptar y mejorar. De hecho, para muchas aplicaciones, la arquitectura de información tiene más que ver con la viabilidad a largo plazo de un programa que con el código fuente en sí.

INGENIERA INVERSA: -

-

La ingeniería inversa puede extraer información de diseño a partir del código fuente, pero el nivel de abstracción, la completitud de la documentación, el grado en el que las herramientas y un analista humano trabajan en conjunto, y la direccionalidad del proceso son enormemente variables. El nivel de abstracción de un proceso de ingeniería inversa y las herramientas usadas para efectuarla tienen que ver con la sofisticación de la información de diseño que puede extraerse del código fuente. De manera ideal, el nivel de abstracción debe ser tan alto como sea posible, es decir, el proceso de ingeniería inversa debe ser capaz de inferir representaciones de diseño procedimental (una abstracción de bajo nivel), información de estructura de programa y datos (un nivel de abstracción un poco más alto), modelos de objeto, modelos de datos y/o flujo de control (un nivel de abstracción relativamente alto) y modelos de relación de entidad (un nivel de abstracción alto). Conforme aumenta el nivel de abstracción se proporciona información que permitirá facilitar la comprensión del programa.


Página 32 de 61


-

Proceso de Ingeniería Inversa:


Página 33 de 61


Ingeniería inversa para comprender datos: -

-

La ingeniería inversa de datos ocurre en diferentes niveles de abstracción y con frecuencia es la primera tarea de reingeniería. En el nivel del programa, las estructuras de datos internas del programa con frecuencia deben someterse a ingeniería inversa como parte de un esfuerzo de reingeniería global. En el nivel del sistema, las estructuras de datos globales con frecuencia se someten a reingeniería para acomodar nuevos paradigmas de administración de base de datos. La ingeniería inversa de las estructuras de datos globales actuales monta el escenario para la introducción de una nueva base de datos en todo el sistema.

Ingeniería inversa para entender el procesamiento: -

-

-

La ingeniería inversa para entender el procesamiento comienza con un intento por comprender y luego extraer abstracciones procedimentales representadas mediante el código fuente. Para comprender las abstracciones procedimentales se analiza el código en varios niveles de abstracción: sistema, programa, componente, patrón y enunciado. Para sistemas grandes, la ingeniería inversa por lo general se logra usando un enfoque semiautomatizado. Es posible usar herramientas automatizadas para auxiliarse en la comprensión de la semántica del código existente. La salida de este proceso pasa entonces a reestructuración de herramientas de ingeniería hacia adelante a fin de completar el proceso de reingeniería.

Ingeniería inversa de interfaces de usuario: -

Las GUI (interfaces de usuario gráficas) sofisticadas se han vuelto obligatorias para productos y sistemas basados en computadora de todo tipo. Por tanto, el redesarrollo de las interfaces de usuario se ha convertido en uno de los tipos más comunes de actividad de reingeniería. Pero antes de poder reconstruir una interfaz de usuario, debe realizarse ingeniería inversa.

REESTRUCTURACION: -

-

La reestructuración de software modifica el código fuente y/o los datos con la intención de hacerlos sensibles a cambios futuros. En general, la reestructuración no modifica la arquitectura global del programa. La reestructuración ocurre cuando la arquitectura básica de una aplicación es sólida, aun cuando el interior técnico necesite trabajarse. Se inicia cuando grandes partes del software son aprovechables y sólo un subconjunto de todos los módulos y datos necesitan modificación extensa.

Reestructuración de código: -

La reestructuración de código se realiza para producir un diseño que produzca la misma función pero con mayor calidad que el programa original.


Página 34 de 61


Reestructuración de datos: -

Antes de que pueda comenzar la reestructuración de datos debe realizarse una actividad de ingeniería inversa llamada análisis de código fuente. La intención es extraer ítems de datos y objetos, obtener información acerca del flujo de datos y entender las estructuras de datos existentes que se implementaron. Esta actividad en ocasiones se llama análisis de datos.

INGENIERÍA HACIA ADELANTE: -

-

-

Para implementar los cambios necesarios puede luchar a través de modificación tras modificación, combatir al diseño ad hoc y el código fuente enredado. Puede intentar comprender los funcionamientos interiores más amplios del programa con la intención de hacer modificaciones de manera más efectiva. Puede rediseñar, recodificar y poner a prueba aquellas porciones del software que requieran modificación y aplicar un enfoque de ingeniería de software a todos los segmentos revisados. Puede rediseñar, recodificar y poner a prueba completamente el programa, y usar herramientas de reingeniería para ayudar a comprender el diseño actual.

Ingeniería hacia adelante para arquitecturas cliente-servidor: -

-

En esencia, los recursos de cómputo centralizados (incluido el software) se distribuyen entre muchas plataformas cliente. Aunque pueden diseñarse varios entornos distribuidos, la aplicación mainframe típica que se somete a reingeniería en una arquitectura cliente-servidor tiene las siguientes características: La funcionalidad de la aplicación migra a cada computadora cliente. Se implementan nuevas interfaces GUI en los sitios cliente. Las funciones de base de datos se ubican en el servidor. La funcionalidad especializada (por ejemplo, análisis con uso intenso de computadora) puede permanecer en el sitio servidor. Deben establecerse nuevos requisitos de comunicaciones, seguridad, archivado y control en los sitios cliente y servidor.

Ingeniería hacia adelante para arquitecturas orientadas a objetos: -

La ingeniería de software orientada a objetos se ha convertido en el paradigma de desarrollo elegido por muchas organizaciones de software. La reingeniería de software convencional en una implementación orientada a objeto usa muchas de las mismas técnicas estudiadas.

ECONOMÍA DE LA REINGENIERÍA: -

Todo programa no mantenible se retiraría de inmediato para sustituirlo con aplicaciones sometidas a reingeniería de alta calidad desarrolladas mediante modernas prácticas de ingeniería de software. Pero se vive en un mundo de


Página 35 de 61


-

recursos limitados. La reingeniería gasta recursos que pueden usarse para otros propósitos empresariales. Sneed propone un modelo de análisis costo-beneficio para reingeniería, definiendo nueve parámetros:

-

El costo asociado con el mantenimiento continuo de una aplicación candidata (es decir, la reingeniería no se realiza) puede definirse como:

-

El costo asociado con reingeniería se define usando la siguiente relación:

-

Con los costos presentados en las ecuaciones antes mencionadas, el beneficio global de la reingeniería puede calcularse como:


Página 36 de 61


CAPITULO 26: ESTIMACION PROYECTOS DE SOFTWARE

PARA

26.1 Observaciones acerca de las estimaciones La administración de proyectos de Software es un conjunto de actividades colectivas llamado “Planificación de Proyectos”. Antes de que pueda comenzar dicha

planificación se debe estimar el trabajo, recurso completo dichas actividades el equipo

y tiempo a utilizarlos, una vez

de software debe establecer un calendario

(hitos y tareas) además identificar un responsable de ellas.

26.2 El proceso de planificación del proyecto Es proporcionar un marco conceptual al gerente para realizar estimaciones de recursos, costo y calendario .donde además de ello se debe definir el escenario de mejor y peor caso.

26.3 Ámbito y factibilidad del software El ámbito de software es la entrega del producto a los usuarios donde se describe las funciones y características de ello, para eso se usan una de las dos técnicas. 



Una descripción narrativa del ámbito del software se desarrolla después de la comunicación con todos los participantes. Los usuarios finales desarrollan un conjunto de casos de uso.


Página 37 de 61


26.4 Recursos

26.4.1 Recursos Humanos El planificador comienza por evaluar el número de personas a utilizase en el proyecto y las habilidades que poseen cada una de ellas, se clasifican en: posición organizacional (por ejemplo, gerente, ingeniero de software ejecutivo) como la especialidad (por ejemplo, telecomunicaciones, base de datos, cliente-servidor). La ubicación varía dependiendo del tamaño del proyecto.

26.4.2 Recursos de software Reutilizable La Ing. de Software se basa en componentes ISBC donde se pone énfasis a la creación

y reutilización de bloques de software donde se divide en

categorías: 

Componentes COTS: Se adquieren de proyectos anteriores y se compran de

terceros


Página 38 de 61


Componentes Experiencia Completa: Son especificaciones, diseños, código o

datos de prueba existentes, desarrollados para proyectos anteriores que son similares al software que se va a construir Por tanto, las modificaciones requeridas para los componentes de experiencia completa tendrán un riesgo relativamente bajo. 

Componentes de Experiencias Parcial: Son especificaciones, diseños, código

o datos de prueba existentes, desarrollados para proyectos anteriores que se relacionan con el software Por tanto, requerirán de

modificaciones

sustanciales y tendrán un riesgo relativamente alto. 

Componentes Nuevos: Son especialmente desarrollados para el Proyecto

26.4.3 Recursos Ambientales

26.5 Estimación de proyectos de software La estimación no es una ciencia exacta existen variables pueden afectar su costo: Para ello se realiza una serie de pasos sistemáticos 

 



Retrase la estimación hasta avanzado el proyecto (obviamente, ¡puede lograr estimaciones 100 por ciento precisas después de que el proyecto esté completo!). Base las estimaciones en proyectos similares que ya estén completos. Use técnicas de descomposición relativamente simples para generar estimaciones de costo y esfuerzo de proyecto. Use uno o más modelos empíricos empíricos para estimación estimación de costo y esfuerzo de software.

En tales pasos sistemáticos se describen características de la organización de desarrollo y el software que se va a desarrollar.

26.6 Técnicas de descomposición 26.6.1 Dimensionamiento de software 26.6.2 Estimación basada en el problema Las estimaciones de LCD y PF son técnicas de estimación distintas. A pesar de que ambas tienen varias características en común. el planificador del proyecto comienza con un enfoque limitado para el ámbito del software y de este estado intenta descomponer el software en funciones que se puedan estimar individualmente.


Página 39 de 61


26.6.3 Estimación basada en proceso La técnica mas común para estimar un proyecto es basar la estimación en el proceso que se va a utilizar. Es decir el proceso se descompone en un conjunto relativamente pequeño de actividades o tareas y en el esfuerzo requerido para llevar a cabo la estimación de cada tarea. Para cada función se debe llevar a cabo una serie de actividades del proceso del software, una vez que se mezclan las funciones del problema y las actividades del proceso, el planificador estima el esfuerzo que se requeriría para llevar a cabo cada una de las actividades del proceso del software en cada función.


Página 40 de 61


CAPITULO 27: PROYECTO

CALENDARIZACION

DE

27.1 Conceptos básicos La Calendarización es una actividad que distribuye estimaciones de esfuerzo a través de la duración planificada del proyecto al esfuerzo de asignar tareas específicas de ingerirá.

27.2 Calendarización de proyecto 27.2.1 Principios básicos 

Compartimentación

El proyecto debe dividirse en compartimentos en varias actividades, acciones y tareas manejables. 

Interdependencia

Se debe determinar la interdependencia de cada actividad, acción o tarea compartimentada. 

Asignación de tiempo

A cada tarea se le debe asignar cierto número de unidades de trabajo (Ej: personas-día de esfuerzo) 

Definiciones responsabilidades

Asignar un miembro del equipo 

Definición de resultados

Toda tarea debe tener un resultado definido. (Ej: Diseño de un módulo) 

Definición de hitos

(significa tener un logro importante): Cualquier tarea o grupo de tareas debe estar asociado con un hito de proyecto. Un hito se logra cuando se ha revisado la calidad de uno o mas productos de trabajo y se ha aprobado.

27.4 Definición de una red de tareas tareas Muestra las principales tareas de la ing de software, sus dependencias y si se pueden ejecutar en paralelo


Página 41 de 61


27.5 Calendarización Pueden utilizar técnicas/herramientas calendarización de proyectos: 

PERT (Técnica de evaluación y revisión de programa)



CPM (Método de la Ruta Crítica)



Identificar todas las actividades que involucra el proyecto, lo que significa, determinar relaciones de precedencia, tiempos técnicos para cada una de las actividades.



Construir una red con base en nodos y actividades (o arcos, según el método más usado), que implican el proyecto.

27.5.1 Cronograma Diagrama de Gantt: Muestra la programación vs tiempo calendario. Uno por proyecto ó uno por cada función.

Diamantes (rombos) marcan

hitos.


Página 42 de 61


27.5.2 Seguimiento de Calendario Realizar reuniones periódicas del estado del proyecto, en las que cada miembro del equipo reporte avances y problemas 

Evaluar los resultados de todas las revisiones realizadas a través del proceso de ingeniería del software



Determinar si los hitos formales del proyecto (los diamantes que se muestran en la figura 27.3) se lograron en la fecha prevista



Comparar la fecha de inicio real con la fecha de inicio planeada para cada tarea de proyecto mencionada en la tabla de recursos (figura 27.4)



Reunirse informalmente con los profesionales para obtener su valoración subjetiva del avance a la fecha y los problemas en el horizonte



Usar análisis de valor ganado para valorar cuantitativamente el avance

27.5.3 Seguimiento de procesos para un proyecto Hitos técnicos: análisis OO completo 

Definición y revisión de todas las clases y de la jerarquía de clases.



Definición y revisión de los atributos de clase y de las operaciones asociadas.


Página 43 de 61


Establecimiento y revisión de las relaciones de clase (capítulo 6).



Creación y revisión de un modelo de comportamiento (capítulo 7).



Anotación de las clases reutilizables.

Hitos técnicos: diseño OO completo 

Definición y revisión del conjunto de subsistemas.



Asignación de clases a subsistemas y su revisión.

Establecimiento y revisión de la asignación de tareas. 

Identificación de responsabilidades y colaboraciones.



Diseño y revisión de atributos y operaciones.



Creación y revisión del modelo de comunicación.

Hitos técnicos: programación OO completa 

Implementación en código de cada nueva clase, a partir del modelo de diseño.



Implementación de las clases extraídas (a partir de la librería de reutilización).



Construcción de prototipo o incremento.


Página 44 de 61


CAP 28 : ADMINITRACION DE RIESGO Tomar medidas proactivas para evitarlos o manejarlos son elementos clave de una buena administración de proyecto de software.

28.1 ADMINISTRACION DE RIESGO: -

-

-

-

El análisis y la administración del riesgo son acciones que ayudan al equipo de software a entender y manejar la incertidumbre. Muchos problemas pueden plagar un proyecto de software. Un riesgo es un problema potencial: puede ocurrir, puede no ocurrir. Pero, sin importar el resultado, realmente es una buena idea identificarlo, valorar su probabilidad de ocurrencia, estimar su impacto y establecer un plan de contingencia para el caso de que el problema realmente ocurra. Todos los involucrados en el proceso de software (gerentes, ingenieros de software y otros interesados) participan en el análisis y la administración del riesgo. El software es una empresa difícil. Muchas cosas pueden salir mal y, francamente, muchas con frecuencia lo hacen. Por esta razón es que estar preparado, comprender los riesgos y llamado “identificación de riesgos”. A continuación, cada riesgo se analiza para determinar la probabilidad de que ocurra y el daño que causará si ocurre. Una vez establecida esta información se clasifican los riesgos, por probabilidad e impacto. Finalmente, se desarrolla un plan para manejar aquellos que tengan alta probabilidad y alto impacto. Se produce un plan para mitigar, monitorear y manejar el riesgo (MMMR) o un conjunto de hojas de información de riesgo. El MMMR debe revisarse conforme avance el proyecto para asegurarse de que los riesgos se mantienen actualizados. Los planes de contingencia para administración del riesgo deben ser realistas.

28.4 ESTRATEGIAS REACTIVAS DE RIESGO FRENTE A ESTRATEGIAS PROACTIVAS DE RIESGO -

Una estrategia considerablemente más inteligente para la administración del riesgo es ser proactivo. Una estrategia proactiva comienza mucho antes de iniciar el trabajo técnico. Los riesgos potenciales se identifican, su probabilidad e impacto se valoran y se clasifican por importancia. Luego, el equipo de software establece un plan para gestionar el riesgo. El objetivo principal es evitarlo, pero, dado que no todos los riesgos son evitables, el equipo trabaja para desarrollar un plan de contingencia que le permitirá responder en forma controlada y efectiva.

28.3 RIESGOS DE SOFTWARE: -

-

Los riesgos del proyecto amenazan el plan del proyecto, es decir, si los riesgos del proyecto se vuelven reales, es probable que el calendario del proyecto se deslice y que los costos aumenten. Los riesgos del proyecto identifican potenciales problemas de presupuesto, calendario, personal (tanto técnico como en la organización), recursos, participantes y requisitos, así como su impacto sobre un proyecto de software.


Página 45 de 61


-

Los riesgos empresariales amenazan la viabilidad del software que se va a construir y con frecuencia ponen en peligro el proyecto o el producto. Los candidatos para los cinco principales riesgos empresariales son: 1) Construir un producto o sistema excelente que realmente no se quiere (riesgo de mercado). 2) Construir un producto que ya no encaje en la estrategia empresarial global de la compañía (riesgo estratégico). 3) Construir un producto que el equipo de ventas no sabe cómo vender (riesgo de ventas). 4) Perder el apoyo de los administradores debido a un cambio en el enfoque o en el personal (riesgo administrativo). 5) Perder apoyo presupuestal o de personal (riesgos presupuestales).

28.4 IDENTIFICACION DE RIESGOS: - Existen dos tipos de Riesgos:

28.4.1 Riesgos Genéricos: Son una amenaza potencial a todo proyecto de software.

28.4.2 Riesgos Específicos: Solo pueden identificarse solamente por quienes tienen clara comprensión de la tecnología, el personal y el entorno específico del software que se construye. - Un método para identificar riesgos es crear una lista de verificación de ítem de riesgo. La lista de verificación puede usarse para identificación del riesgo y así enfocarse sobre algún subconjunto de riesgos conocidos y predecibles en las siguientes subcategorías genéricas:

28.4.3 Tamaño del producto: riesgos asociados con el tamaño global del software que se va a construir o a modificar.

28.4.4 Impacto empresarial: riesgos asociados con restricciones impuestas por la administración o por el mercado.

28.4.5 Características de los participantes: riesgos asociados con la sofisticación de los participantes y con la habilidad de los desarrolladores para comunicarse con los participantes en forma oportuna.

28.5.6 Definición del proceso: riesgos asociados con el grado en el que se definió el proceso de software y la manera como se sigue por parte de la organización desarrolladora.

28.5.7 Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad de las herramientas por usar para construir el producto.


Página 46 de 61


28.5.8 Tecnología por construir: riesgos asociados con la complejidad del sistema que se va a construir y con lo “novedoso” de la tecnología que se incluye en el sistema.

28.5.9 Tamaño y experiencia del personal: riesgos asociados con la experiencia técnica y de proyecto global de los ingenieros de software que harán el trabajo.

28.5 PROYECCION DE RIESGO: -La proyección del riesgo, también llamada estimación del riesgo, intenta calificar cada riesgo en dos formas: 1) la posibilidad o probabilidad de que el riesgo sea real y 2) las consecuencias de los problemas asociados con el riesgo, en caso de que ocurra. Usted trabaja junto con otros gerentes y personal técnico para realizar cuatro pasos de proyección de riesgo: 1. Establecer una escala que refleje la probabilidad percibida de un riesgo. 2. Delinear las consecuencias del riesgo. 3. Estimar el impacto del riesgo sobre el proyecto y el producto. 4. Valorar la precisión global de la proyección del riesgo de modo que no habrá malos entendidos.


Página 47 de 61


28.5 .1. VALORACION DE IMPACTO: Nota:

1) La consecuencia potencial de errores o fallos de software no detectados. 2) La consecuencia potencial si el resultado deseado no se alcanza.

28.5.2. ELABORACION DE UNA TABLA DE RIESGOS: - Una tabla de riesgos proporciona una técnica simple para proyección de riesgos.


Página 48 de 61


- Comenzamos en elaborar una lista de todos los riesgos en la columna de la tabla. Esto puede lograrse con la ayuda de listas de verificación. - Las categorías para cada uno de los cuatro componentes de riesgo (rendimiento, apoyo, costo y calendario).Una vez completadas las primeras

cuatro columnas de la tabla de riesgos, la tabla se ordena por probabilidad y por impacto.

-

Los riesgos de alta probabilidad y alto impacto se ubican en la parte superior de la tabla y los riesgos de baja probabilidad se ubican en el fondo. Esto logra una priorización de riesgo de primer orden.

28.5 .3. VALORACION DE IMPACTO DE RIESGO: -Identificación de riesgo: De hecho, sólo 70 por ciento de los componentes de software calendarizados para reusó se integrarán en la aplicación. La funcionalidad restante tendrá que desarrollarse a la medida. -Probabilidad del riesgo: Un 80 por ciento (probable). -Impacto del riesgo: Se planificaron 60 componentes de software reutilizables. Si sólo puede usarse 70 por ciento, tendrán que desarrollarse 18 componentes desde cero (además de otro software a la medida que se calendarizó para desarrollo). Dado que el componente promedio es de 100 LOC y que los datos


Página 49 de 61


locales indican que el costo de la ingeniería del software para cada LOC es US$14.00, el costo global (impacto) para desarrollar los componentes sería 18 X 100 X 14 = US$25 200. Exposición al riesgo. ER X 0.80 X 25 200 ~ US$20 200. - La exposición al riesgo puede calcularse para cada riesgo en la tabla de riesgo, una vez hecha la estimación del costo del riesgo. La exposición al riesgo total para todos los riesgos (arriba del corte en la tabla de riesgos) puede proporcionar los medios para ajustar la estimación del costo final para un proyecto. También puede usarse para predecir el aumento probable en recursos de personal requeridos en varios puntos durante el calendario del proyecto.

28.6 REFINAMIENTO DE RIESGO: - Durante las primeras etapas de la planificación del proyecto, un riesgo puede enunciarse de manera muy general. Conforme pasa el tiempo y se aprende más acerca del proyecto y de los riesgos, es posible refinar el riesgo en un conjunto de riesgos más detallados, cada uno un poco más sencillo de mitigar, monitorear y manejar. - Dado que todos los componentes de software reutilizables deben apegarse a estándares de diseño específicos y dado que algunos no se apegan, entonces existe preocupación de que (posiblemente) sólo 70 por ciento de los módulos reutilizables planeados puedan realmente integrarse en el sistema que se va a construir, lo que da como resultado la necesidad de ingeniería a la medida del restante 30 por ciento de los componentes. Esta condición general puede refinarse en la forma siguiente: Subcondición 1.- Ciertos componentes reutilizables los desarrolló una tercera persona sin conocimiento de los estándares de diseño internos. Subcondición 2.- El estándar de diseño para interfaces de componente todavía no se consolida y puede no apegarse a ciertos componentes reutilizables existentes. Subcondición 3.-Ciertos componentes reutilizables se implementaron en un lenguaje que no se so- porta en el entorno blanco.

28.7 MITIGACIÓN, MONITOREO Y MANEJO DE RIESGO: - Todas las actividades de análisis de riesgos presentadas hasta el momento tienen una sola meta: auxiliar al equipo del proyecto a desarrollar una estrategia para lidiar con el riesgo. Una estrategia efectiva debe considerar tres


Página 50 de 61


temas: 1) evitar el riesgo, 2) monitorear el riesgo y 3) manejar el riesgo y planificar la contingencia.

Para mitigar este riesgo se desarrollará una estrategia a fin de reducir la rotación. Entre los posibles pasos por tomar están:

-

-

-

Reunirse con el personal actual para determinar las causas de la rotación (por ejemplo, pobres condiciones laborales, salario bajo, mercado laboral competitivo). Mitigar aquellas causas que están bajo su control antes de comenzar el proyecto. Una vez iniciado el proyecto, suponer que la rotación ocurrirá y desarrollar técnicas para asegurar la continuidad cuando el personal se vaya. Organizar equipos de trabajo de modo que la información acerca de cada actividad de desarrollo se disperse ampliamente. Definir estándares de producto operativo y establecer mecanismos para asegurar que todos los modelos y documentos se desarrollen en forma oportuna. Realizar revisiones de pares de todo el trabajo (de modo que más de una persona “se ponga al día”). Asignar un miembro de personal de respaldo para cada técnico crítico.

28.8 EL PLAN MMMR: - En el plan de proyecto del software puede incluirse una estrategia de administración del riesgo, o los pasos de administración del riesgo pueden organizarse en un plan de mitigación, monitoreo y manejo de riesgo (MMMR) por separado. El plan MMMR documenta todo el trabajo realizado como parte del análisis de riesgos y el gerente del proyecto lo usa como parte del plan de proyecto global.


Página 51 de 61


CAP 29: MANTENIMIENTO Y REINGENIERIA 29.1 MANTENIMIENTO Y REINGENIERA: -

-

-

-

-

-

-

-

-

Sin importar su dominio de aplicación, su tamaño o su complejidad, el software de computadora evolucionará con el tiempo. El cambio impulsa este proceso. Para el software de computadora, el cambio ocurre cuando se corrigen los errores, cuando el software se adapta a un nuevo entorno, cuando el cliente solicita nuevas características o funciones y cuando la aplicación se somete a reingeniería para ofrecer beneficio en un contexto moderno. Ley de cambio continuo (1974): El software que se implementó en un contexto de cómputo del mundo real y que, por tanto, evolucionará con el tiempo (llamados sistemas tipo E) debe adaptarse continuamente o de otro modo se volverá progresivamente menos satisfactorio. Ley de complejidad creciente (1974): Conforme un sistema tipo E evoluciona, su complejidad aumenta, a menos que se haga trabajo para mantenerlo o reducirlo. Ley de autorregulación (1974): El proceso de evolución del sistema tipo E es autorregulable con medidas de distribución de producto y de proceso cercanas a lo normal. Ley de conservación de estabilidad organizativa (1980): La tasa de actividad global efectiva promedio en un sistema tipo E en evolución no varía durante el tiempo de vida del producto. Ley de conservación de familiaridad (1980): Conforme un sistema tipo E evoluciona, todo lo asociado con él: desarrolladores, personal de ventas, usuarios, etc., deben mantener el dominio de su contenido y comportamiento para lograr evolución satisfactoria. El crecimiento excesivo disminuye dicho dominio. Por tanto, el crecimiento incremental promedio permanece sin variación conforme el sistema evoluciona. Ley de crecimiento continuo (1980): El contenido funcional de los sistemas tipo E debe aumentar continuamente para mantener la satisfacción del usuario durante su tiempo de vida. Ley de declive de la calidad (1996): La calidad de los sistemas tipo E declinará, a menos que se mantengan y adapten rigurosamente a los cambios del entorno operativo. Ley de realimentación del sistema (1996): Los procesos evolutivos tipo E constituyen sistemas de realimentación multinivel, multibucle y multiagente, y deben tratarse como tales para lograr mejora significativa sobre cualquier base razonable.

29.2 MANTENIMIENTO DE SOFTWARE: -

-

El mantenimiento comienza de inmediato una vez liberado el software a los usuarios finales y en cuestión de días reportan los errores que encontraron para inmediatamente se corrijan esos errores. En semanas, una clase de usuarios indica que el software debe cambiarse de modo que pueda ajustarse a las necesidades especiales de su entorno. Y en meses, otro grupo corporativo, que no quería saber nada del software cuando se liberó, ahora reconoce que puede ofrecerle beneficios inesperados. Necesitará algunas mejoras para hacer que funcione en su mundo.


Página 52 de 61


29.3 SOPORTABILIDAD DEL SOFTWARE: -

-

Con la finalidad de dar soporte efectivo al software de grado industrial, su organización (o su encargado) deben poder realizar las correcciones, adaptaciones y mejoras que son parte de la actividad de mantenimiento. Pero, además, la organización debe proporcionar otras importantes actividades de soporte que incluyen soporte operativo en marcha, soporte al usuario final y actividades de reingeniería durante el ciclo de vida completo del software. Una definición razonable de soportabilidad del software es la capacidad de dar soporte a un sistema de software durante toda la vida del producto. Esto implica satisfacer cualquier necesidad o requisito, pero también provisión de equipo, infraestructura de soporte, software adicional, instalaciones, mano de obra o cualquier otro recurso requerido para mantener el software operativo y capaz de satisfacer su función [SSO08]. En esencia, la soportabilidad es uno de los muchos factores de calidad que deben considerarse durante las acciones de análisis y diseño que son parte del proceso de software. Deben abordarse como parte del modelo (o especificación) de requisitos y considerarse conforme el diseño evoluciona y comienza la construcción.

29.4 REINGENIERIA: -

En la actualidad, las principales compañías tienen decenas de miles de programas de cómputo que soportan las “antiguas reglas empresariales”. Conforme los administradores trabajan para modificar las reglas a fin de lograr mayor efectividad y competitividad, el software debe seguir- les el paso. En algunos casos, esto significa la creación de grandes y novedosos sistemas basados en cómputo. Pero en muchos otros, significa la modificación o reconstrucción de las aplicaciones existentes. En las secciones que siguen, se examina la reingeniería en una forma descendente, comenzando con un breve panorama de la reingeniería de los procesos de empresas y avanzando hacia un análisis más detallado de las actividades técnicas que ocurren cuando el software se somete a reingeniería.

29.5 REINGENIERA DE PROCESOS DE EMPRESA: -

La reingeniería de procesos de empresa (RPE) se extiende más allá del ámbito de las tecnologías de la información y de la ingeniería de software. Entre las muchas definiciones (la mayoría un tanto abstractas) que se han sugerido para la RPE, “la búsqueda, e implementación, de cambios radicales en los procesos de las empresas para lograr resultados innovadores”.

29.5.1 PROCESOS EMPRESARIALES: -

Un proceso empresarial es “un conjunto de tareas lógicamente relacionadas, que se realizan para lograr un resultado empresarial definido”. Dentro del


Página 53 de 61


proceso empresarial, personal, equipo, recursos materiales y procedimientos empresariales se combinan para producir un resultado específico. Empresa → sistemas empresariales → procesos empresariales →

subprocesos empresariales.

-

Cada sistema empresarial (también llamado función empresarial) está compuesto de uno o más procesos empresariales, y cada proceso empresarial se define mediante un conjunto de subprocesos.

-

La RPE puede aplicarse en cualquier nivel de la jerarquía, pero conforme se ensancha su ámbito (es decir, conforme se avanza hacia arriba en la jerarquía), los riesgos asociados con la RPE crecen de manera dramática. Por esta razón, la mayoría de los esfuerzos RPE se enfocan en procesos o subprocesos individuales.

29.6 MODELO RPE: -

Como la mayoría de las actividades de ingeniería, la reingeniería de procesos de empresa es iterativa. Las metas de la empresa y los procesos que los logran deben adaptarse a un entorno empresarial cambiante. Por esta razón, no hay inicio ni fin de la RPE: es un proceso evolutivo.


Página 54 de 61


29.7 REINGENIERIA DE SOFTWARE: -

-

Una aplicación que atendió las necesidades empresariales de una compañía durante 10 o 15 años. Durante ese tiempo se corrigió, adaptó y mejoró muchas veces un software. El software sin mantenimiento no es un problema nuevo. De hecho, el énfasis ampliado acerca de la reingeniería de software se produjo por los problemas de mantenimiento de software que se acumularon durante más de cuatro décadas.

29.8 Un modelo de proceso de reingeniería de software: -

-

-

-

La reingeniería toma tiempo, cuesta cantidades significativas de dinero y absorbe recursos que de otro modo pueden ocuparse en preocupaciones inmediatas. Por todas estas razones, la reingeniería no se logra en pocos meses o incluso en algunos años. La reingeniería de los sistemas de información es una actividad que absorberá recursos de tecnología de la información durante muchos años. Por esto, toda organización necesita una estrategia pragmática para la reingeniería de software. En realidad nunca ha visto la propiedad, pero la adquirió a un precio sorprendentemente bajo, con la advertencia de que es posible que deba reconstruirla por completo. ¿Cómo procedería? Antes de comenzar a reconstruir, parecería razonable inspeccionar la casa. Para determinar si necesita reconstruirse, usted (o un inspector profesional) crea una lista de criterios, de modo que su inspección sea sistemática. Antes de demoler y reconstruir toda la casa, asegúrese de que la estructura es débil. Si la casa es estructuralmente sólida, acaso sea posible “remodelar” sin reconstruir (a un costo mucho más bajo y en mucho menos tiempo).

-

Antes de comenzar a reconstruir, asegúrese de entender cómo se construyó la original. Eche un vistazo detrás de las paredes. Entienda cómo están el alambrado, la plomería y la estructura interna. Incluso si tira todo a la basura, la comprensión que obtenga le servirá cuando comience la construcción.

-

Si comienza a reconstruir, use solamente los materiales más modernos y más duraderos. Esto puede costar un poco más ahora, pero le ayudará a evitar costos y tardados mantenimientos posteriores.

-

Si decide reconstruir, sea disciplinado en ello. Use prácticas que resultarán en alta calidad, hoy y en el futuro.


Página 55 de 61


-

Aunque estos principios se enfocan en la reconstrucción de una casa se aplican igualmente bien a la reingeniería de los sistemas y aplicaciones basados en cómputo.

29.9Actividades de reingeniería de software:

29.9.1 Análisis de inventarios: Toda organización de software debe tener un inventario de todas las aplicaciones. El inventario puede ser nada más que un modelo de hojas de cálculo que contenga información que ofrezca una descripción detallada (por ejemplo, tamaño, edad, importancia empresarial) de cada aplicación activa.

29.9.2 Reestructuración de documentos: La documentación débil es el distintivo de muchos sistemas heredados. Pero, ¿qué puede hacer con ella? ¿Cuáles son sus opciones? 1. La creación de documentación consume demasiado tiempo. Si el sistema funciona puede elegir vivir con lo que tiene. En algunos casos, éste es el enfoque correcto. No es posible volver a crear documentación para cientos de programas de cómputo. 2. La documentación debe actualizarse, pero su organización tiene recursos limitados. Use un enfoque “documente cuando toque”. Acaso no sea necesario volver a documentar por completo una aplicación. En vez de ello, aquellas porciones del sistema que en el momento experimenten cambio se documentan por completo. 3. El sistema tiene importancia empresarial y debe volver a documentarse por completo. - Ingeniera Inversa:


Página 56 de 61


- La ingeniería inversa para software es el proceso de analizar un programa con la intención de crear una representación del mismo en un nivel superior de abstracción que el código fuente. La ingeniería inversa es un proceso de recuperación de diseño. Las herramientas de ingeniería inversa extraen información de diseño de datos, arquitectónico y procedimental de un programa existente. - Reestructuración de código: - Para realizar esta actividad se analiza el código fuente con una herramienta de reestructuración. Las violaciones a los constructos de programación estructurada se anotan y luego el código se reestructura (esto puede hacerse automáticamente) o incluso se reescribe en un lenguaje de programación más moderno. El código reestructurado resultante se revisa y pone a prueba para garantizar que no se introdujeron anomalías. La documentación de código interna se actualiza. - Reestructuración de datos: - Un programa con arquitectura de datos débil será difícil de adaptar y mejorar. De hecho, para muchas aplicaciones, la arquitectura de información tiene más que ver con la viabilidad a largo plazo de un programa que con el código fuente en sí.

29.10 INGENIERA INVERSA: -

-

La ingeniería inversa puede extraer información de diseño a partir del código fuente, pero el nivel de abstracción, la completitud de la documentación, el grado en el que las herramientas y un analista humano trabajan en conjunto, y la direccionalidad del proceso son enormemente variables. El nivel de abstracción de un proceso de ingeniería inversa y las herramientas usadas para efectuarla tienen que ver con la sofisticación de la información de diseño que puede extraerse del código fuente. De manera ideal, el nivel de abstracción debe ser tan alto como sea posible, es decir, el proceso de ingeniería inversa debe ser capaz de inferir representaciones de diseño procedimental (una abstracción de bajo nivel), información de estructura de programa y datos (un nivel de abstracción un poco más alto), modelos de objeto, modelos de datos y/o flujo de control (un nivel de abstracción relativamente alto) y modelos de relación de entidad (un nivel de abstracción alto). Conforme aumenta el nivel de abstracción se proporciona información que permitirá facilitar la comprensión del programa.


Página 57 de 61


-

Proceso de Ingeniería Inversa:


Página 58 de 61


29.11 Ingeniería inversa para comprender datos: -

-

La ingeniería inversa de datos ocurre en diferentes niveles de abstracción y con frecuencia es la primera tarea de reingeniería. En el nivel del programa, las estructuras de datos internas del programa con frecuencia deben someterse a ingeniería inversa como parte de un esfuerzo de reingeniería global. En el nivel del sistema, las estructuras de datos globales con frecuencia se someten a reingeniería para acomodar nuevos paradigmas de administración de base de datos. La ingeniería inversa de las estructuras de datos globales actuales monta el escenario para la introducción de una nueva base de datos en todo el sistema.

29.12 Ingeniería inversa para entender el procesamiento: -

-

-

La ingeniería inversa para entender el procesamiento comienza con un intento por comprender y luego extraer abstracciones procedimentales representadas mediante el código fuente. Para comprender las abstracciones procedimentales se analiza el código en varios niveles de abstracción: sistema, programa, componente, patrón y enunciado. Para sistemas grandes, la ingeniería inversa por lo general se logra usando un enfoque semiautomatizado. Es posible usar herramientas automatizadas para auxiliarse en la comprensión de la semántica del código existente. La salida de este proceso pasa entonces a reestructuración de herramientas de ingeniería hacia adelante a fin de completar el proceso de reingeniería.

29. 13 Ingeniería inversa de interfaces de usuario: -

Las GUI (interfaces de usuario gráficas) sofisticadas se han vuelto obligatorias para productos y sistemas basados en computadora de todo tipo. Por tanto, el redesarrollo de las interfaces de usuario se ha convertido en uno de los tipos más comunes de actividad de reingeniería. Pero antes de poder reconstruir una interfaz de usuario, debe realizarse ingeniería inversa.

29.14 REESTRUCTURACION: -

-

La reestructuración de software modifica el código fuente y/o los datos con la intención de hacerlos sensibles a cambios futuros. En general, la reestructuración no modifica la arquitectura global del programa. La reestructuración ocurre cuando la arquitectura básica de una aplicación es sólida, aun cuando el interior técnico necesite trabajarse. Se inicia cuando grandes partes del software son aprovechables y sólo un subconjunto de todos los módulos y datos necesitan modificación extensa.

29.14.1 Reestructuración de código: -

La reestructuración de código se realiza para producir un diseño que produzca la misma función pero con mayor calidad que el programa original.


Página 59 de 61


29.14.2 Reestructuración de datos: -

Antes de que pueda comenzar la reestructuración de datos debe realizarse una actividad de ingeniería inversa llamada análisis de código fuente. La intención es extraer ítems de datos y objetos, obtener información acerca del flujo de datos y entender las estructuras de datos existentes que se implementaron. Esta actividad en ocasiones se llama análisis de datos.

29.15 INGENIERÍA HACIA ADELANTE: -

-

-

Para implementar los cambios necesarios puede luchar a través de modificación tras modificación, combatir al diseño ad hoc y el código fuente enredado. Puede intentar comprender los funcionamientos interiores más amplios del programa con la intención de hacer modificaciones de manera más efectiva. Puede rediseñar, recodificar y poner a prueba aquellas porciones del software que requieran modificación y aplicar un enfoque de ingeniería de software a todos los segmentos revisados. Puede rediseñar, recodificar y poner a prueba completamente el programa, y usar herramientas de reingeniería para ayudar a comprender el diseño actual.

29.15.1 Ingeniería hacia adelante para arquitecturas cliente-servidor: -

-

En esencia, los recursos de cómputo centralizados (incluido el software) se distribuyen entre muchas plataformas cliente. Aunque pueden diseñarse varios entornos distribuidos, la aplicación mainframe típica que se somete a reingeniería en una arquitectura cliente-servidor tiene las siguientes características: La funcionalidad de la aplicación migra a cada computadora cliente. Se implementan nuevas interfaces GUI en los sitios cliente. Las funciones de base de datos se ubican en el servidor. La funcionalidad especializada (por ejemplo, análisis con uso intenso de computadora) puede permanecer en el sitio servidor. Deben establecerse nuevos requisitos de comunicaciones, seguridad, archivado y control en los sitios cliente y servidor.

29.15.2 Ingeniería hacia adelante para arquitecturas orientadas a objetos: -

La ingeniería de software orientada a objetos se ha convertido en el paradigma de desarrollo elegido por muchas organizaciones de software. La reingeniería de software convencional en una implementación orientada a objeto usa muchas de las mismas técnicas estudiadas.

29.30 ECONOMÍA DE LA REINGENIERÍA: -

Todo programa no mantenible se retiraría de inmediato para sustituirlo con aplicaciones sometidas a reingeniería de alta calidad desarrolladas mediante modernas prácticas de ingeniería de software. Pero se vive en un mundo de recursos limitados. La reingeniería gasta recursos que pueden usarse para otros propósitos empresariales.


Página 60 de 61

Resumen Parte 4 Ingenieria Del Software

Recommend Documents