Resumen Parte 4 Ingenieria Del Software

Semestre 2015 II
Universidad Nacional del Altiplano
Sistema
Planificacin y Evaluacin de Proyectos de
Ingeniera del Software: Un enfoque prctico.
RESUMEN
Objetivos de la UNIDAD IV Administracin de Proyectos de Software:
Captulo 24: Conceptos de Administracin de Proyecto.
Captulo 25: Mtricas de Proceso y de Proyecto.
Captulo 26: Estimacin Para Proyectos de Software.
Captulo 27: Calendarizacin del Proyecto.
Captulo 28: Administracin del Riesgo.
Captulo 29: Mantenimiento y Reingeniera.
Integrantes:
Dennis Martin G. Chipana Aza.
Cristhian Abad Anchapuri Ruelas.
Sleyther Giulio Calsin Pacsi.
Planificacin y Evaluacin de Proyectos de Sistema Ingeniera del Software: Un enfoque
prctico.
Ingeniera del Software: Un enfoque prctico.
Contenido
INTRODUCCION .......................................................................................................... 7
CAPITULO 24: CONCEPTOS DE ADMINISTRACION DE PROYECTOS .................... 8
24.1 : EL ESPECTRO ADMINISTRATIVO ...................................................................................... 9

24.1.1: EL PERSONAL ............................................................................................................. 9
24.1.2: EL PRODUCTO............................................................................................................ 9
24.1.3: EL PROCESO ............................................................................................................... 9
24.1.4: EL PROYECTO ........................................................................................................... 10
24.2: EL PERSONAL .................................................................................................................. 10
24.2.1: LOS 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 DE COORDINACION Y COMUNICACIN ............................................. 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 ............................................... 16

25.1.1: LAS METRICAS DEL PROCESO Y LA MEJORA DEL PROCESO DE SOFTWARE ............ 16
25.1.2: METRICAS DE PROYECTO ........................................................................................ 16
Ingeniera de Sistemas Pgina 2 de 61

prctico.
25.2 MEDICION DEL SOFTWARE ............................................................................................. 17

25.2.1: METRICAS ORIENTADAS A TAMAO....................................................................... 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 DE RIESGOS: ............................................................................................. 21
- Riesgos Genricos ............................................................................................................. 21
- Riesgos Especficos: ........................................................................................................... 21
-Tamao 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 DE RIESGO: ................................................................................................ 24
7. MITIGACIN, MONITOREO Y MANEJO DE RIESGO: ............................................................ 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
REINGENIERIA DE SOFTWARE: ................................................................................................ 29
Un modelo de proceso de reingeniera de software: ............................................................. 30
Actividades de reingeniera de software:............................................................................ 31
INGENIERA INVERSA: .............................................................................................. 32
Ingeniera inversa para comprender datos: ............................................................................ 34

Ingeniera inversa para entender el procesamiento: .............................................................. 34
Ingeniera inversa de interfaces de usuario: ........................................................................... 34

prctico.
REESTRUCTURACION:.............................................................................................................. 34
Reestructuracin de cdigo: ............................................................................................... 34
Reestructuracin de datos: ................................................................................................. 35
INGENIERA HACIA ADELANTE: ............................................................................................... 35
Ingeniera hacia adelante para arquitecturas cliente-servidor: .......................................... 35
Ingeniera hacia adelante para arquitecturas orientadas a objetos: .................................. 35
ECONOMA DE LA REINGENIERA: ........................................................................................... 35
CAPITULO 26: ESTIMACION PARA PROYECTOS DE SOFTWARE ........................ 37
26.1 Observaciones acerca de las estimaciones ..................................................................... 37

26.2 El proceso de planificacin 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 Estimacin de proyectos de software ............................................................................. 39
26.6 Tcnicas de descomposicin ........................................................................................... 39
26.6.1 Dimensionamiento de software ............................................................................... 39
26.6.2 Estimacin basada en el problema .......................................................................... 39
26.6.3 Estimacin basada en proceso ................................................................................. 40
CAPITULO 27: CALENDARIZACION DE PROYECTO ............................................... 41
27.1 Conceptos bsicos .......................................................................................................... 41

27.2 Calendarizacin de proyecto .......................................................................................... 41
27.2.1 Principios bsicos ..................................................................................................... 41
27.4 Definicin de una red de tareas ..................................................................................... 41
27.5 Calendarizacin .............................................................................................................. 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

prctico.
28.4 IDENTIFICACION DE RIESGOS: ......................................................................................... 46

28.4.1 Riesgos Genricos: ................................................................................................... 46
28.4.2 Riesgos Especficos: .................................................................................................. 46
28.4.3 Tamao del producto: .............................................................................................. 46
28.4.4 Impacto empresarial: ............................................................................................... 46
28.4.5 Caractersticas de los participantes:......................................................................... 46
28.5.6 Definicin del proceso:............................................................................................. 46
28.5.7 Entorno de desarrollo: ............................................................................................. 46
28.5.8 Tecnologa por construir: ......................................................................................... 47
28.5.9 Tamao 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 MITIGACIN, 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 reingeniera de software: ..................................................... 55
29.9Actividades de reingeniera de software: ........................................................................ 56
29.9.1 Anlisis de inventarios.............................................................................................. 56
29.9.2 Reestructuracin de documentos: ............................................................................... 56
29.10 INGENIERA INVERSA:..................................................................................................... 57
29.11 Ingeniera inversa para comprender datos: .................................................................. 59
29.12 Ingeniera inversa para entender el procesamiento: .................................................... 59
29. 13 Ingeniera inversa de interfaces de usuario: ................................................................ 59
29.14 REESTRUCTURACION: .................................................................................................... 59

prctico.
29.14.1 Reestructuracin de cdigo: ........................................................................... 59

29.14.2 Reestructuracin de datos: .................................................................................... 60
29.15 INGENIERA HACIA ADELANTE: ..................................................................................... 60
29.15.1 Ingeniera hacia adelante para arquitecturas cliente-servidor:.................... 60
29.15.2 Ingeniera hacia adelante para arquitecturas orientadas a objetos: ..................... 60
29.30 ECONOMA DE LA REINGENIERA: ................................................................................. 60

prctico.
INTRODUCCION
En esta parte de Ingeniera del software. Un enfoque prctico, aprenderemos, sobre
las tcnicas de administracin requeridas para planificar, organizar, monitorear y
controlar proyectos de software. En el desarrollo de los captulos de esta unidad del
libro abordaremos muchas cuestiones como:
o Cmo debe administrarse el personal, el proceso y el problema durante un
proyecto de software?
o Cmo pueden usarse las mtricas del software para administrar un proyecto y
el proceso de software?
o Cmo genera un equipo de software estimaciones confiables de esfuerzo,
costo y duracin del proyecto?
o Qu tcnicas pueden usarse para valorar los riesgos que pueden tener
impacto sobre el xito del proyecto?
o Cmo selecciona un gerente de proyecto de software un conjunto de tareas
laborales para los ingenieros del software?
o Cmo se crea un calendario de proyecto?
o Por qu el mantenimiento y la reingeniera son importantes para los gerentes
de ingeniera de software y para los profesionales?

prctico.
CAPITULO 24: CONCEPTOS DE

ADMINISTRACION DE PROYECTOS
La administracin del proyecto involucra planificacin, 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 tcnicos 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 comunicacin 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, estimndose
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 planificacin 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
tambin los tiempos establecidos sern la medida para ver la efectividad de la
planificacin.
Una vez cumplida todas las actividades, es difcil 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
modificacin o modificaciones estas debern ser hechas cuanto antes en plena
comunicacin entre personal y cliente.

prctico.
24.1 : EL ESPECTRO ADMINISTRATIVO

La administracin de un Proyecto de Software ser efectivo poniendo su enfoque en
las cuatro P. Un gerente que involucre a su personal una buena comunicacin entre
ellos y el cliente estar desarrollando una solucin elegante ante sucesos que lo
requieran, asi tendr un producto que sufra muchos riesgos, adems de no tener en
cuenta buenas metodologas para la evolucin 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 dcada de 1960 se estudia la formacin 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 ingls), en reconocimiento al hecho de que
toda organizacin requiere mejorar continuamente su habilidad para atraer,
desarrollar, motivar, organizar y conservar la fuerza de trabajo necesaria a fin de lograr
sus objetivos empresariales estratgicos.
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 caractersticas de nuestro producto.

prctico.
24.1.4: EL PROYECTO
Los proyectos de software se planean y controlan debido a una razn principal: es la

nica forma conocida para manejar la complejidad. E incluso as, los equipos de
software todava 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 ms o menos 175
experimentaron grandes demoras y excesos, o se dieron por concluidos sin
completarse. Aunque actualmente la tasa de xito para los proyectos de software
puede haber mejorado un poco, la tasa de falla de proyecto sigue siendo mucho ms
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, segn testimonios en los EEUU muchos de los
Vice Presidentes encargados de grandes proyectos de software, declaran que la
seleccin de un buen personal para el desarrollo del proyecto es un buen ndice para
medir el xito del mismo, adems 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 tambin 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 interactan con el software una vez que se
haya lanzado para su uso.

prctico.
24.2.2: LIDERES DE EQUIPO
Para que la administracin 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 quizs por el hecho de cumplir con las caractersticas para el
puesto, pero que en la practica , no suele tener xito en el manejo del grupo
involucrado.
Un excelente libro acerca de liderazgo tcnico, Jerry Weinberg sugiere un modelo MOI
( Motivacin, organizacin e Innovacin de ideas), una visin de las caraterisitca que
definen a un gerente de proyecto eficaz enfatiza cuatro rasgos como claves :
1. Resolucin de Problemas
2. Identidad Administrativa
3. Logro
4. Influencia y construccin del equipo
24.2.3: EL EQUIPO DE SOFTWARE
Existen muchos modelos y estructuras de organizacin 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 organizacin, sin embargo Mantei describe site factores de
proyecto que deben considerarse cuando se planee la estructura de los equipos de
ingeniera de software:
Dificultad del problema que se va a resolver.
Tamao del programa resultante en lneas de cdigo o puntos de funcin.
Tiempo que el equipo permanecer unido (vida del equipo).
Grado en el que puede dividirse en mdulos el problema.
Calidad y confiabilidad requeridas por el sistema que se va a construir.
Rigidez de la fecha de entrega.
Grado de sociabilidad (comunicacin ) requerido para el proyecto.
24.2.4: EQUIPOS AGILES
Para hacer uso efectivo de las competencias de cada miembro del equipo y fomentar
la colaboracin efectiva a travs de un proyecto de software, los equipos giles son
auto organizados.

prctico.
Muchos modelos de proceso gil (por ejemplo, Scrum) dan al equipo gil significativa
autonoma para tomar las decisiones administrativas y tcnicas del proyecto
necesarias para hacer que el trabajo se cumpla. La planificacin se mantiene al
mnimo y al equipo se le permite seleccionar su propio enfoque (por ejemplo, proceso,
mtodos, herramientas), restringido nicamente por los requerimientos empresariales
y los estndares de la organizacin.
24.2.5: CONFLICTOS DE COORDINACION Y COMUNICACIN
La interoperabilidad se ha convertido en una caracterstica 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
caractersticas del software moderno (escala, incertidumbre e interoperabilidad) son
hechos de la vida. Para lidiar con ellos de manera efectiva, deben implantarse
mtodos 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 informacin

slida disponible. Un anlisis detallado de los requerimientos del software
proporcionara la informacin necesaria para las estimaciones, pero el anlisis
usualmente tarda semanas o incluso meses en completarse. Peor an, 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 administracin del proyecto de software,

esto se define al solucionar ciertas cuestiones que respondan al: contexto, objetivos de
informacin y funcin y desempeo.
No debe haber ambigedades ni se incomprensibles en los niveles administrativo

tcnico, debe ser preciso y consistente. Debe acotar un enunciado , es decir, los datos
cuantitativos (Numero de usuarios, entorno objetivo, mximo de tiempo, etc),

prctico.
enunciados de manera explicita , se anotan las restricciones y/o limitaciones (por

ejemplo , el costo del producto restringe el tamao de la memoria) y se reflejan en
factores mitigantes (por ejemplo , los algoritmos deseados estn bien entendidos y
disponibles en java).
24.3.2: DESCOMPOSICION DEL PROBLEMA
Se suele aplicar una estrategia muy conocida divide y venceras cuando se quiere
resolver un problema complejo, de esta manera podemos dividir el problema complejo
en problemas mas pequeos y estos carecern 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 planificacin del proyecto comienza con la fusin de producto y proceso, en esencia

se crea una matriz cada funcin 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 adems de ver las actividades que se realizaran
asociadas a cada celda.
2.4.2 DESCOMPOSICION DEL PROCESO
La descomposicin 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 pequeo puede requerir las siguientes
tareas para la actividad de comunicacin:
Revisar la solicitud del cliente.

prctico.
Planificar y calendarizar una reunin formal facilitada con todos los

participantes.
Realizar una investigacin para especificar la solucin propuesta y los
enfoques existentes.
Preparar un documento de trabajo y una agenda para la reunin formal.
Realizar la reunin.
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
seales que indican que un proyecto de sistemas de informacin 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 tecnologa elegida.
5. Las necesidades empresariales cambian o estn 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 tamao 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 propsito de la
empresa justifica el gasto de personal, tiempo y dinero?
-. Qu (what) se har? Defina el conjunto de tareas requeridas para el proyecto.
-. Cundo (when) se har? El equipo establece un calendario de proyecto al
identificar cundo se realizarn las tareas del proyecto y cundo se alcanzarn los
hitos.
-. Quin (who) es responsable de cada funcin? Defina el papel y la responsabilidad
de cada miembro del equipo de software.

prctico.
-. Dnde (where) se ubicarn en la organizacin? No todos los roles y

responsabilidades residen dentro de los profesionales del software. Clientes, usuarios
y otros participantes tambin tienen responsabilidades.
-. Cmo (how) se har el trabajo, tcnica y organizativamente? Una vez establecido
el mbito del producto, debe definirse una estrategia tcnica para el proyecto.
-. Cunto (how much) se necesita de cada recurso? La respuesta a esta pregunta
se deriva al desarrollar estimaciones (captulo 26) con base en las respuestas a las
preguntas anteriores.

prctico.
CAPITULO 25. METRICAS DE PROCESO Y

DEL PROYECTO
Tener una medicin permite ganar compresin acerca del proceso y del proyecto, al
proporcionar un mecanismo de evaluacin objetiva, adems la medicin puede usarse
a travs de un proyecto de software para auxiliar la estimacin, control de calidad,
valoracin 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 mtricas 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 mtricas 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 organizacin se siente ms cmoda con la recoleccin y uso de
mtricas de proceso, la derivacin de los indicadores simples da lugar a un enfoque
mas riguroso llamado mejora estadstica de proceso de software (MEPS), este
enfoque utiliza un anlisis de falla de software para recopilar informacin acerca de
todos los errores y defectos que se encuentren conforme se desarrolle y use una
aplicacin, sistema o producto.
25.1.2: METRICAS DE PROYECTO

La diferencia entre mtricas de proceso de software que se usaron con propsitos
estratgicos, las mtricas de proyecto son mas tcticos, es decir el gerente de
proyecto y un equipo de software usan las mtricas de proyecto y los indicadores para
adaptar el flujo de trabajo del proyecto y las actividades tcnicas.
Las mtricas de proyecto son de doble intencin , primero para minimizar el calendario
de desarrollo haciendo ajustes necesarios para evitar demoras y lidiar probables

prctico.
problemas y riesgos, segundo se usan para valorar la calidad del producto sobre una
base en marcha, y de ser necesario modificar el enfoque tcnico 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 deteccin de los errores de proceso, sin embargo debe tomarse en cuenta
puntos fuertes como la complejidad y tamao del proyecto, pero esto ayuda a tener
estimaciones de como va desarrollndose el proyecto antes de su liberacin para los
usuarios finales.
25.2.1: METRICAS ORIENTADAS A TAMAO

Las mtricas orientadas a tamao 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 cdigos
de lneas de cdigo como medida clave.
Con la finalidad de desarrollar mtricas que puedan compararse con otros proyectos,
pueden elegirse lneas de cdigos como un valor de normalizacin, a partir de los
datos rudimentarios pueden desarrollarse mtricas simples orientados a tamao para
cada proyecto.
25.2.2: METRICAS ORIENTADAS A FUNCION

Una de las mtricas orientada a funcin de mayor uso es Punto de Funcion (PF), el
calculo del punto de funcin se bas en caractersticas del dominio y de la complejidad
de informacin del software.
El mtodo requiere de cierta maa ya que dicho calculo solo representa un numero y
esta basado mas en datos subjetivos que objetivos, y esto no afecta de manera fsica,
por ser solo un numero.

prctico.
25.2.3: METRICAS ORIENTADAS A OBJETO
A diferencia de las mtricas orientadas a tamao y orientadas a funcin, las mtricas

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 mtricas para proyectos Orientado a

Objeto:
Numero de guiones de escenario: interaccin entre usuario y aplicacin.
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 mtricas 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 mtodo 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 caractersticas, los PCU adems es una
funcin 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
combinacin 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 estn:
Numero de paginas web estticas.
Numero de paginas web dinmicas.
Numero de vnculos de pagina internos.
Numero de objetos de datos persistentes.
Numero de sistemas externos puestos en interfaz.

prctico.
Numero de objetos de contenido estatico.

Numero de funciones ejecutables.
ADMINISTRACION DE RIESGO:
- El anlisis y la administracin del riesgo son acciones que ayudan al equipo de
software a entender y manejar la incertidumbre. Muchos problemas pueden

prctico.
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 anlisis y la administracin del
riesgo.
- El software es una empresa difcil. Muchas cosas pueden salir mal y,
francamente, muchas con frecuencia lo hacen. Por esta razn es que estar
preparado, comprender los riesgos y tomar medidas proactivas para evitarlos o
manejarlos son elementos clave de una buena administracin de proyecto de
software.
- Reconocer qu puede salir mal es el primer paso, llamado identificacin de
riesgos. A continuacin, cada riesgo se analiza para determinar la probabilidad
de que ocurra y el dao que causar si ocurre. Una vez establecida esta
informacin 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 informacin de riesgo.
- El MMMR debe revisarse conforme avance el proyecto para asegurarse de que
los riesgos se mantienen actualizados. Los planes de contingencia para
administracin del riesgo deben ser realistas.
ESTRATEGIAS REACTIVAS DE RIESGO FRENTE A ESTRATEGIAS

PROACTIVAS DE RIESGO
- Una estrategia considerablemente ms inteligente para la administracin del
riesgo es ser proactivo. Una estrategia proactiva comienza mucho antes de
iniciar el trabajo tcnico. 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 tcnico como en la organizacin), 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).

prctico.
2) Construir un producto que ya no encaje en la estrategia empresarial global

de la compaa (riesgo estratgico).
3) Construir un producto que el equipo de ventas no sabe cmo 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 Genricos: Son una amenaza potencial a todo proyecto de software.
- Riesgos Especficos: Solo pueden identificarse solamente por quienes tienen
clara comprensin de la tecnologa, el personal y el entorno especfico del
software que se construye.
- Un mtodo para identificar riesgos es crear una lista de verificacin de tem de
riesgo. La lista de verificacin puede usarse para identificacin del riesgo y as
enfocarse sobre algn subconjunto de riesgos conocidos y predecibles en las
siguientes subcategoras genricas:
-Tamao del producto: riesgos asociados con el tamao global del software
que se va a construir o a modificar.
-Impacto empresarial: riesgos asociados con restricciones impuestas por la
administracin o por el mercado.
-Caractersticas de los participantes: riesgos asociados con la sofisticacin de
los participantes y con la habilidad de los desarrolladores para comunicarse
con los participantes en forma oportuna.
-Definicin 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 organizacin
desarrolladora.
-Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad de
las herramientas por usar para construir el producto.
-Tecnologa por construir: riesgos asociados con la complejidad del sistema
que se va a construir y con lo novedoso de la tecnologa que se incluye en el
sistema.
-Tamao y experiencia del personal: riesgos asociados con la experiencia
tcnica y de proyecto global de los ingenieros de software que harn el trabajo.

prctico.
5. PROYECCION DE RIESGO:
-La proyeccin del riesgo, tambin llamada estimacin 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 tcnico para realizar cuatro pasos de proyeccin 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 precisin global de la proyeccin del riesgo de modo que no habr
malos entendidos.
5.1. VALORACION DE IMPACTO:

prctico.
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 tcnica simple para proyeccin 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 verificacin.
- Las categoras 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 priorizacin de riesgo de primer orden.

prctico.
5.3. VALORACION DE IMPACTO DE RIESGO:

-Identificacin de riesgo: De hecho, slo 70 por ciento de los componentes
de software calendarizados para reus se integrarn en la aplicacin. 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 slo puede usarse 70 por ciento, tendrn que desarrollarse 18 componentes
desde cero (adems 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 ingeniera del software para cada LOC es
US$14.00, el costo global (impacto) para desarrollar los componentes sera 18
X 100 X 14 = US$25 200. Exposicin al riesgo. ER X 0.80 X 25 200 ~ US$20
200.
- La exposicin al riesgo puede calcularse para cada riesgo en la tabla de
riesgo, una vez hecha la estimacin del costo del riesgo. La exposicin al
riesgo total para todos los riesgos (arriba del corte en la tabla de riesgos) puede
proporcionar los medios para ajustar la estimacin del costo final para un
proyecto. Tambin 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 planificacin del proyecto, un riesgo puede
enunciarse de manera muy general. Conforme pasa el tiempo y se aprende
ms acerca del proyecto y de los riesgos, es posible refinar el riesgo en un
conjunto de riesgos ms detallados, cada uno un poco ms sencillo de mitigar,
monitorear y manejar.
- Dado que todos los componentes de software reutilizables deben apegarse a
estndares de diseo especficos y dado que algunos no se apegan, entonces
existe preocupacin de que (posiblemente) slo 70 por ciento de los mdulos
reutilizables planeados puedan realmente integrarse en el sistema que se va a
construir, lo que da como resultado la necesidad de ingeniera a la medida del
restante 30 por ciento de los componentes.
Esta condicin general puede refinarse en la forma siguiente:
Subcondicin 1.- Ciertos componentes reutilizables los desarroll una tercera
persona sin conocimiento de los estndares de diseo internos.

prctico.
Subcondicin 2.- El estndar de diseo para interfaces de componente todava

no se consolida y puede no apegarse a ciertos componentes reutilizables
existentes.
Subcondicin 3.-Ciertos componentes reutilizables se implementaron en un
lenguaje que no se so- porta en el entorno blanco.
7. MITIGACIN, MONITOREO Y MANEJO DE RIESGO:

- Todas las actividades de anlisis 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

rotacin. Entre los posibles pasos por tomar estn:
- Reunirse con el personal actual para determinar las causas de la rotacin (por
ejemplo, pobres condiciones laborales, salario bajo, mercado laboral
competitivo).
- Mitigar aquellas causas que estn bajo su control antes de comenzar el
proyecto.
- Una vez iniciado el proyecto, suponer que la rotacin ocurrir y desarrollar
tcnicas para asegurar la continuidad cuando el personal se vaya.
- Organizar equipos de trabajo de modo que la informacin acerca de cada
actividad de desarrollo se disperse ampliamente.
- Definir estndares 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 ms de una
persona se ponga al da).
- Asignar un miembro de personal de respaldo para cada tcnico crtico.
8. EL PLAN MMMR:
- En el plan de proyecto del software puede incluirse una estrategia de
administracin del riesgo, o los pasos de administracin del riesgo pueden
organizarse en un plan de mitigacin, monitoreo y manejo de riesgo (MMMR) por
separado. El plan MMMR documenta todo el trabajo realizado como parte del
anlisis de riesgos y el gerente del proyecto lo usa como parte del plan de proyecto
global.

prctico.
MANTENIMIENTO Y REINGENIERA:
- Sin importar su dominio de aplicacin, su tamao 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 caractersticas o funciones y cuando la aplicacin se somete a
reingeniera para ofrecer beneficio en un contexto moderno.
- Ley de cambio continuo (1974): El software que se implement en un contexto
de cmputo 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 autorregulacin (1974): El proceso de evolucin del sistema tipo E es
autorregulable con medidas de distribucin de producto y de proceso cercanas
a lo normal.
- Ley de conservacin de estabilidad organizativa (1980): La tasa de actividad
global efectiva promedio en un sistema tipo E en evolucin no vara durante el
tiempo de vida del producto.
- Ley de conservacin 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 evolucin satisfactoria. El crecimiento excesivo disminuye dicho
dominio. Por tanto, el crecimiento incremental promedio permanece sin
variacin conforme el sistema evoluciona.
- Ley de crecimiento continuo (1980): El contenido funcional de los sistemas tipo
E debe aumentar continuamente para mantener la satisfaccin 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 realimentacin del sistema (1996): Los procesos evolutivos tipo E
constituyen sistemas de realimentacin multinivel, multibucle y multiagente, y

prctico.
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 cuestin de das 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 quera 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
organizacin (o su encargado) deben poder realizar las correcciones,
adaptaciones y mejoras que son parte de la actividad de mantenimiento. Pero,
adems, la organizacin debe proporcionar otras importantes actividades de
soporte que incluyen soporte operativo en marcha, soporte al usuario final y
actividades de reingeniera durante el ciclo de vida completo del software. Una
definicin 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 tambin provisin 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 funcin [SSO08].
- En esencia, la soportabilidad es uno de los muchos factores de calidad que
deben considerarse durante las acciones de anlisis y diseo que son parte del
proceso de software. Deben abordarse como parte del modelo (o
especificacin) de requisitos y considerarse conforme el diseo evoluciona y
comienza la construccin.
REINGENIERIA:
- En la actualidad, las principales compaas tienen decenas de miles de
programas de cmputo 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 creacin de grandes y novedosos sistemas
basados en cmputo. Pero en muchos otros, significa la modificacin o
reconstruccin de las aplicaciones existentes. En las secciones que siguen, se
examina la reingeniera en una forma descendente, comenzando con un breve
panorama de la reingeniera de los procesos de empresas y avanzando hacia
un anlisis ms detallado de las actividades tcnicas que ocurren cuando el
software se somete a reingeniera.

prctico.
REINGENIERA DE PROCESOS DE EMPRESA:

- La reingeniera de procesos de empresa (RPE) se extiende ms all del mbito
de las tecnologas de la informacin y de la ingeniera de software. Entre las
muchas definiciones (la mayora un tanto abstractas) que se han sugerido para
la RPE, la bsqueda, e implementacin, de cambios radicales en los procesos
de las empresas para lograr resultados innovadores.
PROCESOS EMPRESARIALES:
- Un proceso empresarial es un conjunto de tareas lgicamente 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 especfico.
Empresa sistemas empresariales procesos empresariales
subprocesos empresariales.
- Cada sistema empresarial (tambin llamado funcin empresarial) est
compuesto de uno o ms procesos empresariales, y cada proceso empresarial
se define mediante un conjunto de subprocesos.
- La RPE puede aplicarse en cualquier nivel de la jerarqua, pero conforme se
ensancha su mbito (es decir, conforme se avanza hacia arriba en la
jerarqua), los riesgos asociados con la RPE crecen de manera dramtica. Por
esta razn, la mayora de los esfuerzos RPE se enfocan en procesos o
subprocesos individuales.
MODELO RPE:
- Como la mayora de las actividades de ingeniera, la reingeniera 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 razn,
no hay inicio ni fin de la RPE: es un proceso evolutivo.

prctico.
REINGENIERIA DE SOFTWARE:
- Una aplicacin que atendi las necesidades empresariales de una compaa
durante 10 o 15 aos. 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 reingeniera de software se produjo por los problemas de
mantenimiento de software que se acumularon durante ms de cuatro
dcadas.

prctico.
Un modelo de proceso de reingeniera de software:

- La reingeniera toma tiempo, cuesta cantidades significativas de dinero y
absorbe recursos que de otro modo pueden ocuparse en preocupaciones
inmediatas. Por todas estas razones, la reingeniera no se logra en pocos
meses o incluso en algunos aos. La reingeniera de los sistemas de
informacin es una actividad que absorber recursos de tecnologa de la
informacin durante muchos aos. Por esto, toda organizacin necesita una
estrategia pragmtica para la reingeniera 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. Cmo procedera?
- Antes de comenzar a reconstruir, parecera razonable inspeccionar la casa.
Para determinar si necesita reconstruirse, usted (o un inspector profesional)
crea una lista de criterios, de modo que su inspeccin sea sistemtica.
- Antes de demoler y reconstruir toda la casa, asegrese de que la estructura es
dbil. Si la casa es estructuralmente slida, acaso sea posible remodelar sin
reconstruir (a un costo mucho ms bajo y en mucho menos tiempo).
- Antes de comenzar a reconstruir, asegrese de entender cmo se construy la

original. Eche un vistazo detrs de las paredes. Entienda cmo estn el
alambrado, la plomera y la estructura interna. Incluso si tira todo a la basura, la
comprensin que obtenga le servir cuando comience la construccin.
- Si comienza a reconstruir, use solamente los materiales ms modernos y ms

duraderos. Esto puede costar un poco ms ahora, pero le ayudar a evitar
costos y tardados mantenimientos posteriores.
- Si decide reconstruir, sea disciplinado en ello. Use prcticas que resultarn en

alta calidad, hoy y en el futuro.
- Aunque estos principios se enfocan en la reconstruccin de una casa se

prctico.
aplican igualmente bien a la reingeniera de los sistemas y aplicaciones

basados en cmputo.
Actividades de reingeniera de software:

- Anlisis de inventarios: Toda organizacin de software debe tener un
inventario de todas las aplicaciones. El inventario puede ser nada ms que un
modelo de hojas de clculo que contenga informacin que ofrezca una
descripcin detallada (por ejemplo, tamao, edad, importancia empresarial) de
cada aplicacin activa.
- Reestructuracin de documentos: La documentacin dbil es el distintivo de
muchos sistemas heredados. Pero, qu puede hacer con ella? Cules son
sus opciones?
1. La creacin de documentacin 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 documentacin para cientos de
programas de cmputo.
2. La documentacin debe actualizarse, pero su organizacin tiene recursos
limitados. Use un enfoque documente cuando toque. Acaso no sea necesario
volver a documentar por completo una aplicacin. 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 ingeniera inversa para software es el proceso de analizar un programa
con la intencin de crear una representacin del mismo en un nivel superior de
abstraccin que el cdigo fuente. La ingeniera inversa es un proceso de
recuperacin de diseo. Las herramientas de ingeniera inversa extraen
informacin de diseo de datos, arquitectnico y procedimental de un programa
existente.
- Reestructuracin de cdigo:
- Para realizar esta actividad se analiza el cdigo fuente con una herramienta
de reestructuracin. Las violaciones a los constructos de programacin
estructurada se anotan y luego el cdigo se reestructura (esto puede hacerse
automticamente) o incluso se reescribe en un lenguaje de programacin ms
moderno. El cdigo reestructurado resultante se revisa y pone a prueba para
garantizar que no se introdujeron anomalas. La documentacin de cdigo
interna se actualiza.
- Reestructuracin de datos:

prctico.
- Un programa con arquitectura de datos dbil ser difcil de adaptar y mejorar.

De hecho, para muchas aplicaciones, la arquitectura de informacin tiene ms
que ver con la viabilidad a largo plazo de un programa que con el cdigo fuente
en s.
INGENIERA INVERSA:
- La ingeniera inversa puede extraer informacin de diseo a partir del cdigo
fuente, pero el nivel de abstraccin, la completitud de la documentacin, 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 abstraccin de un proceso de ingeniera inversa y las herramientas
usadas para efectuarla tienen que ver con la sofisticacin de la informacin de
diseo que puede extraerse del cdigo fuente. De manera ideal, el nivel de
abstraccin debe ser tan alto como sea posible, es decir, el proceso de
ingeniera inversa debe ser capaz de inferir representaciones de diseo
procedimental (una abstraccin de bajo nivel), informacin de estructura de
programa y datos (un nivel de abstraccin un poco ms alto), modelos de
objeto, modelos de datos y/o flujo de control (un nivel de abstraccin
relativamente alto) y modelos de relacin de entidad (un nivel de abstraccin
alto). Conforme aumenta el nivel de abstraccin se proporciona informacin
que permitir facilitar la comprensin del programa.

prctico.
- Proceso de Ingeniera Inversa:

prctico.
Ingeniera inversa para comprender datos:

- La ingeniera inversa de datos ocurre en diferentes niveles de abstraccin y
con frecuencia es la primera tarea de reingeniera. En el nivel del programa, las
estructuras de datos internas del programa con frecuencia deben someterse a
ingeniera inversa como parte de un esfuerzo de reingeniera global.
- En el nivel del sistema, las estructuras de datos globales con frecuencia se
someten a reingeniera para acomodar nuevos paradigmas de administracin
de base de datos. La ingeniera inversa de las estructuras de datos globales
actuales monta el escenario para la introduccin de una nueva base de datos
en todo el sistema.
Ingeniera inversa para entender el procesamiento:

- La ingeniera inversa para entender el procesamiento comienza con un intento
por comprender y luego extraer abstracciones procedimentales representadas
mediante el cdigo fuente.
- Para comprender las abstracciones procedimentales se analiza el cdigo en
varios niveles de abstraccin: sistema, programa, componente, patrn y
enunciado.
- Para sistemas grandes, la ingeniera inversa por lo general se logra usando un
enfoque semiautomatizado. Es posible usar herramientas automatizadas para
auxiliarse en la comprensin de la semntica del cdigo existente. La salida de
este proceso pasa entonces a reestructuracin de herramientas de ingeniera
hacia adelante a fin de completar el proceso de reingeniera.
Ingeniera inversa de interfaces de usuario:

- Las GUI (interfaces de usuario grficas) 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
ms comunes de actividad de reingeniera. Pero antes de poder reconstruir una
interfaz de usuario, debe realizarse ingeniera inversa.
REESTRUCTURACION:
- La reestructuracin de software modifica el cdigo fuente y/o los datos con la
intencin de hacerlos sensibles a cambios futuros. En general, la
reestructuracin no modifica la arquitectura global del programa.
- La reestructuracin ocurre cuando la arquitectura bsica de una aplicacin es
slida, aun cuando el interior tcnico necesite trabajarse. Se inicia cuando
grandes partes del software son aprovechables y slo un subconjunto de todos
los mdulos y datos necesitan modificacin extensa.
Reestructuracin de cdigo:
- La reestructuracin de cdigo se realiza para producir un diseo que produzca
la misma funcin pero con mayor calidad que el programa original.

prctico.
Reestructuracin de datos:
- Antes de que pueda comenzar la reestructuracin de datos debe realizarse una
actividad de ingeniera inversa llamada anlisis de cdigo fuente.
- La intencin es extraer tems de datos y objetos, obtener informacin acerca
del flujo de datos y entender las estructuras de datos existentes que se
implementaron. Esta actividad en ocasiones se llama anlisis de datos.
INGENIERA HACIA ADELANTE:

- Para implementar los cambios necesarios puede luchar a travs de
modificacin tras modificacin, combatir al diseo ad hoc y el cdigo fuente
enredado.
- Puede intentar comprender los funcionamientos interiores ms amplios del
programa con la intencin de hacer modificaciones de manera ms efectiva.
- Puede redisear, recodificar y poner a prueba aquellas porciones del software
que requieran modificacin y aplicar un enfoque de ingeniera de software a
todos los segmentos revisados.
- Puede redisear, recodificar y poner a prueba completamente el programa, y
usar herramientas de reingeniera para ayudar a comprender el diseo actual.
Ingeniera hacia adelante para arquitecturas cliente-servidor:

- En esencia, los recursos de cmputo centralizados (incluido el software) se
distribuyen entre muchas plataformas cliente. Aunque pueden disearse varios
entornos distribuidos, la aplicacin mainframe tpica que se somete a
reingeniera en una arquitectura cliente-servidor tiene las siguientes
caractersticas:
- La funcionalidad de la aplicacin 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, anlisis 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.
Ingeniera hacia adelante para arquitecturas orientadas a objetos:

- La ingeniera de software orientada a objetos se ha convertido en el paradigma
de desarrollo elegido por muchas organizaciones de software.
- La reingeniera de software convencional en una implementacin orientada a
objeto usa muchas de las mismas tcnicas estudiadas.
ECONOMA DE LA REINGENIERA:
- Todo programa no mantenible se retirara de inmediato para sustituirlo con
aplicaciones sometidas a reingeniera de alta calidad desarrolladas mediante
modernas prcticas de ingeniera de software. Pero se vive en un mundo de

prctico.
recursos limitados. La reingeniera gasta recursos que pueden usarse para

otros propsitos empresariales.
- Sneed propone un modelo de anlisis costo-beneficio para reingeniera,
definiendo nueve parmetros:
- El costo asociado con el mantenimiento continuo de una aplicacin candidata

(es decir, la reingeniera no se realiza) puede definirse como:
- El costo asociado con reingeniera se define usando la siguiente relacin:
- Con los costos presentados en las ecuaciones antes mencionadas, el beneficio

global de la reingeniera puede calcularse como:

prctico.
CAPITULO 26: ESTIMACION PARA

PROYECTOS DE SOFTWARE
26.1 Observaciones acerca de las estimaciones
La administracin de proyectos de Software es un conjunto de actividades colectivas
llamado Planificacin de Proyectos. Antes de que pueda comenzar dicha
planificacin se debe estimar el trabajo, recurso y tiempo a utilizarlos, una vez
completo dichas actividades el equipo de software debe establecer un calendario
(hitos y tareas) adems identificar un responsable de ellas.
26.2 El proceso de planificacin del proyecto

Es proporcionar un marco conceptual al gerente para realizar estimaciones de
recursos, costo y calendario .donde adems 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 caractersticas de ello, para eso se usan una de las dos tcnicas.
Una descripcin narrativa del mbito del software se desarrolla despus de la
comunicacin con todos los participantes.
Los usuarios finales desarrollan un conjunto de casos de uso.

prctico.
26.4 Recursos
26.4.1 Recursos Humanos

El planificador comienza por evaluar el nmero de personas a utilizase en el
proyecto y las habilidades que poseen cada una de ellas, se clasifican en:
posicin organizacional (por ejemplo, gerente, ingeniero de software
ejecutivo) como la especialidad (por ejemplo, telecomunicaciones, base de
datos, cliente-servidor). La ubicacin vara dependiendo del tamao del
proyecto.
26.4.2 Recursos de software Reutilizable

La Ing. de Software se basa en componentes ISBC donde se pone nfasis a
la creacin y reutilizacin de bloques de software donde se divide en
categoras:
Componentes COTS: Se adquieren de proyectos anteriores y se compran de
terceros

prctico.
Componentes Experiencia Completa: Son especificaciones, diseos, cdigo 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
tendrn un riesgo relativamente bajo.
Componentes de Experiencias Parcial: Son especificaciones, diseos, cdigo
o datos de prueba existentes, desarrollados para proyectos anteriores que
se relacionan con el software Por tanto, requerirn de modificaciones
sustanciales y tendrn un riesgo relativamente alto.
Componentes Nuevos: Son especialmente desarrollados para el Proyecto
26.4.3 Recursos Ambientales
26.5 Estimacin de proyectos de software

La estimacin no es una ciencia exacta existen variables pueden afectar su costo:
Para ello se realiza una serie de pasos sistemticos
Retrase la estimacin hasta avanzado el proyecto (obviamente, puede lograr
estimaciones 100 por ciento precisas despus de que el proyecto est
completo!).
Base las estimaciones en proyectos similares que ya estn completos.
Use tcnicas de descomposicin relativamente simples para generar
estimaciones de costo y esfuerzo de proyecto.
Use uno o ms modelos empricos para estimacin de costo y esfuerzo de
software.
En tales pasos sistemticos se describen caractersticas de la organizacin de
desarrollo y el software que se va a desarrollar.
26.6 Tcnicas de descomposicin
26.6.1 Dimensionamiento de software
26.6.2 Estimacin basada en el problema

Las estimaciones de LCD y PF son tcnicas de estimacin distintas. A pesar de
que ambas tienen varias caractersticas en comn. 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.

prctico.
26.6.3 Estimacin basada en proceso

La tcnica mas comn para estimar un proyecto es basar la estimacin en el
proceso que se va a utilizar. Es decir el proceso se descompone en un conjunto
relativamente pequeo de actividades o tareas y en el esfuerzo requerido para
llevar a cabo la estimacin de cada tarea. Para cada funcin 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 requerira para llevar a cabo cada una de
las actividades del proceso del software en cada funcin.

prctico.
CAPITULO 27: CALENDARIZACION DE

PROYECTO
27.1 Conceptos bsicos
La Calendarizacin es una actividad que distribuye estimaciones de esfuerzo a travs
de la duracin planificada del proyecto al esfuerzo de asignar tareas especficas de
ingerir.
27.2 Calendarizacin de proyecto
27.2.1 Principios bsicos

Compartimentacin
El proyecto debe dividirse en compartimentos en varias actividades,
acciones y tareas manejables.
Interdependencia
Se debe determinar la interdependencia de cada actividad, accin o
tarea compartimentada.
Asignacin de tiempo
A cada tarea se le debe asignar cierto nmero de unidades de trabajo
(Ej: personas-da de esfuerzo)
Definiciones responsabilidades
Asignar un miembro del equipo
Definicin de resultados
Toda tarea debe tener un resultado definido. (Ej: Diseo de un mdulo)
Definicin 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 Definicin de una red de tareas

Muestra las principales tareas de la ing de software, sus dependencias y si se pueden
ejecutar en paralelo

prctico.
27.5 Calendarizacin
Pueden utilizar tcnicas/herramientas calendarizacin de proyectos:
PERT (Tcnica de evaluacin y revisin de programa)
CPM (Mtodo de la Ruta Crtica)
Identificar todas las actividades que involucra el proyecto, lo que
significa, determinar relaciones de precedencia, tiempos tcnicos para
cada una de las actividades.
Construir una red con base en nodos y actividades (o arcos, segn el
mtodo ms usado), que implican el proyecto.
27.5.1 Cronograma
Diagrama de Gantt: Muestra la programacin vs tiempo calendario.
Uno por proyecto uno por cada funcin. Diamantes (rombos) marcan
hitos.

prctico.
27.5.2 Seguimiento de Calendario

Realizar reuniones peridicas del estado del proyecto, en las que cada
miembro del equipo reporte avances y problemas
Evaluar los resultados de todas las revisiones realizadas a travs del
proceso de ingeniera 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
valoracin subjetiva del avance a la fecha y los problemas en el
horizonte
Usar anlisis de valor ganado para valorar cuantitativamente el avance
27.5.3 Seguimiento de procesos para un proyecto

Hitos tcnicos: anlisis OO completo
Definicin y revisin de todas las clases y de la jerarqua de clases.
Definicin y revisin de los atributos de clase y de las operaciones
asociadas.

prctico.
Establecimiento y revisin de las relaciones de clase (captulo 6).

Creacin y revisin de un modelo de comportamiento (captulo 7).
Anotacin de las clases reutilizables.
Hitos tcnicos: diseo OO completo
Definicin y revisin del conjunto de subsistemas.
Asignacin de clases a subsistemas y su revisin.
Establecimiento y revisin de la asignacin de tareas.
Identificacin de responsabilidades y colaboraciones.
Diseo y revisin de atributos y operaciones.
Creacin y revisin del modelo de comunicacin.
Hitos tcnicos: programacin OO completa
Implementacin en cdigo de cada nueva clase, a partir del modelo de
diseo.
Implementacin de las clases extradas (a partir de la librera de
reutilizacin).
Construccin de prototipo o incremento.

prctico.
CAP 28 : ADMINITRACION DE RIESGO

Tomar medidas proactivas para evitarlos o manejarlos son elementos clave de una
buena administracin de proyecto de software.
28.1 ADMINISTRACION DE RIESGO:

- El anlisis y la administracin 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 anlisis y la administracin del
riesgo.
- El software es una empresa difcil. Muchas cosas pueden salir mal y,
francamente, muchas con frecuencia lo hacen. Por esta razn es que estar
preparado, comprender los riesgos y llamado identificacin de riesgos. A
continuacin, cada riesgo se analiza para determinar la probabilidad de que
ocurra y el dao que causar si ocurre. Una vez establecida esta informacin
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 informacin de riesgo.
- El MMMR debe revisarse conforme avance el proyecto para asegurarse de que
los riesgos se mantienen actualizados. Los planes de contingencia para
administracin del riesgo deben ser realistas.
28.4 ESTRATEGIAS REACTIVAS DE RIESGO FRENTE A ESTRATEGIAS

PROACTIVAS DE RIESGO
- Una estrategia considerablemente ms inteligente para la administracin del
riesgo es ser proactivo. Una estrategia proactiva comienza mucho antes de
iniciar el trabajo tcnico. 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 tcnico como en la organizacin), recursos,
participantes y requisitos, as como su impacto sobre un proyecto de software.

prctico.
- 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 compaa (riesgo estratgico).
3) Construir un producto que el equipo de ventas no sabe cmo 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 Genricos: Son una amenaza potencial a todo proyecto de
software.
28.4.2 Riesgos Especficos: Solo pueden identificarse solamente por quienes
tienen clara comprensin de la tecnologa, el personal y el entorno especfico
del software que se construye.
- Un mtodo para identificar riesgos es crear una lista de verificacin de tem de
riesgo. La lista de verificacin puede usarse para identificacin del riesgo y as
enfocarse sobre algn subconjunto de riesgos conocidos y predecibles en las
siguientes subcategoras genricas:
28.4.3 Tamao del producto: riesgos asociados con el tamao global del
software que se va a construir o a modificar.
28.4.4 Impacto empresarial: riesgos asociados con restricciones impuestas
por la administracin o por el mercado.
28.4.5 Caractersticas de los participantes: riesgos asociados con la
sofisticacin de los participantes y con la habilidad de los desarrolladores para
comunicarse con los participantes en forma oportuna.
28.5.6 Definicin 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
organizacin desarrolladora.
28.5.7 Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad
de las herramientas por usar para construir el producto.

prctico.
28.5.8 Tecnologa por construir: riesgos asociados con la complejidad del

sistema que se va a construir y con lo novedoso de la tecnologa que se
incluye en el sistema.
28.5.9 Tamao y experiencia del personal: riesgos asociados con la
experiencia tcnica y de proyecto global de los ingenieros de software que
harn el trabajo.
28.5 PROYECCION DE RIESGO:

-La proyeccin del riesgo, tambin llamada estimacin 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 tcnico para realizar cuatro pasos de proyeccin 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 precisin global de la proyeccin del riesgo de modo que no habr
malos entendidos.

prctico.
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 tcnica simple para proyeccin de
riesgos.

prctico.
- Comenzamos en elaborar una lista de todos los riesgos en la columna de la

tabla. Esto puede lograrse con la ayuda de listas de verificacin.
- Las categoras 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 priorizacin de riesgo de primer orden.
28.5 .3. VALORACION DE IMPACTO DE RIESGO:

-Identificacin de riesgo: De hecho, slo 70 por ciento de los componentes
de software calendarizados para reus se integrarn en la aplicacin. 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 slo puede usarse 70 por ciento, tendrn que desarrollarse 18 componentes
desde cero (adems de otro software a la medida que se calendariz para
desarrollo). Dado que el componente promedio es de 100 LOC y que los datos

prctico.
locales indican que el costo de la ingeniera del software para cada LOC es
US$14.00, el costo global (impacto) para desarrollar los componentes sera 18
X 100 X 14 = US$25 200. Exposicin al riesgo. ER X 0.80 X 25 200 ~ US$20
200.
- La exposicin al riesgo puede calcularse para cada riesgo en la tabla de
riesgo, una vez hecha la estimacin del costo del riesgo. La exposicin al
riesgo total para todos los riesgos (arriba del corte en la tabla de riesgos) puede
proporcionar los medios para ajustar la estimacin del costo final para un
proyecto. Tambin 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 planificacin del proyecto, un riesgo puede
enunciarse de manera muy general. Conforme pasa el tiempo y se aprende
ms acerca del proyecto y de los riesgos, es posible refinar el riesgo en un
conjunto de riesgos ms detallados, cada uno un poco ms sencillo de mitigar,
monitorear y manejar.
- Dado que todos los componentes de software reutilizables deben apegarse a
estndares de diseo especficos y dado que algunos no se apegan, entonces
existe preocupacin de que (posiblemente) slo 70 por ciento de los mdulos
reutilizables planeados puedan realmente integrarse en el sistema que se va a
construir, lo que da como resultado la necesidad de ingeniera a la medida del
restante 30 por ciento de los componentes.
Esta condicin general puede refinarse en la forma siguiente:
Subcondicin 1.- Ciertos componentes reutilizables los desarroll una tercera
persona sin conocimiento de los estndares de diseo internos.
Subcondicin 2.- El estndar de diseo para interfaces de componente todava
no se consolida y puede no apegarse a ciertos componentes reutilizables
existentes.
Subcondicin 3.-Ciertos componentes reutilizables se implementaron en un
lenguaje que no se so- porta en el entorno blanco.
28.7 MITIGACIN, MONITOREO Y MANEJO DE RIESGO:

- Todas las actividades de anlisis 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

prctico.
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

rotacin. Entre los posibles pasos por tomar estn:
- Reunirse con el personal actual para determinar las causas de la rotacin (por
ejemplo, pobres condiciones laborales, salario bajo, mercado laboral
competitivo).
- Mitigar aquellas causas que estn bajo su control antes de comenzar el
proyecto.
- Una vez iniciado el proyecto, suponer que la rotacin ocurrir y desarrollar
tcnicas para asegurar la continuidad cuando el personal se vaya.
- Organizar equipos de trabajo de modo que la informacin acerca de cada
actividad de desarrollo se disperse ampliamente.
- Definir estndares 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 ms de una
persona se ponga al da).
- Asignar un miembro de personal de respaldo para cada tcnico crtico.
28.8 EL PLAN MMMR:

- En el plan de proyecto del software puede incluirse una estrategia de
administracin del riesgo, o los pasos de administracin del riesgo pueden
organizarse en un plan de mitigacin, monitoreo y manejo de riesgo (MMMR) por
separado. El plan MMMR documenta todo el trabajo realizado como parte del
anlisis de riesgos y el gerente del proyecto lo usa como parte del plan de proyecto
global.

prctico.
CAP 29: MANTENIMIENTO Y REINGENIERIA
29.1 MANTENIMIENTO Y REINGENIERA:

- Sin importar su dominio de aplicacin, su tamao 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 caractersticas o funciones y cuando la aplicacin se somete a
reingeniera para ofrecer beneficio en un contexto moderno.
- Ley de cambio continuo (1974): El software que se implement en un contexto
de cmputo 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 autorregulacin (1974): El proceso de evolucin del sistema tipo E es
autorregulable con medidas de distribucin de producto y de proceso cercanas
a lo normal.
- Ley de conservacin de estabilidad organizativa (1980): La tasa de actividad
global efectiva promedio en un sistema tipo E en evolucin no vara durante el
tiempo de vida del producto.
- Ley de conservacin 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 evolucin satisfactoria. El crecimiento excesivo disminuye dicho
dominio. Por tanto, el crecimiento incremental promedio permanece sin
variacin conforme el sistema evoluciona.
- Ley de crecimiento continuo (1980): El contenido funcional de los sistemas tipo
E debe aumentar continuamente para mantener la satisfaccin 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 realimentacin del sistema (1996): Los procesos evolutivos tipo E
constituyen sistemas de realimentacin 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 cuestin de das 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 quera saber nada del software cuando
se liber, ahora reconoce que puede ofrecerle beneficios inesperados.
Necesitar algunas mejoras para hacer que funcione en su mundo.

prctico.
29.3 SOPORTABILIDAD DEL SOFTWARE:

- Con la finalidad de dar soporte efectivo al software de grado industrial, su
organizacin (o su encargado) deben poder realizar las correcciones,
adaptaciones y mejoras que son parte de la actividad de mantenimiento. Pero,
adems, la organizacin debe proporcionar otras importantes actividades de
soporte que incluyen soporte operativo en marcha, soporte al usuario final y
actividades de reingeniera durante el ciclo de vida completo del software. Una
definicin 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 tambin provisin 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 funcin [SSO08].
- En esencia, la soportabilidad es uno de los muchos factores de calidad que
deben considerarse durante las acciones de anlisis y diseo que son parte del
proceso de software. Deben abordarse como parte del modelo (o
especificacin) de requisitos y considerarse conforme el diseo evoluciona y
comienza la construccin.
29.4 REINGENIERIA:
- En la actualidad, las principales compaas tienen decenas de miles de
programas de cmputo 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 creacin de grandes y novedosos sistemas
basados en cmputo. Pero en muchos otros, significa la modificacin o
reconstruccin de las aplicaciones existentes. En las secciones que siguen, se
examina la reingeniera en una forma descendente, comenzando con un breve
panorama de la reingeniera de los procesos de empresas y avanzando hacia
un anlisis ms detallado de las actividades tcnicas que ocurren cuando el
software se somete a reingeniera.
29.5 REINGENIERA DE PROCESOS DE EMPRESA:

- La reingeniera de procesos de empresa (RPE) se extiende ms all del mbito
de las tecnologas de la informacin y de la ingeniera de software. Entre las
muchas definiciones (la mayora un tanto abstractas) que se han sugerido para
la RPE, la bsqueda, e implementacin, 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 lgicamente relacionadas,
que se realizan para lograr un resultado empresarial definido. Dentro del

prctico.
proceso empresarial, personal, equipo, recursos materiales y procedimientos

empresariales se combinan para producir un resultado especfico.
Empresa sistemas empresariales procesos empresariales
subprocesos empresariales.
- Cada sistema empresarial (tambin llamado funcin empresarial) est
compuesto de uno o ms procesos empresariales, y cada proceso empresarial
se define mediante un conjunto de subprocesos.
- La RPE puede aplicarse en cualquier nivel de la jerarqua, pero conforme se
ensancha su mbito (es decir, conforme se avanza hacia arriba en la
jerarqua), los riesgos asociados con la RPE crecen de manera dramtica. Por
esta razn, la mayora de los esfuerzos RPE se enfocan en procesos o
subprocesos individuales.
29.6 MODELO RPE:

- Como la mayora de las actividades de ingeniera, la reingeniera 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 razn,
no hay inicio ni fin de la RPE: es un proceso evolutivo.

prctico.
29.7 REINGENIERIA DE SOFTWARE:

- Una aplicacin que atendi las necesidades empresariales de una compaa
durante 10 o 15 aos. 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 reingeniera de software se produjo por los problemas de
mantenimiento de software que se acumularon durante ms de cuatro
dcadas.
29.8 Un modelo de proceso de reingeniera de software:

- La reingeniera toma tiempo, cuesta cantidades significativas de dinero y
absorbe recursos que de otro modo pueden ocuparse en preocupaciones
inmediatas. Por todas estas razones, la reingeniera no se logra en pocos
meses o incluso en algunos aos. La reingeniera de los sistemas de
informacin es una actividad que absorber recursos de tecnologa de la
informacin durante muchos aos. Por esto, toda organizacin necesita una
estrategia pragmtica para la reingeniera 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. Cmo procedera?
- Antes de comenzar a reconstruir, parecera razonable inspeccionar la casa.
Para determinar si necesita reconstruirse, usted (o un inspector profesional)
crea una lista de criterios, de modo que su inspeccin sea sistemtica.
- Antes de demoler y reconstruir toda la casa, asegrese de que la estructura es
dbil. Si la casa es estructuralmente slida, acaso sea posible remodelar sin
reconstruir (a un costo mucho ms bajo y en mucho menos tiempo).
- Antes de comenzar a reconstruir, asegrese de entender cmo se construy la

original. Eche un vistazo detrs de las paredes. Entienda cmo estn el
alambrado, la plomera y la estructura interna. Incluso si tira todo a la basura, la
comprensin que obtenga le servir cuando comience la construccin.
- Si comienza a reconstruir, use solamente los materiales ms modernos y ms

duraderos. Esto puede costar un poco ms ahora, pero le ayudar a evitar
costos y tardados mantenimientos posteriores.
- Si decide reconstruir, sea disciplinado en ello. Use prcticas que resultarn en

alta calidad, hoy y en el futuro.

prctico.
- Aunque estos principios se enfocan en la reconstruccin de una casa se

aplican igualmente bien a la reingeniera de los sistemas y aplicaciones
basados en cmputo.
29.9Actividades de reingeniera de software:
29.9.1 Anlisis de inventarios: Toda organizacin de software debe tener un

inventario de todas las aplicaciones. El inventario puede ser nada ms que un
modelo de hojas de clculo que contenga informacin que ofrezca una
descripcin detallada (por ejemplo, tamao, edad, importancia empresarial) de
cada aplicacin activa.
29.9.2 Reestructuracin de documentos:
La documentacin dbil es el distintivo de muchos sistemas heredados. Pero,
qu puede hacer con ella? Cules son sus opciones?
1. La creacin de documentacin 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 documentacin para cientos de
programas de cmputo.
2. La documentacin debe actualizarse, pero su organizacin tiene recursos
limitados. Use un enfoque documente cuando toque. Acaso no sea necesario
volver a documentar por completo una aplicacin. 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:

prctico.
- La ingeniera inversa para software es el proceso de analizar un programa

con la intencin de crear una representacin del mismo en un nivel superior de
abstraccin que el cdigo fuente. La ingeniera inversa es un proceso de
recuperacin de diseo. Las herramientas de ingeniera inversa extraen
informacin de diseo de datos, arquitectnico y procedimental de un programa
existente.
- Reestructuracin de cdigo:
- Para realizar esta actividad se analiza el cdigo fuente con una herramienta
de reestructuracin. Las violaciones a los constructos de programacin
estructurada se anotan y luego el cdigo se reestructura (esto puede hacerse
automticamente) o incluso se reescribe en un lenguaje de programacin ms
moderno. El cdigo reestructurado resultante se revisa y pone a prueba para
garantizar que no se introdujeron anomalas. La documentacin de cdigo
interna se actualiza.
- Reestructuracin de datos:
- Un programa con arquitectura de datos dbil ser difcil de adaptar y mejorar.
De hecho, para muchas aplicaciones, la arquitectura de informacin tiene ms
que ver con la viabilidad a largo plazo de un programa que con el cdigo fuente
en s.
29.10 INGENIERA INVERSA:

- La ingeniera inversa puede extraer informacin de diseo a partir del cdigo
fuente, pero el nivel de abstraccin, la completitud de la documentacin, 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 abstraccin de un proceso de ingeniera inversa y las herramientas
usadas para efectuarla tienen que ver con la sofisticacin de la informacin de
diseo que puede extraerse del cdigo fuente. De manera ideal, el nivel de
abstraccin debe ser tan alto como sea posible, es decir, el proceso de
ingeniera inversa debe ser capaz de inferir representaciones de diseo
procedimental (una abstraccin de bajo nivel), informacin de estructura de
programa y datos (un nivel de abstraccin un poco ms alto), modelos de
objeto, modelos de datos y/o flujo de control (un nivel de abstraccin
relativamente alto) y modelos de relacin de entidad (un nivel de abstraccin
alto). Conforme aumenta el nivel de abstraccin se proporciona informacin
que permitir facilitar la comprensin del programa.

prctico.
- Proceso de Ingeniera Inversa:

prctico.
29.11 Ingeniera inversa para comprender datos:

- La ingeniera inversa de datos ocurre en diferentes niveles de abstraccin y
con frecuencia es la primera tarea de reingeniera. En el nivel del programa, las
estructuras de datos internas del programa con frecuencia deben someterse a
ingeniera inversa como parte de un esfuerzo de reingeniera global.
- En el nivel del sistema, las estructuras de datos globales con frecuencia se
someten a reingeniera para acomodar nuevos paradigmas de administracin
de base de datos. La ingeniera inversa de las estructuras de datos globales
actuales monta el escenario para la introduccin de una nueva base de datos
en todo el sistema.
29.12 Ingeniera inversa para entender el procesamiento:

- La ingeniera inversa para entender el procesamiento comienza con un intento
por comprender y luego extraer abstracciones procedimentales representadas
mediante el cdigo fuente.
- Para comprender las abstracciones procedimentales se analiza el cdigo en
varios niveles de abstraccin: sistema, programa, componente, patrn y
enunciado.
- Para sistemas grandes, la ingeniera inversa por lo general se logra usando un
enfoque semiautomatizado. Es posible usar herramientas automatizadas para
auxiliarse en la comprensin de la semntica del cdigo existente. La salida de
este proceso pasa entonces a reestructuracin de herramientas de ingeniera
hacia adelante a fin de completar el proceso de reingeniera.
29. 13 Ingeniera inversa de interfaces de usuario:

- Las GUI (interfaces de usuario grficas) 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
ms comunes de actividad de reingeniera. Pero antes de poder reconstruir una
interfaz de usuario, debe realizarse ingeniera inversa.
29.14 REESTRUCTURACION:
- La reestructuracin de software modifica el cdigo fuente y/o los datos con la
intencin de hacerlos sensibles a cambios futuros. En general, la
reestructuracin no modifica la arquitectura global del programa.
- La reestructuracin ocurre cuando la arquitectura bsica de una aplicacin es
slida, aun cuando el interior tcnico necesite trabajarse. Se inicia cuando
grandes partes del software son aprovechables y slo un subconjunto de todos
los mdulos y datos necesitan modificacin extensa.
29.14.1 Reestructuracin de cdigo:

- La reestructuracin de cdigo se realiza para producir un diseo que produzca
la misma funcin pero con mayor calidad que el programa original.

prctico.
29.14.2 Reestructuracin de datos:

- Antes de que pueda comenzar la reestructuracin de datos debe realizarse una
actividad de ingeniera inversa llamada anlisis de cdigo fuente.
- La intencin es extraer tems de datos y objetos, obtener informacin acerca
del flujo de datos y entender las estructuras de datos existentes que se
implementaron. Esta actividad en ocasiones se llama anlisis de datos.
29.15 INGENIERA HACIA ADELANTE:

- Para implementar los cambios necesarios puede luchar a travs de
modificacin tras modificacin, combatir al diseo ad hoc y el cdigo fuente
enredado.
- Puede intentar comprender los funcionamientos interiores ms amplios del
programa con la intencin de hacer modificaciones de manera ms efectiva.
- Puede redisear, recodificar y poner a prueba aquellas porciones del software
que requieran modificacin y aplicar un enfoque de ingeniera de software a
todos los segmentos revisados.
- Puede redisear, recodificar y poner a prueba completamente el programa, y
usar herramientas de reingeniera para ayudar a comprender el diseo actual.
29.15.1 Ingeniera hacia adelante para arquitecturas cliente-servidor:

- En esencia, los recursos de cmputo centralizados (incluido el software) se
distribuyen entre muchas plataformas cliente. Aunque pueden disearse varios
entornos distribuidos, la aplicacin mainframe tpica que se somete a
reingeniera en una arquitectura cliente-servidor tiene las siguientes
caractersticas:
- La funcionalidad de la aplicacin 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, anlisis 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 Ingeniera hacia adelante para arquitecturas orientadas a objetos:

- La ingeniera de software orientada a objetos se ha convertido en el paradigma
de desarrollo elegido por muchas organizaciones de software.
- La reingeniera de software convencional en una implementacin orientada a
objeto usa muchas de las mismas tcnicas estudiadas.
29.30 ECONOMA DE LA REINGENIERA:

- Todo programa no mantenible se retirara de inmediato para sustituirlo con
aplicaciones sometidas a reingeniera de alta calidad desarrolladas mediante
modernas prcticas de ingeniera de software. Pero se vive en un mundo de
recursos limitados. La reingeniera gasta recursos que pueden usarse para
otros propsitos empresariales.

prctico.
- Sneed propone un modelo de anlisis costo-beneficio para reingeniera,

definiendo nueve parmetros:
- El costo asociado con el mantenimiento continuo de una aplicacin candidata

(es decir, la reingeniera no se realiza) puede definirse como:
- El costo asociado con reingeniera se define usando la siguiente relacin:
- Con los costos presentados en las ecuaciones antes mencionadas, el beneficio

global de la reingeniera puede calcularse como:

Resumen Parte 4 Ingenieria Del Software

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Resumen Parte 4 Ingenieria Del Software

Caricato da

Copyright:

Formati disponibili

Semestre 2015 II

Universidad Nacional del Altiplano

Ingeniera del Software: Un enfoque prctico.

Ingeniera del Software: Un enfoque prctico.

CAPITULO 24: CONCEPTOS DE ADMINISTRACION DE PROYECTOS .................... 8

24.1 : EL ESPECTRO ADMINISTRATIVO ...................................................................................... 9

25.1: METRICA EN LOS DOMINIOS DE PROCESO Y PROYECTO ............................................... 16

Ingeniera de Sistemas Pgina 2 de 61

25.2 MEDICION DEL SOFTWARE ............................................................................................. 17

ESTRATEGIAS REACTIVAS DE RIESGO FRENTE A ESTRATEGIAS PROACTIVAS DE RIESGO ...... 20

MANTENIMIENTO DE SOFTWARE: .......................................................................................... 27

Ingeniera inversa para comprender datos: ............................................................................ 34

Ingeniera de Sistemas Pgina 3 de 61

26.1 Observaciones acerca de las estimaciones ..................................................................... 37

27.1 Conceptos bsicos .......................................................................................................... 41

28.1 ADMINISTRACION DE RIESGO: ........................................................................................ 45

Ingeniera de Sistemas Pgina 4 de 61

28.4 IDENTIFICACION DE RIESGOS: ......................................................................................... 46

29.2 MANTENIMIENTO DE SOFTWARE: .................................................................................. 52

Ingeniera de Sistemas Pgina 5 de 61

29.14.1 Reestructuracin de cdigo: ........................................................................... 59

Ingeniera de Sistemas Pgina 6 de 61

Ingeniera de Sistemas Pgina 7 de 61

CAPITULO 24: CONCEPTOS DE

Ingeniera de Sistemas Pgina 8 de 61

24.1 : EL ESPECTRO ADMINISTRATIVO

Desde la dcada de 1960 se estudia la formacin de personal de software motivado y

Antes de planear un Proyecto debemos establecer los objetivos y el mbito del

Un proceso de software proporciona el marco conceptual el cual puede ser establecido

Ingeniera de Sistemas Pgina 9 de 61

Los proyectos de software se planean y controlan debido a una razn principal: es la

El personal es la herramienta mas importante, el factor humano ha determinado

24.2.1: LOS PARTICIPANTES

El proceso de software involucra muchos participantes, pero podemos diferenciarlos

Ingeniera de Sistemas Pgina 10 de 61

24.2.2: LIDERES DE EQUIPO

Para que la administracin de un proyecto sea efectiva y se desarrolle con mucha

24.2.3: EL EQUIPO DE SOFTWARE

Existen muchos modelos y estructuras de organizacin humana para el desarrollo de

24.2.4: EQUIPOS AGILES

Ingeniera de Sistemas Pgina 11 de 61

24.2.5: CONFLICTOS DE COORDINACION Y COMUNICACIN

La interoperabilidad se ha convertido en una caracterstica clave de muchos sistemas.

Se requieren estimaciones cuantitativas y un plan organizado, pero no hay informacin

24.3.1: AMBITO DEL SOFTWARE

Esta es una de las primeras actividades en la administracin del proyecto de software,

No debe haber ambigedades ni se incomprensibles en los niveles administrativo

Ingeniera de Sistemas Pgina 12 de 61

enunciados de manera explicita , se anotan las restricciones y/o limitaciones (por

24.3.2: DESCOMPOSICION DEL PROBLEMA

2.4.1: FUSION DE PRODUCTO Y PROCESO

La planificacin del proyecto comienza con la fusin de producto y proceso, en esencia

2.4.2 DESCOMPOSICION DEL PROCESO

La descomposicin del proceso beneficiara al desarrollo de las actividades

Ingeniera de Sistemas Pgina 13 de 61

Planificar y calendarizar una reunin formal facilitada con todos los

24.6: EL PRINCIPIO W5HH

Ingeniera de Sistemas Pgina 14 de 61

-. Dnde (where) se ubicarn en la organizacin? No todos los roles y

Ingeniera de Sistemas Pgina 15 de 61

CAPITULO 25. METRICAS DE PROCESO Y

25.1: METRICA EN LOS DOMINIOS DE PROCESO Y PROYECTO

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