You are on page 1of 15

Gestión de Proyectos Unidad 5

Ing. Sistemas Computacionales
Catedratico: Ing. Jorge Magaña Govea
Alumnos:
Ballina Montuy José Juan
Cañas Landero Agustín
Domínguez Hernandez Deyvis
León Gómez Esdras Román
López Gutiérrez Hilda Virginia


Balancán Tabasco; Julio de 2014
7mo. Semestre Matutino
Productividad en el desarrollo de un proyecto de
software.
Índice
Introducción ..................................................................................................................................... 3
Productividad .................................................................................................................................. 4
Actividades de control .................................................................................................................. 5
Supervisión ...................................................................................................................................... 8
Revisiones Técnicas Formales ................................................................................................. 11


Introducción
La productividad en el proceso de desarrollo de software es de mucha importancia
al momento de desarrollar un software, ya que marca como se debe realizar y con
cuales características debe de estar conformado para que sea un gran producto
de calidad.
Todo esto se realiza de acuerdo a los requisitos que se han asignado para este.
En todo el proceso se realizan revisiones para saber cómo va el avance y así
poder detectar los errores que hayan surgido, mientras más pronto se encuentren
los errores mejor será la calidad del software.
Las supervisiones son realizadas por un encargado para llevar acabo cada
revisión durante el proceso del desarrollo y así mejorar la productividad del
producto.

Productividad

Ingeniería de Software Séptima Edición. Autor: Ian Somerville. Editorial: Addison
Wesleyae.

La productividad en una empresa manufacturera se mide dividiendo el
número de unidades producidas entre el número de personas/hora requeridas
para producirlas. Sin embargo, para cualquier problema de software, existen
muchas soluciones diferentes con distintas características. Una solución podría
ejecutarse de forma más eficiente mientras otra podría ser más legible y fácil de
mantener. Cuando se producen soluciones con distintas características, no tiene
sentido comparar las tasas de producción.

Sin embargo, los administradores tienen que estimar la productividad de los
ingenieros en el proceso de desarrollo software. Estas estimaciones son
necesarias para la estimación del proyecto y para valorar si los procesos o las
mejoras tecnológicas son efectivas. Por lo general, estas estimaciones de
productividad se basan en medir alguno de los atributos del software y dividir el
resultado entre el esfuerzo total requerido para el desarrollo. Existen dos tipos de
medidas utilizadas:

1. Medidas relacionadas con el tamaño. Está se relacionan con el tamaño
de la salida de alguna actividad. La medida más común relacionada con el
tamaño son las líneas de código fuente entregadas. Otras medidas que se
utilizan son el número de instrucciones de código objeto entregado o el
número de páginas de la documentación del sistema.
2. Medidas relacionadas con la función. Éstas se relacionan con la
funcionalidad total del software entregado. La productividad se expresa
según la cantidad de funcionalidad útil producida en un tiempo dado. Los
puntos de función y los puntos objeto son las medidas más conocidas de
este tipo.

Las líneas de código fuente por programador/mes son una métrica
ampliamente utilizada en la medida de la productividad. Ésta se calcula contando
el número total de líneas de código fuente que se entrega. La cuenta se divide
entre el tiempo total de programadores/mes requeridos para completar el proyecto.
Por lo tanto, este tiempo incluye el tiempo requerido para el análisis y diseño,
codificación, pruebas y documentación.

La productividad se expresa como el número de puntos de función que son
implementados por persona/mes. Un punto de función no es una característica
simple sino que es una combinación de características del programa. El número
total de puntos de función en un programa se calcula midiendo o estimando las
siguientes características del programa:

 Entradas y salidas externas.
 Interacciones con el usuario.
 Interfaces externas.
 Archivos utilizados por el sistema.

MÉTRICAS DE REVISIÓN Y SU EMPLEO

Las revisiones técnicas son una de las muchas acciones que se requieren
como parte de las buenas prácticas de la ingeniería de software. Cada acción
requiere un esfuerzo humano dirigido. Como el esfuerzo disponible para el
proyecto es finito, es importante que una organización de software comprenda la
eficacia de cada acción, definiendo un conjunto de métricas.

Aunque se han definido muchas métricas para las revisiones técnicas, un
conjunto relativamente pequeño da una perspectiva útil. Las siguientes métricas
para la revisión pueden obtenerse conforme se efectúe ésta:

 Esfuerzo de preparación, E
p
: esfuerzo (en horas-hombre) requerido para
revisar un producto del trabajo antes de la reunión de revisión real.
 Esfuerzo de evaluación, E
a
: esfuerzo requerido (en horas-hombre) que se
dedica a la revisión real.
 Esfuerzo de la repetición, Er: esfuerzo (en horas-hombre) que se dedica a
la corrección de los errores descubiertos durante la revisión.
 Tamaño del producto del trabajo, TPT: medición del tamaño del producto
del trabajo que se ha revisado (por ejemplo, número de modelos UML o
número de páginas de documento o de líneas de código).
 Errores menores detectados, Err
menores
: número de errores detectados que
pueden clasificarse como menores (requieren menos de algún esfuerzo
especificado para corregirse).
 Errores mayores detectados, Err
mayores
: número de errores encontrados que
pueden clasificarse como mayores (requieren más que algún esfuerzo
especificado para corregirse).

Estas métricas pueden mejorarse, asociando el tipo de producto del trabajo
que se revisó con las métricas obtenidas.

Actividades de control
Control de calidad
El control de cambios puede equiparse al control de calidad. Pero ¿Cómo
se logra el control de calidad? El control de calidad es una serie de inspecciones,
revisiones y pruebas utilizado a lo largo del proceso del software para asegurar
que cada producto cumple con los requisitos que le han sido asignados. El control
de calidad incluye un bucle de retroalimentación (feedback) del proceso que creo
el producto. La combinación de medición y realimentación permite afirmar el
proceso cuando los productos de trabajos creados fallan al cumplir sus
especificaciones. Este enfoque ve el control de calidad como parte del proceso de
fabricación.
¿Qué es el control de calidad de software?
Las actividades de control de calidad pueden ser manuales, completamente
automáticas o una combinación de herramientas automáticas e interacción
humana. Un concepto clave del control de calidad es que se hayan definido todos
los productos y las especificaciones mensurables en las que se puedan comparar
los resultados de cada proceso. El bucle de retroalimentación es esencial para
reducir los defectos producidos.

Garantía de calidad
La garantía de calidad consiste en la auditoria y las funciones de
información de la gestión. El objetivo de la garantía de calidad es proporcionar la
gestión para informar de los datos necesarios sobre la calidad del producto, por lo
que se va adquiriendo una visión más profunda y segura de que la calidad del
producto está cumpliendo sus objetivos. Por supuesto, si los datos proporcionados
mediante la garantía de calidad identifican problemas, es responsabilidad de la
gestión afrontar los problemas y aplicar los recursos necesarios para resolver
aspectos de calidad.

Coste de calidad
El coste de calidad incluye todos los costes acarreados en la búsqueda de
calidad o en las actividades relacionadas en la obtención de calidad. Se realizan
estudios sobre el coste de calidad, para proporcionar una línea base del coste
actual de calidad, para identificar oportunidades de reducir este coste, y para
proporcionar una base normalizada de comparación. La base de normalización
siempre tiene un precio. Una vez que se han normalizados los costes de calidad
sobre un precio base, tenemos los datos necesarios para evaluar el lugar en
donde hay oportunidades de mejorar nuestro proceso.
Es más podemos evaluar cómo afectan los cambios en términos de dinero.
Los costes de calidad se pueden dividir en costes asociados con la
prevención, la evaluación y los fallos.
Entre los costes de prevención se incluyen:
 Planificación de calidad,
 Revisiones técnicas formales,
 Equipo de pruebas,
 Formación.


Resumen
El control de calidad es una revisión general de todo lo que se está
realizando en el desarrollo de software para cumplir con los requisitos que se le
han sido asignados. El bucle de retroalimentación es esencial para reducir los
defectos producidos.
La garantía de calidad es un informe de lo que se está realizando con el
software, es una revisión profunda para saber que es de buena calidad dicho
software.
Los costes de calidad se realizan para saber todo lo que se va a gastar en
el desarrollo del software y así poder reducir todos estos costes. Estos se pueden
dividir en costos asociados con la prevención: los de evaluación y los de fallos.

Supervisión

Es una actividad técnica y especializada que tiene como fin fundamental
utilizar racionalmente los factores: hombre, materia prima, equipos, maquinarias,
herramientas y dinero.
Requiere, planificar, organizar, dirigir, ejecutar y retroalimentar
constantemente. Exige constancia, dedicación y perseverancia.
Objetivos
 Desarrollar un uso.
 Mejorar la productividad de los empleados.
 Obtener una adecuada rentabilidad de cada actividad óptima de los
recursos.
 Apoyar el desarrollo constante de los empleados de manera integral y
realizada.
 Monitorear las actitudes de los subordinados y condiciones laborales.
Principios
1. La dirección y supervisión no pueden separarse. Son funciones
coordinadas, complementarias y mutuamente compartidas en el
funcionamiento de cualquier organización.
2. Se ocupa de mejorar un trabajo o labor en particular.
3. Es sensible a cambios y debe dedicarse continuamente a la reevaluación
de los objetivos, materiales, políticas y métodos.
4. Deberá basarse en la filosofía democrática.
5. Deberá emplear métodos para el estudio y mejoramiento del trabajo de la
evaluación del trabajo, actitudes científicas aplicables al trabajo, al
trabajador y a los procesos de trabajo.
6. Tiene que ser creativa.
7. Debe realizarse a través de actividades orientadas, proyectadas,
programadas y ejecutadas en conjunto.
8. Debe juzgarse por la economía y la eficacia de los resultados que obtenga.
Los supervisores que conocen cabalmente los principios de la supervisión y
se guían por ellos son, por lo general, mucho más efectivos y eficientes que
los que operan a nivel técnico.
Características
 Energía y buena salud.
 Potencial para el liderazgo.
 Capacidad para desarrollar buenas relaciones personales.
 Conocimiento del trabajo y competencia técnica.
 Capacidad para mantener el ritmo de trabajo.
 Capacidad de enseñanza.
 Habilidad para resolver problemas.
 Dedicación y confiabilidad.
 Actitud positiva hacia la administración.

Niveles de supervisión
 Supervisión en el ámbito comunitario: El propósito más importante de la
supervisión es el de mejorar la implementación y la gestión de los
proyectos. Asegurar que los proyectos se implementan a tiempo y que sean
de buena calidad. Que las aportaciones al proyecto se utilizan
adecuadamente.

 Supervisión en el ámbito regional y comarcal: La región tiene que
supervisar el incremento en la fuerza, capacidad y poder de la comunidad
destinataria para el estímulo de su propio desarrollo.

 Supervisión en el contexto nacional y de donantes: La supervisión en el
ámbito nacional y de donantes sirve para comprobar si las aportaciones se
utilizan correctamente (es decir, que se alcanzan los objetivos deseados), si
el diseño del proyecto es el adecuado y para adquirir experiencia.
Supervisor de proyectos
El supervisor es un elemento clave dentro de cualquier organización. De él
depende la calidad del trabajo, el rendimiento, la moral y el desarrollo de buenas
actitudes por parte de los trabajadores. Dirige y evalúa el trabajo y conoce a todos
los trabajadores. Especialista del comportamiento humano, en lo que concierne a
la práctica de la habilidad administrativa y de los aspectos técnicos de su cargo.
Características del Supervisor
 Conocimiento del Trabajo: Esto implica que debe conocer la tecnología de
la función que supervisa, las características de los materiales, la calidad
deseada, los costos esperados y los procesos necesarios.

 Conocimiento de sus Responsabilidades: Esta característica es de gran
importancia, ya que ella implica que el supervisor debe conocer las
políticas, reglamentos y costumbres de la empresa, su grado de autoridad,
sus relaciones con otros departamentos, las normas de seguridad,
producción, calidad, entre otros.

 Habilidad Para Instruir: El supervisor necesita adiestrar a su personal para
poder obtener resultados óptimos. Las informaciones, al igual que las
instrucciones que imparte a sus colaboradores, deben ser claras y precisas.

 Habilidad Para Mejorar Métodos: El supervisor debe aprovechar de la mejor
forma posible los recursos humanos, materiales, técnicos y todos los que la
empresa facilite, siendo crítico en toda su gestión para que de esta manera
se realice de la mejor forma posible, es decir, mejorando continuamente
todos los procesos del trabajo.

 Habilidad para Dirigir: El supervisor debe liderar a su personal, dirigiéndolo
con la confianza y convicción necesaria para lograr credibilidad y
colaboración de sus trabajos.

Funciones del Supervisor:
 Proyectar: Programar o planificar el trabajo del día, establecer la prioridad y
el orden.
 Dirigir: Delegación de autoridad y la toma de decisiones, el supervisor debe
dar instrucciones claras, específicas, concisas y completas.
 Desarrollar: Es la responsabilidad de mejorar constantemente a su
personal, desarrollando sus aptitudes en el trabajo, estudiando métodos de
trabajo y elaborando planes de adiestramiento para el personal nuevo y
antiguo.
 Controlar: Significa crear conciencia en sus colaboradores para que sea
cada uno de ellos los propios controladores de su gestión, actuando luego
el supervisor como conciliador de todos los objetivos planteados.

Resumen
Es una actividad técnica y especializada que tiene como fin fundamental
utilizar racionalmente los factores: hombre, materia prima, equipos, maquinarias,
herramientas y dinero.
Para ello en el desarrollo de software se le da el rol “supervisor” a un
empleado donde de él depende la calidad del trabajo, el rendimiento, la moral y el
desarrollo de buenas actitudes por parte de los trabajadores. Dirige y evalúa el
trabajo y conoce a todos los trabajadores.
Revisiones Técnicas Formales

Ingeniería del Software “Un Enfoque Práctico” Séptima Edición, Autor: Roger S.
Pressman. Editorial: Mc Graw Gill.

Una revisión técnica formal (RTF) es una actividad del control de calidad del
software realizada por ingenieros de software (y otras personas). Los objetivos de
una RTF son:

1. Descubrir los errores en funcionamiento, lógica o implementación de
cualquier representación del software.
2. Verificar que el software que se revisa cumple sus requerimientos.
3. Garantizar que el software está representado de acuerdo con estándares
predefinidos.
4. Obtener software desarrollado de manera uniforme.
5. Hacer proyectos más manejables.

Además, la RTF sirve como método de capacitación, pues permite que los
ingenieros principiantes observen distintos enfoques de análisis, diseño e
implementación del software. La RTF también funciona para estimular el respaldo
y la continuidad debido a que varias personas se familiarizan con software que de
otra manera no hubieran visto.

La RTF en realidad es una clase que incluye walkthroughs e inspecciones.
Cada RTF se realiza como una reunión y tendrá éxito sólo si se planea, controla y
ejecuta en forma apropiada. En las secciones que siguen se presentan
lineamientos similares a aquellos usados para un walkthrough, como
representativos de la revisión técnica formal.

La reunión de revisión

Sin importar cuál formato de RTF se elija, cualquiera de ellos debe cumplir
las restricciones siguientes:

• En la revisión deben involucrarse de tres a cinco personas (normalmente).
• Debe haber preparación previa, pero no debe exigir más de dos horas de
trabajo de cada persona.
• La duración de la reunión de revisión debe ser de al menos dos horas.

Dadas estas restricciones, debe resultar obvio que una RTF se centra en una
parte específica (y pequeña) del software general. Al reducir el alcance, la RTF
tiene mayor probabilidad de detectar errores.

La atención de la RTF se dirige a un producto. El individuo que haya
desarrollado el producto —el productor— informa al líder del proyecto que ha
terminado y que se requiere hacer una revisión. El líder del proyecto contacta al
líder de la revisión, quien evalúa el producto en cuanto a su conclusión, genera
copias de los materiales del producto y las distribuye a dos o tres revisores para la
preparación previa. Se espera que cada revisor dedique de una a dos horas a la
inspección del producto, tome notas y se familiarice con el trabajo. Al mismo
tiempo, el líder del proyecto también revisa el producto y establece una agenda
para la reunión de revisión, que por lo general se programa para el día siguiente.

A la reunión de revisión acuden el líder de ésta, todos los revisores y el
productor. Uno de los revisores adopta el rol de secretario, es decir, quien registra
(por escrito) todos los acontecimientos importantes que surjan durante la revisión.
La RTF comienza con el análisis de la agenda y una introducción breve por parte
del productor. Después, éste procede a “recorrer” el producto del trabajo,
explicando el material, mientras los revisores hacen sus comentarios con base en
la preparación que hicieron. Cuando se descubren problemas o errores válidos, el
secretario toma
nota de ellos.

Al terminar la revisión, todos los asistentes deben decidir si:

1. Aceptan el producto sin modificaciones.
2. Lo rechazan debido a errores graves (una vez corregidos, se realiza otra
revisión).
3. Aceptan el producto de manera provisional (se encontraron errores
menores que deben corregirse, pero no se necesita otra revisión).

Una vez tomada la decisión, todos los asistentes a la RTF firman el acta
que indica su participación y su acuerdo con los descubrimientos del equipo de
revisión.

Reporte y registro de la revisión

Durante la RTF, un revisor (el secretario) registra activamente todos los
asuntos que se planteen. Éstos se resumen al final de la reunión y se produce la
lista de pendientes de la revisión. Además se elabora un reporte técnico formal de
la revisión. Éste responde tres preguntas:

1. ¿Qué fue lo que se revisó?
2. ¿Quién lo revisó?
3. ¿Cuáles fueron los descubrimientos y las conclusiones?

El resumen del reporte de la revisión es una sola página que se vuelve
parte del registro histórico del proyecto y se entrega al líder del proyecto y a otras
partes interesadas.

La lista de pendientes de la revisión tiene dos propósitos:

1. Identificar áreas de problemas en el producto.
2. Servir como lista de verificación de acciones que guíe al productor cuando
se hagan las correcciones.

La lista de pendientes normalmente se anexa al reporte técnico. Debe
establecerse un procedimiento de seguimiento para garantizar que los pendientes
de la lista se corrijan de manera apropiada. A menos que esto se haga, es posible
que los pendientes anotados “se pierdan en el camino”. Un enfoque consiste en
asignar la responsabilidad del seguimiento al líder del proyecto.

Lineamientos para la revisión

Los lineamientos para efectuar revisiones técnicas formales deben
establecerse por adelantado, distribuirse a todos los revisores, llegar al consenso
y, después, seguirse. Una revisión sin control con frecuencia es peor que si no se
hiciera ninguna. Los siguientes representan un conjunto mínimo de lineamientos
para hacer revisiones técnicas formales:

1. Revise el producto, no al productor. Una RTF involucra personas y sus
egos. Si se lleva a cabo en forma adecuada, la RTF debe dejar en todos los
participantes una sensación de logro. Si se efectúa de modo inapropiado,
adopta un aire inquisitorial. Los errores deben señalarse en forma amable;
el tono de la reunión debe ser relajado y constructivo; el trabajo no debe
apenar o menospreciar a nadie. El líder de la revisión debe conducir la
reunión en tono y actitud apropiados y debe detenerla de inmediato si se
sale de control.

2. Establezca una agenda y sígala. Una de las fallas clave de las reuniones de
todo tipo es la dispersión. Una RTF debe mantenerse encarrilada y dentro
del programa. El líder de la revisión tiene la responsabilidad de que así sea
y no debe sentir temor de llamar al orden a las personas cuando se
dispersen.

3. Limite el debate y las contestaciones. Cuando el revisor plantee un asunto,
quizá no haya acuerdo universal acerca de su efecto. En vez de perder
tiempo en debatir la cuestión, ésta debe registrarse para discutirla después.

4. Enuncie áreas de problemas, pero no intente resolver cada uno. Una
revisión no es una sesión para resolver problemas. Es frecuente que la
solución de un problema la obtenga el productor, solo o con ayuda de otra
persona. La solución de los problemas debe posponerse para después de
la reunión de revisión.

5. Tome notas por escrito. A veces es buena idea que el secretario tome notas
en un pizarrón a fin de que la redacción y prioridades sean evaluadas por
los demás revisores a medida que la información se registra. De manera
alternativa, pueden tomarse notas directamente en una computadora.

6. Limite el número de participantes e insista en la preparación previa. Dos
cabezas piensan más que una, pero 14 no son necesariamente mejor que
4. Mantenga limitado el número de personas involucradas. Sin embargo,
todos los miembros del equipo de revisión deben prepararse. El líder de la
revisión tiene que solicitar comentarios por escrito (lo que proporciona un
indicador de que el revisor ha inspeccionado el material).

7. Desarrolle una lista de verificación para cada producto que sea probable
que se revise. Una lista de verificación ayuda al líder del proyecto a
estructurar la RTF y a cada revisor a centrarse en los aspectos importantes.
Deben desarrollarse listas para los productos del análisis, el diseño, el
código e incluso las pruebas.

8. Asigne recursos y programe tiempo para las RTF. Para que las revisiones
sean eficaces, deben programarse como tareas del proceso de software.
Además, debe programarse tiempo para hacer las inevitables
modificaciones que ocurrirán como resultado de la RTF.

9. Dé una capacitación significativa a todos los revisores. Para que una
revisión sea eficaz, todos los revisores deben recibir cierta capacitación
formal. Ésta debe hacer énfasis tanto en aspectos relacionados con el
proceso como en el lado de la sicología humana de la revisión. Freedman y
Weinberg [Fre90] estiman en un mes la curva de aprendizaje para que 20
personas participen de modo eficaz en una revisión.

10. Revise las primeras revisiones. Volver a revisar puede ser benéfico para
descubrir problemas con el proceso de revisión en sí mismo. El primer
producto por revisar deben ser los lineamientos de la revisión.

Revisiones orientadas al muestreo

Idealmente, todo producto del trabajo de la ingeniería de software debe
pasar por una revisión técnica. En el mundo real de los proyectos de software, los
recursos son limitados y el tiempo, escaso. En consecuencia, es frecuente que las
revisiones se omitan, aun cuando se reconozca su valor como un mecanismo de
control de calidad.

Thelin et al. Sugieren un proceso de revisión orientado al muestreo en el
que se toman muestras de todos los productos del trabajo de ingeniería de
software a fin de inspeccionarlos para determinar cuáles son más susceptibles de
tener errores. Después se enfocan todos los recursos de la RTF sólo en aquellos
productos en los que sea muy probable encontrar errores (con base en los datos
obtenidos durante el muestreo).

Para que sea eficaz, el proceso de revisión orientada al muestreo debe
tratar de identificar aquellos productos del trabajo que sean objetivos principales
para hacer la RTF. Para lograrlo se sugiere seguir las etapas siguientes.

1. Inspeccionar una fracción a
i
de cada producto del trabajo i. Registrar el
número de fallas fi encontradas dentro de a
i
.
2. Desarrollar una estimación gruesa del número de fallas en el producto del
trabajo i, con la multiplicación de f
i
por 1/a
i
.
3. Ordenar los productos del trabajo en orden descendente de acuerdo con la
estimación gruesa del número de fallas que hay en cada uno.
4. Dedicar los recursos disponibles para la revisión a aquellos productos que
tengan el número estimado más grande de fallas.

La fracción del producto del trabajo de la que se tomen muestras debe ser
representativa del producto del trabajo total y suficientemente grande a fin de que
tenga significado para todos los revisores que no hagan muestreo. A medida que
aumenta a
i
se incrementa la probabilidad de que la muestra sea una
representación válida del producto del trabajo. Sin embargo, los recursos
requeridos para hacer el muestreo también aumentan. El equipo de ingeniería de
software debe establecer el mejor valor de a
i
para los tipos de productos
generados.

Resumen

El objetivo de toda revisión técnica es detectar errores y descubrir aspectos
que tendrían un efecto negativo en el software que se va a desarrollar. Entre más
pronto se descubra y corrija un error, menos probable es que se propague a otros
productos del trabajo de la ingeniería de software y que se amplifique, lo que
provocaría un mayor esfuerzo para corregirlo.

A fin de determinar si las actividades de control de calidad funcionan, deben
determinarse varias métricas. Éstas se centran en el esfuerzo requerido para
realizar la revisión y los tipos y severidad de errores descubiertos durante la
revisión. Una vez recabadas las métricas, se usan para evaluar la eficacia de las
revisiones que se efectúen. Los datos de la industria indican que las revisiones
tienen un rendimiento elevado sobre la inversión.