Pressman GestionProyectosSofware

IS074 Administración de Proyectos Pressman Cáp. 21

Conceptos Gestión PSW

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

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.




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.


Métricas de Procesos en PSW

Ignacio Granados Pág. 1

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




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


Estimación para PSW

Alexander Díaz Pág. 1

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.




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.


Calendarización de PSW

Luis Randall Zúñiga Pág. 1

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.




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 proyec se enfocan en aplicar las siguientes tareas

minación del ámbito del concepto.

ncepto.

eden refinar detalladamente para así calendarizar detalladamente.

idades, es una representación gráfica del flujo de tareas en

la ruta crítica.

calendarización de tareas con el método PERT Y CMP son dos métodos de

de la función del

as

ndariza se comienza con un conjunto de tareas, donde se hace la red de

da su duración su fecha de inicio, se

as e hitos

e reuniones valorando el estado del proyecto.

l proyecto.

La calendarización l ión que es un componente

tos de desarrollo del concepto principales:

1.1 La deter

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 co

1.6 La reacción del cliente.

Teniendo estas tareas se pu

Definición de una red de tareas

También se denomina red de activun 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

Calendarización

Con respecto a la calendarización de proyecto que se pueden aplicar al desarrollo de software.

Anteriormente se han realizado la estimación del esfuerzo, descomposiciónproducto, Selección del modelo de proceso y conjunto de tareas apropiadas, descomposición de tareas.

Cronogram

Cuando se caletareas, 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 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 tareseguir y controlar conforme avanza el proyecto.

Este seguimiento se puede realizar mediante:

o Realización periódica d

o Evaluación de los resultados a lo largo del proceso.

o Determinación se han logrados los hitos formales de

o Medición de tiempos, fechas previstas contra fechas reales.

o Evaluación sugestiva de los trabajadores.

o Evaluación del progreso cuantitativamente

es a culminación de una actividad de planificacn del principal de la gestió proyecto de software.


Gestión del Riesgo en PSW

Luis Diego Pérez Pág. 1

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




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


Gestión de la Calidad en PSW

Mariano Dilascio Pág. 1

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.




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.


Gestión del Cambio en PSW

Fernando Alberto Segura Pág. 1

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:

Nuevas condiciones en el negocio o mercado dictan los cambios en lo requisitos de producto o las reglas del negocio.

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.

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.

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




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:

Elementos de componentes: conjunto de herramientas acopladas dentro de un sistema de gestión de archivos.

Elementos de proceso: serie de procedimientos y tareas que definen un enfoque eficaz con el cual gestionar el cambio.

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

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:

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.

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.

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.

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.

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.

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:

¿Cómo identifica un equipo de software los elementos discretos de una configuración de software?

¿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?




¿Cómo controla una organización los cambios antes y después de que el software se libere al cliente?

¿Quién tiene la responsabilidad de aprobar y clasificar los cambios?

¿Cómo se garantiza que los cambios se hayan realizado adecuadamente?

¿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:

¿Quién asume la responsabilidad de la precisión de la información en el Sitio Web?

¿Quién asegura que se han seguido los procesos de control de calidad antes de que la información se publique en el Sitio?

¿Quién es le responsable de realizar los cambios?

¿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:

Base de datos de contenido: la estructura de información que se ha establecido para almacenar todos los objetos de contenido.

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.

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:

Elementos estáticos: ya no requieren procesamiento anterior se transmiten directamente al lado del cliente.

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.

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.


Reingeniería

Freddy Rocha Boza Pág. 1

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.


Reingeniería


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.


Reingeniería


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:


Reingeniería


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:


Reingeniería


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


Reingeniería


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


Reingeniería


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

Documents

Transcript of Pressman GestionProyectosSofware