Pressman GestionProyectosSofware

IS074 Pressman Cáp.
21
Administración de Proyectos Conceptos Gestión PSW
Capítulo 21: Conceptos de Gestión de Proyectos

1. El espectro de la gestión: una gestión eficaz se enfoca en las cuatro P: personal,
producto, proceso y proyecto. El orden no es arbitrario. Un gestor que fracasa en alentar la
comunicación con los participantes en etapas tempranas del proyecto se arriesga a
construir una solución elegante para el problema equivocado. El gestor que se embarca sin
un plan de proyecto sólido arriesga el éxito del producto.
1.1. El personal: el factor humano es tan importante que el Software Engineering Institute
ha creado un modelo de madurez de la capacidad de gestión de personal (MMCGP)
para aumentar la rapidez en que se crean las aplicaciones cada vez más complejas
para retener el talento necesario para mejorar su capacidad de desarrollo de software.
El modelo de madurez se define en las siguientes áreas claves prácticas para el
personal de software: reclutamiento, selección, gestión del desempeño,
entrenamiento, retribución, desarrollo de la carrera, diseño de la organización y el
trabajo, y desarrollo de la cultura de equipo.
1.2. El producto: antes de planear un proyecto se deberían establecer los objetivos y el
ámbito del producto, considerar soluciones alternativas e identificar restricciones
técnicas y de gestión. Sin esta información no se podrían definir estimaciones
(precisas) del costo, una valoración del riesgo, una visión realista de las tareas del
proyecto o un calendario de proyecto que indique el progreso. El desarrollador y el
cliente se deben de reunir para definir los objetivos y el ámbito del producto. Los
objetivos identifican las metas globales del producto (desde el punto de vista del
cliente) sin considerar cómo se lograrán. El ámbito identifica los datos primarios, las
funciones y los comportamientos que caracterizan al producto y los intentos por
enlazar las características en una forma cuantitativa. Y una vez entendidos los
objetivos y el ámbito se consideran soluciones alternativas.
1.3. El proceso: proporciona el marco de trabajo donde se puede establecer un plan
detallado para el desarrollo del software. Algunos conjuntos de tareas diferentes
(tareas, hitos, productos de trabajo y puntos de control de calidad) permiten que las
actividades del marco de trabajo se adapten a las características del proyecto, así
como a los requisitos del equipo del proyecto. Las actividades protectoras (como el
control de calidad del software, la gestión de configuración del software y la medición)
son independientes de cualquier actividad del marco de trabajo y ocurre durante todo
el proceso.
1.4. El proyecto: se realizan de manera planificada y controlada por que es la única forma
conocida de gestionar la complejidad. Para evitar el fracaso del proyecto, un gestor de
proyecto de software y los ingenieros que contribuyen el producto deben eludir un
conjunto de señales de advertencia, comprender los factores de éxito críticos que
conducen a una buena gestión del proyecto y desarrollar un enfoque de sentido
común para planificar, supervisar y controlar el proyecto.
2. Personal: muchos de los vicepresidentes de grandes compañías no prestan atención al
personal. Los gestores argumentan que las personas son lo principal, pero sus acciones
con frecuencia contradicen sus palabras.
2.1. Los participantes lo integran 5 categorías:
1) Gestores ejecutivos, que definen los aspectos del negocio que tienen una
influencia significativa en el proyecto.
2) Gestores (técnicos) del proyecto, quienes planifican, motivan, organizan y
controlan a los profesionales que realizan el trabajo de software.
3) Profesionales, quienes proporcionan las habilidades técnicas necesarias para
realizar la ingeniería de un producto o aplicación.
4) Clientes, quienes especifican los requerimientos para la ingeniería del software y
otros elementos que tienen un interés mínimo en el resultado.
5) Usuarios finales, quienes interactúan con el software una vez que se libera para su
uso productivo.
Adrián Rojas González Pág. 1

IS074 Pressman Cáp. 21
2.2. Líderes de equipo: las actividades son humanas, pero los profesionales competentes
con frecuencia no son buenos líderes de equipo. No tienen la mezcla correcta de
habilidades con el personal. Modelo MOI sugiere: Motivación: la habilidad para
alentar al personal técnico para que se produzca según su mejor capacidad.
Organización: la habilidad para adecuar los procesos existentes que permitirán que el
concepto inicial sea traducido en un producto final.
Ideas o innovación: la habilidad para alentar a la gente a crear y sentir creativamente,
incluso cuando deben trabajar dentro de los límites establecidos por un producto o
aplicación de software. Otra visión de las características que definen un gestor de
proyecto eficiente resalta 4 rasgos clave:
Resolución de problemas: puede diagnosticar los conflictos técnicos y organizativos
más relevantes, estructurar de manera sistemática una solución o motivar
adecuadamente a otros profesionales para desarrollar la solución, aplicar nuevas
situaciones en proyectos anteriores, y mantenerse lo suficientemente flexible como
para cambiar de dirección si los intentos iniciales no son los correctos Dotes de
gestión: debe de tener la confianza de asumir el control cuando es necesario y la
seguridad para permitir que los buenos profesionales técnicos sigan sus instintos.
Incentivos: para optimizar la productividad de un equipo de proyecto, un gestor debe
compensar la iniciativa y los logros. Influencia y fomento de la cultura de equipo: un
gestor de proyecto eficaz debe ser capaz de leer a la gente y reaccionar a las
necesidades de la gente que las envía.
2.3. El equipo de software: la estructura organizacional no puede ser fácilmente
modificada. La mejor estructura de equipo depende del estilo de gestión de cada
organización, del número de personas que la integrarán el equipo y de sus grados de
habilidad, así como de la dificultad global del problema. Los 7 factores de proyecto
que deberían considerarse cuando se planifica la estructura de los equipos de
ingeniería del software son:
• La dificultad del problema que se resolverá.
• El tamaño del programa resultante en líneas de código o puntos de función.
• El tiempo que el quipo estará junto.
• El grado en que el problema puede separarse en módulos.
• La calidad y confiabilidad requeridos del sistema que se construirá.
• La rigidez de la fecha de entrega.
• El grado de sociabilidad (comunicación) que requiere el proyecto.
Cuatro paradigmas organizacionales para los equipos de ingeniería del software son:
1) Paradigma cerrado, estructura un equipo a lo largo de una jerarquía tradicional de
autoridad. Estos equipos trabajarán mejor cuando hacen software similar a
proyectos anteriores, pero serán poco innovadores.
2) Paradigma aleatorio, estructura un equipo libremente y depende de la iniciativa
individual de los miembros del equipo. Son innovadores y estos equipos pueden
luchar cuando se requiere desempeño ordenado.
3) Paradigma abierto, intenta estructurar un equipo en una forma que logre algunos
de los controles asociados con el paradigma cerrado, tienen mucho innovación
que ocurre cuando se aplica el paradigma aleatorio. El trabajo se desarrolla en
colaboración.
4) Paradigma sincrónico, se apoya en compartir un problema y organiza a los
miembros del equipo para trabajar en partes del problema con poca comunicación
activa entre ellos. Entonces equipo es cualquier grupo de personas asignadas a
trabajar juntas. Pero muchos de estos grupos no parecen equipos. No tienen una
definición común del éxito o algún espíritu de equipo identificable. Lo que se ha
perdido es un fenómeno que llamamos cuajar. Pero no todos los equipos cuajan lo
cual se llama “toxicidad de equipo” del cual se definen 5 factores:

1) Una atmósfera de trabajo frenética.

2) Alta frustración que provoca fricción entre los miembros del equipo.
3) Un proceso de software “fragmentado o pobremente coordinado”.
4) Una definición poco clara de los papeles del equipo de software.
5) Continuas y repetidas exposiciones al fracaso. Además de cinco toxinas el equipo
enfrenta los diferentes rasgos humanos de sus miembros. Algunos miembros del
equipo son extrovertidos; otros, introvertidos. Algunas personas recopilan
información intuitivamente; separan los conceptos amplios de los hechos
disparatados. Otros procesan la información linealmente, reúnen y organizan
detalles minuciosos de los datos proporcionados, etc.
2.4. Equipos ágiles: la filosofía ágil alimenta la satisfacción del cliente y la temprana
entrega incremental de software. El pequeño equipo de trabajo enormemente
motivado, también llamado equipo ágil, adopta muchas características de los equipos
de proyecto de software exitosos y evitan muchas de las toxinas que crean problemas.
Para aprovechar en forma eficiente las competencias de cada miembro del equipo y
fomentar la colaboración eficaz a lo largo de un proyecto de software, los equipos
ágiles son autoorganizados. Conforme el proyecto avanza el equipo se auto organiza
para enfocar la competencia individual en una forma que sea más benéfica para el
proyecto en un punto dado en el tiempo. Para lograrlo un equipo ágil puede dirigir
breves reuniones de equipo diarias para coordinar y sincronizar el trabajo que se debe
lograr ese día. Con base en la información obtenida durante esas reuniones, el equipo
adapta su enfoque de forma tal que logra un incremento de trabajo.
2.5. Conflictos de coordinación y comunicación: la escala de muchos esfuerzos de
desarrollo es grande, lo que conduce a la complejidad, confusión y dificultades
significativas en la coordinación de los miembros del equipo. La incertidumbre genera
una corriente continua de cambios que mueve gradualmente en una sola dirección al
equipo del proyecto. La interoperabilidad es donde el software nuevo debe
comunicarse con el anterior y adecuarse a las restricciones predefinidas que impone
el sistema o producto. Para lidiar con estos aspectos en forma eficaz el equipo debe
establecer métodos eficientes para coordinar al personal que realiza el trabajo. Para
lograrlo se debe de establecer mecanismos para la comunicación formal e informal
entre los miembros del equipo y entre múltiples equipos. La comunicación formal se
logra por medio de “escritos”, reuniones estructuradas y otros canales de
comunicación relativamente no interactivos e impersonales. La comunicación informal
es cuando los miembros de un equipo comparten ideas sobre una base, piden ayuda
cuando surgen problemas e interactúan unos con otros diariamente.
3. El producto: es donde el gestor requiere estimaciones cuantitativas y un plan organizado,
pero no dispone de información sólida. Un análisis detallado de los requisitos
proporcionaría la información necesaria para las estimasiones, pero esto llevaría mucho
tiempo en completarse y también los requisitos cambian regularmente conforme el proyecto
avanza.
3.1. Ámbito del software: se define al responder las siguiente preguntas:
Contexto. ¿Cómo encaja el software que se desarrollará en un sistema más grande,
producto o contexto de negocios, y qué restricciones se imponen como resultado del
contexto? Objetivos de
información. ¿Qué objetos de datos visibles al usuario se peoducen como resultado
del software? ¿Qué objetos de datos se requieren en entrada?
Función y desempeño. ¿Qué funciones realiza el software para transformar los datos
de entrada en salida? ¿Existen algunas características de desempeño especiales que
deban abordarse?
3.2. Descomposición del problema: es una actividad que se asienta en el núcleo del
análisis de requisitos de software. La descomposición se aplica en dos grandes áreas:
1) La funcionalidad que debe entregarse.
2) El proceso que se empleará para entregarla. Un
problema complejo se divide en problemas menores que resultan más manejables.

Puesto que las estimaciones de costo y planificación temporal están funcionalmente

orientadas, con frecuencia es útil cierto grado de descomposición.
4. El proceso: el gestor del proyecto debe decidir cuál modelo de proceso es más adecuado
para:
1. Los clientes que han solicitado el producto y el personal que hará el trabajo.
2. Las características del producto mismo.
3.El ambiente del proyecto en el que trabaja el equipo de software. Cuando ya se ha definido
un modelo de proceso, entonces el equipo define un plan de proyecto preliminar con base en el
conjunto de actividades del marco de trabajo del proceso.
4.1. Combinación del producto y el proceso: cada función que el equipo de software
someterá a ingeniería debe pasar a través del conjunto de actividades del marco de
trabajo definidas para una organización de software. El trabajo del gestor del proyecto
(y de otros miembros del equipo) consiste en estimar los requisitos de recursos.
4.2. Descomposición del proceso: un equipo de software debe tener un grado significativo
de flexibilidad al elegir el modelo de proceso de software que sea mejor para el
proyecto y las tareas de ingenería del software que integren el modelo de proceso una
vez elegido. Una vez elegido el modelo de proceso, el marco de trabajo respectivo se
adapta a él. El marco de trabajo del proceso es invariable y sirve como base para todo
el trabajo de software que realiza una organización de software.
5. El proyecto: la gestión de un proyecto de software exitoso requiere entender qué puede
salir mal (de modo que sea factible evitar los problemas). Donde las 10 señales que indican
que un proyecto de sistemas de información está en peligro son:
1) El personal de software no entiende las necesidades de sus clientes.
2) El ámbito del producto está mal definido.
3) Los cambios se gestionan mal.
4) La tecnología elegida cambia.
5) Las necesidades comerciales cambian (o están mal definidas).
6) Los plazos de entrega no son realistas.
7) Los usuarios se resisten.
8) Se pierde el patrocinio (o nunca se obtuvo de manera adecuada).
9) El equipo de proyecto carece de personal con las habilidades apropiadas.
10) Los gestores (y los profesionales) evitan las mejores prácticas y las lecciones aprendidas.
Entonces ¿Cómo actúa un gestor para evitar los problemas recién señalados? Se sugiere
un enfoque de sentido común de 5 partes para proyectos de software que son:
1) Comience con el pie derecho: esto se logra trabajando duro para entender el problema que
será resuelto y entonces establecer objetivos y expectativas realistas para todos lo que
estarán involucrados en el proyecto.
2) Mantenga el ímpetu: muchos proyectos tienen un buen comienzo y luego lentamente se
desintegran. Para mantenerlo el gestor debe proporcionar incentivos para conservar los
reveses del personal en un mínimo absoluto; el equipo debe resaltar la calidad en cada
tarea que realiza, y los gestores ejecutivos deben hacer todo lo posible por mantenerse
fuera del camino del equipo.
3) Rastree el progreso: se rastrea conforme se elaboran los productos de trabajo y se
aprueban (mediante revisiones técnicas formales) como parte de una actividad de
aseguramiento de la calidad.
4) Tome decisiones inteligentes: las decisiones del gestor del proyecto y del equipo de
software deben caminarse a “mantenerlo simple”.
5) Realice un análisis de resultados: establezca un mecanismo consistente para extraer
lecciones aprendidas por cada proyecto. Evalúe la planificación real y la prevista, recolecte

y analice métricas de proyecto de software, obtenga realimentación de los miembros del

equipo y de los clientes, y registre los hallazgos de forma escrita.

Administración de Proyectos Métricas de Procesos en PSW
Capitulo 22: “Métricas de proceso y de proyecto”

Las métricas del proceso y mejora del proceso de software
Las métricas del proceso tienen impacto a largo plazo y se utilizan con fines estratégicos. Su
objetivo es mejorar el proceso en sí. Con frecuencia, las métricas del proyecto contribuyen al
desarrollo de métricas de proceso. Por esto las mismas métricas se utilizan en el dominio de
proceso como de proyecto.
1 Métricas del proceso y mejora del proceso del software
La manera de mejorar cualquier proceso es medir sus atributos específicos. Aunque es
importante conocer esto, también debemos saber que el proceso sólo es uno de varios factores
controlables en la mejora de la calidad del software y el desempeño organizacional. La
habilidad y motivación del personal de software que realiza el trabajo son los factores más
importantes que influyen en la calidad del software, así también como la tecnología utilizada.
La eficacia de un proyecto la medimos deduciendo un conjunto de métricas basadas en los
resultados que se derivan del proceso y los resultados van a incluir medidas de errores antes
de liberar el software, defectos que detectan usuarios finales, etc.
Existen usos privados y públicos para diferentes tipos de datos del proceso. Entre métricas
privadas encontramos índices de defecto por individuo, índices de defecto por componente de
software y errores encontrados durante el desarrollo. Estos datos pueden funcionar como un
importante promotor para que el trabajo individual del ingeniero del software mejore. Las
métricas públicas por lo general asimilan información que originalmente era privada para los
individuos.
1.1 Métricas de proyecto
La primera aplicación de las métricas del proyecto en la mayoría de los proyectos se da en la
etapa de estimación, las cuales nos sirven de base para las estimaciones de esfuerzo y tiempo
para el trabajo de software actual. Luego conforme avanzamos se comparan las métricas que
utilizamos con las estimaciones originales para ver el progreso.
Las métricas de proceso tienen dos funciones: la primera es para minimizar el tiempo de
desarrollo haciendo los ajustes necesarios para evitar demoras y reducir los problemas y
riesgos potenciales. Segundo se utilizan para valorar la calidad del producto sobre una base
actual, y cuando es necesario, modificar el enfoque técnico para mejorar la calidad.
2. Medición del software
La medición del software se clasifica en dos categorías:
1. Medidas directas del proceso de software y del producto.
2. Medidas indirectas del producto que incluyen funcionalidad, calidad, complejidad,
eficiencia, confiabilidad, facilidad de mantenimiento.
2.1 Métricas orientadas al tamaño (LDC)
Las métricas de software orientadas al tamaño preceden de la normalización de las medidas de
calidad o productividad considerando el tamaño del software que se ha producido. Estas
métricas utilizan las líneas de código como medida.
Las métricas orientadas al tamaño no se aceptan universalmente como la mejor forma de medir
el proceso de software.
2.2Métricas orientadas a la función (PF)
Las métricas de software orientadas a la función emplean como un valor de normalización una
medida de la funcionalidad que entrega la aplicación. La métrica orientada a la función utilizada
con mayor amplitud es el punto de función que se calcula basado en características del
dominio de información y la complejidad del software.
2.3 Reconciliación de las métricas LDC y PF
La relación entre líneas de código y puntos de función depende del lenguaje de programación
en que se implementan el software y la calidad del diseño. Se ha encontrado que las métricas
Ignacio Granados Pág. 1

basadas en puntos de función y LDC son indicadores relativamente precisos del esfuerzo y el
costo del desarrollo de software.
2.4 Métricas orientadas a objetos
Las métricas tradicionales se aplican en la estimación de proyectos de software orientados a
objetos, sin embargo, estas métricas no proporcionan suficiente granularidad para la
planificación y los ajustes de esfuerzo que se requieren conforme se itera a lo largo de un
proceso evolutivo o incremental. Se sugiere el siguiente conjunto de métricas par proyectos
OO:
• Número de guiones de escenario
• Número de clases clave
• Número de clases de apoyo
• Número promedio de clases de apoyo por clase clave
• Número de subsistemas
2.5 Métricas orientadas a casos de uso
Los casos de uso describen indirectamente funciones y características visibles al usuario que
son requisitos básicos para un sistema. El caso de uso es independiente del lenguaje de
programación. Además el caso de uso es proporcional al tamaño de la aplicación LDC, así
como al número de casos de prueba que tendrán que diseñarse para ejercitar completamente
la aplicación.
2.6 Métricas de proyectos de ingeniería Web
Las medidas de métricas de proyectos tradicionales son difíciles de traducir a aplicaciones
Web. Por eso se recopilan las siguientes métricas para aplicaciones Web:
• Número de páginas Web estáticas
• Número de páginas Web dinámicas
• Número de vínculos internos de página
• Número de objetos de datos persistentes
• Número de sistemas externos en interfaz
• Número de objetos de contenido estático
• Número de objetos de contenido dinámico
• Número de funciones ejecutables
3. Métricas para la calidad del software
La meta primordial de la ingeniería del software es producir un sistema, aplicación o producto
de alta calidad dentro de un marco temporal que satisfaga una necesidad del mercado.
3.1 Medición de la calidad
Existen muchas formas de medir la calidad pero las más importantes son:
• Corrección: Un programa debe operar correctamente o proporcionará poco valor para
sus usuarios. La corrección es el grado en que el software desempeña la función para
la que fue creado.
• Facilidad de mantenimiento: La facilidad de mantenimiento es la sencillez con la que
un programa puede corregirse si se encuentra un error, adaptarse si su entorno
cambia, o mejorar si el cliente desea un cambio en los requisitos.
• Integridad: Este atributo mide la habilidad de un sistema para resistir ataques a su
seguridad. Los ataques se pueden presentar en los tres componentes del software:
programas, datos y documentos.

• Facilidad de uso: La facilidad de uso es un intento por cuantificar la sencillez de la

aplicación al utilizarla y se puede medir en términos de las características.
3.2 Eficacia en la eliminación de elementos (EED)
Esta es una medida de la habilidad de filtrar las actividades de la garantía de cualidad y de
control conforme se aplica a través de todas las actividades del marco de trabajo del proceso.
Cuando de se considera un proyecto como un todo, la EED se define de la manera siguiente:
EED = E / (EED+D)
Donde E es el número de errores encontrados antes de entregar el software al usuario final y D
el número de defectos encontrados después de la entrega. El valor ideal de EED es 1.
La EED también se puede aplicar a la habilidad de un grupo a encontrar errores. En este
contexto funciona así:
EEDi= Ej / (Ei+1)
Donde Ei es el número de errores encontrado durante la actividad i de ingeniería de software y
Ei + 1 es el número de errores encontrado durante la actividad i+1 de ingeniería del software que
se puede seguir para llegar a errores que no fueron descubiertos en la actividad i de ingeniería.
Un objetivo de calidad es lograr que EED se acerque a 1, es decir, los errores deben filtrarse
antes de que pasen a la siguiente actividad.
4 Integración de las métricas dentro del proceso del software
4.1 Argumentos para las métricas de software
Es importante medir el proceso de ingeniería del software porque si no se mide no existe una
forma real de determinar si se está mejorando. Y si no se mejora, se está perdido, con esto se
pueden establecer metas significativas para mejorar el proceso del software.
4.2 Establecimiento de una línea base
Con una línea de base de métricas se obtienen beneficios en los ámbitos del proceso, del
proyecto y del producto. La línea base de métricas consiste de datos recopilados en proyectos
previos de desarrollo de software.
Los datos de la línea deben tener los siguientes atributos: los datos deber ser razonablemente
precisos, los datos deben recopilarse para tantos proyectos como sea posible, las medidas
deben ser consistentes y las aplicaciones deben ser similares al trabajo que se estimará.
4.3Recopilación, cálculo y evaluación de métricas
Los datos de métricas de línea base deben recopilarse de una gran muestra representativa de
proyectos de software previos. Dependiendo de la amplitud de las medidas recopiladas, las
métricas pueden abarcar una amplia gama de métricas orientadas a la aplicación, calidad o al
proyecto. La evaluación de las métricas se centra en las razones subyacentes de los resultados
obtenidos y produce un conjunto de indicadores que guían el proyecto o proceso.
5 Métricas para organizaciones pequeñas
Una organización pequeña puede seleccionar el siguiente conjunto de medidas que se
recopilan con facilidad:
• Tiempo transcurrido desde el momento en que se hizo una solicitud hasta que la
evaluación está completa, tcola
• Esfuerzo para realizar la evaluación, Teval
• Tiempo transcurrido desde que se completa la evaluación hasta la asignación del
pedido de cambio al personal, teval
• Esfuerzo requerido para hacer el cambio, Tcambio
• Tiempo requerido para hacer el cambio, tcambio
• Errores descubiertos durante el trabajo para hacer el cambio, Ecambio

• Defectos descubiertos después de que el cambio es liberado a la base de clientes,

Dcambio
La eficacia en la eliminación de defectos se puede calcular como
EED= Ecambio / (Ecambio + Dcambi o )
6 Establecimiento de un programa de métricas de software
1. Identificar los objetivos de la empresa
2. Identificar lo que se quiere conocer o aprender
3. Identificar los subobjetivos
4. Identificar las entidades y atributos relacionados con los objetivos secundarios
5. Formalizar los objetivos de la medición
6. Identificar preguntas cuantificables y los indicadores relacionados que se emplearán
como apoyo para lograr los objetivos de sus mediciones.
7. Identificar los elementos de datos que se recopilarán para construir los indicadores que
ayudarán a responder las preguntas.
8. Definir las medidas que se emplearán y hacer que estas definiciones sean operativas
9. Identificarlas acciones que se tomarán para implementar las medidas
10. Preparar un plan para implementar las medidas.
Al trabajar como equipo, la ingeniería del software y los gestores del negocio pueden
confeccionar una lista de metas priorizadas del negocio:
1. Mejorar la satisfacción de los clientes con los productos
2. Hacer que los productos sean más fáciles de usar
3. reducir el tiempo que toma poner un producto en el mercado
4. Simplificar el soporte para los productos
5. Mejorar la obtención global de utilidades

Administración de Proyectos Estimación para PSW
Capitulo 23: Estimación para Proyectos de Software

La gestión del proyecto de software comienza con un conjunto de actividades que en grupo se
denominan planificación del proyecto, siendo el tema de los costos el punto fundamental de
cualquier proyecto su estimación se convierte en un punto de mucha relevancia para los
proyectos en nuestros tiempos.
Términos
LDC Líneas de Código
PF Punto de fusión
Observación acerca de la estimación
La planificación requiere que los gestores técnicos y los miembros del equipo establezcan un
compromiso inicial aun cuando sea probable que este compromiso pruebe estar equivocado.
Aunque la estimación es tanto un arte como una ciencia esta importante actividad no necesita
realizarse en una forma improvisada, existen técnicas útiles para la estimación de tiempo y
esfuerzo.
La estimación de recursos, costo y programa de trabajo para una tarea de ingeniería de
software requiere experiencia, acceso a buena información histórica y el valor para
comprometerse con predicciones cuantitativas cuando la información cualitativa es todo lo que
existe.
El proceso de planificación del proyecto
El objetivo de la planificación del proyecto de software es proporcionar un marco de trabajo que
le permita al gestor estimar razonablemente recursos costo y programa de trabajo.
Ámbito del software y factibilidad
El ámbito del software describe las funciones y características que se entregaran a los usuarios
finales los datos que son entrada y salida, el contenido que se presenta a los usuarios como
consecuencia de emplear software, así como el desempeño las restricciones, las interfases y la
confiabilidad que acotan el sistema.
Recursos
La segunda tarea de la planificación es la estimación de los recursos necesarios para
completar el esfuerzo del desarrollo del software sus tres grandes categorías son: el personal,
los componentes del software reutilizable y el entorno de desarrollo.
Recursos humanos
El planificador comienza evaluando el ámbito del software y seleccionando las habilidades
requeridas para completar el desarrollo se especifica tanto la posición organizacional como la
especialidad.
El número de personas requeridas solo se determina después de que se ha hecho una
estimación de esfuerzo de desarrollo.
Recursos de software reutilizables
La ingeniería de software basada en componentes enfatiza la reutilización es decir la creación
y reutilización de bloques de construcción de software, tales bloque llamados componentes
deben catalogarse para consultarlos con facilidad estandarizarse para facilitar su aplicación y
validarse para integrarlos fácilmente.
Recursos del entorno
El entorno que soporta un proyecto de software con frecuencia denominado entorno de
ingeniería del software incorpora hardware y software.
Estimación de proyectos de software
El software es el elemento más caro de virtualmente todos los sistemas basados en
computadora donde un gran error en la estimación del costo puede hacer la diferencia entre
beneficio y perdida rebasar el costo puede ser desastroso para el desarrollador.
Alexander Díaz Pág. 1

La estimación del costo y el esfuerzo nunca serán una ciencia exacta se pueden utilizar varias
técnicas para lograr que el costo se acerque lo mas posible a la realidad.
1- Demorar la estimación hasta que el proyecto este bien avanzado
2- Basar las estimaciones en proyectos similares
3- Emplear técnicas de descomposición relativamente simples
4- Utilizar uno o más modelos empíricos en la estimación de costo y esfuerzo.
Desgraciadamente la primera opción aunque atractiva no es práctica, la segunda opción puede
funcionar razonablemente bien si el proyecto en curso es similar a los previos.
Las demás opciones pueden ser viables si se utilizan con el debido cuidado y serán tan buenas
como los sean los datos históricos.
Técnicas de descomposición
El problema se descompone en varios segmentos pero antes de este paso es importante
entender el ámbito del sistema para así poder determinar el tamaño del sistema.
Tamaño del software
La precisión de la estimación de un proceso de software se manifiesta en varios factores
1- El grado con el cual el planificador ha estimado adecuadamente el tamaño del producto
que se construirá
2- La habilidad para traducir la estimación del tamaño en esfuerzo humano, programa de
trabajo y dinero
3- El grado en el cual el plan del proyecto refleja las habilidades del equipo de software
4- La estabilidad de los requisitos del producto y el entorno que soporta el esfuerzo de la
ingeniería del software
Estimación basada en el problema
Es importante considerar la estimación basada en el tamaño del problema ya que de esta
manera se puede cuantificar la cantidad de recursos que se debe asignar al proyecto no
obstante toda estimación siempre esta sujeta a una buena dosis de sentido común y la
experiencia que en todos los casos es muy importante.
Un ejemplo de estimación basada en PF
La descomposición de la estimación basada en pf se centra en los valores de dominio de
información mas que en las funciones de software en cuanto a los propósitos de esta
estimación se supone que el factor ponderado de complejidad es el promedio.
Estimación basada en el proceso
La técnica más común para estimar un proyecto es basa basar la estimación en el proceso que
se empleara, esto por cuanto el proceso se descompone en un conjunto de tareas y se estima
el esfuerzo requerido para realizar cada tarea.
Estimación con casos de uso
Los casos de uso permiten que un equipo de software comprenda el ámbito del software y los
requisitos no obstante este sistema cuenta con las siguientes desventajas
1- Los casos de uso se describen empleando muchos formatos y estilos diferentes no
existe un estándar
2- Los casos de uso representan una visión externa
3- Los casos de uso no abordan la complejidad de las funciones ni de las características
que se describen
4- Los casos de uso no describen el comportamiento complejo
Reconciliación de estimaciones

Las técnicas anteriores se deben reconciliar para establecer una sola estimación de esfuerzo
duración del proyecto y costo
Modelos empíricos de estimación
Un modelo de estimación para software de computadora utiliza formulas obtenidas
empíricamente para predecir el esfuerzo como una función de LDC o PF
Un modelo de estimación debe calibrarse para reflejar las condiciones locales si la
concordancia es insuficiente debe afinarse y ponerse a prueba nuevamente.
La estructura de los modelos de estimación
Un modelo de estimación típico se deriva mediante el análisis de regresión de los datos
recompilados de los proyectos anteriores de software previos.
El modelo COCOMO II
Su nombre proviene de las siglas constructive cost model este modelo se volvió uno de los mas
utilizados en la industria además ha evolucionado desde sus inicios a un modelo mas amplio, al
igual que su predecesor cocomo, es una jerarquía de modelos de estimación que aborda las
siguientes áreas:
1- Modelo de composición de la aplicación se emplea durante las primeras etapas de la
ingeniería del software cuando son primordiales los prototipos de internas de usuarios
2- Modelo de etapa de diseño temprano, se utiliza una vez que se han estabilizado los
requisitos y se ha establecido una jerarquía básica de software
3- Modelo de etapa posterior a la arquitectura Se emplea durante la construcción del
software
La ecuación del software
Es un modelo multivariable que supone una distribución específica del esfuerzo a lo largo de la
vida de un proyecto de desarrollo de software, el modelo procede de datos de productividad
recopilados de casi 4000 proyectos de software contemporáneos
Estimación para proyectos orientados a objetos
Vale la pena complementar los métodos convencionales de estimación de costo del software
con un enfoque diseñado explícitamente para software.
Técnicas de estimación especializadas
Dentro de las mas comunes se encuentran la estimación para desarrollo ágil este funciona
bajo un enfoque de estimación informal aunque razonablemente disciplinado y significativo
dentro del contexto de la planificación del proyecto aplica un enfoque de descomposición
La decisión desarrollar-comprar
A menudo en muchas áreas de software es más rentable adquirir que desarrollar esto por
cuanto la empresa no debe lidiar con personal cargas sociales, contratiempos, incapacidades
etc. Que pueden dar al traste con un proyecto de software no obstante las implicaciones de
comprar el software siempre tienen sus inconvenientes si no se compra un software a la
medida debido a la incompatibilidad del mismo con la empresa además de la posibilidad de que
la empresa desarrolladora no haga bien su trabajo por lo que se debe definir políticas claras y
contratos que aseguren el correcto empleamiento de los fondos o recursos de la empresa.
Subcontratación
Tarde o temprano cualquier compañía que desarrolla software de computadora se plantean la
necesidad de sub contratar a terceros para que le desarrollen los sistemas a un costo mas bajo
y se espera que sea con una alta calidad.

Administración de Proyectos Calendarización de PSW
Capitulo 24: Calendarización de Proyectos de Software

En la cultura mal hecha de la mayoría de los ingenieros de software, se da el caso que nos dan
un proyecto de un sistema de software, le damos un vistazo rápido y comenzamos a codificar
en el lenguaje de programación que mejor de adapte para su fin, comedimos riesgos, una red
de tareas asignación de responsabilidades, que esta tarea le toca al ingeniero de software.
Cuando se da el caso que se debe de entregar el proyecto a una fecha determinada no se ha
llevado a cabo ni el 45% del proyecto o talvez se entrega pero un producto no eficiente.
En este capitulo 24 con el título de Calendarización de proyectos de software nos en seña y
nos las opciones necesarias del por que hacerlo, ya que trae muchos beneficios ya que nos
disminuye los riesgos y nos aumenta las posibilidades de que el producto final sea lo que se
esperaba.
Conceptos Básicos
Se dan varios conceptos o razones por lo que casi siempre los proyectos se entregan con
retraso entre ellas:
• Una fecha límite irrealizable.
• Cambio de requisitos dados por el cliente que no se habían estimado en la
calendarización.
• Subestimación de los recursos y esfuerzos que requieren el proyecto.
• Riesgos.
• Dificultades técnicas.
• Falta de comunicación entre el personal del proyecto.
• Falla en la gestión de l proyecto.
Entre otras razones por las cuales no se da el producto al tiempo limite que se debe.
Se da el caso que nos llevan un proyecto el cual el cliente nos da la fecha limite para
entregarlo, pero después de un arduo análisis nos damos cuenta que no se podría entregar en
el limite de tiempo que el cliente impuso ¿Qué hacer?
Tenemos varias opciones:
1. Realizar una estimación detallada empleando datos históricos de proyectos
previos.
2. Aplicar un modelo de proceso incremental y desarrollar una estrategia de
ingeniería de software que se entregará la funcionalidad crítica en la fecha
impuesta. Pero demorará otra.
3. Reunirse con el cliente y con la estimación detallada, explicarle por qué la fecha
limite es irrealizable.
4. ofrezca la estrategia incremental alternativa:
• Primero: se puede aumentar los presupuestos y conseguir lo recursos y
esfuerzos necesarios para poder terminarlo en la fecha impuesta por el
cliente, lo cual no va asegurar que el producto sea muy eficiente.
• Segundo: se puede remover varios de los funcionalidades y capacidades
del software, y luego de la fecha limite entregar las otras funcionalidades e
integrarlas.
• Tercero: hacerlo en el plazo impuesto por el cliente y tener un producto
irreal y no provechoso, lo cual no esta bien.
La calendarización del proyecto de software es una actividad que distribuye estimaciones de
esfuerzo a través de la duración planificada del proyecto al asignar el esfuerzo a tareas
específicas de ingeniería de software.
Es importante recalcar que la calendarización evoluciona a lo largo del tiempo.
Luis Randall Zúñiga Pág. 1

La calendarización del proyectos se puede ver de dos perspectivas diferentes, la primera que
no se puede cambiar la fecha ya que esta impuesta por la computadora, por lo cual la empresa
está restringida a distribuir esfuerzos. Y la segunda se maneja límites cronológicos estimados
por lo cual la empresa es la que impone la fecha y así tiene control de distribución de recursos
y esfuerzos.
Existen varios principios de la ingeniería del software lo cual guían la calendarización:
• Compartimentación: llegar a descomponer o dividirse en
compartimentos en varias tareas manejables.
• Interdependencia: determinar su interdependencia algunas actividades
son en paralelo u otras en secuencia., ya que unas no pueden
comenzar hasta que terminen unas y habrán otras actividades que si
se pueden comenzar independientemente.
• Asignación de tiempo: se le debe asignar a cada tarea fecha de inicio y
de final.
• Validación del esfuerzo: Todo proyecto tiene un número definido de
personas, el gestor de proyecto debe asegurarse que, en un tiempo
dado, no se han asignado más que el número de personas
calendarizadas.
• Definición de responsabilidades: toda tarea calendarizada se le debe
asignar a un miembro específico del equipo.
• Definición de resultados: normalmente en los proyectos son productos
que son entregables.
• Definición de hitos: cualquier tarea o grupo de tareas debe estar
relacionado a un hito de trabajo.
Relación entre personal y el esfuerzo.
Un proyecto pequeño se puede realizar con una solo persona que sea la que analice los
requerimientos, diseñe, codifique, y dirija las pruebas, pero cuando valla aumentando la
intensidad del proyecto mas personas se Irán integrando con diferentes responsabilidades.
Existe un mito, que dice que cuando se atrasa la fecha que se ha calendarizado se deben de
ingresar mas personas en el proyecto para ejecutarlo a tiempo, lo cual eso es falso ya que se
desfasa mas el calendario.
Distribución de esfuerzo
Existe una recomendada distribución de esfuerzos en los proyectos de software que es llamada
la regla de los 40-20-40.
Un 20% de los esfuerzos para la etapa análisis y diseño un 20% para lo que es codificación y
un 40% para lo que es para ponerlo a prueba.
Definición de un conjunto de tareas para el proyecto de software
Es una colección de tareas de trabajo de ingeniería del software, hitos, y productos de trabajo
que se deben de terminar para completar un proyecto particular.
La calendarización requiere que se distribuya en un conjunto de tareas en todo la línea del
proyecto.
Dependiendo del proyecto así se hará la distribución de tareas, existen proyectos de:
Proyectos de desarrollo del concepto, los cuales se inician para explorar
algunas de las aplicaciones o conceptos de negocios de alguna tecnología.
Proyectos de desarrollo de nuevas aplicaciones: con solicitud específica del
cliente.
Proyectos de mejora de aplicación: cuando el software existente sufre grandes
modificaciones.
Proyectos de mantenimiento de aplicación.
Proyectos de reingeniería.
Los proyectos de desarrollo del concepto se enfocan en aplicar las siguientes tareas
principales:
1.1 La determinación del ámbito del concepto.
1.2 La planeación preliminar del concepto.
1.3 La valoración del riesgo de la tecnología
1.4 La prueba del concepto.
1.5 La implementación de l concepto.
1.6 La reacción del cliente.
Teniendo estas tareas se pueden refinar detalladamente para así calendarizar detalladamente.
Definición de una red de tareas
También se denomina red de actividades, es una representación gráfica del flujo de tareas en
un proyecto, mediante el cual se puede demostrar la dependencia de tareas y sub-tareas.
Esta se utiliza cuando se requiere crear una Calendarización microscópica.
El gestor del proyecto debe estar al tanto a estas tareas si se encuentran en la ruta crítica.
Calendarización
Con respecto a la calendarización de tareas con el método PERT Y CMP son dos métodos de
calendarización de proyecto que se pueden aplicar al desarrollo de software.
Anteriormente se han realizado la estimación del esfuerzo, descomposición de la función del
producto, Selección del modelo de proceso y conjunto de tareas apropiadas, descomposición
de tareas.
Cronogramas
Cuando se calendariza se comienza con un conjunto de tareas, donde se hace la red de
tareas, se miden los esfuerzos se dan las fechas de inicio y así nace entonces el formar el
cronograma de tareas, también llamado grafico de Gantt.
Cuando las tareas en desglose o descompuestas se les da su duración su fecha de inicio, se
ve la concurrencia de tareas, se ve mediante tablas horizontales el progreso del proyecto lo
cual es una herramienta importante para el gestor del proyecto así llevar su control.
Se debe dar el seguimiento necesario a la calendarización, la cual dice que tareas e hitos
seguir y controlar conforme avanza el proyecto.
Este seguimiento se puede realizar mediante:
o Realización periódica de reuniones valorando el estado del proyecto.
o Evaluación de los resultados a lo largo del proceso.
o Determinación se han logrados los hitos formales del proyecto.
o Medición de tiempos, fechas previstas contra fechas reales.
o Evaluación sugestiva de los trabajadores.
o Evaluación del progreso cuantitativamente
La calendarización es la culminación de una actividad de planificación que es un componente
principal de la gestión del proyecto de software.

Administración de Proyectos Gestión del Riesgo en PSW
Capitulo 25: Gestión del Riesgo en Proyectos de Software

El riesgo es un problema potencial que puede ocurrir o no, la gestión del riesgo es una serie de pasos
que ayudan a un equipo de software a comprender y manejar la incertidumbre.
Existen dos estrategias que abordan el riego, la primera es la reactiva, conocida mejor como modo
bombero, esta no se preocupa por los riesgos hasta que algo sale mal, la segunda estrategia es
preactiva, donde desde el inicio se identifican los riesgos potenciales, se valoran su probabilidad e
impacto y se les clasifica según su importancia de manera que permita la elaboración de un plan de
contingencia.
En lo que se refiere al riesgo del software, siempre se presentan dos características: la incertidumbre
(puede o no ocurrir) y la pérdida (consecuencias o pérdidas indeseables). Éstas deben de cuantificarse
tanto el grado de incertidumbre como el grado de pérdida, para ello se realiza la diferenciación del riesgo
en categorías como por ejemplo:
• Riesgos del proyecto, problemas potenciales en presupuesto, calendarización, personal,
recursos y otros
• Riesgos técnicos, problemas potenciales en diseño, implantación, interfaz, verificación y
mantenimiento.
• Riesgos de negocios, problemas potenciales que amenazan con la viabilidad del software que
se construirá se subdivide en;
o Riesgo de mercado, excelente producto que nadie quiere
o Riesgo de estrategia, producto no encaja con la estrategia de la empresa
o Riesgo de ventas, producto que la fuerza de ventas no sabe como vender.
o Riesgo administrativo, perdida del apoyo de los altos ejecutivos
o Riesgo presupuestal, pérdida de presupuesto.
Principios para lograr una gestión de riesgo efectiva:
• Mantenimiento de una perspectiva global
• Tener una visión previsora
• Alentar la comunicación abierta
• Integración, consideración de los riesgos
• Enfatizar un proceso continuo
• Desarrollo de una visión conjunta del producto
• Alentar el trabajo en equipo
La identificación del riesgo es un intento sistemático encaminado a especificar las amenazas al plan
del proyecto que involucra estimaciones, calendarización, carga de recursos, etc. Se distinguen dos tipos
de riesgos para las categorías definidas anteriormente que son:
• Riesgos genéricos, que son una amenaza potencial para todo el proyecto de software y
• Riesgos específicos del producto, identificados sólo por aquellos con claro conocimiento de la
tecnología, el personal y el entorno.
Un método para identificar riesgos consiste en crear una lista de verificación de riesgos con las
siguientes subcategorías genéricas:
• Tamaño del producto
• Impacto en el negocio
Luis Diego Pérez Pág. 1

• Características del cliente

• Definición del cliente
• Entorno de desarrollo
• Tecnología a construir
• Tamaño y experiencia del personal
De acuerdo con unas directrices establecidas por la Fuerza Aérea de los Estados Unidos, se deben de
identificar los controladores del riesgo que afectan los componentes de riesgo que a continuación se
definen:
1. Riesgo de desempeño, satisfacción de los requisitos y ajuste al uso pretendido.
2. Riesgo de costo, incertidumbre presupuestaria.
3. Riesgo de soporte, incertidumbre sobre la facilidad de corrección, adaptación y mejora del
producto.
4. Riesgo de calendarización, incertidumbre del cumplimiento de la calendarización y de la
entrega del producto.
La proyección del riesgo o estimación del riesgo, intenta clasificar el riesgo ya sea por la posibilidad o
probabilidad de que el riesgo sea real y por las consecuencias de los problemas asociados con el riesgo,
en caso de que ocurra.
Para realizar la proyección del riesgo con el objeto del establecimiento de prioridades se establecen los
pasos que se detallan a continuación:
• Establecimiento de una escala que refleje la posibilidad percibida de un riesgo
• Delineado de las consecuencias del riesgo.
• Estimación del impacto del riesgo
• Tomar nota de la precisión global de la proyección del riesgo.
El desarrollo de una tabla de riesgos ofrece una técnica simple para la proyección de riesgos, donde en
primera instancia los integrantes del proyecto elaboran una lista inicial de riesgos, luego cada uno se
clasifica, se define su probabilidad de ocurrencia y su impacto. Una vez definidos estos conceptos la lista
se ordena según su probabilidad e impacto y se realiza una línea de corte en la lista que pretende una
atención posterior de los puntos sobre la línea de corte y los colocados debajo de esta se reevaluarán y
priorizarán en un segundo orden.
En la evaluación del impacto del riesgo se analizan tres factores que son:
• Naturaleza, que indica los problemas que probables si ocurre
• Ámbito, que involucra la severidad.
• Tiempo, que considera cuándo y durante qué periodo se sentirá.
El refinamiento del riesgo es el proceso mediante el cual se realiza un mayor detalle de los riesgos
definidos inicialmente en la planificación del proyecto, lo cual se puede realizar solo conforme pasa el
tiempo necesario para aprender más acerca del proyecto.
En el análisis del riesgo se desarrollan las actividades de:
• Reducción, evitar el riesgo
• Supervisión, supervisar el riesgo
• Gestión del riesgo, planes de contingencia

Como consecuencia de todas las actividades detalladas anteriormente surge el plan RSGR (Reducción
Supervisión y Gestión del Riesgo) que documenta todo el trabajo realizado en el análisis del riesgo y se
emplea como parte del plan global del proyecto. Posteriormente se realiza la supervisión del riesgo que
es una actividad de seguimiento del proyecto con tres objetivos principales, valorar si los riesgos
predichos de hecho ocurren, asegurar que los pasos para evitar los riesgos definidos se estén aplicando
con propiedad y recopilar información que pueda usarse en futuros análisis.

Administración de Proyectos Gestión de la Calidad en PSW
Capitulo 26: Gestión de la Calidad en Proyectos de Software

La gestión de calidad abarca:
• Un procesos de garantía de la calidad del software (SQA)
• Tareas especificas de aseguramiento de la calidad.
• Practicas efectivas de ingeniería del software
• Control de todos los productos de trabajo del software y los cambios que generan.
• Un procedimiento para garantizar la concordancia con los estándares de desarrollo de
software.
• Mecanismos de medición e informes.
Concepto de Calidad
El control de la variación es el corazón del control de calidad. En el contexto del software se
lucha por controlar la variación en el proceso genérico y en el análisis de calidad que permea el
trabajo de ingeniería del software.
Calidad
“Una característica o atributo de algo”; existen mediciones de las características de un
programa. Cuando se examina un elemento con base en sus características mesurables se
pueden encontrar dos tipos de características:
• Calidad de diseño: Características que los diseñadores especifican para un elemento.
• Calidad de concordancia: Grado en el que las especificaciones de diseño se aplican
durante la fabricación.
Satisfacción del usuario = producto manejable + buena calidad

+ entrega dentro de presupuesto y tiempo
Robert Glass [GLA98]
Control de Calidad
Involucra una serie de inspecciones, revisiones y pruebas empleadas a lo largo del proceso de
software para garantizar que cada producto de trabajo satisfaga los requisitos que se le han
asignado; minimizando los defectos producidos.
Garantía de la Calidad
Consiste en un conjunto de funciones de auditoria e informática que evalúan la efectividad de
qué tan completas son las actividades de control de calidad.
Costo de la Calidad
Son todos los costos que genera la búsqueda de calidad.
Se dividen en:
• Costos de prevención: Planificación de la calidad, revisiones técnicas formales, equipo
de pruebas y entrenamiento.
• Costos de evaluación: Actividades para comprender mejor la condición del producto la
“primera vez a través de” cada proceso (Ej. calibración).
• Costos de fallas (reelaboración, reparación y análisis en modo de falla)
o Internas: Cuando se detecta un defecto antes de su envío.
o Externas: Cuando se detecta un defecto después de su envío.
Mariano Dilascio Pág. 1

Garantía de la Calidad del Software (SQA)

• Los requisitos del software son la base de las medidas de la calidad. La falta de
concordancia con los requisitos es una falta de calidad.
• Los estándares especificados definen un conjunto de criterios de desarrollo que guían
la forma en que el software se elabora. Si no se siguen los criterios, casi seguramente
resultara una falta de calidad.
• Con frecuencia no se menciona un conjunto de requisitos implícitos (Ej. El deseo de
uso sencillo y facilidad de mantenimiento). Si el software concuerda con sus requisitos
explícitos pero fracasa al satisfacer los requisitos implícitos, su calidad esta en duda.
Actividades de SQA
La misión del grupo SQA es auxiliar al equipo de software a conseguir un producto final de alta
calidad.
Actividades:
• Preparar un plan de SQA para un proyecto.
• Participar en el desarrollo de la descripción del proceso de software del proyecto.
• Revisar las actividades de ingeniería del software para verificar que se ajuste al
proceso de software definido.
• Audita productos de trabajo de software seleccionados para verificar que se ajusten
con los definidos como parte del proceso del software.
• Garantiza que las desviaciones en el trabajo del software y en los productos de trabajo
estén documentadas y se manejen de acuerdo con el procedimiento establecido.
• Registra cualquier falta de ajuste y lo informa al gestor ejecutivo.
Revisiones del Software
Las revisiones del software “purifican” las actividades de ingeniería del software que se han
denominado análisis, diseño y codificación.
La meta del SQA es eliminar los problemas de calidad en el software, donde estos pueden ser
• Error : Se detecta antes de la liberación del software.
• Defecto : Se detecta después de la liberación del software.
El beneficio obvio de las revisiones técnicas formales es el descubrimiento temprano de los
errores de modo que ya no se propaguen al paso siguiente en el proceso de software.
Revisiones técnicas formales (RTF)
Una Revisión técnica formal es una actividad de control de calidad del software que llevan a
cabo los ingenieros de software; Incluye recorridos, inspecciones, revisiones cíclicas y otro
pequeño grupo de evaluaciones técnicas de software.
Los objetivos de una RTF:
1. Descubrir errores en la función, lógica o implementación en cualquier representación
del software.
2. Verificar que el software en revisión satisface sus requisitos.
3. Garantizar que el software se ha representado de acuerdo con los estándares
predefinidos.
4. Lograr software desarrollado en una manera uniforme.
5. Hacer proyectos más manejables.
La junta de revisión
Restricciones:
• En la revisión se deben involucrar entre 3 y 5 personas.
• Se debe preparar con anticipación, pero sin que requiera más de 2 horas de trabajo de
cada persona.
• La duración de la junta de revisión debe ser menor a 2 horas.
El enfoque de trabajo de la RTF se dirige a un producto de trabajo o una porción de una
especificación.
La RTF comienza con una presentación de la agenda y luego se procede a recorrer el
producto de trabajo y explica el material.
Al final, todos los asistentes a la RTF deben decidir si:
1. Aceptan el producto sin modificaciones posteriores.
2. Rechazan el producto debido a errores severos.
3. Aceptan el producto provisionalmente.
Informe de la revisión y conservación de registros
Durante la RTF, un revisor registra activamente todos los problemas; se llena un informe
resumen de la revisión técnica formal.
Un informe resumen de la revisión responde a 3 preguntas:
1. ¿Qué se revisó?
2. ¿Quién lo revisó?
3. ¿Cuáles fueron los hallazgos y conclusiones?
La lista de problemas de revisión cumple 2 propósitos:
1. Identificar áreas problema en el producto.
2. Funcionar como lista de verificación de elementos de acción que guían al productor
conforme se hacen las correcciones.
Directrices de la revisión
Las siguientes representan un conjunto mínimo de directrices para las revisiones técnicas
formales:
• Revisar el producto, no al productor.
• Establecer una agenda y respetarla.
• Limitar el debate y la impugnación.
• Enunciar áreas de problemas, pero no se intente resolver todos los que se hayan
señalado.
• Limitar el número de participantes e insistir en la preparación anticipada.
• Desarrollar una lista de verificación para cada producto que tenga probabilidad de ser
revisado.
• Asignar recursos y programar las RTF.
• Realizar un entrenamiento significativo de todos los revisores.
• Analizar las revisiones previas.
Enfoques formales acerca del SQA
Si el modelo de requisitos (especificación) y el lenguaje de programación, se representan en
una forma rigurosa, debe ser posible aplicar pruebas matemáticas de exactitud para demostrar
que un programa concuerda exactamente con sus especificaciones.
Garantía de la Calidad Estadística del Software
Para el software, garantía de calidad estadística implica los siguientes pasos:
1. La información acerca de los defectos de software se recopila y clasifica.

2. Se intenta determinar la causa subyacente de cada defecto.

3. Mediante el principio de Pareto (80% de los defectos se encuentra en el 20% de todas
las causas posibles) se aísla un 20%.
4. una vez que las causas vitales han sido identificadas, se corrigen los problemas que
han provocado los defectos.
Algunos de los defectos se descubren cuando el software está en desarrollo; otros, después de
que se ha liberado entre sus usuarios finales. Todos tienen una o más de las causas
siguientes:
• Especificaciones incompletas o erróneas.
• Mala interpretación de la comunicación del cliente.
• Desviación intencional de las especificaciones.
• Violación de los estándares de programación.
• Errores en la representación de los datos.
• Interfaz de componente inconsistente.
• Error en la lógica de diseño.
• Prueba incompleta o errónea.
• documentación imprecisa o incompleta.
• Error en la traducción del diseño al lenguaje de programación.
• Interfaz hombre-computadora ambigua o inconsistente.
• Misceláneo.
La aplicación del SQA estadístico y el principio de Pareto se pueden resumir en una sola
oración: “Emplee su tiempo enfocándose en las cosas que realmente importan, ¡pero primero
asegúrese de entender qué es lo que realmente importa!”
Seis sigma para ingeniería del software
Seis sigma es la estrategia más ampliamente empleada en la actualidad para el aseguramiento
de la calidad estadístico en la industria.
El término se deriva de seis desviaciones estándar, lo que implica un estándar de calidad
extremadamente elevado.
La metodología seis sigma define 3 pasos:
• Definir los requisitos del cliente, entregables y metas del proyecto por medio de
métodos bien definidos de comunicación con el cliente.
• Medir el proceso existente y su salida para determinar el desempeño de la calidad
actual.
• Analizar las métricas de defecto y determinar las causas poco vitales.
Pasos adicionales; si el software esta en marcha:
• Mejorar el proceso eliminando las causas originales de los defectos.
• Controlar el proceso para garantizar que el trabajo futuro no vuelva a introducir las
causas de defectos.
Fiabilidad del Software
Se define en términos estadísticos como “la probabilidad de la operación libre de fallas de un
programa de computadora en un entorno específico durante un tiempo específico”.
Siempre que se estudia la fiabilidad del software, surge una pregunta central
¿Qué significa el término falla?

En el contexto del software, la falla es la falta de concordancia con los requisitos del software.
Seguridad del software
Es una actividad de aseguramiento de la calidad del software que se enfoca en la identificación
y evaluación de los peligros potenciales que pueden afectar negativamente al software y
provocar una falla de todo el sistema.
La confiabilidad del software utiliza análisis estadístico para determinar la probabilidad de que
ocurrirá una falla del software.
La seguridad del software examina las formas en las cuales las fallas resultan en condiciones
que pueden conducir a un percance.
Los estándares de Calidad ISO 9000
Es posible definir un “sistema de garantía de la calidad” como la estructura organizacional,
responsabilidades, procedimientos, procesos y recursos para implementar la gestión de la
calidad. El estándar ISO 9000 describe un sistema de garantía de la calidad en términos
genéricos que se aplican a cualquier negocio sin importar los productos o servicios ofrecidos;
describe lo que se debe hacer para ser manejable, pero no describe cómo se debe hacer.
El plan del SQA
Proporciona un mapa para instituir la garantía de la calidad del software; funciona como
plantilla para las actividades del SQA.

Administración de Proyectos Gestión del Cambio en PSW
Capitulo 27: Gestión del Cambio en Proyectos de Software

Gestión del Cambio
El cambio es inevitable cuando se construye software de computadora. Y el cambio aumenta el grado
de confusión entre los ingenieros de software que trabajan en un proyecto. La confusión surge
cuando los cambios no se analizan antes de realizarlos. Babich aborda esto cuando afirma:
“El arte de coordinar el desarrollo de software para minimizar…la confusión se llama gestión de
configuración. La meta es maximizar la productividad al minimizar las equivocaciones.”
La gestión del cambio, más usualmente llamada gestión de configuración del software (GCS O GC),
es una actividad protectora (sombrilla) que se aplica a lo largo el proceso de software. Las actividades
de GCS se desarrollan para 1) identificar el cambio, 2) controlar el cambio, 3) garantizar que el cambio
se implementará de manera adecuada, y 4) reportar los cambios a otros que pudieran estar
interesados. Es importante distinguir con claridad entre soporte de software y gestión de la
configuración del software. El soporte es un conjunto de actividades de ingeniería de software que
ocurren después de que este se ha entregado al cliente y fue puesto en operación. La gestión de la
configuración del software es un conjunto de actividades de seguimiento y control que se inician
cuando comienza un proyecto de ingeniería de software y terminan solo cuando este se retira de
operación. Una meta primordial de la ingeniería de software es mejorar la falibilidad con la que los
cambios se pueden acomodar y reducir el esfuerzo cuando los cambios se deben realizar.
1. Gestión de la Configuración de Software
La salida del proceso de software es información que se puede dividir e tres amplias categorías: 1)
programas de computadora, 2) productos de trabajo que describen los programas de computadora, y
3) datos. Los elementos que comprenden la información producida como parte del proceso de
software se denominan colectivamente configuración de software. Por desgracia, otra variable entra
en el proceso: el cambio. Este puede ocurrir en cualquier momento, por cualquier razón.
¿Cuál es el origen de estos cambios? La respuesta es tan variada como los cambios mismos. Sin
embargo, existen cuatro fuentes fundamentales en cambio:
9 Nuevas condiciones en el negocio o mercado dictan los cambios en lo requisitos de
producto o las reglas del negocio.
9 Nuevas necesidades el cliente demandan la modificación de os datos que producen
los sistemas de información, de la funcionalidad que entregan los productos o los servicios que
entrega un sistema basado en computadora.
9 La reorganización o el crecimiento o reducción del negocio provocan cambios en las
prioridades del proyecto o en la estructura del equipo de ingeniería del software.
9 Restricciones presupuestales o de calendarización inducen una redefinición del
sistema o producto.
La gestión de la configuración del software es un conjunto de actividades que se han desarrollado
para gestionar el cambio a lo largo del ciclo de vida del software de computadora.
Un escenario de GCS
Un típico escenario operativo de GCS involucra un gestor de proyecto a cargo de un grupo de
software; un gestor de configuración a cargo de los procedimientos y políticas de GC; los ingenieros
de software responsables del desarrollo y mantenimiento del producto de software, y el cliente que
emplea el producto. En el ámbito operativo el escenario involucra diversos papeles y tareas. La meta
del gestor del proyecto es garantizar que el producto se entregue dentro de cierto periodo. En
consecuencia, el gestor supervisa el progreso del desarrollo y reconoce y reacciona ante los
problemas.
Las metas del gestor de configuración son garantizar que se siguen los procedimientos t políticas para
crear, cambiar y poner a prueba el código, así como posibilitar el acceso a la información acerca del
Fernando Alberto Segura Pág. 1

proyecto. El gestor crea y distribuye las listas de tareas para los ingenieros y básicamente crea el
contexto del proyecto.
La meta de los ingenieros de software es trabajar con eficiencia. Esto significa que no interfieren de
manera innecesaria unos con otros en la creación y prueba del código ni en la producción de los
documentos de soporte. No obstante, al mismo tiempo, intentan comunicarse y coordinarse de
manera eficiente. Ellos se comunican y coordinan al notificarse mutuamente las tareas que se
requieren y las tareas cumplidas. Los cambios se propagan por medio del trabajo de cada uno
mediante archivos fusionados. Existen mecanismos para asegurar que, respecto de los componentes
que experimentan cambios simultáneos, existe alguna forma de resolver los conflictos y fusionar los
cambios.
El gestor del proyecto ve una GC como un mecanismo de auditoria; el gestor de configuración, como
un mecanismo de creación de control, seguimiento y políticas; el ingeniero de software, como un
mecanismo de control de cambio, la construcción y el acceso; y el usuario, como un mecanismo de
garantía de la calidad.
Elementos de un sistema de gestión de la configuración
En su detallado artículo acerca de la gestión de la configuración de software, Susan Dart identifica
cuatro importante elementos que deben estar presentes cuando se desarrolla un Sistema de Gestión
de la Configuración:
9 Elementos de componentes: conjunto de herramientas acopladas dentro de un
sistema de gestión de archivos.
9 Elementos de proceso: serie de procedimientos y tareas que definen un enfoque
eficaz con el cual gestionar el cambio.
9 Elementos de construcción: conjunto de herramientas que automatizan la construcción
del software al asegurar que se ha ensamblado un conjunto adecuado de componentes validados
9 Elementos humanos: implementación GCS eficaz requiere que el equipo de software
utilice un conjunto de herramientas y características de procesos.
Estos elementos no son mutuamente excluyentes.
Líneas base
El cambio es un hecho de vida e el desarrollo del software. Los clientes quieren modificar los
requisitos. Los desarrolladores quieren modificar el enfoque técnico. Los gestores quieren modificar la
estrategia del proyecto. ¿Por qué todas esta modificaciones? La respuesta, en realidad, es bastante
simple. Conforme pasa el tiempo, todos los participantes saben más acerca de lo que necesitan. Este
conocimiento adicional es la fuerza impulsora detrás de la mayoría de los cambios y conduce a una
expresión difícil de aceptar para muchos profesionales de la ingeniería del software: ¡la mayoría de los
cambios están justificados!
Una línea base es un concepto de gestión de la configuración del software que ayuda a controlar el
cambio sin impedir seriamente el cambio justificable. El IEEE define una línea base como:
“Una especificación o producto que sea revisado formalmente y se está de acuerdo con los
resultados, y que a partir de ahí sirve para la base para el desarrollo anterior y que puede cambiarse
sólo por medio de procedimientos formales de control del cambio”
Antes de que un elemento de configuración del software se convierta en línea base, es posible realizar
el cambio rápida e informalmente. Sin embargo, una vez establecida una línea base, metafóricamente
se pasa a través de una puerta giratoria de una sola dirección. Los cambios se pueden realizar, pero
se debe aplicar un procedimiento específico formal para evaluar verificar cada uno.
En el contexto de la ingeniería del software, una línea base es un hito en el desarrollo del software. Se
marca una línea base para la entrega de uno o más elementos de la configuración del software (ECS)
que se han aprobado como consecuencia de una revisión técnica formal.
Elementos de Configuración del Software

Un elemento de configuración del software (ECS) es información que se crea como parte del proceso
de ingeniería de software. De manera más realista, un ECS es un documento, un conjunto completo
de casos de prueba o un componente de un programa dado.
Además de los ECS provenientes de los productos de trabajo de software, muchas organizaciones de
ingeniería de software también colocan las herramientas respectivas bajo control de configuración.
Esto es: versiones especificas de editores, compiladores, navegadores y otras herramientas
automatizadas se “congelan” como parte de la configuración del software. Aunque los problemas son
raros, es posible que una nueva versión de una herramienta produzca resultados diferentes a los de la
versión original. Por esta razón, las herramientas, al igual que el software que ayudan a producir,
pueden convertirse en línea base como parte de un proceso global de gestión de configuración.
En realidad, los ECS están organizados para formar objetos de configuración susceptibles de
catalogar en la base de datos del proyecto con un solo nombre. Un objeto de configuración tiene un
nombre, atributos y está “conectado” con otros objetos por medio de relaciones.
2. El Depósito de ECS
En los primeros días de la ingeniería del software los elementos de configuración se conservaban
como documentos de papel (¡o tarjetas perforadas!). Este enfoque era problemático por muchas
razones: 1) con frecuencia era difícil encontrar un elemento de configuración cuando se necesitaba; 2)
usualmente era un reto determinar cuál elemento había sido cambiado, cuándo y por quien; 3) la
construcción de una nueva versión de un programa existente consumía mucho tiempo y era proclive al
error; 4) la descripción de relaciones detalladas o complejas entre elementos de configuración era
virtualmente imposible.
En la actualidad, los ECS se conservan en una base de datos o depósito del proyecto. El diccionario
Webster define depósito como “cualquier cosa o persona que se considera como centro de
acumulación o almacenamiento”. En los inicios de la ingeniería de software, el depósito de hecho era
una persona. Tristemente, emplear a una persona como “centro de acumulación y almacenamiento”
no funciona muy bien. Hoy el depósito es una “cosa” : una base de datos que actúa como el centro
tanto de la acumulación como del almacenamiento de la información de ingeniería de software.
El papel del depósito
El depósito de ECS es el conjunto de mecanismos y estructuras de datos que permiten que un equipo
de software maneje el cambio en una forma eficaz. El depósito proporciona las funciones obvias de un
sistema de gestión de bases de datos pero, además, el depósito realiza o impulsa las siguientes
funciones:
9 La integridad de los datos incluye funciones para validar las entradas al depósito,
garantizar la consistencia entre objetos relacionados y automáticamente realizar modificaciones “en
cascada” cuando un cambio en un objeto demanda algún cambio a los objetos relacionados con él.
9 El compartir información ofrece un mecanismo para distribuir la información entre
múltiples desarrolladores y herramientas, manejar y controlar los accesos a los datos por parte de
múltiples usuarios y cerrar y abrir los objetos de modo que los cambios no sean trasladados
inadvertidamente hacia otros.
9 La integración de herramientas establece un modelo de datos al que se puede tener
acceso mediante muchas herramientas de ingeniería de software, controlar el acceso a los datos y
realizar funciones adecuadas de gestión de la configuración.
9 La integración de los datos brinda funciones de base de datos que permiten que
varias tareas de GCS se realicen en uno o más ECS.
9 El fortalecimiento de la metodología define un modelo de entidad-relación guardado
en el depósito que implica un modelo de proceso específico para la ingeniería de software.
9 Estandarización de los documentos es la definición de los objetos en la base de datos
que conduce directamente a un enfoque estándar para la creación de documentos de ingeniería de
software.

El depósito se define en función de un metamodelo. Para lograr estas funciones el metamodelo

determina cómo se guarda la información en el depósito, cómo se tiene acceso a los datos mediante
las herramientas y cómo los visualizan los ingenieros de software.
Características y contenidos generales
Las características y el contenido del depósito se comprenden mejor si se les observa desde dos
perspectivas: qué se guardara en el depósito y qué servicios específicos ofrece éste. Un depósito
robusto proporciona dos clases diferentes de servicios: 1) los mismos tipos de servicios que se
pueden esperar de cualquier sistema sofisticado de gestión de base de datos, y 2) servicios
específicos del entorno de la ingeniería del software.
Características de la GCS
El apoyo a la GCS requiere que el almacén o depósito tenga un conjunto de herramientas que
ofrezca soporte para las siguientes características:
Versiones. Conforme un proyecto progrese se crearan muchas versiones de productos de trabajo
individuales. El depósito debe ser capaz de guardar todas estas versiones para permitir la gestión
eficaz de las liberaciones de producto.
El depósito debe ser capaz de controlar una amplia variedad de tipos de objetos. Un depósito maduro
sigue las versiones de los objetos con grados arbitrarios de granularidad.
Gestión del seguimiento de la dependencia y del cambio. El depósito gestiona una amplia
variedad de relaciones entre los objetos de configuración que guarda. Se incluyen relaciones entre
entidades y procesos empresariales. Algunas de estas relaciones son meramente asociaciones, y
algunas son dependencias o relaciones obligatorias.
La habilidad con que se da seguimiento a todas estas relaciones es crucial para la integridad de la
información guardada en el depósito y la generación de productos de trabajo basados en ella, y es
una de las aportaciones mas importantes del concepto de depósito a la mejora del proceso de
desarrollo de software.
Seguimiento de requisitos. Esta función especial ofrece la habilidad de seguir todos los
componentes y entregables de diseño y construcción que resulten de una determinación específica de
requisitos. Además, proporciona la habilidad de identificar qué requisitos generaron algún producto de
trabajo dado.
Gestión de configuración. Una gestión de la configuración facilita la conservación del rastro de una
serie de configuraciones que representan hitos específicos del proyecto o liberaciones de producción.
Rutas de auditoria. Una ruta de auditoria establece información adicional acerca de cuándo, por qué
y por quién se hicieron los cambios.
3. El Progreso de GCS
El proceso de gestión de la configuración del software define una serie de tareas que tienen cuatro
objetivos principales: 1) identificar todos los elementos que colectivamente definen la configuración del
software; 2) gestionar los cambios a uno o más de dichos elementos; 3) facilitar la construcción de
diferentes versiones de una aplicación; y 4) garantizar que la calidad del software se conserva
conforme la configuración evoluciona a lo largo del tiempo.
Un proceso que logra estos objetivos no necesita ser burocrático y molesto, pero sí debe
caracterizarse en una forma que permita que un equipo de software desarrolle respuestas a un
conjunto de preguntas complejas:
9 ¿Cómo identifica un equipo de software los elementos discretos de una configuración
de software?
9 ¿Cómo gestiona una organización las numerosas versiones existentes de un
programa (y su documentación) en una forma que permita que el cambio se acomode eficientemente?

9 ¿Cómo controla una organización los cambios antes y después de que el software se
libere al cliente?
9 ¿Quién tiene la responsabilidad de aprobar y clasificar los cambios?
9 ¿Cómo se garantiza que los cambios se hayan realizado adecuadamente?
9 ¿Con qué mecanismo se valoran otros cambios que se realizan?
Estas preguntas conducen a la definición de las cinco tareas: identificación, control de la versión,
control de cambio, auditoria de la configuración e informe.
Identificación de objetos en la configuración de software
El control y la gestión de elementos de configuración del software requiere nombrar cada uno por
separado y luego organizado mediante un enfoque orientado a objetos. Es posible identificar dos tipos
de objetos: básicos y agregados. Un objeto básico e una unidad de información creada por un
ingeniero de software durante el análisis, el diseño, el código o las pruebas. Un objeto agregado es
una colección de objetos básicos y otros agregados. Conceptualmente, es posible verlo como una lista
nombrada (identificada) de punteros que especifican objetos básicos. Cada objeto tiene un conjunto
de características distintivas que los identifican de manera exclusiva.
El esquema de identificación para los objetos de configuración debe reconocer que los objetos
evolucionan a lo largo del proceso de software.
Control de la versión
El control de la versión combina procedimientos y herramientas para gestionar diferentes versiones de
objetos de configuración que se crean durante el proceso del software. Un sistema de control de la
versión implementa o está directamente integrado con cuatro grande capacidades: 1) una base de
datos del proyecto que guarda todos los objetos de configuración relevantes; 2) una capacidad de
gestión de la versión que almacena todas las versiones de un objeto de configuración; 3) una facilidad
de hechura que permita al ingeniero de software recopilar todos los objetos de configuración
relevantes y construir una versión específica del software. Además, los sistemas de control de versión
de la versión y control de cambio con frecuencia implementan una capacidad de seguimiento de
conflictos.
Varios sistemas de control de la versión establecen un conjunto de cambio que requiere la creación de
una versión específica de software. Es posible identificar varios conjuntos de cambio nombrados para
una aplicación o sistema. Esto se logra aplicando un enfoque de modelado de sistema. El modelo de
sistema contiene 1) una plantilla que incluye una jerarquía de componentes, 2) reglas de construcción
y 3) reglas de verificación.
Control de cambio
La realidad del control del cambio en un contexto moderno de ingeniería de software es vital. Bach
reconoce que se enfrenta un acto de equilibrio. Demasiado control del cambio, y se crean problemas;
poco, y se crean otros problemas.
En un gran proyecto de ingeniería de software el cambio incontrolado conduce rápidamente al caos.
Respecto a tales proyectos el control del cambio combina procedimientos humanos y herramientas
automatizadas. Se emite una solicitud de cambio y se estima para evaluar los méritos técnicos, los
potenciales efectos colaterales, el impacto global sobre otros objetos de configuración y funciones del
sistema, y el costo proyectado del cambio. Los resultados de la evaluación se presentan como un
informe de cambio, que lo utiliza una autoridad del control de cambio. Se genera una orden de cambio
en la ingeniería para cada cambio aprobado.
El objeto que se cambiara se coloca en un directorio que controle exclusivamente el ingeniero de
software que realiza el cambio. Un sistema de control de la versión actualiza el archivo original una
vez realizado el cambio.
Estos mecanismos de control de la versión, integrados en el proceso de control de cambios,
implementan dos importantes elementos de gestión de cambio: control del acceso y de sincronización.

El control del acceso rige qué ingenieros de software están autorizados para ingresar y modificar un
objeto de configuración particular. El control de la sincronización ayuda a garantizar que los cambios
paralelos, efectuados por dos personas diferentes, no se sobrescriben uno sobre otro. Antes de que
un ECS se convirtiera en línea base sólo se necesita aplicar control de cambio formal. El desarrollador
del objeto de configuración (ECS) en cuestión tiene la posibilidad de realizar cualesquiera cambios
justificados por el proyecto y los requisitos técnicos. Una vez que el objeto haya experimentado una
revisión técnica formal y haya sido aprobado, se puede crear una línea base. Una vez que un ECS se
convierte en línea base se implementa un control de cambio a nivel de proyecto.
Cuando el producto de software se libera entre los clientes se instituye el control de cambio formal. La
autoridad de control del cambio juega un papel activo en la segunda y tercera capas del control.
Dependiendo del tamaño y carácter de un proyecto de software, la ACC puede estar compuesta de
una persona o varias personas.
Auditoria de la Configuración
La identificación, el control de la versión y el control de cambio ayudan al desarrollador del Software a
mantener el orden en lo que de otro modo seria una situación caótica e inestable. Sin embargo,
incluso el mecanismo de control más exitoso solo sigue un cambio hasta que no se genera OCI.
¿Cómo se puede garantizar que el cambio sea implementado con propiedad? La respuesta es
doble:1) revisiones técnicas formales y 2) auditorias de la configuración del software.
La revisión técnica formal se enfoca en la corrección técnica del objeto de configuración que se ha
modificado. Se debe realizar una revisión técnica formal en casi la mayoría de los cambios triviales.
Una auditoria de configuración del software complementa la revisión técnica formal al abordar las
siguientes preguntas:
1. ¿Se ha realizado el cambio especificado en la OCI? ¿Se han incorporado modificaciones
adicionales?
2. ¿Se ha realizado una revisión técnica formal para evaluar la corrección técnica?
3. ¿Se ha seguido el proceso de software? ¿Se han aplicado adecuadamente los estándares
de ingeniería de software?
4. ¿El cambio se ha resaltado en el ECS? ¿Se han especificado la fecha y el autor del
cambio? ¿Los atributos del objeto de configuración reflejan el cambio?
5. ¿Se han seguido los procedimientos de GCS para destacar el cambio, registrarlo e
informar de él?
6. ¿Todos los ECS relacionados se han actualizado de manera adecuada?
En algunos casos, las preguntas de la auditoria se plantean como parte de una revisión técnica formal.
Sin embargo, cuando la GCS es una actividad formal, la auditoria de GCS la lleva a cabo por
separado el grupo de aseguramiento de la calidad.
Informe de estado
El informe de estado de la configuración es una tarea de GCS que responde las siguientes preguntas:
1) ¿qué ocurrió? 2) ¿quién lo hizo? 3) ¿cuándo ocurrió? 4) ¿qué cosa será afectada?
Cada vez que se le asigna una identificación nueva o actualizada a un ECS se efectúa una entrada de
IEC. Cada vez que la ACC aprueba un cambio se genera una entrada en el IEC. Cada vez que se
realiza una auditoria de la configuración los resultados se reportan como parte de la tarea de IEC.
4. Gestión de la Configuración para Ingeniería Web
Entre las muchas características que diferencian a la WebApps del software convencional se
encuentra la naturaleza ubicua del cambio.
La ingeniería Web utiliza un modelo de proceso incremental iterativo que aplica muchos principios
derivados del desarrollo software ágil. Al utilizar este enfoque, un equipo de ingeniería con frecuencia
desarrolla un incremento de WebApp en un periodo muy corto mediante un enfoque basado en el

cliente. En consecuencia, en el mundo ágil de la ingeniería Web el cambio se ve de manera un poco

diferente.
Los ingenieros Web deben adoptar el cambio, e incluso un típico equipo ágil evita todas las cosas que
parecen pesados procesos, burocráticos y formales.
Problemas en la Gestión de la Configuración para WebApps
Conforme las WebApps se vuelven cada vez mas importantes para la sobre vivencia y el crecimiento
de los negocios, crece la necesidad de la gestión de la configuración. ¿Por qué sin controles eficaces
los cambios inadecuados a una WebApp conducirían a la difusión no autorizada de información de un
nuevo producto; funcionalidad errónea o pobremente probada; hoyos en la seguridad que ponen en
peligro los sistemas internos de la compañía; y otras consecuencias económicamente desagradables
e incluso desastrosas. Se deben considerar cuatro temas cuando se desarrollan tácticas para la
gestión de la configuración de la WebApp: contenido, personal, escalabilidad y políticas.
Contenido. Una WebApp típica contiene una amplia variedad de contenido: Texto, gráficos, apples,
guiones, archivos de audio/video, formatos, elementos de página activos, tablas, datos clasificados
por niveles y muchos otros. El reto es organizar este océano de contenido en un conjuntó racional de
objetos de configuración y luego establecer mecanismos de control de configuración adecuados para
dichos objetos.
Personal. Puesto que un porcentaje significativo del desarrollo de la WebApp se continúa revisando
de una forma add hot, cualquier persona involucrada en la WebApp puede: crear contenido. Por lo
tanto, crece y cambia en una forma descontrolada.
Estabilidad. Las técnicas y controles aplicados en una WebApp pequeña no se escalan bien hacia
arriba. No es inusual que una WebApp siempre crezca significativamente conforme se implementen
interconexiones con sistemas de información existentes, los cambios pequeños pueden tener efectos
de largo alcance e imprevistos que pueden ser problemáticos en consecuencia, el rigor de los
mecanismo de configuración debe ser directamente proporcional a la escala de la aplicación.
Políticas. ¿Quién “posee” una WebApp? Esta pregunta se plantea en compañías grandes y
pequeñas, y su respuesta tiene un impacto significativo en las actividades de gestión y control
asociadas con la Web. Dart sugiere las siguientes preguntas para ayudar a entender las políticas
asociadas con la IWeb:
9 ¿Quién asume la responsabilidad de la precisión de la información en el Sitio Web?
9 ¿Quién asegura que se han seguido los procesos de control de calidad antes de que la
información se publique en el Sitio?
9 ¿Quién es le responsable de realizar los cambios?
9 ¿Quién asume el costo del cambio?
Las respuestas a estas preguntas ayudan a determinar a las personas que, dentro de una
organización, deben adoptar un proceso de gestión de la configuración para las WebApps.
Objetos de Configuración WebApp
Las WebApp abarcan una amplia gama de objetos de configuración: objetos de contenido,
componentes funcionales y objetos de interfaz. Los objetos WebApp de pueden identificar en
cualquier forma que sea apropiada para la organización.
Todo el contenido de la WebApp tiene formato y estructura. Los formatos internos de archivo, los dicta
el entorno de computo en el que se almacena el contenido. Sin embargo, el formato de representación
se define con el estilo estético y las reglas de diseño establecidas para la WebApp. La estructura del
contenido define la arquitectura del contenido. Boiko define la estructura como “mapas que usted tiene
sobre un conjunto de trozos de contenido para organizarlos y hacerlos accesibles a las personas que
los necesitan”.
Gestión de Contenido

La Gestión de Contenido se relaciona con la Gestión de la Configuración en el sentido en un sistema

de gestión del contenido establece un proceso que adquiere contenido existente los estructura en una
forma que permite presentarlos a un usuario final y los ofrece al entorno del lado del cliente para su
despliegue.
El caso mas común del sistema de gestión del contenido ocurre cuando se construye una WebApp
dinámica. Este WebApp crea páginas Web “al vuelo”. Es decir, usualmente el usuario consulta la
WebApp solicitando información específica. La WebApp consulta una base de datos formatea la
información en concordancia y la presenta al usuario.
En el sentido más general un SGC configura el contenido para el usuario final al invocar tres
subsistemas integrados: de colección, de gestión y publicación.
El subsistema de colección. El subsistema de colección abarca todas las acciones que se reúnen
para crear i/o adquirir contenido, así como las funciones técnicas necesarias 1) convertir el contexto
en un formato que pueda representar en un lenguaje de marcas y 2) organizar el contenido en
paquetes en que se puede despegar con eficacia en el lado del cliente.
El subsistema de gestión. Una vez que el contenido existe debe guardarse en un depósito,
catalogarse para adquisición y uso subsecuentes, y etiquetarse para definir 1) su estado actual, 2) la
versión apropiada del objeto de contenido, y 3) los objetos de contenido relacionado. Por lo tanto, el
subsistema de gestión implementa un depósito que abarca los siguientes elementos:
9 Base de datos de contenido: la estructura de información que se ha establecido para
almacenar todos los objetos de contenido.
9 Capacidades de la base de datos: funciones que permiten al SGC buscar objetos de
contenido específicos, almacenar y recuperar los objetos, y gestionar la estructura de archivos que se
ha establecido para el contenido.
9 Funciones de gestión de la configuración: los elementos funcionales y flujo de trabajo
asociado que soportan la identificación del objeto de contenido.
Además de estos elementos, el subsistema de gestión implementa una función de administración que
abarca los metadatos y reglas que controlan la estructura global del contenido y la forma en la que
recibe soporte.
El subsistema de publicación. El contenido se debe extraer del depósito, convertirse en una forma
que esté dispuesta para la publicación y formatearse de modo que sea posible transmitirlo a los
navegadores del lado del cliente. El subsistema de publicación logra estas tareas mediante una serie
de plantillas. Cada plantilla es una función que construye una publicación empleando uno de tres
componentes diferentes:
9 Elementos estáticos: ya no requieren procesamiento anterior se transmiten directamente
al lado del cliente.
9 Servicios del publicación: función que solicita servicios específicos de recuperación y
formateo que personalizan el contenido efectúan conversión de datos y construyen vínculos de
navegación apropiados.
9 Servicios externos: proporcionan acceso a infraestructura de información corporativa
externa como datos de la empresa o aplicaciones de “cuarto trasero”.
Un sistema de gestión de contenido que abarque cada uno de estos subsistemas es aplicable a
grandes proyectos de ingeniería Web. Sin embargo, la filosofía básica y la funcionalidad asociados
con un SGC son aplicables a todas las WebApps dinámicas.
Gestión del cambio
El flujo de trabajo asociado con el control del cambio para software convencional generalmente es
demasiado laborioso para la ingeniería Web. Es improbable que se logre la secuencia petición de
cambios, informe de cambio y orden de cambio de ingeniería en una forma ágil y aceptable para la

mayoría de los proyectos de desarrollo WebApp. Entonces, ¿cómo se gestiona una corriente continua
de cambios solicitada para el contenido y la funcionalidad de la WebApp?
La implementación de una gestión de cambio eficaz dentro de la filosofía “codifica y ve” que continúe
dominando el desarrollo de las WebApps requiere modificar el proceso de control de cambios
convencional. Cada cambio se debe clasificar en una de cuatro clases:
Clase 1: un cambio de contenido o función que corrija un error o mejore el contenido o funcionalidad
locales.
Clase 2: un cambio de contenido o función que tenga impacto sobre otros objetos de contenido o
componentes funcionales.
Clase 3: un cambio de contenido o función que tenga amplio impacto a través de una WebApp.
Clase 4: un gran cambio de diseño que inmediatamente apreciaran una o más categorías de usuarios.
Control de la versión
Conforme una WebApp evoluciona por medio de una serie de incrementos, es posible que exista al
mismo tiempo varias versiones diferentes. Una versión está disponible para los usuarios finales por
Internet; otra versión quizá este en las ultimas etapas finales de prueba previas al lanzamiento; una
tercera versión está en desarrollo y representa una gran actualización en contenido, estética de
interfaz y funcionalidad. Los objetos de configuración deben estar claramente definidos, de modo que
cada uno pueda estar asociado con la versión adecuada. Además, deben estar establecidos los
mecanismos de control.
Esta situación debe sonar familiar a todos los ingenieros de software, así como a todos los ingenieros
Web. Para evitarlo, se debe establecer un proceso de control de la versión.
1. Se debe establecer un depósito central para el proyecto WebApp.
2. Cada ingeniero Web crea su propia carpeta de trabajo.
3. Los relojes en las estaciones de trabajo de todos los desarrolladores deben estar sincronizados.
4. Conforme se desarrollen nuevos objetos de configuración o se cambian los objetos existentes e
importan al depósito central.
5. Conforme los objetos se importan al o exportar del depósito se elabora un mensaje automático de
registro cronometrado.
La herramienta de control de la versión mantiene diferentes versiones de la WebApp puede revertirse
a una versión más antigua si se requiere.
Auditoria y elaboración de informes
En búsqueda de agilidad, las funciones de auditoria y elaboración de informes no se resaltan en el
trabajo de ingeniería Web. Sin embargo, no se eliminaran por completo. Todos los sujetos que entran
o salen del depósito se anotan en un registro que puede revisarse en cualquier punto en el tiempo.
Además, de envía unan notificación automática de correo electrónico cada vez que un objeto entre o
salga del depósito.

Administración de Proyectos Reingeniería
Capitulo 31: Reingeniería

En los últimos años ha surgido una nueva tendencia en el desarrollo de las organizaciones y que ha sido
el resultado de los cambios cada vez más rápidos dentro del entorno de la misma. La reingeniería viene a
dar la pauta para nuevos cambios en la forma de operar de las organizaciones.
Reingeniería de Sistemas
Recupera información sobre el diseño de un programa existente y utiliza esta información para
reestructurar o reconstruir el programa existente, con vistas a adaptarlo a un cambio, a ampliarlo o a
mejorar su calidad general, con el objetivo de conseguir una mayor facilidad de mantenimiento en el
futuro (esto es lo que se denomina mantenimiento preventivo).
Reingeniería
Es la revisión fundamental y el rediseño radical de procesos para alcanzar mejoras espectaculares en
medidas críticas, tales como costos, calidad, servicio y rapidez.
Esto implica rehacer la Institución o parte de ella desde cero, olvidándonos de lo que se hacía y proponer
un nuevo sistema de operación.
El pensar en una nueva estructura organizacional nos hace ver una nueva serie de perspectivas para la
Institución y sus empleados.
Existe una importante tendencia al cambio de los valores organizacionales y de actitudes de tipo
proteccionista a orientaciones productivas en donde el papel de los directivos cambia de supervisores a
entrenadores de su gente, en donde las estructuras organizacionales serán planas desapareciendo las
estructuras jerárquicas y la ambición y las habilidades de los ejecutivos cambien de "anotadores de
tantos" a verdaderos directivos de transformaciones.
Los directivos de las Instituciones del futuro deberán apoyar a que el personal de los diferentes niveles
tomen decisiones y por lo tanto estén debidamente facultados para ello.
La reingeniería no solo es automatizar procesos existentes, sino presentar nuevos procesos que rompan
con los actuales, logrando mejorar la forma de hacer las cosas.
En la reingeniería se han tomado como referencia los siguientes aspectos
· Varios oficios se combinan en uno.
· Los trabajadores toman decisiones.
· Los pasos del proceso se ejecutan en orden natural.
· Los procesos tienen múltiples versiones.
· El trabajo se realiza en el sitio razonable.
· Se reducen las verificaciones y los controles.
Reingeniería del Software
La reingeniería del software es la tecnología que surge de aplicar las técnicas de Inteligencia Artificial y
matemática sofisticada al análisis automatizado y modificación del código fuente de programas, para
abreviarlo y hacerlo más eficiente.
Actualmente la creación y modificación de programas de computadora es una tarea principalmente
manual, y una tarea difícil e imprevisible. Los programas grandes suelen ser más complejos y más
difíciles de depurar.
Freddy Rocha Boza Pág. 1

Aunque la tecnología todavía está en su infancia, la reingeniería del software está empezando a tomar
algunas tareas de programación, particularmente las tareas menos creativas, más repetitivas y las
automatiza. Estos programas de reingeniería, escritos en idiomas especialmente diseñados, operan en el
código fuente de los programas y realizan una variedad de análisis y modificaciones.
Por qué aplicar reingeniería del software
Cuando una aplicación ha servido para las necesidades del negocio de una compañía durante varios
años, se vuelve inestable debido a las correcciones, adaptaciones y mejoras que se realizaron. Esto
deriva en que cada vez que se intenta efectuar un cambio se produzcan efectos colaterales graves e
inesperados. Por esta razón es conveniente utilizar la reingeniería del software.
Tecnología:
La tecnología debe estar al servicio del usuario; a través de ella se hace un mejoramiento de la capacidad
decisoria del personal. La tecnología facilita el diseño de los sistemas de información para la calidad del
servicio, siempre pensando en el cliente. Así se debe manejar más información y menos papeles.
Cada proyecto será desarrollado cuidadosamente por personal capacitado en el área, y cuyo proyecto
será presentado al Presidente para su previa autorización y puesta en marcha después de ésta.
Dicho proyecto será respaldado por su documentación correspondiente y su bitácora de seguimiento.
Ingeniería inversa
La ingeniería inversa se basa en quitar, remover, suspender uno o más temas de protección de alguna
aplicación ya siendo comercial y otras. Muchos consideran esto como un arte.
El objetivo de la ingeniería inversa es obtener información técnica a partir de un producto accesible al
público, con el fin de determinar de qué está hecho, qué lo hace funcionar y cómo fue fabricado. Los
productos más comunes que son sometidos a la ingeniería inversa son los Programas de computadoras y
los componentes electrónicos.
Este método es denominado ingeniería inversa porque avanza en dirección opuesta a las tareas
habituales de ingeniería, que consisten en utilizar datos técnicos para elaborar un producto determinado.
En general si el producto u otro material que fue sometido a la ingeniería inversa fue obtenido en forma
apropiada, entonces el proceso es legítimo y legal.
La ingeniería inversa es un método de resolución. Aplicar ingeniería inversa a algo supone profundizar en
el estudio de su funcionamiento, hasta el punto de que podemos llegar a entender, modificar, y mejorar
dicho modo de funcionamiento.
Pero este término no sólo se aplica al software de protección. Así pues se considera ingeniería inversa
también al estudio de todo tipo de elementos, por ejemplo equipos electrónicos, microcontroladores, etc.,
siempre y cuando el resultado de dicho estudio repercuta en el entendimiento de su funcionamiento.

Un modelo RPN
Definición del Negocio:
Las metas del negocio y los procesos con se logran se deben de adaptar a un entorno de negocios
cambiante pos esta razón no existe principio ni fin para la RPN , se trata de un proceso evolutivo
Definición del negocio:
Las metas del negocio se identifican en el contexto de cuatro controladores clave
1. Reducción del costo
2. Reducción de tiempos
3. Mejora de la calidad y desarrollo
4. Fortalecimiento de del personal
Identificación del proceso:
Se identifican los procesos cruciales para lograr las metas precisadas en la definición del negocio luego
puede clasificarse de acuerdo a su importancia o necesidad de cambio o cualquier otra forma que sea
adecuada para la actividad de la reingeniería.
Evaluación de procesos
El proceso existente se analiza y se mide exhaustivamente. Se identifican las tareas del proceso, se
anotan los costos y el tiempo que consumen los procesos y se aíslan los problemas de calidad y de
desempeño
Especificación y diseño del proceso
Con base a la retroalimentación obtenida durante las primeras tres actividades de la RPN se preparan
casos de uso para cada proceso que será rediseñado
Elaboración de prototipos:

Un proceso de negocio rediseñado debe de convertirse en prototipo antes de que sea integrado por
completo en el negocio
Refinamiento y particularización
Con base a la retroalimentación del prototipo el proceso del negocio se refina y luego se particulariza
dentro del sistema del negocio
Modelo de Procesos de Reingeniería del software

Análisis de inventarios:
El inventario talvez no sea mas que un modelo en una hoja de calculo que contenga información que
proporcione un a descripción detallada de las aplicaciones activas .permite que la organización evalué
cada aplicación sistemáticamente con la finalidad de establecer cuales son candidatos a la reingeniería
Reestructuración de documentos:
Crea un marco de trabajo de documentación que es necesario para brindar apoyo a largo plaza a una
aplicación.
El sistema es crucial para el negocio se debe de recortar la documentación a un mínimo esencial
Ingeniería inversa:
Es el proceso de crear una representación del programa a un mayor grado de abstracción que el código
fuente empleando modernas prácticas de ingeniería de software
Reestructuración de código fuente:

Se indican las violaciones de las estructuras de programación estructurada y entonces el código se

reestructura.
El código reestructurado resultante se revisa y prueba para revisar que no se han introducido
anormalidades, la documentación del código interno se actualiza
Reestructuración de los datos:
Es una actividad de reingeniería a gran escala, comienza con una actividad de ingeniería inversa, se
analizan con minuciosidad y se definen los modelos de datos necesarios se identifican los modelos de
datos y los atributos y después de revisa la calidad de la estructura de datos existente
Ingeniería directa:
También llamada renovación o reclamación no solo recupera la información de diseño a partir del
software existente también utiliza esta información para alterar o reconstruir el sistema existente con la
finalidad de mejorar la calidad global en ocasiones también añade nuevas tareas e información
aprendidas durante la aplicación de la ingeniería inversa.
Además se toman en cuenta otros aspectos de la ingeniería inversa

A saber
Ingeniería inversa para comprender los datos
Las bases de datos se ajustan con los nuevos paradigmas y se establece el escenario para la
introducción de una nueva base de datos que abarque todo el sistema
Ingeniería inversa para comprender el procesamiento

Para comprender las abstracciones de procesamiento de código se analizan en grados variables de

abstracción: sistema, programa, componentes, patrón y planeamiento
Esto establece un contexto para un mayor análisis
Ingeniería inversa para interfaces de usuario
Se requiere especificar la estructura y el comportamiento de la interfaz con preguntas como
1. Cuales son las acciones básicas
2. Cual es la descripción compacta de las respuestas de comportamientos de sistema a estas
acciones
3. Que se entiende por reemplazo
Aspectos de la ingeniería Directa
Ingeniería directa para arquitecturas cliente servidor
Características:
La funcionalidad de la aplicación migra hacia cada computadora cliente
En los sitios cliente se implementan nuevas interfaces
La funcionalidad especializada puede permanecer en el sitio servidor
Tanto en los sitios cliente como en los sitios servidor se deben de establecer nuevos requisitos de
comunicaciones, seguridad, archivado, y control
Ingeniería directa para arquitecturas orientadas a objetos
Ingeniería directa para arquitecturas orientadas a objetos:
La ingeniería del software orientado a objetos se ha convertido en la alternativa en cuanto al paradigma
de desarrollo para muchas organizaciones
Pero, ¿Qué hay acerca de las aplicaciones existentes que se desarrollan empleando métodos
convencionales? En algunos casos la respuesta es dejar tales aplicaciones “como están” .En otros, las
aplicaciones viejas deben de someterse a reingeniería de modo que se integre con facilidad en grandes
sistemas orientados a objetos
Ingeniería directa para interfaces de usuario
Interfaces de usuario
Características:
1. Comprender la interfaz original de los datos que se trasladan entre ella y el resto de la aplicación
2. Remoldear el comportamiento implícito en la interfaz existente en una seria de abstracciones
que tengan sentido en el contexto de una GUI
3. Introducir mejoras que hagan más eficiente el modo de interacción
4. Construir e integrar la nueva GUI
La economía de la reingeniería
Cualquier programa que no se le pueda dar mantenimiento será retirado inmediatamente y será
sustituido por aplicaciones de mayor calidad con reingeniería desarrollada empleando modernas
prácticas de ingeniería de software
Sin embargo la reingeniería demanda recursos limitados que pueden utilizarse para otros propósitos del
negocio por ello se debe de realizar un-análisis costo-beneficio
Aquellas aplicaciones que muestren mayor costo-beneficio podrán destinarse a la reingeniería mientras el
trabajo con otras se puede posponer hasta que haya recursos disponibles.
En costo-beneficio de la reingeniería se determina cuantitativamente.
Conclusión
La ingeniería e presenta en dos diferentes grados de abstracción en el ámbito del negocio con el
propósito de efectuar los cambios para mejorar la competitividad en alguna área del negocio y en el
ámbito del software ,la reingeniería examina los sistemas y aplicaciones de información con la finalidad
de reestructurarlos o reconstruirlos de modo que muestren mayor calidad, define las metas del negocio,
identifica y evalúa los procesos de negocios existentes, especifica y diseña procesos revisados, elabora
prototipos los refina y particulariza dentro del negocio
La reingeniería de software comprende una serie de actividades que incluyen análisis de inventario,
reestructuración de documentos, ingeniería inversa, reestructuración de programas y datos, e ingeniería
directa .la finalidad de todas estas actividades es crear versiones de programas existentes que sean de
mayor calidad y tengan mayor facilidad de mantenimiento.

Pressman GestionProyectosSofware

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Pressman GestionProyectosSofware

Uploaded by

Copyright:

Available Formats

IS074 Pressman Cáp.

Capítulo 21: Conceptos de Gestión de Proyectos

Adrián Rojas González Pág. 1

Adrián Rojas González Pág. 2

1) Una atmósfera de trabajo frenética.

Adrián Rojas González Pág. 3

Puesto que las estimaciones de costo y planificación temporal están funcionalmente

Adrián Rojas González Pág. 4

y analice métricas de proyecto de software, obtenga realimentación de los miembros del

Adrián Rojas González Pág. 5

Capitulo 22: “Métricas de proceso y de proyecto”

Ignacio Granados Pág. 1

Ignacio Granados Pág. 2

• Facilidad de uso: La facilidad de uso es un intento por cuantificar la sencillez de la

Ignacio Granados Pág. 3

• Defectos descubiertos después de que el cambio es liberado a la base de clientes,

Ignacio Granados Pág. 4

Capitulo 23: Estimación para Proyectos de Software

Alexander Díaz Pág. 1

Alexander Díaz Pág. 2

Alexander Díaz Pág. 3

Capitulo 24: Calendarización de Proyectos de Software

Luis Randall Zúñiga Pág. 1

Luis Randall Zúñiga Pág. 3

Capitulo 25: Gestión del Riesgo en Proyectos de Software

Luis Diego Pérez Pág. 1

• Características del cliente

Luis Diego Pérez Pág. 2

Luis Diego Pérez Pág. 3

Capitulo 26: Gestión de la Calidad en Proyectos de Software

Satisfacción del usuario = producto manejable + buena calidad

Mariano Dilascio Pág. 1

Garantía de la Calidad del Software (SQA)

Mariano Dilascio Pág. 3

2. Se intenta determinar la causa subyacente de cada defecto.

Mariano Dilascio Pág. 4

Mariano Dilascio Pág. 5

Capitulo 27: Gestión del Cambio en Proyectos de Software

Fernando Alberto Segura Pág. 1

Fernando Alberto Segura Pág. 2

Fernando Alberto Segura Pág. 3

El depósito se define en función de un metamodelo. Para lograr estas funciones el metamodelo

Fernando Alberto Segura Pág. 4

Fernando Alberto Segura Pág. 5

Fernando Alberto Segura Pág. 6

cliente. En consecuencia, en el mundo ágil de la ingeniería Web el cambio se ve de manera un poco

Fernando Alberto Segura Pág. 7

La Gestión de Contenido se relaciona con la Gestión de la Configuración en el sentido en un sistema

Fernando Alberto Segura Pág. 8

Fernando Alberto Segura Pág. 9

Capitulo 31: Reingeniería

Freddy Rocha Boza Pág. 1

Freddy Rocha Boza Pág. 2

Freddy Rocha Boza Pág. 3

Modelo de Procesos de Reingeniería del software

Freddy Rocha Boza Pág. 4

Se indican las violaciones de las estructuras de programación estructurada y entonces el código se

Además se toman en cuenta otros aspectos de la ingeniería inversa

Freddy Rocha Boza Pág. 5

Para comprender las abstracciones de procesamiento de código se analizan en grados variables de

Freddy Rocha Boza Pág. 7

You might also like