Guia Didactica

Informática
Modalidad Abierta y a Distancia
Ingeniería de Software
Guía Didáctica
4 créditos
Ciclo Titulación
9 Informática
La Universidad Católica de Loja
Facultad de Ingenieria y Arquitectura

Facultad de Ingenierias y Arquitectura
Departamento de Ciencias de la Computación y Electrónica
Ingeniería de Software
Guía didáctica
4 créditos
Titulación Ciclo
Informática IX
Autores:
Ing. Marco Patricio Abad Espinoza
Ing. Manuel Eduardo Sucunuta España
Asesoría virtual:
www.utpl.edu.ec
INGENIERÍA DE SOFTWARE
Guía didáctica
Marco Patricio Abad Espinoza
Manuel Eduardo Sucunuta España
UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA

CC Ecuador 3.0 By NC ND
Diagramación y Diseño digital:

Ediloja Cía. Ltda.
Telefax: 593-7-2611418
San Cayetano Alto s/n
www.ediloja.com.ec
edilojainfo@ediloja.com.ec
Loja-Ecuador
Segunda edición
ISBN físico -978-9942-08-535-1
ISBN digital -978-9942-04-423-5
Esta versión impresa y digital ha sido acreditada bajo la licencia Creative Commons Ecuador 3.0 de reconocimiento -no comercial- sin obras
derivadas; la cual permite copiar, distribuir y comunicar públicamente la obra, mientras se reconozca la autoría original, no se utilice con fines
comerciales ni se realicen obras derivadas. http://www.creativecommons.org/licences/by-nc-nd/3.0/ec/
16 de Enero, 2014
2. Índice
2. Índice....................................................................................................................................... 4
3. Introducción.......................................................................................................................... 6
4. Bibliografía............................................................................................................................ 8
4.1. Básica........................................................................................................................................... 8
4.2. Complementaria...................................................................................................................... 8
5. Orientaciones generales para el estudio................................................................... 11
6. Proceso de enseñanza-aprendizaje para el logro de competencias............... 14
PRIMER BIMESTRE
6.1. Competencias genéricas........................................................................................................ 14

6.2. Planificación para el trabajo del alumno......................................................................... 15
6.3. Sistema de evaluación de la asignatura (primero y segundo bimestre)............... 17
UNIDAD 1. TERMINOLOGÍA BÁSICA DE LA GESTIÓN DE PROYECTOS.................................... 18

1.1. Conceptos básicos de la gestión de proyectos....................................................... 18
1.2. Grupos de procesos de la administración de proyectos........................................ 27
1.3. Áreas de conocimiento............................................................................................ 29
Autoevaluación 1................................................................................................................ 30
UNIDAD 2. PROYECTOS DE INGENIERÍA DEL SOFTWARE...................................................... 32

2.1. Gestión de proyectos software................................................................................ 32
2.2. Gestión del riesgo..................................................................................................... 33
2.3. Gestión de personal................................................................................................. 38
2.4. Trabajo en equipo..................................................................................................... 40
2.5. Procesos de gestión de la ingeniería de software................................................. 43
Autoevaluación 2................................................................................................................ 46
UNIDAD 3. PLANIFICACIÓN DE PROYECTOS DE SOFTWARE.................................................. 48

3.1. Procesos de planificación de la ingeniería de software........................................ 49
3.2. Calendarización del proyecto.................................................................................. 52
3.3. Técnicas de estimación............................................................................................ 58
3.4. Técnicas de estimación para la ingeniería del software........................................ 61
Autoevaluación 3................................................................................................................ 68
SEGUNDO BIMESTRE
UNIDAD 4. GESTION DE LA CALIDAD DEL SOFTWARE........................................................... 73

4.1. Calidad del software................................................................................................ 75
4.2. Estándares del software.......................................................................................... 78
4.3. Revisiones e inspecciones........................................................................................ 79
4.4. Medición y métricas del software........................................................................... 82
Autoevaluación 4................................................................................................................ 86
UNIDAD 5. ADMINISTRACIÓN DE LA CONFIGURACIÓN......................................................... 88

5.1. Administración del cambio..................................................................................... 90
5.2. Gestión de versiones................................................................................................ 91
5.3. Construcción del sistema......................................................................................... 91
5.4. Gestión de entregas de software............................................................................ 92
Autoevaluación 5................................................................................................................ 94
UNIDAD 6. MEJORA DE PROCESOS SOFTWARE..................................................................... 96

6.1. El proceso de MPS.................................................................................................... 98
6.2. Evaluación y mejora de procesos software............................................................ 100
6.3. CMMI......................................................................................................................... 100
6.4. Otros marcos conceptuales MPS............................................................................. 104
Autoevaluación 6................................................................................................................ 105
7. Solucionario.......................................................................................................................... 107
8. Anexos..................................................................................................................................... 113
Guía didáctica: Ingeniería de Software PRELIMINARES
3. Introducción
El componente educativo de Ingeniería de Software es una asignatura troncal de carrera que se

imparte en el 9no ciclo en la titulación de Ingeniería en Informática del Departamento de Ciencias de la
Computación y Electrónica, y tiene una valoración de 4 créditos académicos.
A lo largo de su carrera ha tenido la oportunidad de estudiar varios componentes educativos de la línea

de Ingeniería de Software, donde básicamente desarrolló competencias para identificar y describir
requerimientos de software, modelar el sistema y organizar las actividades siguiendo un modelo de
procesos, sin embargo este aprendizaje aunque es muy importante, resulta insuficiente para llevar un
proyecto en la vida real, lo que falta es saber cómo gestionar un proyecto, cómo realizar estimaciones
para poder negociar y sobre todo cómo organizar el proyecto para obtener resultados exitosos, el
aporte de otros componentes como arquitectura de aplicaciones, gestión de proyectos y varias de la
línea de programación configuran junto con el presente componente un conjunto de competencias
profesionales de gran valía en el ámbito laboral.
El componente educativo se encuentra dividido en dos bimestres con tres unidades cada uno: en la
Unidad 1, se realiza un revisión muy rápida de la terminología más importante en el tema de gestión de
proyectos se usara a lo largo de la guía didáctica. Esta unidad se sustenta en la Guía de los Fundamentos
de la Dirección de proyectos del Instituto de Gestión de Proyectos (PMI)1 que actualmente es un estándar
mundialmente reconocido, por lo que su estudio aunque breve le será de mucha utilidad, se pueden
aplicar a cualquier tipo de proyecto, sea este de tecnología o no.
En la Unidad 2 se plantea el desarrollo de aspectos esenciales respecto de los proyectos de desarrollo

de software, uno de los insumos que aportan al desarrollo de esta unidad a más del texto básico es el
cuerpo de conocimiento de la Ingeniería de Software de la Computer Society de la IEEE (SWEBOK)2, el
cual le da mucha relevancia al tema.
La Unidad 3 se centra en los procesos de planificación y se intenta combinar técnicas y herramientas

generales planteadas por el PMI con métodos y procedimientos específicos de la Ingeniería de Software,
organizados por actividades planteadas en el SWEBOK edición 20043, además se ha enriquecido los
métodos de estimación planteados en el texto básico con otros modelos de estimación adicionales de
gran valía.
En el segundo bimestre se empieza a tratar otro tema fundamental para la Ingeniería de Software como
es la gestión de la calidad, haciéndose énfasis en el uso de estándares de aseguramiento de calidad, el
uso de métricas y al generación de indicadores.
En la Unidad 5, se desarrolla un aspecto esencial de la industria del software conocido como administración
de la configuración, el cual se enfoca en aspectos tales como: la gestión del cambio cambio, manejo de
versiones del producto y gestión de la puesta en producción del software.
1 Project Management Institute, www.pmi.org

2 IEEE Computer Society, http://www.computer.org/portal/web/swebok
3 Se ha optado por la edición 2004, debido a que es la última versión completa disponible hasta la fecha.
6
Y se culmina con la Unidad 6, tratando el tema de la mejora de procesos de software que permite a las
organizaciones o empresas desarrolladoras de software entrar en un proceso de mejora continua cuya
repercusión es altamente beneficiosa tanto para la empresa desarrolladora como para el cliente, puesto
que éste en un esquema de mejora continua.
Finalmente, le deseamos el mejor de los éxitos en el desarrollo del presente componente educativo y le
recordamos que tiene a su disposición una serie de recurso educativos en línea además de la ayuda de
su tutor.
7
4. Bibliografía
4.1. Básica
• Sommerville, I. (2011). Ingeniería de Software. México: Pearson.
El presente texto cubre los temas relacionados con el desarrollo y gestión de proyectos
de software. Su autor es un reconocido académico vinculado con importantes proyectos
relacionados con la ingeniería del software, por lo que en el texto los temas se abordan de
una manera coherente y con casos que resultan fácilmente entendibles.
• Abad, M. y Sucunuta, E. (2013). Guía didáctica Ingeniería de Software. Loja, Ecuador: Ediloja.
Guía didáctica elaborada para la materia de Ingeniería del software de la titulación de

Ingeniería en Informática de la modalidad de estudios a distancia de la Universidad Técnica
Particular de Loja.
4.2. Complementaria
• Project Management Institute. (2004). Guía de los fundamentos de la dirección de proyectos.

Newton Square, Pennsylvania: PMI.
Tercera edición de la guía de los fundamentos de la dirección de proyectos, se usa sobre

todo para reforzar algunos aspectos conceptuales sobre la gestión de proyectos, que ya no
son tratados en las nuevas ediciones.
• Project Management Institute. (2013). A Guide to the Project Management Body Of Knowledge.
Newton Square, Pennsylvania: PMI.
Guía de los fundamentos de la dirección de proyectos del PMI, es un estándar internacional

para la gestión de proyectos aplicable a cualquier industria, este texto tiene valiosa
información tanto en la conceptualización como en las actividades de planificación,
ejecución, seguimiento y cierre de los proyectos.
• IEEE Computer Society. (2004). SWEBOK Guide to the Software Engineering Body of Knowledge.
USA: Angela Burgess Group Manager Editor CS Press
Cuerpo de conocimiento de la ingeniería de software, de la IEEE computer Society, esta

corresponde a la última publicación oficial y describe todas las áreas de conocimiento de la
ingeniería de software que usan como referencia para todos los procesos de desarrollo de
software. La IEEE Computer Society, reúne a varios expertos a nivel mundial en la rama de
ingeniería de software.
8
• Pressman, R. (2010). Ingeniería del Software. Un enfoque práctico. México: McGrawHill.
• Texto relacionado ampliamente con los tema de desarrollo y gestión de proyectos de

software. Cada uno de los temas se abordan tanto desde una perspectiva conceptual como
con el análisis de casos de estudio.
• Lister, T. (1997). Risk management is project management for adults. USA: IEEE Software.
• Publicación relacionada con la forma de gestionar los riesgos en un proyecto de desarrollo

de software.
• Sánchez, P. (2010). Gestión de riesgos. MATESCO.
• Recurso educativo abierto en la que se indican estrategias y técnicas para la gestión del
riesgo en proyectos de software. Se realizan los análisis en base a modelos.
• Charette, R., & Mac, A. (1997). Managing risk in software maintenance. IEEE Software.
• Estudio que aborda la diferencia de la gestión del riesgo entre el mantenimiento y el

desarrollo del proyecto de softwar. Su analisis se basa en un caso de estudio concreto y real.
• McConnell, S. (1997). Desarrollo y Gestion de Proyectos Informaticos. México: McGraw Hill.
• Texto que enfoca las tareas de desarrollo y gestión en proyectos de desarrollo de software.
El autor McConnell fue nombrado como una de las pesonas mas influyentes en la industria
junto a Bill gates y Linus Torvalds
• Silberman, A. (2011). Administración de riesgos en proyectos de desarrollo de software.
• Guía practica sobre la gestión de los riesgos en proyectos de desarrollo de software.
• iattini, M. G., García, F. O., & Caballero, I. (2007). Calidad de Sistemas Informáticos. México:
P
Alfaomega.
• Texto relacionado con temas de calidad en los sistemas de software, se hace referencia
a conceptos, herrmaientas y estrategias para lograr que los sistemas adquieran un nivel
aceptable de desempeño.
Direcciones Electrónicas
• http://www.sei.cmu.edu/
Es el sitio oficial del Carnegie Mellon Software Engineering Institute (SEI), realiza
investigaciones para explorar soluciones prometedoras a los problemas de ingeniería de
software, identifica y codifica soluciones tecnológicas y metodológicas, pruebas y refina
las soluciones a través de programas piloto que ayudan a la industria y al gobierno a
resolver sus problemas, difunde soluciones probadas a través de la formación, concesión de
licencias, y la publicación de las mejores prácticas. En esta dirección encontrará recursos para
complementar su estudio y el desarrollo de sus trabajos tanto académico como profesional.
9
• www.pmi.org
Sitio oficial del Project Management Institute, ofrece recursos en temas de gestión de
proyectos, eventos pagados y gratuitos. Se puede pagar una membresía anual que le daría
acceso a todos los estándares internacionales relacionados con su área.
• http://www.computer.org/portal/web/swebok
Es el sitio oficial del SWEBOK, puede tener acceso a recursos y a las últimas versiones del
SWEBOK disponibles.
• http://www.iso.org/iso/home/standards/management-standards/iso_9000.htm
Sitio oficial del ISO (International Organization for Standardization), organización a nivel
mundial que desarrolla normas internacionales que permitan a las organizaciones e
industrias a ser mas eficientes y eficaces.
Recurso OCW
• Universidad de California. (2013). Introduction to project management. Recuperado de http://

ocw.uci.edu/courses/course.aspx?id=38
Curso introductorio al proceso de gestión de proyectos que se puede usar como base para el
desarrollo de los contenidos de la Unidad 1, se tomarán algunos elementos de este recurso
para desarrollar el contenido
• Universidad de Murcia. (2009). Fundamentos de Ingeniería del Software. Recuperado de

http://ocw.um.es/ingenierias/fundamentos-de-ingenieria-del-software
Curso de Ingeniería de software que le servirá para complementar su estudio en los

apartados de conceptos, procesos de desarrollo y modelado de componentes de software.
10
5. Orientaciones generales para el estudio
Para el estudio del presente componente educativo el estudiante contará con las siguientes herramientas
básicas:
La guía didáctica: Le orientará sobre cómo y qué temas estudiar, además contiene ejercicios de
autoevaluación que le permitirán medir su grado de comprensión y la necesidad de tutoría por parte del
docente. Muchos estudiantes empiezan estudiando directamente el texto, pero como verá más adelante
no es recomendable hacerlo.
El texto básico: Le servirá para desarrollar los contenidos principales conforme se lo indica en la guía
didáctica. Vale acotar que no todos los capítulos del texto se consideran para el componente educativo
y tampoco cubre todos los contenidos por lo que el estudio debe hacerse siguiendo las instrucciones de
la guía didáctica.
El Entorno Virtual de Aprendizaje: Donde podrá interactuar con sus profesores a través de una orientación
del trabajo semanal, uso de mensajería electrónica para resolver inquietudes, foros, desarrollo de
ejercicios prácticos publicación de recursos.
La tutoría personal: Es un tiempo semanal que como profesores dedicamos para atender las inquietudes
en relación a los contenidos o desarrollo de trabajos, para ello se publicará un horario en el cual podrán
asistir personalmente o contactarse vía telefónica, el mismo que se detalla en la carátula de la evaluación
a distancia.
Los trabajos a distancia: Son actividades teóricas y prácticas que acompañan a la guía didáctica de cada
una de las materias, le permiten aplicar y reforzar los conocimientos adquiridos mediante su desarrollo,
y debe enviarlos a su profesor. La entrega de estos trabajos con su respectiva carátula es obligatoria y no
recuperable, lo cual significa que si no entrega alguno de los mismos no tendrá opción a la evaluación
presencial, su valoración es de 6 puntos.
En cuanto a la forma de trabajo damos algunos lineamientos que le ayudarán a aprovechar su tiempo y
lograr mejores resultados:
• El tiempo que dedique a la lectura y desarrollo de los ejercicios es fundamental, por lo tanto
deberá dedicar al menos 8 horas semanales. Puede apoyarse con técnicas como subrayado,
cuadros sinópticos y sobre todo mapas conceptuales.
• Recuerde que cuenta con su profesor tutor para la comprensión de los temas, entonces
la comunicación con el mismo será fundamental, para lo cual debe familiarizarse con las
formas de comunicación que tiene, ya sea por teléfono (consultar horario de tutoría), correo
electrónico, chat, y otras herramientas tecnológicas. Recuerde además que existe una
variada información en el internet, bibliotecas digitales y también la documentación que su
profesor le acerca a través del EVA.
• En la guía didáctica encontrará la planificación del trabajo con las actividades sugeridas
para cada unidad, distribuidas en el tiempo, por lo tanto trate de cumplir con estas según
se lo indica.
11
• Las autoevaluaciones que se presentan al final de cada unidad así como las que constan en
el texto básico le ayudarán a comprender de mejor manera cada uno de los temas por lo que
su realización es de suma importancia para afianzar el proceso de enseñanza aprendizaje.
• Una vez resueltas las autoevaluaciones de la guía didáctica puede comparar sus respuestas
con el solucionario al final de la guía. En caso que su resultado no sea satisfactorio le
sugerimos volver a revisar los temas y acudir a su tutor para aclarar sus dudas.
A lo largo del presente documento encontrará los siguientes focalizadores:
Focalizador Propósito
Se lo usará cuando deba realizar un lectura bien sea del texto básico o de
bibliografía complementaria.
Cuando encuentre este focalizador deberá desarrollar alguna actividad como un

ejercicio o una consulta.
Cuando encuentre este ícono deberá desarrollar la autoevaluación de unidad, las

respuestas a estas preguntas son importantes para medir cuánto ha avanzado
en el estudio.
Este llamará su atención cuando el párrafo en cuestión denote aclaraciones

importantes o temas esenciales para el desarrollo del resto de contenidos.
Evaluación
El sistema de estudios de la modalidad abierta y a distancia de la Universidad Técnica Particular de Loja

contempla los siguientes parámetros de evaluación, con la particularidad de que en la titulación de
Ingeniería en Informática se incluye de manera obligatoria la participación en el EVA.
El componente educativo se encuentra dividido en dos bimestres, cada uno de los cuales se califica
sobre 20 puntos, en el caso de que algún estudiante no obtenga una nota mínima de 14 puntos, deberá
presentarse a un examen final calificado sobre 20 que reemplaza la nota bimestral correspondiente. Los
estudiantes aprueban cuando han logrado un mínimo de 28 puntos.
En el presente cuadro constan los parámetros y puntajes que se tomarán en cuenta en el primer y
segundo bimestre.
Instrumento Puntaje
Trabajo a distancia:
Objetiva 2 puntos
Ensayo 2 puntos
Interacción EVA 2 puntos
Evaluación presencial 14 puntos
TOTAL 20 PUNTOS
12
Guía didáctica: Ingeniería de Software PRIMER BIMESTRE
6. Proceso de enseñanza-aprendizaje para el logro de competencias
PRIMER BIMESTRE
6.1. Competencias genéricas
Trabajo en equipo II: Contribuye en la consolidación y desarrollo del equipo, favoreciendo la

comunicación, el reparto equilibrado de tareas, el clima interno y la cohesión.
§§ Acepta y cumple las normas del grupo
§§ Contribuye al establecimiento y aplicación de los procesos de trabajo del equipo.
14
6.2. Planificación para el trabajo del alumno
15
COMPETENCIAS CRONOGRAMA
COMPETENCIAS CONTENIDOS
ESPECIFICAS DEL ORIENTATIVO
ESPECIFICAS DE ACTIVIDADES DE APRENDIZAJE INDICADORES DE APRENDIZAJE
COMPONENTE (Unidades/Tema) (Tiempo
TITULACIÓN
EDUCATIVO estimado)
Asocia los conceptos de Unidad 1: Proceso de gestión Estudiar de la unidad 1 de la guía • Diferencia entre proyectos y Semana 1 y 2
gestión de proyectos de proyectos. didáctica. operaciones.
con los de Ingeniería de 8 horas de
1.1. Conceptos básicos de la Desarrollar de los ejercicios • Reconoce los entregables de un autoestudio
Software.
gestión de proyectos propuestos en la unidad 1 de la proyecto independientemente
de la industria a la que se 8 horas de
1.2. Grupos de procesos de guía didáctica. aplique. interacción
la administración de
Revisar los capítulos 1 y 2 del • Establece diferencias entre los
procesos OCW-Introduction to project
Guía didáctica: Ingeniería de Software
grupos de procesos de la
1.3. Áreas de conocimiento management (2013) gestión de proyectos y el ciclo
de vida del software.
Desarrollar la autoevaluación.
Desarrollar la evaluación a
distancia, ítems 1-10 parte
objetiva y literal 1 y 2 de la parte
Elaborar presupuestos y de ensayo
estimaciones de alcance, Identifica los aspectos Unidad 2: Proyectos de Semana 3 y 4
• Estudio de la unidad 2 de la • Describe los factores que
costo y tiempo en fundamentales de los Ingeniería del software guía didáctica, capítulo 22 del inciden en la complejidad
proyectos de TI. proyectos de Ingeniería 8 horas de
2.1. Gestión de proyectos texto básico y capítulo 8 del del software. estudio
de software, Swebok.
entendiendo su software • Identifica riesgos en personal
complejidad y 2.2. Gestión del riesgo • Revisión del tema 6 del proyectos de software
naturaleza.
8 horas de
bloque 3 del OCW- valorándolos cualitativa y interacción
2.3. Gestión de personal
Fundamentos de Ingeniería cuantitativamente.
2.4. Trabajo en equipo de software.
• Establece roles y
2.5. Procesos de gestión • Desarrollo de las responsabilidades para
de la ingeniería de autoevaluaciones de la guía equipos de proyectos de
software didáctica. desarrollo de software y los
enmarca en procesos de
• Desarrolle la evaluación a
gestión
objetiva y literal 3 y 4 de la
parte de ensayo
PRIMER BIMESTRE
COMPETENCIAS CRONOGRAMA
COMPETENCIAS CONTENIDOS
ESPECIFICAS DEL ORIENTATIVO
ESPECIFICAS DE ACTIVIDADES DE APRENDIZAJE INDICADORES DE APRENDIZAJE
16
COMPONENTE (Unidades/Tema) (Tiempo
TITULACIÓN
EDUCATIVO estimado)
Utiliza herramientas y Unidad 3: Procesos de • Lectura de la unidad 3 de la • Organiza cronogramas para Semana 5 y 6
técnicas de gestión de planificación. guía didáctica, capítulo 23 del proyectos de Ingeniería de
proyectos para 8 horas de
3.1. Procesos de texto básico y capítulo 8 del Software. estudio
planificar y organizar Swebok
proyectos de ingeniería planificación de la • Realiza estimaciones de personal
de software. ingeniería de software • Desarrollo de actividades alcance, costo y tiempo para 8 horas de
3.2. Calendarización del recomendadas y proyectos de ingeniería de interacción
proyecto autoevaluaciones software.
3.3. Técnicas de estimación • Estudio del anexo 2 de la guía • Organiza proyectos
didáctica. integrando procesos,
3.4. Técnicas de estimación
alcance, costo, tiempo,

para la ingeniería de • Desarrolle la evaluación a
calidad y riesgos.
software. distancia, ítems 21-30 parte
objetiva y literal 5 y 6 de la
parte de ensayo
Unidades 1 a 3 • Revisión de contenidos como Semana 7 y 8
preparación para la 8 horas de
evaluación presencial estudio
personal
8 horas de
interacción
PRIMER BIMESTRE
6.3. Sistema de evaluación de la asignatura (primero y segundo bimestre)
Formas de evaluación 2. Heteroevaluación

Evaluación a Evaluación
1. Autoevaluación *
distancia ** presencial
3. Coevaluación
Interacción en el EVA
Parte de ensayo
Prueba objetiva
Parte objetiva
Competencia: criterio
Comportamiento ético x x x x x
cumplimiento, puntualidad,
x x x x x
Actitudes
responsabilidad
esfuerzo e interés en los trabajos x x x x x
respeto a las personas y a las
x
normas de comunicación
Creatividad e iniciativa x x x x
habilidades
contribución en el trabajo
x
colaborativo y de equipo
presentación, orden y ortografía x x x x
emite juicios de valor
x
argumentadamente
Dominio del contenido x x x x x
conocimientos
investigación (cita fuentes de

x x
consulta)
aporta con criterios y soluciones x x
análisis y profundidad en el desarrollo
x
de temas
Máximo 1 punto
pORCENTAJE 10% 20% 30% 70%

Estrategia de
aprendizaje
presenciales y en el
distancia)***
evaluación a
(completa la
Puntaje 2 4 6 14
Actividades
EVA
TOTAL 20 puntos
Para aprobar la asignatura se requiere obtener un puntaje mínimo de 28/40 puntos, que equivale al 70%.
* Son estrategias de aprendizaje, no tienen calificación; pero debe responderlas con el fin de autocomprobar su
proceso de aprendizaje.
** Recuerde que la evaluación a distancia consta de dos partes: una objetiva y otra de ensayo, debe desarrollarla y
entregarla en su respectivo centro universitario.
*** Su tutor(a) le planteará una o más actividades en el EVA que serán calificadas por un punto en total. Este solo
computará para complementar la nota del trabajo a distancia, es decir, si Ud. logra menos de seis puntos en el mismo
podrá aumentar dicha nota (hasta completar los 6 puntos) con esas actividades en el EVA.
Señor estudiante:
Tenga presente que la finalidad de la valoración cualitativa es
principalmente formativa.
17
6.4. Orientaciones específicas para el aprendizaje por competencias
UNIDAD 1. TERMINOLOGÍA BÁSICA DE LA GESTIÓN DE PROYECTOS
Estimado estudiante:
Iniciamos el estudio del presente componente educativo con una breve revisión de los denominados grupos
de procesos de la gestión de proyectos desde el punto vista del cuerpo de conocimiento del PMI4, que muy
probablemente habrá tenido la oportunidad de estudiar, sin embargo hemos querido dedicar un capítulo
introductorio a este por la importancia que tienen para los procesos de ingeniería del software, de hecho no
podemos hablar de Ingeniería de Software sin hablar de procesos de gestión de proyectos.
Para una comprensión adecuada de estos temas, utilizaremos como referencia la Guía de los Fundamentos de la
Dirección Proyectos 5ta Edición, a la cual nos referiremos más adelante como PMBOK, que son las siglas de Project
Management Body of Knowledge, y que hoy en día se constituye en uno de los estándares más importantes para
la gestión de proyectos en todas las industrias
Si usted dispone de este material, puede referirse a los capítulos 1 y 2 del texto indicado,
alternativamente puede ingresar al recurso OCW titulado “Introduction to Project Management”
de la Universidad de California cuya dirección encontrará en el apartado Recursos OCW de la
bibliografía.
Como sugerencia puede ingresar al sitio utilizando Google Chrome y realizar la traducción al idioma español, la
cual puede ayudarle a comprender mejor la temática, sin embargo será necesario hacer algunas correcciones a
este tipo de traducción.
1.1. Conceptos básicos de la gestión de proyectos
Puesto que la Ingeniería de Software estudia los métodos y procedimientos para el desarrollo de
aplicaciones de software, siempre estos terminan desarrollándose bajo la figura de proyectos, por lo
tanto es necesario revisar algunos conceptos y principios de la dirección de proyectos que se usarán más
adelante.
Proyecto:
De acuerdo con Project Management Institute (2013) “un proyecto es un esfuerzo temporal que se
realiza con el propósito de crear un producto, servicio o resultado único”5, lo cual se puede aplicar
de manera particular a los proyectos de desarrollo de software. Un proyecto termina cuando se han
cumplido alguna de las siguientes condiciones: se han alcanzado sus objetivos, en cuyo caso se trataría
de un proyecto exitoso; cuando se ha establecido que no será posible alcanzar sus objetivos y cuando la
necesidad del proyecto ya no existe.
En este punto es vital recalcar que todo proyecto tiene una salida, un inicio y fin definidos y, recursos
limitados.
4 Project Management Institute, www.pmi.org

5 PMI (2013), pp 3
18
Cuando hablamos de resultado único, nos referimos al heche de que el producto, servicio o resultado
que se espera, no se ha hecho antes en ese entorno, pueden haber proyectos similares en muchos
aspectos, pero no son iguales.
Ejemplos de proyectos:
• La construcción de una casa.

• La automatización de una planta.
• El desarrollo de un producto de software.
• La elaboración de un libro.
Los proyectos se componen de procesos, los cuales son series de acciones que los participantes del
proyecto ejecutan para conseguir los resultados, estas actividades pueden corresponder a dos categorías
de procesos.
• Procesos de gestión del proyecto, que soportan la conducción efectiva del proyecto a lo
largo de su duración, incluyen actividades de planificación, ejecución, monitoreo y control
y cierre.
• Procesos orientados al producto: que incluyen actividades para construir los entregables
del producto, y en el caso del software son las actividades planteadas en los procesos de
desarrollo como el RUP, SCRUM, XP, etc.
Desde el punto de vista de la Ingeniería del Software nos interesa saber cómo organizar las actividades de
desarrollo de software en un modelo de gestión del proyecto.
Operaciones:
Se debe diferenciar a los proyectos de las operaciones puesto que todo proyecto se desarrolla con el
propósito de que los resultados de dicho proyecto generen los beneficios esperados esto significa que
entran en operación, las operaciones por tanto son las actividades del día a día que lleva la organización
y son las que le proveen el sustento diario.
Ejemplo:
La UTPL decide crear una nueva titulación, para ello se ejecuta un proyecto cuyo propósito es establecer
la estructura académica, cuerpo docente, infraestructura requerida, y permisos legales correspondientes
para obtener la autorización de funcionamiento, el proyecto termina cuando este objetivo se ha logrado;
los resultados del proyecto entran en una etapa de operación siendo las operaciones, las siguientes:
• Oferta las asignaturas,

• Matrículas,
• Clases,
• Evaluaciones,
• Recepción de trabajos
Podemos además decir que las operaciones son las actividades que realizan las compañías con el propósito de
obtener sus ingresos, son su modo de subsistencia.
19
Ejercicio 1.1:
El siguiente ejercicio le ayudará a afianzar los conceptos que tiene sobre lo que es un proyecto y lo
que son las operaciones, es importante que lo desarrolle sin buscar nuevas fuentes de información.
Indique si los elementos de la tabla 1.1 corresponden a proyectos o a operaciones:
Tabla 1.1: Lista de conceptos y operaciones.
Descripción Categoría
Venta de computadores
Control de inventarios
Desarrollo de un portal WEB
El respaldo a una base de datos
La corrección de errores de una aplicación de software
La obtención de un permiso de construcción
La construcción de un puente
El diseño de un nuevo vehículo
Las clases presenciales en la universidad
El lanzamiento de un nuevo disco de música
Seguramente tuvo dudas al momento de categorizar alguno de los ítems dados, eso es lo más normal,
sin embargo si lo analiza con calma se dará cuenta de la diferencia entre estos dos tipos de elementos.
Para comprobar sus respuestas puede remitirse al anexo 1. Soluciones a ejercicios.
Ciclo de vida del proyecto
El Project Management Institute (2013) define al ciclo de vida del proyecto como “una serie de fases
por las que pasa un proyecto desde su inicio hasta su cierre. Estas fases por lo general son secuenciales
y sus nombres y número se determinan por las necesidades de gestión y control de la organización u
organizaciones implicadas en el proyecto, la naturaleza propia del proyecto y su área de aplicación”6
El ciclo de vida del proyecto por tanto depende en gran medida de cómo lo organice el gestor del
proyecto y sobre todo del modelo o metodología de desarrollo que se esté empleando.
En la figura 1.1 se aprecia un modelo típico del ciclo de vida del proyecto planteado por el PMI, en la cual
se distinguen tres etapas a nivel general, que son la inicial, la intermedia y la final, cada una de las cuales
se origina o genera algunos artefactos de la gestión de proyectos, así por ejemplo la entrada para la
etapa inicial empieza con la “idea” del proyecto, luego se genera una acta de constitución del proyecto,
la cual autoriza formalmente el desarrollo del proyecto y permite constituir el equipo del proyecto, y
finaliza con el enunciado del alcance del proyecto.
6 Project Management Institute (2013) pp. 38
20
Figura 1.1 Modelo de ciclo de vida de proyectos7
La segunda etapa inicia con el desarrollo de un plan y la estructuración de la línea base del proyecto,
conforme se desarrolla el trabajo del proyecto se va controlando el avance y culmina con la aceptación
y aprobación por parte del cliente, es en esta etapa donde se desarrollan las actividades del proyecto,
como la construcción de los componentes del proyecto, la validación, etc y por último tenemos la etapa
final en la cual se cierra el proyecto y entregan todos los componentes del proyecto; se cierran contratos
y compromisos asumidos de modo que una vez completado el proyecto se haga un cierre formal.
Administración del proyecto
El Project Management Institute(2013) define a la administración de proyectos como la aplicación de

habilidades, herramientas, conocimiento y técnicas para conseguir que la actividades del proyecto
alcancen los requerimientos para los que se constituyó, estas habilidades se combinan mediante la
aplicación apropiada e integración de 47 procesos organizados de manera lógica en los denominados
grupos de procesos y distribuidos por área de conocimiento, tal como se muestra en la figura 1.2
Figura 1.2 Grupos de procesos y áreas de conocimiento de la gestión de proyectos8
7 Project Management Institute, (2003). Guía de los Fundamentos de la Dirección de Proyectos. PMI Publications.Newton
Square, Pensylvannia.
8 Basado en cuadro de grupos de procesos, y áreas de conocimiento del PMBOK, Project Management Institute (2013) pp
61
21
En el apartado 1.3 de la guía didáctica, se revisará brevemente cada una de las áreas de conocimiento
que conforman el cuerpo de conocimiento del PMBOK. Estos procesos complementan las actividades
propias de la Ingeniería de Software y si bien ayudan a que las actividades de definición, planificación,
seguimiento y control del proyecto se realicen de manera coherente, no involucran procesos técnicos
propios de la Ingeniería del Software. Este aspecto se revisará con mayor detalle en el capítulo III.
Desde el punto de vista de la Ingeniería del Software, cada uno de estos se alimenta con parámetros
propios de los procesos de desarrollo de software.
Fase
El concepto de fase desde el punto de vista de la gestión de proyectos es el desarrollo de un grupo de

actividades que generan un resultado para completar la totalidad o una parte del proyecto. Esta fase
involucra el paso por cada uno de los grupos de procesos.
No debe confundir las fases de un proyecto con las fases del ciclo de vida de los procesos de desarrollo.
Si nos fijamos en los procesos de desarrollo de software el modelo típico de fases comprende el análisis
diseño implementación pruebas y mantenimiento.
Para una mejor comprensión del concepto de fase, revise el siguiente ejemplo:
Proyecto: Automatización de los procesos académicos de un centro de estudios universitario.
Propósito: Implementar aplicaciones de software que permitan automatizar los procesos académicos del
centro de estudio universitario.
Análisis preliminar: A primera vista se trata de un proyecto grande, puesto que los centros de estudios superiores
tienen gran cantidad de procesos que es necesario desagregar para iniciar el desarrollo, se estima que se podría
tener funcionando un grupo de aplicaciones que resuelvan esta problemática en un lapso de entre 3 y 4 años,
con lo cual es preciso descomponer el proyecto en fases, las cuales deben tener una secuencia lógica de modo
que la anterior aporte a las nuevas etapas.
Estructuración de fases del proyecto: Para poder resolver el problema es necesario hacer una revisión global de
los procesos de negocio que se automatizarán. Esta revisión global nos lleva a identificar procesos académicos,
procesos financieros y procesos administrativos los cuales nos da una pauta de cómo se puede estructurar el
proyecto en fases, que podrían ser las siguientes:
Fase 1: Montaje de infraestructura tecnológica y definición de arquitectura de soporte para desarrollo y

producción de las aplicaciones.
Fase 2: Desarrollo del sistema financiero (contabilidad, recaudaciones, bancos)
Fase 3: Desarrollo de plataforma académica (inscripciones, admisión, matrículas, notas, evaluaciones)
Fase 4: Desarrollo de plataforma académica (trámites académicos, inteligencia de negocio servicios en línea)
Fase 5: Implementación de procesos administrativos.
Ejercicio 1.2
22
Llegó el momento de evaluar su nivel de comprensión del tema, se lo invita a que proponga un ejemplo
de un proyecto de desarrollo de software que pueda dividirse en fases, y describa que se desarrollaría
en cada una de ellas.
Proyecto:
Propósito:
Análisis preliminar:
Estructuración de fases del proyecto:
¿Cómo le fue con la actividad? Se le recuerda la importancia de desarrollarla para entender mejor los
conceptos, si tiene dudas respecto del ejercicio, es buen momento para acudir a su tutor.
Triple restricción
Todo los proyectos se someten a ciertas restricciones las cuales forman parte también de los criterios
de aceptación del proyecto, para un gerente de proyectos es muy importante conocer cuáles son y
cómo afectan las unas a las otras, de forma que pueda tomar decisiones considerando el impacto que
cualquier alteración a estos parámetros.
En principio se consideraba al alcance, costo y tiempo como triple restricción porque comprendía
únicamente 3 aspectos como se muestra en la figura 1.3 . Sin embargo con el paso de los años se han
incluido 3 criterios adicionales que son calidad, nivel de riesgo y satisfacción del cliente.
23
Figura 1.3 Triple restricción
Para quienes lideran un proyecto sobre todo si se trata de desarrollo de software, es vital considerar
el efecto de la triple restricción en el sentido de que estos proyectos tienen alta probabilidad de sufrir
variaciones en alguno de estos parámetros, lo cual puede considerarse normal, sin embargo no puede
considerarse normal descuidar el impacto en los demás. Para comprenderlo mejor vamos a revisar el
siguiente ejemplo.
Ejemplo:
Suponga que está desarrollando un proyecto para implementar una aplicación de ventas para una
cadena de supermercados a nivel nacional, para ello se ha establecido los siguientes lineamientos:
Alcance: Administración de información de clientes, inventario de productos, ventas en caja, facturación

y emisión de reportes de ventas. Instalación en 5 ciudades del pais.
Tiempo: 8 meses
Costo: 40.000 USD
Nivel de calidad: soporte hasta 200 usuarios concurrentes en ventas, base de datos distribuida por
ciudades, manejo de arquitectura orientada a servicios.
El proyecto inicia en el mes de marzo del año actual y luego de que se ha completado la planificación y
se ha ajustado a los parámetros establecidos, el cliente le pide que se agregue una funcionalidad para
realizar ventas en línea, lo cual desde su punto de vista no representaría mayor problema puesto que se
trata de una aplicación web, sin embargo después de analizar el impacto se da cuenta que el cambio no
es simple, claramente le están cambiando el alcance del proyecto, y las estimaciones que usted hizo no
serán suficientes para atender este requerimiento.
El componente de ventas en línea implicará aumentar la seguridad, adquirir certificados electrónicos,

desarrollar un catálogo en línea y toda la infraestructura de soporte para ello, realiza nuevamente su
estimación y llega a la conclusión de que se necesitará 2 programadores adicionales y un mes extra
de mano de obra por parte del equipo de aseguramiento de calidad, las personas que trabajarán en
manuales, instalación de los componentes adicionales, en cuanto a costos, esos se incrementarán debido
al tiempo extra de trabajo, los nuevos programadores, y la adquisición de infraestructura y certificados
de seguridad.
24
En este punto debe plantearse la pregunta ¿se debe aceptar el cambio?, lo que si está claro es que bajo
las condiciones iniciales, el aceptarlo hará que fallen todos los planes, lo correcto es por tanto someterlo
a un proceso de control de cambios, el cual se debe aplicar cuando alguno de los parámetros de la
triple restricción se ven afectados, esto conlleva a una nueva aprobación del presupuesto y del plazo
de entrega, sin embargo si estas nuevas aprobaciones no se dan, puede intentar modificar la calidad
reduciendo uno o más parámetros de los inicialmente establecidos, lo cual afectará a la satisfacción del
cliente e incrementara los niveles de riesgo.
Naturalmente si opta por hacer lo segundo su reputación se verá afectada y a pesar de haber actuado
profesionalmente exponiendo los efectos que podría tener el aceptar el cambio, terminará desgastando
su imagen.
Una solución ideal para una situación de estas sería el completar el proyecto en su configuración inicial
y empezar otra fase u otro proyecto nuevo que incluya los nuevos componentes, esto propiciará una
muy buena imagen frente al cliente y le permitirá culminar de manera exitosa ambos proyectos, si no
se aprueba el desarrollo del nuevo proyecto al menos el primer proyecto culminará de manera exitosa.
Con este sencillo ejemplo puede darse cuenta de la importancia que tiene para quien gestiona el
proyecto tener en cuenta la triple restricción.
Línea base
Se conoce como línea base al “conjunto de variables recopiladas, tales como: calendario original con
fechas de inicio y terminación; esfuerzo planificado (expresado en horas); costo presupuestado; ingresos
presupuestados, etc.”9
Aunque esta definición incluye los parámetros más importantes como el tiempo y el costo, la línea base
debe incluir otros elementos como el alcance y calidad, los cuáles son parámetros ligados directamente
a la triple restricción.
La utilidad de la línea base reside en que a partir de ella se realiza la planificación y todo el trabajo se
organiza en torno a ella, una vez que esta se aprueba sirve como elemento de negociación y también
como elemento de evaluación para establecer el avance el proyecto y cómo se desvía respecto de la
línea base con lo cual se pueden tomar acciones correctivas para dichas desviaciones.
Entregable:
Existen muchas formas por las cuales se puede definir y controlar un proyecto, no solo en el ámbito
de la Ingeniería de Software, sino en la mayoría de las ingenierías; cada una tiene sus particularidades,
pero existe un acuerdo en que la mejor manera de planificar y controlar en proyecto, es hacerlo por
entregables; el PMI define a un entregable como “un producto, resultado o capacidad de ejecutar un
servicio que permite completar un proyecto o fase” por tanto hablamos de un elemento tangible que
tiene sentido para una persona o un grupo de personas que normalmente suelen ser los interesados del
proyecto.
Si acogemos la definición anterior se puede establecer como entregables únicamente a aquellos

elementos que son de valor para el cliente o los interesados y que de alguna manera marcan el avance
del proyecto.
9 PMI Venezuela, http://www.pmi.org.ve/index.php?option=com_k2&view=item&id=172:la-importancia-de-una-

l%C3%ADnea-base-en-el-proyecto&Itemid=130 [consultado el 15 mayo 2013]
25
En cualquier proyecto se puede evidenciar el desarrollo de actividades, pero estas no tienen valor alguno
si no aportan para completar un entregable.
Estructura desagregada de trabajo (EDT):
La estructura desagregada de trabajo o WBS por sus siglas en inglés, es una especie de organigrama
que permite especificar los entregables y sub entregables del proyecto, básicamente resume todo el
trabajo requerido para completar el proyecto y por tanto es una de las herramientas más importantes de
planificación del proyecto, puesto que a partir de este se puede establecer actividades, asignar recursos,
secuenciarlas, calcular costos, identificar riesgos, etc.
El EDT del proyecto puede configurarse de varias formas, pero la manera que suele resultar más útil es
la descomposición por entregables como el que se muestra en la figura 1.4, en el que se puede apreciar
varios niveles de descomposición de cada uno de los componentes que conforman un proyecto de
implantación de una aplicación en una empresa.
Figura 1.4 Ejemplo de WBS para un proyecto de implantación de un sistema financiero.
En esta estructura desagregada del trabajo se puede apreciar varios niveles: los del primer nivel son
los denominados entregables mayores, estos luego se descomponen en sub entregables y los últimos
niveles se conocen como paquetes de trabajo, y estos se consideran la unidad mínima para asignación
del trabajo y se toman como base para la planificación, como se verá en la unidad 3.
Ejercicio 1.3
Acogiendo la definición dada, establezca qué es un entregable y qué no es en la siguiente

lista aplicada a un proyecto de desarrollo de una aplicación para gestionar inscripciones en
línea en cursos de capacitación.
26
Nro. Entregable SI/NO

1 Documento de requerimientos
2 Diseño arquitectónico
3. Diagrama entidad relación.
4. Diagrama de casos de uso.
5. Plan de comunicaciones
6. Esquema de base de datos.
7. Pantalla de ingreso de usuarios.
8. Instalación de la aplicación
9 Interface con sistema financiero
10. Manual de usuario
Seguramente la mayoría de componentes los pudo identificar fácilmente, sin embargo hay otros que a
pesar de ser piezas importantes del proceso de desarrollo de software, generan duda respecto de si son
o no entregables. Una pregunta clave aquí es el determinar si eso le agrega valor al cliente.
Revise la solución propuesta en el anexo 1, y en caso de no estar de acuerdo con alguna de las soluciones
coméntelo para luego contrastarlas con las descripciones dadas.
1.2. Grupos de procesos de la administración de proyectos.
Muchas veces se confunde el ciclo de vida del proyecto con los grupos de procesos de gestión de
proyectos, sin embargo estos rara vez coinciden. Si queremos establecer en términos generales cuales
son las etapas del ciclo de vida de un proyecto, podemos hablar de etapas que son inicio, ejecución y
cierre.
Los grupos de procesos podemos decir que son la manera como se organizan los procesos de la
administración de proyectos para cumplir con las actividades propias de la gestión. En la figura
1.5podemos apreciar estos grupos de procesos, cada uno de los cuales contiene procesos específicos
que se enlazan con los siguientes. Estos grupos de procesos “son independientes del área de aplicación
o específicos para una industria”.
Figura 1.5 Grupos de procesos de la administración de proyectos10
10 Project Management Institute (2013) basado en la figura 2-10 pp 50
27
Estos procesos tienen dependencias claras y es usual que se ejecuten de manera iterativa, además el
equipo de dirección es el responsable de establecer cuáles de estos se usarán y cómo se ejecutarán,
lo importante es tener en cuenta que estos procesos deben ayudar a la organización y ejecución del
proyecto, en ningún caso deben afectar a los procesos propios de desarrollo del producto, ya que
estos no producen entregables, simplemente proveen información para que el proyecto se desarrolle a
tiempo, dentro de los costos y con el alcance establecido.
Procesos de inicio
Son procesos que se ejecutan para definir un nuevo proyecto o una nueva fase de un proyecto existente,
su propósito principal es obtener la autorización para iniciar un nuevo proyecto. Todo proyecto generará
resultados que afectan positiva o negativamente, y también directa e indirectamente a muchas personas
a las cuales se conoce como los afectados o interesados11 y en cualquier proyecto una de las principales
actividades de inicio es identificar a estos afectados, investigar sus necesidades e intereses; esto es de
vital importancia ya que bastaría con la decisión o influencia de uno de ellos para que el proyecto se
cancele.
Procesos de planificación
Este es el grupo procesos más extenso, incluye los procesos ejecutados con el fin de establecer el alcance
total, el esfuerzo, definir y refinar los objetivos y desarrollar los cursos de acción requeridos para alcanzar
sus objetivos.
Entre los elementos que se desarrollan tenemos el plan de gestión y los documentos que se usarán para
llevar a cabo el proyecto.
Uno de los aspectos más importantes de la planificación es que se establecen las bases sobre las que se
ejecutará el proyecto, a estas se las conoce como líneas base y se refieren a los aspectos como alcance,
tiempo, costo y calidad, aquellos parámetros que se habían establecido como triple restricción.
Procesos de ejecución
Son los procesos ejecutados con el propósito de completar el trabajo definido en el plan de gestión del
proyecto de modo que se cumplan con las especificaciones establecidas. Este grupo de procesos implica
la coordinación de recursos, personas, expectativas de interesados, así como también actividades del
proyecto relacionadas al plan de gestión del proyecto.
Conforme avanza el proyecto, las actividades de ejecución pueden generar actualizaciones, si alguna de
las líneas base se ven afectadas, es necesario seguir un proceso de control de cambios.
Procesos de monitoreo y control
Son procesos destinados a dar seguimiento al proyecto, revisar y regular su rendimiento y progreso,
además de identificar posibles necesidades de cambios, los objetivos de este grupo de procesos son
controlar los cambios y recomendar acciones preventivas o correctivas de modo que se anticipen a los
potenciales problemas; monitorear las actividades del día a día y contrastarlas con los planes de gestión
de los proyectos, medir los resultados contra la línea base e influenciar en los factores que puedan
interferir con el control de cambios o con la gestión de la configuración, de forma que únicamente se
implementen los cambios aprobados.
Procesos de cierre
11 En inglés la palabra es stakeholder
28
Son procesos que se ejecutan con el propósito de cerrar formalmente el proyecto bien sea porque
se completo todo el proyecto alcanzando los objetivos que se propusieron, se cumplió una fase y
se produce un cierre contractual debido a que se determinó que no era posible acabar el proyecto,
además se cierran los contratos con proveedores, se documentan lecciones aprendidas se archiva la
documentación del proyecto y se libera a las personas que trabajaron en el proyecto.
1.3. Áreas de conocimiento
El Cuerpo de Conocimiento de la Administración de Proyectos12 (PMBOK), comprende 10 áreas de

conocimiento, las cuales aportan con herramientas y técnicas para cada uno de los 47 procesos, que
comprenden todo el proceso de gestión de proyectos. En la tabla 1.2 podemos apreciar el nombre y la
función de cada una estas áreas, las cuales se organizan en grupos de procesos para ayudar al equipo de
dirección de proyecto a cumplir con actividades de definición, planificación y seguimiento de proyectos
de manera efectiva.
Tabla 1.2. Áreas de conocimiento de los fundamentos de la dirección de proyectos del PMI.
Nro. Nombre Propósito

1. Gestión de la integración Incluye los procesos para integrar y coordinar todas las actividades
(Integration Management) del proyecto. Comprende aspectos como; unificación, consolidación y
comunicación.
2 Gestión del alcance Su propósito es asegurarse de que se incluya todo el trabajo requerido
(Scope management) y solamente el trabajo necesario para cumplir las expectativas del
proyecto.
3 Gestión del tiempo Incluye los procesos necesarios para asegurarse que el proyecto se
(Time management) desarrolla en los plazos establecidos.
4 Gestión de los costos Comprende procesos y actividades para la estimación de costos y
(Cost Management) asegurarse de que el proyecto se cumple dentro del presupuesto.
5 Gestión de la calidad Busca implementar herramientas y técnicas para realizar el
(Quality Management) aseguramiento y control de calidad del proyecto.
6 Gestión de recursos humanos Establece los procesos para asegurarse de que el proyecto cuenta con
(Human Resource Management) los recursos humanos necesarios el entrenamiento, la capacitación y el
seguimiento.
7 Gestión de las comunicaciones Establece métodos y mecanismos para asegurar una correcta
(Communications management) comunicación entre el equipo del proyecto y los interesados.
8 Gestión de riesgos Trata de asegurar que el proyecto no fracasará debido a la ocurrencia de
(Risk Management) riesgos y toma medidas para evitar los riesgos o mitigar la probabilidad
y el impacto de los mismos.
9 Gestión de adquisiciones Implementa mecanismos para gestionar y evaluar los procesos de
(Procurement management) adquisiciones del proyecto.
10 Gestión de interesados Su propósito es asegurar la participación y apoyo de parte de todos los
(Stakeholder management) interesados del proyecto.
12 Project Management Body of Knowledge del PMI
29
Autoevaluación 1
Se ha completado la unidad 1, en la cual con toda seguridad encontró algunos conceptos que no conocía, sin
embargo es preciso realizar una autoevaluación para determinar cuanto a logrado asimilar.
Aunque el desarrollo de estas preguntas no es obligatorio, se le recomienda resolverlas ya que es
posible que haya algunos temas que no se han comprendido a plenitud. Recuerde que al final
de la guía se han incluido las soluciones a estas autoevaluaciones sin embargo deberá usarlas
solo después de haber obtenido sus propias respuestas para volver a revisar temas que quizá no
quedaron bien comprendidos.
Lea detenidamente cada una de la preguntas y seleccione la alternativa correcta según corresponda.
1. En la siguiente lista, identifique aquella que por sus características puede considerarse como
proyecto diferenciándose de lo que son las operaciones:
a. El mantenimiento preventivo de un equipo de cómputo.

b. El desarrollo de un nuevo portal para una empresa.
c. La revisión de la operación de un proceso industrial.
2. Cuando en la definición de proyecto se menciona que es un esfuerzo temporal para crear un

“producto o resultado único”, se refiere a:
a. Jamás se ha desarrollado un producto similar.

b. El gerente de proyecto no ha participado en proyectos similares.
c. No se ha hecho un proyecto igual en las condiciones actuales de la organización.
3. Desde el punto de vista del PMBOK, la frase que mejor define lo que es una fase es:
a. Una etapa de la metodología de desarrollo de software.

b. Un conjunto de entregables que se han establecido para completar una parte o la totalidad
del proyecto.
c. Una actividad de un proceso de gestión.
4. La organización de un proyecto en general debe corresponder con los siguientes grupos de

procesos:
a. Inicio, Planificación, Ejecución, Monitoreo y Control, y Cierre.

b. Inicial, Intermedio, Final.
c. Integración, Alcance, Costo, Tiempo, Calidad, Riesgos, Recursos Humanos, Procura,
Comunicaciones e Interesados.
5. La gestión del alcance tiene como propósito principal:
a. Establecer la duración del proyecto.

b. Identificar los riesgos del proyecto.
c. Identificar los entregables y los criterios de éxito del proyecto.
30
6. ¿Cuál de las siguientes alternativas corresponde a un entregable para un proyecto de desarrollo

de software?
a. El modelo de datos.
b. Un módulo de facturación.
c. Un contrato.
7. ¿Qué importancia tiene el control de la triple restricción en un proyecto de desarrollo de software?
a. Evita que el proyecto tenga menos funcionalidades de las esperadas.

b. Permite al gerente de proyecto definir con claridad el alcance.
c. Permite al gerente de proyecto controlar el alcance, costo, tiempo y calidad de acuerdo a
una línea base establecida.
8. ¿Por qué los documentos de gestión de proyectos o propios del proceso de desarrollo de software
no pueden ser considerados como entregables desde el punto de vista de la gestión de proyectos?
a. Porque no representan resultados visibles para el cliente.

b. Porque no corresponden a estándares de la industria.
c. Porque son intangibles.
9. ¿Cuál es el grupo de procesos más fuerte desde el punto de vista de la gestión del proyecto?
a. Inicio
b. Planificación
c. Ejecución
10. ¿En cuál de los grupos de procesos de la gestión del proyecto se mide el rendimiento del proyecto?
a. En los de monitoreo y control.

b. En los de ejecución.
c. En los de cierre.
31
UNIDAD 2. PROYECTOS DE INGENIERÍA DEL SOFTWARE
Iniciamos la presente unidad enfocando una importante actividad relacionada con la ingeniería del
software, como es la gestión de proyectos de software, donde el interés de todos los involucrados es
planificar actividades encaminadas a construir software de calidad. Los temas que se han planificado
se refiere a la gestión de los proyectos software, gestión del riesgo, gestión del personal y sobre todo la
importancia del trabajo en equipo.
2.1. Gestión de proyectos software
Los proyectos de software comúnmente están atados a restricciones de presupuesto y tiempo, por lo
que el gerente del proyecto deberá considerar una adecuada planificación sin restringir actividades que
ponga en riesgo la calidad del producto. Esto no quiere decir que a pesar de una eficiente gestión del
proyecto desaparezcan los problemas en el desarrollo del mismo, ya que conforme avanza el desarrollo
de los proyectos, aparecerán nuevos riesgos, ocurrirán problemas con el personal comúnmente
relacionados con las actividades en equipo, por lo que es indispensable una adecuada gestión por parte
de los gerentes quienes deberán planificar y ejecutar actividades que permitan minimizar en lo posible
estos problemas.
Al hablar de proyectos de software es importante recalcar como la Ingeniería del software aporta al
proceso. En (IEEE Computer Society, 2004) se define a la gestión de la Ingeniería de Software como
la aplicación de actividades administrativas, como son la planeación, coordinación, medición,
monitorización, control y reporte que permitan asegurar que el desarrollo y el mantenimiento de
software sea sistemático, disciplinado y cuantificable.
(Pressman, 2010), indica que desde el punto de vista administrativo la efectividad de los proyectos de
software se enfocan en las cuatro “P”:
• Personal: ¿Quiénes?
• Producto: ¿Qué?
• Proceso: ¿Cómo?
• Proyecto: ¿Para qué?
Con una breve introducción de lo que es la gestión de proyectos software, revise la parte
introductoria del capítulo 22 del texto básico. Ponga énfasis en los criterios de éxito para
la gestión de proyectos y sobre todo en aquellas formas que hacen a la ingeniería del
software diferente a otras ingenierías.
Una vez revisado el presente apartado concluimos reconociendo que la gestión de proyectos de
software radica sus diferencias con otras ingenierías, en:
• Que el software es intangible.
• La divergencia de proyectos, esto ocasiona que a pesar de tener amplia experiencia en

proyectos anteriores, siempre será difícil predecir problemas futuros.
• Que la organización es la que establece los procesos de software.
32
Adicionalmente en el (IEEE Computer Society, 2004) se indica que la gestión de proyectos incluye
fundamentalmente:
• Identificar los requisitos.
• Establecer objetivos claros y posibles de realizar.
• Adaptar las especificaciones, los planes y el enfoque a las diversas inquietudes y expectativas
de los diferentes interesados.
• Equilibrar las demandas concurrentes entre calidad, alcance, tiempos y costes.
Para finalizar el presente apartado desarrolle la actividad que se propone.
Actividad recomendada
Indique a qué actividad del Administrador corresponde cada una de las siguientes tareas.
Tareas Actividad
Se encarga de supervisar el trabajo para asegurarse que se están
utilizando los estándares adecuados.
Establece las formas de trabajo.
Valorar los riesgos que afectan al proyecto.
Informar el avance del proyecto tanto a los clientes como a los
directivos de la organización.
Se encarga de describir los objetivos del proyecto y la forma en que
se realizará.
Se encarga de elegir los integrantes del equipo.
Controlan que el desarrollo de las actividades estén a tiempo y dentro
del presupuesto.
2.2. Gestión del riesgo
En la actualidad se asume con gran interés la presencia del riesgo en todos los proyectos y especialmente
en los proyectos de tecnología, como es el caso de los proyectos de desarrollo de software. A continuación
se indican algunos conceptos relacionados con el riesgo.
“Un riesgo es cualquier variable del proyecto, sobre la cual se pueda o no tener control directo, que tome
un valor dentro de su distribución normal de valores posibles que o bien hagan peligrar o directamente
elimine la posibilidad de éxito del proyecto”(Lister, 1997)
“Un evento con probabilidad de ocurrencia y consecuencias potencialmente negativas” (Charette &
Mac, 1997). En otras palabras, un riesgo es un problema potencial, cuya probabilidad alcanza niveles de
incertidumbre.
Como se habrá dado cuenta en componentes educativos anteriores se han realizado múltiples debates
sobre la adecuada definición del “riesgo del software” las mismas que giran sobre dos características:
33
• Incertidumbre: Que puede o no ocurrir.

• Pérdida: Si ocurre, ocasiona consecuencias no deseadas o pérdidas.
Reflexione sobre estas definiciones y luego destaque el riesgo enfocado desde la perspectiva de un
proyecto y lo importante que resulta su adecuada gestión. En consecuencia podemos afirmar que al
desarrollar proyectos de software una tarea primordial por parte de los administradores es la correcta
gestión de los riesgos con el afán de minimizar su impacto.
En (Sánchez, 2010) se establece que los objetivos de la gestión del riesgo radican en:
• Identificar, analizar y cuantificar posibles riesgos que puedan aparecer durante el desarrollo
de un proyecto software.
• Desarrollar respuestas adecuadas para los posibles riesgos.
• Monitorizar el proyecto para evaluar el estado de los  riesgos y actuar en caso de ser
necesario.
Comúnmente se suele confundir entre preocupación, riesgo y problema. Una preocupación es una
situación sobre la cual existen dudas y que por lo tanto puede ser evaluada como un posible riesgo,
mientras que un problema es un riesgo que efectivamente se ha producido.
Preocupación Riesgo Problema
Figura 2.1: Diferencia de riesgo
Estimado estudiante, es hora de ir al texto básico y leer de forma comprensiva el literal

22.1 Gestión del riesgo, ponga especial énfasis en cada una de las actividades del
proceso de gestión del riesgo.
Una vez realizada la actividad de lectura, analice el ¿por qué? es necesario hacer una adecuada “gestión
del riesgo”.
Es necesario acotar que los riesgos dependen de muchos factores, principalmente del proyecto y el
entorno de la empresa encargada del desarrollo del software. De igual forma existen riesgos que son
comunes a los proyectos, tal como se indica en la figura 22.1 del texto básico, en el que cada riesgo se
asocia con las categorías que se propone (riesgos del proyecto, producto y empresariales).
Así como se identifican los riesgos, están las estrategias frente a los riesgos. Algunos autores identifican
dos tipos de estrategias, las reactivas y preactivas. Las reactivas evalúan las consecuencias cuando
el riesgo ya se ha producido, mientras que las preactivas permiten realizar los análisis del riesgo de
forma temprana, sistemática, formal y profunda para evitar y minimizar las consecuencias mediante la
conformación de planes de contingencia.
34
Figura 2.2: Gestión del riesgo. (Pressman, 2010)
En (Pressman, 2010), y en (Mcconnell, 1997), se indica las actividades relacionadas con la gestión de
riesgo, tal como se indica en la figura 2.2. Sin embargo en el texto básico se hace referencia a cuatro
etapas, las etapas son:
• Identificación del riesgo

• Análisis del riesgo
• Planeación del riesgo
• Monitorización del riesgo
1. Identificación del riesgo.
Es la primera actividad del proceso de gestión, que consiste en identificar las amenazas que pudieran
afectar tanto al proceso, al producto o a la organización que desarrolla el producto, y como punto de
partida para poder identificar los riesgos se utiliza una lista de verificación de diferentes tipos de riesgos.
En el texto básico de indican al menos seis tipos de riesgos que se pueden incluir en la lista de verificación.
Así mismo en la figura 22.3 se indican algunos ejemplos de este tipo de riesgos.
De acuerdo a (Sánchez, 2010), existen ciertas técnicas que permiten identificar de forma apropiada los
riesgos, entre las que tenemos:
• Revisión de la documentación existente.

• Revisión, planificación y estimaciones.
• Tormenta de ideas.
• Juicio Experto: Técnica Delphi.
• Taxonomías de riesgos.
• Análisis SWOT.
• Diagrama de Ishikawa.
35
De la misma forma en (Silberman, 2011) indica que no todos los riesgos son iguales y su influencia en
cada proyecto es diferente, como no todos los riesgos pueden ser tratados de forma exitosa ni pueden
ser transferidos. También se hace referencia a 10 ítems de riesgo y recomienda técnicas de administración
de riesgos, que están considerados en la Figura 22.1 del texto básico.
2. Análisis del riesgo.
Una vez que se dispone los riesgos debidamente identificados el analista debe tener la suficiente
capacidad, basado en la experiencia y un adecuado análisis para determinar la probabilidad de ocurrencia
y la gravedad de cada riesgo. La mayoría de autores sugieren que el análisis de los riesgos se los realice
tanto de forma cuantitativa como cualitativa.
Cualitativa: Definir de manera cualitativa la importancia o prioridad de cada riesgo. Las técnicas que se
sugiere para realizar este tipo de análisis son:
• Juicio experto.
• Tablas de impacto.
• Matrices de probabilidad e impacto.
• Agrupación por causas.
• Agrupación por prioridad temporal.
Cuantitativa: Cuantificar de forma precisa el impacto y probabilidad de ocurrencia de un riesgo. Las

técnicas para realizar éste tipo de análisis son:
• Obtención de datos estadísticos descriptivos.

• Distribuciones de probabilidad.
• Juicio Experto.
• Análisis de Sensibilidad (diagramas de Tornado).
• Análisis de Valor Esperado + Arboles de decisión.
• Modelado y Simulación (Montecarlo).
De acuerdo a (Silberman, 2011), el propósito fundamental del análisis de riesgo es calcular la influencia
que producen cada uno de los riesgos que se han logrado identificar. Para proyectos de software los
métodos básicos de análisis de riesgo son:
• Análisis de riesgos independientes.

• Análisis de sensibilidad.
• Análisis de probabilidad.
• Análisis de árboles de decisión.
Durante la ejecución de un proyecto de software, la influencia del riesgo puede ser medida por la exposición del
riesgo, mediante la formula:
36
ER = p(DE) * PR (1)
Donde:
ER à Exposición al riesgo.
DE à Daño esperado.
PR à Pérdida resultante.
En base a este análisis se reducen los riesgos previamente identificados, por lo que es necesario
información detallada del proceso, proyecto, equipo de desarrollo y la organización.
En la figura 22.4 del texto básico por cada riesgo se indica la probabilidad que ocurra y el efecto que esto
ocasionaría. Finalmente se debe completar el análisis indicando los riesgos más significativos.
3. Planeación del riesgo.
Esta actividad consiste en recopilar la información necesaria para desarrollar estrategias que permitan
mitigar los riesgos previamente analizados. Es de mucha importancia que esta tarea la realice personas
que tengan una amplia experiencia en proyectos similares.
En la figura 22.5 del texto básico se establecen algunas estrategias ante ciertos riesgos, aunque son
descripciones breves se puede determinar que cada estrategia está encaminada a evitar o reducir
el impacto del riesgo si llega a darse. No olvide que las estrategias se establecen en tres categorías:
Estrategias de evitación, minimización y contingencia.
Queda a criterio del administrador del proyecto decidir sobre qué riesgo se deben afrontar, comúnmente
en orden de prioridad aquellos cuyo efectos impiden el normal desarrollo de las actividades del proyecto.
4. Monitorización del riesgo.
A pesar de establecer actividades para minimizar el impacto de los riesgos, es necesario que se realice un
continuo control con el fin de conocer el comportamiento de cada uno de los riesgos, para poder realizar
los ajustes necesarios si ese fuera el caso. El control básicamente consiste en implementar una lista con
todos los riesgos identificados para una actividad específica del proyecto y para la situación actual.
De acuerdo a (Silberman, 2011) las fases de monitoreo de riesgos durante la ejecución del proyecto son:
• Construir una lista de ítems durante la etapa de identificación de riesgos.
• Si se encuentran ítems de riesgos se debe analizar los riesgos, especificar sus probabilidades
y evaluar el daño esperado en términos monetarios, temporales y de esfuerzo.
• Aplicar estrategias o bien transferir ítems de riesgo a las próximas etapas del proyecto, es
decir, determinar cuales riesgos administrar.
• Llevar a cabo acciones para reducir el daño esperado y acciones inhibitorias de próximos
riesgos.
Observe y analice detenidamente la figura 22.6 “Indicadores de riesgo”, del texto básico, en el que se
indican algunos ejemplos de factores que permiten la valoración de los riesgos que se pueden identificar.
37
Dado los siguientes riesgos, complete el cuadro. Para ello analice los ejemplos que se indican en el
texto básico en el literal correspondiente a la gestión del riesgo. Además en el Anexo 3, existe un
ejemplo sobre la gestión del riesgo que le ayudará a realizar la actividad.
Tabla
Tipo de Nivel
Id. Riesgo Categoría Probabilidad Impacto Acción
riesgo Expos.
Interfaz del
R06 subsistema de formato
de gráficos inestable
La aprobación del
R07 proyecto tarda más de
lo esperado
El personal
contratado se retrasa
en la entrega del
R08
subsistema encargado
de formatear los
gráficos
Los recursos no están
R09 disponibles en su
momento
Los informes de
estado a nivel de
R10 directiva necesitan
más tiempo del
previsto
2.3. Gestión de personal
Recuerde que en todo proyecto de software el gerente como parte de su gestión procura tener el
mejor recurso humano (personal debidamente capacitado), un proceso de desarrollo adecuado y una
planificación acorde a la magnitud del proyecto, con el fin de tener un producto a tiempo y de calidad.
El recurso humano siempre es el mas importante en el desarrollo de un producto software; y muchos de

los empresarios, administradores o líderes de empresas de renombre coinciden en que el éxito que han
logrado depende mucho de la gente y el trabajo en equipo y no a las herramientas que utilizan.
Los administradores de proyectos de software cuando desconocen la manera de gestionar el personal

de una forma adecuada en los equipos de desarrollo, deben adquirir cierto conocimiento y desarrollar
habilidades que les permitan realizar una apropiada gestión del recurso humano que tienen a su cargo.
Estimado estudiante, realice la lectura del literal “22.2 Gestión de personal”, del texto
básico.
Claramente en el texto básico se indica los cuatro factores en la gestión del personal:
Consistencia, Respecto, Inclusión y Honestidad, que permitirían planificar y asignar actividades dentro
de los parámetros normales.
38
Es importante recalcar que la experiencia de los administradores con respecto a la gestión del
recurso humano es un factor clave para cumplir a cabalidad con las actividades encomendadas,
por lo que es fundamental que se determinen las formas de como actuar de forma apropiada
ante problemas que pudiera ocurrir.
Los administradores de los proyectos deben conocer a sus empleados de tal manera que puedan saber
si en algún momento ocurren problemas que afecten al normal desarrollo del proyecto. En la figura 22.8
del texto básico se indica un caso de motivación a los que normalmente se enfrentan los administradores.
Se sugiere que analice detenidamente el caso, si es posible vuelva a leer para que realice un adecuado
análisis.
Modelo personal CMM.
El modelo de madurez de capacidad de personal (P-CMM), es propuesto por el SEI de la Carnegie-Mellon,

diseñado para ayudar a las organizaciones a mejorar la capacidad de su equipo humano y la efectividad
de la organización. El modelo ofrece un marco de mejora de la madurez que las organizaciones pueden
utilizar para gestionar y mejorar sus acciones para atraer, motivar y retener al personal mejor calificado.
Los componentes esenciales de la estructura del modelo Personal-CMM son los siguientes:
• Niveles de madurez
• Áreas de proceso
• Objetivos
• Prácticas
El modelo Personal-CMM (People-CMM, en inglés), consiste de cinco niveles de madurez como se indica
en la figura 2.2, o estados evolutivos, a través de los cuales evolucionan las prácticas y procesos de
gestión de las capacidades del recurso humano de una organización. En cada nivel de madurez, un
nuevo sistema de prácticas es superpuesto a aquellas implementadas en los niveles anteriores. Cada
superposición de prácticas eleva el nivel de sofisticación por medio de cual la organización desarrollo
su fuerza laboral. Para esto, las organizaciones se equiparan de prácticas más poderosas para atraer,
desarrollar, organizar y motivar a sus empleados.
39
Disciplinas de Personal CMM

Desarrollo de Creación de Motivación y Manejo del
Capacidades y una cultura y de administración del personal
Competencias grupos de trabajo desempeño
Alineamiento Innovación
Optimizado Capacidad de mejora continua del desempeño continua del
organizacional personal
Integración de
Tutoría competencias. Administración Administración de
Predecible Recursos basados Grupo de trabajo cuantitativa del las capacidades
en competencias con poder de desempeño organizacionales.
decisión.
Desarrollo
Desarrollo de
de grupos de Prácticas basadas en
competencias. Planeación de la
Definido trabajos. competencias.
Análisis de planta de personal.
Cultura de Desarrollo de carrera
competencias.
participación
Compensación
Formación y Comunicación y Administración del
Administrado Contratación
desarrollo coordinación desempeño.
Ambiente laboral
Inicial
Figura 2.2: Niveles y áreas de procesos del modelo Personal CMM.
Haciendo referencia al estudio del caso del texto básico de la figura 22.8, analice las preguntas que
se indican.
• ¿Es correcta la decisión tomada por Alice?

• ¿Qué pasaría con el proyecto, si Alice no decide hablar sobre la situación de Dorothy?
• ¿En que beneficia al equipo la decisión tomada por Alice?
• ¿Afectará a los demás miembros del equipo las consideraciones otorgadas a Dorothy?
2.4. Trabajo en equipo
Los proyectos de desarrollo de software requieren de un trabajo en equipo, por lo tanto el éxito de
implementar un producto software depende en gran medida del rendimiento de los equipos de trabajo
que intervienen en el proyecto. Si por diversos motivos el administrador del proyecto tiene que enfrentar
plazos ajustados que conllevan a importantes decisiones, depende mucho de su equipo de trabajo que
esta formado por personas que tienen diferentes aspiraciones, intereses y maneras de trabajar como son
las relaciones interpersonales que podrían en su momento determinar el éxito o fracaso del proyecto.
40
En definitiva, el tener un equipo de trabajo significa que este debe tener ciertas responsabilidades, por
lo tanto surgen ciertas interrogantes como por ejemplo:
• Con respecto al proyecto de desarrollo, ¿Cuáles serían las principales ventajas de tener un
grupo de trabajo?
• ¿Los equipos de trabajo de cuantos miembros se recomienda?
• ¿Qué es un grupo cohesivo?
• ¿Cuáles deberían ser los factores para decir que un equipo de trabajo es efectivo en el
desarrollo de las actividades?
• ¿Cómo debería estar organizado un equipo de trabajo?
• ¿Cuál es el compromiso? A nivel de equipo y forma individual.
• ¿Cómo hacer conciencia en el equipo de la importancia del proyecto?
De acuerdo al (IEEE Computer Society, 2004), “El éxito global del proyecto depende del compromiso del
equipo del proyecto, el cual está directamente relacionado con su nivel de motivación”, la motivación
tiene que ver con un adecuado ambiente que tenga claro los objetivos del proyecto de tal manera que
cada integrante sienta los valores personales que pueden ser la satisfacción personal, un trabajo
estimulante, una compensación salarial suficiente, entre otras.
Estimado estudiante, es momento de revisar el tema “22.3 Trabajo en equipo”, del texto
básico, para identificar ciertas consideraciones que se deben tener en cuenta por parte
de los administradores en la gestión del proyecto.
Una vez analizado el tema en el texto básico, se asume que se despejaron las interrogantes planteadas
anteriormente. A continuación se indican algunos análisis adicionales que ayudan a tener una idea mas
concreta del trabajo en equipo.
En (Letelier, Penadés, & Sánchez, 2005) se enfatiza que cada vez, se valora más la capacidad de un
individuo de trabajar en equipo de forma efectiva, ya que el trabajo en equipo es un escenario habitual
en los proyectos de software.
En el texto básico se definen tres factores genéricos que afectan al trabajo en equipo, indistintamente de
los conflictos y la organización; esto se relaciona directamente con la estructura del equipo, dado que, es
de vital importancia establecer los mecanismos para escoger las personas del grupo, además de la forma
en que se organizará y se asignarán las actividades o tareas, para finalmente establecer los mecanismos
necesarios de comunicación.
En (Pressman, 2010) se indica que la mejor estructura del equipo depende de:
• El estilo administrativo de la organización.

• El número de personas y sus habilidades.
• La dificultad del problema.
41
Con respecto al personal (Pressman, 2010), indica que el proceso de construcción y gestión de software
esta poblado de participantes, quienes pueden organizarse en diferentes áreas, tal como se indica en la
figura 2.3.
Participantes
Proyectos Software
Gerentes de
Gerentes
proyecto Profesionales Clientes Usuarios finales
ejecutivos
(técnicos)
Definen los temas Planifican, Motivan, Aportan con habilidades Especifican los Interactúan con el
empresariales. Organizan y Controlan a técnicas. requerimientos para el software una vez que se
los profesionales que software. libera para su uso.
desarrollan el software
Figura 2.3: Participantes del equipo de trabajo (Pressman, 2010)
Constantine sugiere cuatro paradigmas organizacionales para los equipos de ingeniería del software
(Pressman, 2010), que permiten organizar el equipo de trabajo:
• Un paradigma cerrado. Dónde se estructura un equipo en base a una jerarquía de autoridad.
• Un paradigma aleatorio. Se estructura el equipo de forma holgada y depende de la iniciativa

de cada integrante.
• Un paradigma abierto: En esta estructura el trabajo se desarrolla de forma colaborativa.
• Un paradigma síncrono: Se organiza a los miembros para que trabajen en partes del
problema, dejando de lado una comunicación activa.
Figura 2.4: Composición del equipo de trabajo (Pressman, 2010)
42
Cabe destacar que de acuerdo al texto básico son tres los factores que influyen en los grupos de trabajo,
tal como se muestra en la figura 2.4.
Finalmente considerando “El estudio de caso”, de la figura 22.10, del texto básico, se puede deducir que
para conformar el equipo es necesario realizar ciertas actividades que permitan “conocer” y seleccionar
de forma coherente a los futuros miembros del equipo.
2.5. Procesos de gestión de la ingeniería de software.
Existen varios aspectos de la administración de proyectos que deben tomarse en cuenta, si revisamos la
definición del Glosario Estándar IEEE para la gestión de la ingeniería de software, encontramos la
siguiente definición “la aplicación para actividades de gestión -planificación, coordinación, medición,
monitoreo, control e informes- que asegure un desarrollo y mantenimiento del software sistemático,
disciplinado y cuantificado”13. Según esta definición la gestión de la ingeniería del software implica
actividades de planificación, coordinación, medición, monitoreo y control, la cual coincide claramente
con los grupos de procesos establecidos en PMBOK.
Se le recomienda realizar la lectura del capítulo 8 de SWEBOK, el cual lo puede descargar

del sitio http://bit.ly/10EaHL6. El contenido de este libro le será útil para estudiar
diferentes apartados de la presente guía didáctica.
Es preciso establecer una diferencia entre lo que es la gestión de la ingeniería del software y el proceso
de ingeniería del software que comprende las actividades técnicas y de gestión aplicables al ciclo de
vida del software, en tanto que el área de gestión involucra actividades de planificación, seguimiento
y control, ninguna de estas áreas puede funcionar independiente la una de la otra, ambas áreas de
conocimiento son esenciales para lograr proyectos exitosos.
Otro aspecto en el que hace énfasis SWEBOK, tiene que ver con la complejidad inherente al software,
que lo hace diferente del trabajo en otras ramas de la Ingeniería, entre ellas podemos mencionar:
• La naturaleza intangible del software a menudo hace que los clientes subestimen su
complejidad, sobre todo a la hora de establecer o cambiar los requisitos.
• Por naturaleza los requerimientos son muy cambiantes lo cual ha derivado en el desarrollo
de procesos iterativos que se desarrollan pasando por un grupo de tareas específicas.
• Los cambios y evolución de la tecnología es muy rápida lo cual hace necesario que los equipos
de desarrollo estén siempre aprendiendo y lidiando con nuevas técnicas y herramientas.
Según IEEE Computer Society (2004) las actividades de gestión para la Ingeniería de Software ocurren a
nivel de gestión organizacional y de infraestructura; a nivel de gestión de proyectos y a nivel de programa
de planificación y control de mediciones. Considera además que “una gestión sin medición, cualitativa y
cuantitativa, da la sensación de una falta de rigor, y medir sin gestionar da la sensación de una falta de
fines o de contexto. De igual manera, sin embargo, gestión y medición sin conocimientos de expertos es
igualmente ineficaz”14
Con ello queda clara la importancia de usar métricas para una gestión adecuada de proyectos
de desarrollo de ingeniería de software. Naturalmente para poder hacerlo hay que tener el
conocimiento necesario, varios temas de estimación y métricas se considerarán a lo largo de este
capítulo.
13 citado en IEEE Computer Society (2004), pp 8-1

14 IEEE Computer Society (2004), pp 8-2
43
Es necesario también establecer la diferencia entre el proceso de gestión y la obtención de métricas, en el primer
caso nos referimos a las actividades necesarias para asegurarse que los procesos de desarrollo de software se
ejecutan de acuerdo a los estándares establecidos y en el segundo caso se trata las actividades encaminadas a
obtener valores relacionados con los procesos y los productos obtenidos.
En la figura 2.5 se puede apreciar la descomposición de los temas de gestión de la ingeniería de software, la cual
le ayudará a comprender como empatan las etapas y áreas de conocimiento de la Gestión de Proyectos con los
procesos de Gestión de la Ingeniería de Software. A continuación se realizará una descripción de cada una de estas
actividades.
Actividades de inicio y alcance
Están encaminadas a la definición de requerimientos de software y su factibilidad de implementación; estas

actividades incluyen la determinación y negociación de los requisitos; estudio de factibilidad en el que se
consideran aspectos como el técnico, operativo, financiero, político, alineación con objetivos organizacionales,
entre otros; y la validación de requerimientos de forma que se llegue a acuerdos respecto del alcance del proyecto.
Actividades de planificación de un proyecto de software
Este es el conjunto de actividades de gestión que mayor esfuerzo y cuidado demandan, su importancia es muy alta
debido a que en ellas se establece la línea base del proyecto en los aspectos relativos a: alcance, tiempo y costo,
los cuales configuran la forma en que el proyecto se desarrollará. Por lo que estará regulado por el alcance y los
requisitos, siendo de vital importancia evaluar los procesos de ciclo de vida del software y se elije el mas adecuado,
considerando ciertos factores como es: la naturaleza del proyecto, complejidad, requisitos, calidad, etc.).
Actividades de promulgación del proyecto de software
Estas actividades están las relacionadas con la ejecución de los planes y la divulgación de los procesos que se han
establecido como parte de los planes. La promulgación se fundamenta en actividades de gestión que permita
medir, supervisar, controlar e informar.
Figura 2.5: Descomposición de los tópicos para área de conocimiento de Gestión de la Ingeniería de Software. IEEE Computer Society (2004),
pp 8-3
44
Actividades de revisión y evaluación.
Una vez que se han desarrollado las actividades necesarias de acuerdo al plan establecido, es momento
de evaluar el progreso global verificando el logro de los objetivos planteados y la satisfacción del cliente/
usuario, siendo necesario determinar ciertos hitos y valorar tanto el proceso, el personal, las herramientas
y los métodos que se han utilizado.
Actividades de cierre
Una vez que se han desarrollado las actividades de revisión y evaluación y los procesos implicados se han
completado por ende divulgados, el proyecto llega a su fin siendo necesario documentar la aceptación
por parte del cliente, indicando que se han completado las tareas tal como se especificaron en los planes.
Actividades de medición de la ingeniería del software
La madurez de las organizaciones se refleja con la eficacia con que se mida el software. El estándar ISO/
IEC 15939 (Proceso de medición del software), y el PSM (Medición práctica del software), establecen
actividades y tareas del proceso de medición, ya que permiten: identificar, definir, seleccionar, aplicar y
mejorar la medición del software tanto a nivel del proyecto como de la estructura de medición de una
organización. El estándar se compone de dos elementos: (i) el modelo de información de la medición y
(ii) el proceso de medición, tal como se indica en la figura 2.5.
Requisitos de medición Realimentación de los usuarios

Procesos técnicos y de gestión
Necesidades de Productos
información informativos
Acciones de mejora
Núcleo del proceso de medición
Establecer y
Planificar el Realizar las
mantener el Evaluar
proceso Información de mediciones Productos
compromiso
planificación informativos y
resultados de las
informaciones
Base de experiencias de medición Productos informativos y

resultados de evaluación
Acciones de mejora
Figura 2.5: Actividades ISO/IEC 15939.
45
Autoevaluación 2
Hemos finalizado la unidad 2, por lo que es necesario realizar una autoevaluación para determinar
el conocimiento asimilado. Se recomienda resolver lo porpuesto ya que es posible que haya
algunos temas que no se han comprendido a plenitud. Recuerde que al final de la guía se han
incluido las soluciones a estas autoevaluaciones sin embargo deberá usarlas solo después de
haber obtenido sus propias respuestas para volver a revisar temas que quizá no quedaron bien
comprendidos.
1. Cuando se da la renuncia de un analista experimentado del equipo de trabajo, entonces tenemos

un riesgo de:
a. Producto
b. Proyecto
c. Empresarial
2. Para una empresa que desarrolla un determinado producto y la competencia introduce al mercado
un nuevo producto, existe un riesgo:
a. Producto
b. Proyecto
c. Empresarial
3. Dentro del proceso de gestión de riesgo, cuando se requiere valorar la probabilidad que ocurra un
riesgo y las consecuencias que estos ocasionan, se conoce como:
a. Identificación del riesgo

b. Planeación del riesgo
c. Análisis de riesgos
4. Cuando se han desarrollado estrategias para estar preparados para lo peor, a esto se lo conoce
como:
a. Estrategias de evitación
b. Estrategias de minimización
c. Planes de contingencia
5. Uno de los factores críticos en la gestión de personal es la Inclusión, se refiere a:
a. Todas las personas del equipo reciben un trato similar.

b. Las personas aportan cuando los demás toman en cuenta sus criterios y propuestas
c. Que las personas se respetan mutuamente
46
6. El ofrecer un programa de capacitación a los integrantes del grupo de trabajo para que desarrollen
sus habilidades, permite satisfacer las necesidades:
a. Sociales
b. Estima
c. Autorrealización
7. Desde el punto de vista de la motivación, aquellas personas que están dispuestas a cumplir con
el reto de desarrollar software, es un tipo de personalidad:
a. Orientada a las tareas

b. Orientada hacia sí mismas
c. Orientadas a la interacción
8. El gerente de un proyecto de software debe conformar un grupo para el proyecto de ingeniería de

software. ¿Cuántos integrantes es lo recomendable?
a. Hasta 10 miembros
b. Hasta 50 miembros
c. Mínimo 20 miembros.
9. Si el un grupo del proyecto esta conformado por 9 miembros, el número de vínculos de

comunicación es:
a. 18
b. 72
c. 9
10. Si un integrante del equipo se ausenta y los demás integrantes son capaces de cubrir sus
actividades, entonces hablamos de un:
a. Grupo adherido
b. Grupo especializado
c. Grupo cohesivo
47
UNIDAD 3. PLANIFICACIÓN DE PROYECTOS DE SOFTWARE
Iniciamos ahora el estudio de la tercera unidad del componente educativo en la cual nos sumergimos de
lleno en los procesos de planificación de proyectos de software.
Seguramente habrá escuchado la analogía común que suele hacerse entre los proyectos de construcción
con los proyectos de desarrollo de software, en realidad es un ejercicio muy ilustrativo y vale la pena
traer el tema para iniciar el estudio de esta unidad.
¿Se ha preguntado alguna vez la diferencia entre un albañil y un arquitecto o ingeniero civil? si lo piensa
un poco es probable que piense en que cumplen funciones diferentes, además de qué los arquitectos
e ingenieros son estudiados y que los albañiles por lo general han aprendido su trabajo ejerciendo sus
funciones o que alguien se lo ha enseñado, etc.
Sin embargo pensemos un poco en el rol que cumple cada uno de ellos y establezcamos la misma
analogía al respecto, como se muestra en la tabla 3.1
Tabla 3.1 Analogía de roles y responsabilidades entre ingeniería de software y la construcción
Como se aprecia en la tabla anterior, hay un papel trascendental que cumplen los ingenieros y los
arquitectos en la industria de la construcción sin el cual, el trabajo de los albañiles por buenos que estos
sean, sería un trabajo inútil; de la misma manera, el rol del programador no tendría mayor relevancia si su
trabajo no se enmarca en un esquema de proyecto, y ello necesariamente deriva en otras afirmaciones
que posiblemente le causarán controversia, y se puede llegar a ellas contestando a las siguientes
interrogantes:
48
¿Puede un Ingeniero en Informática ejercer su profesión si no domina técnicas de planificación y gestión

de proyectos?
¿Resulta confiable un ingeniero que no es capaz de estimar costos y duración de un proyecto?
¿Puede dirigir un proyecto un ingeniero que no puede organizar el trabajo de equipo?
Las respuestas a estas preguntas nos dan la pauta para determinar la importancia de las técnicas de
planificación y gestión de proyectos en la Ingeniería del Software, entonces las afirmaciones a las que
llegamos son las siguientes:
1. Un ingeniero en informática que no sabe planificar y gestionar proyectos en el área de

tecnología es un profesional incompleto.
2. La planificación y gestión de proyectos es una competencia inherente al trabajo de un

ingeniero en cualquiera de las áreas en que se especialice.
Con esta breve reflexión, avancemos en el desarrollo de la presente unidad tomando como referencia al
capítulo 23 del texto básico y la sección 2. Software Planning del capítulo 8 de SWEBOK15.
3.1. Procesos de planificación de la ingeniería de software
Antes de comenzar a estudiar esta unidad, se le recomienda realizar la lectura introductoria

al capítulo 23 del texto básico, el cual le dará una pauta sobre los procesos de planificación y
estimación en los proyectos de desarrollo de software, los cuales iremos revisando a lo largo
de la presente unidad.
Seguro que pudo notar que la preocupación principal de los procesos de gestión de proyectos están
relacionados principalmente con la estimación de costos y de tiempo, los cuales forman parte de la triple
restricción, sin embargo es importante recalcar que si bien estos elementos son fundamentales para la
gestión de un proyecto, no son los únicos y sería un error no considerar los demás elementos.
En este sentido vamos a complementar el tema recurriendo a SWEBOK (2004) que mencionamos
anteriormente, el cual en esencia describe los procesos de planificación de proyectos desde el punto
de vista de la Ingeniería del Software y para hacerlo se basa en el cuerpo de conocimiento del PMI, cuya
terminología básica ya estudiamos en la unidad 1.
Las actividades de planificación se constituyen en las actividades de gestión que mayor esfuerzo y
cuidado demandan, su importancia es muy alta debido a que en ellas se establece la línea base del
proyecto en los aspectos relativos a: alcance, tiempo y costo, que se constituyen en parámetros que se
deben cumplir en el proyecto. En la figura 3.1 se puede apreciar todos los elementos de la planificación
de la ingenieria de software segun swebok
En este momento puede centrarse en revisar la sección 2. Software Planning, del capítulo 8
de SWEBOK, en el cual se profundiza los elementos esenciales del proceso de planificación.
15 Software Engineering Body of Knowledge, IEEE Computer Society (2004)
49
Gestión de la Ingeniería del

Software
.. Planificación ...
Planificación del proceso
Definición de entregables
Estimación de esfuerzo
cronograma y tiempo
Adquisición de recursos
Gestión de riesgos
Gestión de la calidad
Planificación de la gestión
Figura 3.1. Tópicos de los procesos de planificación del área de conocimiento de Gestión de la Ingeniería de Software. IEEE Computer Society
(2004), pp 8-3
Revisemos cada uno de estos procesos para establecer cómo se debe llevar a cabo la planificación de
un proyecto de software.
3.1.1. Planificación del proceso
A este proceso también podemos denominarlo “selección del proceso de desarrollo”, y se trata de
evaluar las posibles metodologías de desarrollo de software aplicables al proyecto, de acuerdo a sus
características tales como: el grado de incertidumbre, la complejidad técnica o funcional, los niveles de
calidad requeridos, etc.
Para seleccionar el proceso de desarrollo, debe tener en cuenta las metodologías existentes; una muy
buena guía de estas puede tenerla en el capítulo 2 del texto básico “modelos de proceso de software”,
el cual se le invita a leer, este capítulo describe las características de cada uno de los modelos tanto los
tradicionales como los ágiles y establece algunos lineamientos para saber cuándo conviene usar uno u
otro modelo.
Es conveniente recordar que todos los procesos de desarrollo pueden personalizarse en función de varios
factores, entre los que podemos mencionar: las características de la organización, la disponibilidad de
recursos humanos y económicos, el tiempo disponible, etc.
Por ejemplo si luego de evaluar los modelos de proceso del software, se determina que debe utilizar el
Proceso Unificado Rational, y considerando que este modelo propone 4 etapas, 9 disciplinas y 31 roles de
personas trabajando en el equipo, debería preguntarse ¿es necesario desarrollar todas las actividades y
tener todos los roles? La respuesta es no, de hecho el Proceso Unificado Rational es uno de los procesos
que en una de sus disciplinas concretamente la denominada “environment”, o entorno en español, se
desarrolla la personalización del proceso, además tiene un componente denominado RUP Builder que es
una herramienta de software que permite personalizar el proceso añadiendo las actividades y artefactos
necesario de acuerdo a los procesos que se llevarán a cabo.
50
3.1.2. Definición de entregables
En este punto se busca identificar los productos resultantes que debe producir el proyecto se consideran
entregables por lo general a aquellos elementos que el cliente recibirá como resultado del desarrollo
del proyecto, además algunos elementos propios del proyecto cuya incidencia es clave para obtener los
resultados, siendo así se puede considerar como entregables: el diseño arquitectónico, del sistema, los
componentes de software construidos, la capacitación, los manuales, etc.
En esta etapa también se evalúa las oportunidades de reutilización de software existente, el uso de
software de terceros y se planifica los proveedores correspondientes.
3.1.3. Estimación de esfuerzo, costo y cronograma
Una de las técnicas más importantes en los procesos de planificación es la descomposición del proyecto
en entregables, sub entregables, paquetes de trabajo y tareas, en relación al software se puede identificar
además las entradas y salidas, con los cuales se puede realizar una estimación del esfuerzo requerido
para cumplir con las actividades, para ello se puede usar uno de los variados modelos de estimación
existentes.
3.1.4. Obtención de recursos para el proyecto
Los recursos humanos son el elemento más importante para el desarrollo del proyecto, sin embargo
suelen ser los recursos más escasos o difíciles de conseguir, dependiendo del tipo de organización estos
pueden ser parte de la empresa o se contratarán para cumplir con actividades exclusivas del proyecto,
en ambos casos se puede tener dificultades, por ejemplo en el primer caso es posible que los empleados
de la organización deban seguir con sus funciones normales a más de trabajar con el proyecto, lo cual
restringe en gran medida el tiempo de dedicación al proyecto; y, en el segundo caso la estabilidad del
equipo y la pérdida de la experiencia de quienes trabajaron el proyecto y se fueron llevándose consigo
la experiencia adquirida durante el transcurso del proyecto.
Administración de riesgos del proyecto
La identificación, análisis y evaluación de riesgos del proyecto es una tarea crucial en cualquier proyecto,
en la parte de planificación se busca sobre todo determinar las diferentes categorías de riesgos,
identificarlos, evaluarlos para determinar su probabilidad e impacto y con esta información poder
proponer estrategias de mitigación. Esto naturalmente tiene incidencia en el presupuesto del proyecto,
ya que es necesario destinar recursos para evitar que el proyecto fracase debido a los riesgos.
3.1.5. Administración de la calidad
La calidad es un atributo esencial en cualquier producto, especialmente en los productos de software, a

pesar de ello no suele haber claridad en lo que significa desarrollar un software de calidad. Existen varios
enfoques para el aseguramiento de calidad y esta puede definirse tanto en términos cuantitativos como
cualitativos.
Otro aspecto esencial cuando se habla de calidad es considerar que esta no es accidental, por el
contrario debe planificarse, ejecutar los planes y validar si los resultados obtenidos están dentro del
rango esperado.
En el área de conocimiento de Gestión de la Calidad, el PMBOK establece 3 procesos que son: planificación
de la calidad, aseguramiento de calidad y control de calidad, cada uno de los cuales establece
procedimientos y herramientas que puede usarse en cualquier tipo de proyecto, y especialmente en
proyectos de complejidad alta como los procesos de desarrollo de software.
51
Como lectura recomendada, se sugiere revisar el capítulo 8 del PMBOK, 5ta edición, en
el cual se establece herramientas y técnicas generales que puede usarse para diferentes
tipos de proyectos.
3.1.6. Gestión de planes
Según IEEE Computer Society (2004), se debe definir no solo la manera en la que se gestionará el
proyecto, sino también la forma en que se gestionarán los planes, los cuales contienen elementos de
estimación, reporte, monitoreo y control del proyecto asegurándose que correspondan al proceso de
desarrollo seleccionado, además estos deben reflejarse en los artefactos de gestión que se usarán. Estos
planes también es preciso monitorearlos para evitar que se escapen de los procesos seleccionados.
A continuación se le invita revisar el apartado 23.2.2 El proceso de planeación, del texto

básico, en este punto se le pide especial énfasis en la figura 23.3 que muestra utilizando
un diagrama UML el proceso de planeación del proyecto, el cual analizaremos a detalle
en este capítulo.
Según esta lectura, lo primero que debe hacerse antes de profundizar en los temas de planificación es
identificar las restricciones, identificar los riesgos y definir los plazos y entregas, sin estas actividades
sería imposible empezar planificar puesto que todo proyecto se ejecuta con el fin de satisfacer dichas
restricciones.
3.2. Calendarización del proyecto
Sin lugar a dudas el cronograma del proyecto es uno de los insumos más importantes del proceso de
planificación, sin embargo a este no siempre se le da el seguimiento necesario para controlar los avances
y tomar acciones correctivas.
En relación a la calendarización, podemos decir que no se trata simplemente colocar una lista de
actividades con sus tiempos y sus dependencias, en realidad se trata de integrar una serie de elementos
tales como los recursos, hitos y dependencias de actividades que nos permitan establecer de manera
efectiva los elementos necesarios para el desarrollo del proyecto, como se muestra en la figura 3.2.
En ella se consideran elementos como los hitos, que en general representan el vencimiento de un
plazo o la culminación de una parte del proyecto, estos son importantes porque permiten planificar
contra las fechas establecidas para cada hito; las actividades representan las acciones necesarias para
desarrollar el proyecto, estas incluyen varios atributos como el esfuerzo requerido, la prioridad, entre
otras; las dependencias establecen el orden en que deben ejecutarse dichas actividades; los recursos
son las personas que se harán cargo de desarrollar dichas actividades y el calendario establece los días
y horas disponibles para trabajar en el proyecto, y puede indicar además si hay días y horas especiales
para determinados miembros del equipo de desarrollo.
52
Hitos Actividades Dependecias

Dependencias Recursos
Recursos Calendario
Calendario
Cronograma
Figura 3.2: Ingredientes para el desarrollo del cronograma.
En la figura 23.4 del texto básico se aprecia el proceso para crear el calendario del proyecto, en el primer
proceso del flujo planteado tenemos la identificación de actividades, las cuales si lo combinamos con
el proceso de gestión de proyectos nos llevan a un modelo más efectivo para poder obtener es lista de
actividades.
Esta consiste en partir de los paquetes de trabajo definidos en la estructura desagregada del trabajo y a
partir de allí generar una lista de actividades que se requieren para desarrollarlo, luego es avanzar con
los siguientes pasos planteados.
Ejemplo
Suponga que se le pide desarrollar una aplicación de software para procesar encuestas de una compañía
de marketing, la cual envía una solicitud de respuesta en línea a los encuestados y procesan la información
brindada por ellos en base a un modelo estadístico, los resultados obtenidos los publican en una revista
mensual.
Analizando este proyecto, se podría presentar la estructura desagregada del trabajo (EDT), que se
muestra en la figura 3.3 aplicable para este proyecto.
Figura 3.3: Estructura desagregada del trabajo para proyecto desarrollo de software para encuestas en línea.
Dentro de esta estructura, los elementos que se encuentran al último nivel los consideraríamos como
paquetes de trabajo, cada uno de los cuales posee una especificación (diccionario EDT) desde la cual se
puede desagregar las actividades necesarias para construirlos.
53
Si tomamos los paquetes de trabajo del entregable “Requerimientos” podríamos obtener las siguientes
actividades:
Tabla 3.1 Lista de actividades por paquete de trabajo para sistema de procesamiento de encuestas
Paquete de trabajo Descripción Actividades

Levantamiento de Proceso de captura de A. Identificar interesados y usuarios del
información necesidades de parte de sistema.
interesados y usuarios del B. Preparar entrevistas y cuestionarios
sistema. C. Aplicar entrevistas
D. Aplicar cuestionarios
E. Elaborar informe de entrevistas y
cuestionarios.
Revisión documental Análisis de la documentación F. Identificar fuentes documentales de
y procesos existentes información.
respecto de las preguntas y G. Solicitar autorización de acceso a
cuestionarios aplicables. documentos.
H. Revisar información documental.
I. Elaborar informe de hallazgos y
procedimientos encontrados.
Informe de Resumen de los J. Revisar informes de entrevistas,
requerimientos requerimientos identificados cuestionarios e información documental.
clasificados en funcionales K. Definir formato de informe de
y no funcionales con sus requerimientos.
respectivos atributos. L. Identificar y clasificar requerimientos.
M. Describir requerimientos
N. Redactar informe de requerimientos.
O. Validar informe de requerimientos
Si seguimos los pasos del flujo propuesto en la figura 23.4 lo siguiente sería identificar las dependencias
entre actividades, y aunque aún no revisamos como hacer la estimación, colocaremos la posible duración
de las mismas:
54
Tabla 3.2 Definición de dependencias y duración de las actividades del proyecto de desarrollo de un
software para procesar encuestas en línea.
Duración
Actividades Dependencias
(días)
A. Identificar interesados y usuarios del sistema. 2 --
B. Preparar entrevistas y cuestionarios 3 A
C. Aplicar entrevistas 5 B
D. Aplicar cuestionarios 3 B
E. Elaborar informe de entrevistas y cuestionarios. 2 C, D
F. Identificar fuentes documentales de información. 3 --
G. Solicitar autorización de acceso a documentos. 2 F
H. Revisar información documental. 5 G
I. Elaborar informe de hallazgos y procedimientos encontrados. 2 H
J. Revisar informes de entrevistas, cuestionarios e información 2 E,I
documental.
K. Definir formato de informe de requerimientos. 1 I
L. Identificar y clasificar requerimientos. 3 J,K
M. Describir requerimientos 5 L
N. Redactar informe de requerimientos. 3 M
O. Validar informe de requerimientos 2 N
Los siguientes pasos serían estimar los recursos para las actividades, asignar personal y crear gráficas de
proyecto, para lo cual se puede optar por una de las representaciones indicadas que son los diagramas
de Gantt y los diagramas de red.
Para la estimación y asignación de recursos se puede considerar la participación de varias personas

cuyos roles serían de analista, encuestador y director.
Para establecer las dependencias entre actividades se debe considerar tres tipos, las
denominadas obligatorias cuyo origen está en la necesidad de completar una actividad
antes de comenzar la otra debido a que se requieren los resultados de la anterior; las
discrecionales que dependen los recursos o conveniencias del gestor del proyecto, por
ejemplo si no dispone de recursos suficientes para desarrollar un grupo de actividades,
tendrá que asignarlas secuencialmente entre los recursos que dispone, y finalmente
tenemos las dependencias externas que no dependen del gestor del proyecto sino de definiciones
dadas a nivel de la organización o de una entidad externa, como por ejemplo el que antes de iniciar la
construcción de un edificio es preciso obtener los permisos correspondientes.
En lo relacionado a la asignación de recursos se puede considerar la información de la tabla 3.3:
55
Tabla 3.3 Estimación y asignación de recursos a las actividades del proyecto
Duración
Actividades
(días)
Analista 1
Identificar interesados y usuarios del sistema. 2
Preparar entrevistas y cuestionarios 3
Aplicar entrevistas 5
Elaborar informe de entrevistas y cuestionarios. 2
Revisar informes de entrevistas, cuestionarios e información documental. 2
Identificar y clasificar requerimientos. 3
Describir requerimientos 5
Redactar informe de requerimientos. 3
Encuestador
Aplicar cuestionarios 3
Elaborar informe de entrevistas y cuestionarios. 2
Analista 2
Identificar fuentes documentales de información. 3
Revisar información documental. 5
Elaborar informe de hallazgos y procedimientos encontrados. 2
Definir formato de informe de requerimientos. 1
Identificar y clasificar requerimientos. 3
Validar informe de requerimientos 2
Director de proyecto
Solicitar autorización de acceso a documentos. 2
En lo relacionado a los hitos que son resultados o fechas que marcan la culminación
o inicio de una nueva etapa del proyecto, estos ayudan en la planificación para
ajustar los cronogramas de modo que se logre completar las actividades en los plazos
establecidos. Los hitos que marcan la culminación de una fase normalmente vienen
dados por cuestiones de gerencia del proyecto o por los procesos de desarrollo, por
ejemplo si seguimos el RUP hay al menos cuatro hitos globales que marcan la culminación de cada fase
de desarrollo, en la fase de conceptualización, el hito es el alcance definido, de la fase de elaboración, el
hito es la arquitectura estable, de la fase de construcción el hito es la aplicación construida y de la fase
de transición el hito es la aceptación del cliente.
Para el ejemplo que estamos desarrollando plantearemos un hito al que denominaremos “Definición de
requerimientos completa”, la cual marca la culminación del entregable de requerimientos.
Consolidando toda esta información, podríamos tener el cronograma de la figura 3.4 en donde se puede
apreciar la representación en formato de diagrama de Gantt, el cual ha sido elaborado utilizando MS-
Project, y bien podría utilizarse otra herramienta como Excel u otro graficador.
De lo que se puede apreciar la duración total del entregable de requerimientos alcanza los 27 días de
trabajo y el hito se ha marcado con una duración de 0 días, lo cual significa que es una actividad que no
consume recursos ni tiempo.
56
Figura 3.4 Cronograma para el desarrollo del entregable de requerimientos para el proyecto de la aplicación para procesamiento de encuestas
en línea. Desarrollado en MS-Project 2013.
Otra forma de representar gráficamente el cronograma es mediante el uso de diagramas de precedencia

o diagramas de red, los cuales facilitan la visualización de la denominada ruta crítica. En la figura 3.5
podemos apreciar una versión de diagrama de red para las actividades del mismo proyecto.
Es preciso recalcar que estos diagramas muestran con mayor claridad la dependencia entre actividades
y sobre todo permiten visualizar la ruta crítica, a la cual podemos definirla como la ruta (secuencia) de
actividades más larga para que partiendo de una de las actividades iniciales llegar al final del mismo, lo
que también permite determinar la duración total del proyecto.
Figura 3.5 Diagrama de red para el proyecto de desarrollo del sistema de encuestas.
Hasta aquí se ha mostrado como preparar el cronograma para una parte del proyecto vinculando los
diferentes ingredientes que conforman su elaboración.
Los ejemplos hipotéticos que presenta el texto básico, ayudan a comprender de manera sencilla la
técnica de creación del cronograma por lo que se recomienda su revisión, además la inclusión de los
hitos es un aspecto importante para planificar de manera adecuada las actividades.
No se está considerando aún la parte de estimación debido que es mejor comprender en primera
instancia la técnica de calendarización, para luego proceder con los métodos de estimación, que en el
caso del software suelen ser bastante imprecisos.
57
Ejercicio 3.1
Para reforzar su aprendizaje, como actividad se le propone que tome otro entregable del
proyecto y utilizando la misma técnica siga los pasos hasta completar el cronograma,
adicionalmente puede finalizar el cronograma de todo el proyecto. Puede usar herramientas
como MS-Project si dispone de ella o descargar otras como Open Project16 disponible gratis
para varias plataformas.
Una vez que ha desarrollado el ejercicio, se habrá dado cuenta de que una planificación sin usar
herramientas termina siendo muy tediosa, además suele ser necesario realizar ajustes a los cronogramas
principalmente debido a que los plazos que se tienen estipulados no se pueden alcanzar y el gerente se
ve obligado a mover recursos, incluir otros nuevos y a desarrollar actividades en paralelo; esto no resulta
muy fácil si no se cuenta con las herramientas de software adecuadas.
Ahora considere el apartado 23.4 del texto básico donde se habla de la planeación ágil
que actualmente es un tema de moda, revíselo detenidamente.
En relación a la planeación ágil hay una serie de principios que se encuentran tras estas
metodologías, de hecho todas se sustentan en el denominado manifiesto ágil17, que
sostiene entre otras cosas el enfoque en las personas antes que en los procesos y en el software antes
que en la documentación; sin embargo hay otras prácticas que no sólo las usan los modelos ágiles como
lo son los modelos iterativos que favorecen en gran medida estos principios.
No siempre se puede aplicar modelos ágiles para planeación o para el desarrollo, sin embargo dada
la tendencia actual es una buena opción a considerar sobre todo si se aplica estos métodos no como
moda, sino como una nueva forma de hacer las cosas enfocándose en los resultados que es lo que al
cliente finalmente le interesa.
3.3. Técnicas de estimación
La estimación en cualquier tipo de proyecto es un tema complejo y lo es particularmente en los proyectos

de desarrollo de software, si revisamos las técnicas de estimación en general podemos decir que existen
dos grupos, unas basadas en la experiencia y otras basadas en métodos de cálculo, sin embargo no
podemos decir que existe una única técnica que sea capaz de resolver por sí sola el problema de la
estimación.
Antes de hablar de los métodos de estimación, es importante recalcar la importancia que la estimación
tiene en los procesos de planificación de proyectos, si pensamos en el proceso de planificación dos de
los temas que en general la planificación trata de responder es ¿cuánto va a demorar el proyecto? Y
¿cuánto va a costar?, con lo cual el problema más grande está justamente en el poder responder a estas
preguntas.
Algunos modelos de gestión de proyectos como los recomendados por en Project Management Institute
(2013), se sugiere el uso de cuatro métodos de estimación, los cuales pueden ser aplicados a cualquier
tipo de proyecto en cualquier área de ingeniería, y se pueden resumir en los siguientes términos:
16 Open Project, http://www.project-open.com/

17 http://agilemanifesto.org/iso/es/
58
• Juicio experto: Se sustenta en el uso de información histórica para recomendar tiempos

máximos o la combinación de técnicas de estimación, para ello se vale de personas con
experiencia en el área de aplicación del proyecto, aunque este método pudiera ser válido
para muchas áreas, en el campo del software suele ser más difícil de aplicar debido a las
innovaciones tecnológicas y las posibilidades de reutilización de componentes.
• Estimación análoga: Es una técnica válida tanto para estimar tiempo como para estimar
costos y se sustenta nuevamente en el uso de información histórica y establecer analogías
entre proyectos o componentes similares en aspectos como presupuesto, tamaño y
complejidad.
• Estimación paramétrica: Este tipo de estimación es muy común en proyectos en los que
se cuenta con información estandarizada para realizar los cálculos, se sustenta en el uso de
valores de rendimiento o costo por unidad, por ejemplo se sabe que el metro cuadrado de
construcción de una vivienda es de 300 USD, si se desea construir una vivienda de 200 m² se
puede establecer el costo en 60.000 USD; lo mismo puede aplicarse para estimar tiempo o
cualquier otro parámetro del proyecto, la precisión de esta estimación depende mucho de
la calidad de los parámetros que se tenga, sin embargo si lo aplicamos al software es muy
complicado contar con este tipo de información salvo entornos muy específicos.
• Estimación por tres valores: Este método de estimación utiliza una fórmula matemática para
determinar la duración o el costo de un proyecto, se la conoce también como estimación
Pert y se basa el cálculo de tres valores estimados para cada una de las actividades, estos
valores son:
mm Tiempo más probable (Tm): Este tiempo se lo obtiene en función de las características
de los recursos a los que se asignará la tarea, entre estas características podemos
hablar de su productividad, las expectativas realistas de su disponibilidad para realizar
el trabajo, de las dependencias de otras personas y de las eventuales interrupciones
del trabajo, también se puede considerar las fechas límite del proyecto.
mm Tiempo Optimista (To): Este tiempo se lo puede obtener considerando el mejor

escenario posible para el desarrollo del proyecto, considerar por ejemplo los recursos
más preparados, disponibilidad de tiempo suficiente, sin retrasos durante el desarrollo.
mm Tiempo Pesimista (Tp): Este se lo obtiene de considerar el peor escenario posible

para el desarrollo de las actividades, como por ejemplo la falta de experiencia de las
personas a cargo, falta de información, indisposición de los recursos asignados.
Como estrategia se puede optar por realizar el cálculo entre tres grupos de personas, así para los tiempos
más probables por ejemplo puede asignarse a un grupo que trabaje junto con el gerente de proyecto,
quienes tengan conocimiento del trabajo, de las características del personal que será asignado y de
las restricciones del proyecto; para el segundo equipo se puede considerar un equipo de personas
entusiasta con experiencia es ese tipo de proyectos asumiendo que no se presentarán complicaciones;
y el tercer grupo será un equipo de personas con poca o ninguna experiencia en ese tipo de actividades;
un poco pesimistas.
El siguiente paso es calcular el tiempo esperado (Te) a partir de esos 3 valores, aplicando la siguiente
fórmula Pert:
59
Esta es la fórmula menos utilizada en la cual se asume que los datos provienen de una distribución
triangular, y para el caso en que se trabaja con una distribución beta, que es la más comúnmente utilizada
fórmula sería la siguiente:
Ejemplo:
Retomando el ejercicio de la aplicación para el procesamiento de encuestas en línea, vamos a realizar

la estimación aplicando el método de estimación 3 puntos, para lo cual se ha considerado el tiempo
planteado inicialmente, y los datos de los tiempos pesimista y optimista se han calculado considerando
el peor y el mejor escenario posible respectivamente, estos datos se pueden apreciar en la tabla 3.4, a la
cual se le ha añadido la columna Te, que se ha obtenido aplicando la fórmula para distribuciones beta.
Tabla 3.4 Estimación de la duración de actividades utilizando el método de estimación 3 puntos.
Duración (Días)
Actividades
Tp Tm To Te
A. Identificar interesados y usuarios del sistema. 4 2 2 2,33
B. Preparar entrevistas y cuestionarios 5 3 2 3,17
C. Aplicar entrevistas 9 5 4 5,5
D. Aplicar cuestionarios 5 3 3 3,33
E. Elaborar informe de entrevistas y cuestionarios. 5 2 1 2,33
F. Identificar fuentes documentales de información. 6 3 1 3,17
G. Solicitar autorización de acceso a documentos. 5 2 2 2,5
H. Revisar información documental. 8 5 3 5,17
Elaborar informe de hallazgos y procedimientos
I. 4 2 1 2,17
encontrados.
Revisar informes de entrevistas, cuestionarios e
J. 5 2 2 2,5
información documental.
K. Definir formato de informe de requerimientos. 3 1 1 1,33
L. Identificar y clasificar requerimientos. 6 3 2 3,33
M. Describir requerimientos 12 5 2 5,67
N. Redactar informe de requerimientos. 7 3 1 3,33
O. Validar informe de requerimientos 8 2 1 2,83
Si analiza los datos, la columna de tiempo esperado (Te) tiende a semejarse a la columna de tiempo más
probable (Tm); sin embargo aunque esta situación se da, el rango de variación de datos es muy pequeño
y en rangos más amplios puede haber diferencias mayores. Dependiendo de la unidad de medida del
esfuerzo que utilice, estos datos pueden redondearse sobre todo si se trabaja con unidades como días,
sin embargo los efectos pueden ser muy grandes en el total del proyecto.
Otro aspecto que puede resultar valioso en este caso es el cálculo de la desviación
estándar y de la varianza, y pueden obtenerse aplicando las siguientes fórmulas, las cuales
pueden usarse para establecer un rango de variación de la estimación, concretamente
con la desviación estándar (S)
60
Como se lo había mencionado antes, este método puede resultar útil no solamente para estimar tiempo,
sino también para estimar costos, en cuyo caso los estimados en lugar de realizarse sobre el tiempo se
harían sobre el valor, pero esto puede resultar un poco más difícil ya que la noción de costo normalmente
la asociamos al costo hora de trabajo, sin embargo es preciso aclarar que esto no necesariamente es
cierto ya que para el desarrollo de una actividad se precisa no solo de la mano de obra sino de otros
recursos como materiales, equipamiento, servicios, etc.
3.4. Técnicas de estimación para la ingeniería del software
La Ingeniería del software desde su aparición ha intentado resolver el problema de la estimación y como
veremos estudiando el texto básico hay muchas variables y decisiones que se toman durante el transcurso
del proyecto que afectan al tiempo y al costo.
Es momento de leer el apartado 23.5 del texto básico, donde se abordará el problema
de la estimación para proyectos de desarrollo de software, el cual difiere mucho de
las estimaciones realizadas en otro tipo de proyectos, particularmente debido a su
naturaleza intangible.
Luego de revisar este apartado, seguramente se preguntará si es posible una aproximación cercana a los
proyectos de software, la respuesta como pudo apreciarlo depende de muchos factores, entre los cuales
se puede mencionar las herramientas de desarrollo utilizadas, la cantidad de código reutilizable, el nivel
de experiencia del equipo de desarrollo, etc.
Cuando el autor menciona los modelos basados en la experiencia, notará que en esta categoría caen
los modelos estudiados en el apartado 3.1 de la presente guía didáctica, sin embargo no es aconsejable
trabajar con una sola técnica de estimación, siempre resultará más conveniente combinar algunas de
ellas, especialmente con técnicas denominadas algorítmicas, cuyo principal método de cálculo es el uso
de parámetros en modelos matemáticos.
Las fórmulas de cálculo se basan en la determinación del esfuerzo que está asociado al tamaño del
producto con incidencia de la complejidad como factor modificador de estos métodos de cálculo, los
métodos más conocidos en esta línea son el modelo constructivo de costos, más conocido como
COCOMO por sus siglas en Inglés, propuesto por Bohem en los años 70, el modelo COCOMO II que surgió
como una variante del anterior para adaptarla a las nuevas tecnologías de desarrollo de software de la
década del 90 y el modelo de puntos de función que se fundamenta en identificar las características del
software en lugar de la forma de implementarlo y que actualmente tiene mucha aceptación.
Empiece estudiando la sección 23.5.1 donde se presenta una introducción al cálculo

algorítmico de costos.
61
Un elemento que tiene mucha incidencia al momento de realizar las estimaciones basadas en los
métodos algoritmos son las líneas de código, utilizadas como una métrica para determinar el tamaño del
producto, sin embargo en la actualidad las herramientas y técnicas de desarrollo de software dificultan
mucho su uso
Asegúrese de comprender esta sección del texto básico, antes de pasar a estudiar el siguiente modelo.
3.4.1. El modelo COCOMO II
El texto básico ofrece un muy buen desarrollo de este modelo, por lo que se deberá estudiarlo
detenidamente y complementarlo con la información adicional propuesta.
A continuación lea todo el apartado 23.5.2 del texto básico, realice una lectura pausada
y asegúrese de comprender como funciona el método de estimación.
Luego de estudiar el apartado indicado, notará que los modelos de estimación de software son
complejos, esto debido a la misma naturaleza del software que incluye factores como la complejidad, la
reutilización, el uso de herramientas generadoras de código, entre otras, y que en las versión original de
COCOMO no tenían incidencia, por lo que originalmente el método buscaba determinar el esfuerzo en
función de las líneas de código, sin embargo los factores antes mencionados no permiten que se pueda
trabajar con él; COCOMO II recoge estas variables y trata de resolverlas utilizando cuatro sub modelos,
los cuales pueden ser aplicados en distintas circunstancias.
Para complementar esta información se le recomienda descargar el documento que se encuentra en la

siguiente dirección http://alarcos.inf-cr.uclm.es/doc/pgsi/doc/teo/8/cocomo2-apuntes.pdf, el cual le
ayudará a aclarar algunas dudas en relación a COCOMO II. No obstante recuerde que siempre puede
acudir a su tutor para resolver estas inquietudes.
Cuando hablamos de estimación es importante recordar que los modelos nos ayudan a
determinar por un lado el esfuerzo que podemos entenderlo como la cantidad de horas/
hombre requeridas para desarrollar el producto y por otro el costo, sin embargo no nos
dicen nada de cuánto va a tardar, si queremos saber eso necesitamos calendarizar el
proyecto, esto es establecer las actividades, asignar recursos, establecer precedencias y
calcular los tiempos tal como se estudió en el apartado anterior.
3.4.2. Estimación por puntos de función
El modelo de estimación por puntos de función actualmente es uno de los más utilizados, debido a
que la estimación se realiza considerando parámetros independientes de la implementación, se centra
en identificar y contar las siguientes características del sistema clasificándolas de acuerdo la cantidad
de atributos que poseen de acuerdo a las siguientes categorías: entradas externas, salidas externas,
consultas externas, archivos lógicos internos y archivos de interfaz externos.
62
El proceso de estimación se los puede evidenciar en el diagrama de la figura 3.6.
Contar las
funciones de Determinar
Identificar el datos los puntos
alcance de de función Determinar
Identificar el Contar las no ajustados
la medición puntos de
tipo de funciones
y los límites Determinar función
cuenta transaccionales
de la el valor del ajustados
aplicación factor de
ajuste
Figura 3.6 Pasos para estimar con puntos de función18
1. Identificar el tipo de cuenta: Puesto que los proyectos pueden ser de desarrollo de una nueva
aplicación o de mantenimiento, en este paso se debe establecer a cuál de estas dos categorías
pertenece el proyecto.
2. Identificar el alcance de la medición: Consiste en establecer el alcance de la aplicación en función

del proceso de negocio que será beneficiado con el proyecto.
3. Contar las funciones de datos: En este paso se debe identificar y contar la capacidad de
almacenamiento de datos, en este punto identificamos dos tipos de funciones de datos:
• Archivos lógicos internos (ILF) que son archivos destinados a almacenar información de
transacciones de la aplicación.
• Archivos de interfaz externos (EIF) que se refiere a grupos de datos referenciados pero no
almacenados en la aplicación.
Cada uno de estos datos puede ubicarse en una de tres categorías de complejidad
establecidas como baja, media y alta en función del número de atributos que poseen los
archivos.
4. Contar las funciones transaccionales: Se refiere a la capacidad de aplicación de realizar

operaciones, estas capacidades se pueden clasificar en las siguientes categorías:
• Entradas externas (EI) que se refieren a proceso está destinado a mantener uno o más
archivos lógicos internos.
• Salidas externas (EO) que se refieren a las funcionalidades cuyo propósito es presentar
información al usuario mediante un proceso lógico diferente al de simplemente recuperar
los datos.
• Consultas externas (EQ), corresponden a procesos cuya finalidad principal es mostrarle

información al usuario.
18 Durán, S. (2003). Puntos por función. Una métrica estándar para establecer el tamaño del software. Recuperado de http://goo.
gl/53Iz2
63
Cada uno de estos debe ubicarse en una de las categorías de complejidad en media, baja y alta y
multiplicarse por un factor, de acuerdo a los datos de la tabla 3.5:
Tabla 3.5 Clasificación de la complejidad de las características del sistema en función del número de
atributos.
Clasificación de entradas y
consultas 1 – 4 atributos 5 – 15 atributos Más de 15 atributos
(EI – EQ)
0 a 1 archivo accedido Baja Baja Media
2 archivos accedidos Baja Media Alta
Más de 2 archivos accedidos Media Alta Alta
Clasificación de Salidas
1 – 5 atributos 6 – 19 atributos Más de 19 atributos
(EO)
0 a 1 archivo accedido Baja Baja Media
2 o 3 archivos accedidos Baja Media Alta
Más de 3 archivos accedidos Media Alta Alta
Archivos lógicos internos 1 – 19

20 -50 atributos Más de 50 atributos
(ILF) atributos
1 entidad o registro lógico Baja Baja Media
2 a 5 entidades o registros Baja Media Alta
lógicos
Más de 5 entidades o registros Media Alta Alta
lógicos
Archivos lógicos externos 1 – 19

20 -50 atributos Más de 50 atributos
(EIF) atributos
1 entidad o registro lógico Baja Baja Media
2 a 5 entidades o registros Baja Media Alta
lógicos
Más de 5 entidades o registros Media Alta Alta
lógicos
5. Determinar los puntos de función no ajustados: Consiste en sumar el número de componentes

de cada tipo conforme a la complejidad identificada en los parámetros anteriores, para lo cual se
puede usar la tabla 3.6, donde se colocan todos los valores identificados en cada categoría <v> y
se los multiplica por el factor expresado en la celda correspondiente.
64
Tabla 3.6 Matriz de cálculo de los puntos de función sin ajustar
Parámetro del Complejidad Complejidad Media Complejidad Alta Total

Sistema Baja
Entradas Externas <vEI bajos> *3 <vEI medias> *4 <vEI alta>*6 totalEI
(EI)
Salidas Externas <vEO bajos> *4 <vEO medias> *5 <vEO altas> *7 totalEO
(EO)
Consultas <vEQ bajos> *3 <vEQ medias> *4 <vEQ altas>*6 totalEQ
Externas (EQ)
Archivos lógicos <vILF bajos> *7 <vILF media> *10 <vILF altas>*15 totalILF
internos (ILF)
Archivos de <vEIF bajos>*5 <vEIF media> *7 <vEIF altas>*10 totalEIF
interfaz externos
(EIF)
PFSA
Luego de sumar los totales de cada fila, obtenemos los Puntos de Función Sin Ajustar (PFSA)
6. Determinar el valor del factor de ajuste (FA): Los factores de ajuste de complejidad, consideran
un total de 14 características generales del sistema los cuales se valoran en una escala de 0 a 5 en
función de los nivel de complejidad esperado en cada ítem, estos se muestran en la tabla 3.7
Tabla 3.7 Tabla de cálculo de factores de ajuste de complejidad (ACT)
Valor
Nro. Factor de complejidad
(0 – 5)
1 Comunicación de datos
2 Proceso Distribuido
3 Objetivos de rendimiento
4 Configuración operacional compartida
5 Tasa de transacciones
6 Entrada de datos en línea
7 Eficiencia con el usuario final
8 Actualizaciones en línea
9 Lógica de proceso interno compleja
10 Reusabilidad de código
11 Conversión e instalación contempladas
12 Facilidad de operación
13 Instalaciones múltiples
14 Facilidad de cambios
65
Luego se calcula el factor de ajuste utilizando la siguiente fórmula:
FA = 0.65 + (0.01*ACT)
7. Determinar los puntos de función ajustados: El cálculo de los puntos de función ajustados (PFA),
se obtiene simplemente multiplicando los puntos de función sin ajustar (PFSA) por el factor de
ajuste (FA)
PFA = PFSA * FA
Los parámetros indicados se basan en el estándar ISO/IEC 20926:2003, actualizados en el

estándar ISO/IEC 20926:2009, al igual que existe una norma para establecer los valores
de 0 a 5, de cada uno de los factores de complejidad. Por otro lado es preciso acotar
que el cálculo de los puntos de función por si solos no nos dicen mucho respecto de
cuánto cuesta o cuánto esfuerzo se requiere para desarrollar un producto de software,
este cálculo puede hacerse considerando un tiempo en horas de esfuerzo por punto de
función y luego asignar un valor por hora de trabajo.
Veamos ahora como podemos traducir los puntos de función obtenidos a horas hombre y a costos. Para
ello se puede usar unas equivalencias históricas o estandarizadas de horas por punto de función, como
se muestra en la tabla 3.8
Tabla 3.8 Equivalencias de puntos de función a líneas código y horas de esfuerzo
Esfuerzo
Entorno y lenguaje
Líneas de código por PF Hora por PF
Leguajes de segunda generación.
Ensambladores 300 20 a 30
C estándar
Lenguajes de tercera generación
100 10 a 20
Cobol
Lenguajes de cuarta generación,
20 5 a 10
herramientas visuales
Finalmente para obtener el esfuerzo (E) del proyecto en horas multiplicamos el número de PF por el
número de horas establecido de acuerdo a la tabla 3.8.
E = PFA * HorasPF
Este valor representa las horas requeridas, las cuales divididas para el número de personas que
participarán en el proyecto para 8 horas diarias y 20 días laborables de un mes pueden darnos una idea
del tiempo que puede tomar, así:
Tmeses = (E / Personas) / 8/20
Sin embargo en la práctica, sabemos que en los proyectos no trabaja una sola persona ni todas las
actividades se ejecutan en paralelo aunque hayan varias personas trabajando, por ello diremos que este
método de cálculo no suple a la calendarización, simplemente lo podemos usar para estimar el esfuerzo
y el costo de acuerdo al valor por hora de trabajo.
66
Respecto de los costos, podemos decir que no todos los participantes del proyecto ganan igual, por
ello puede ser necesario realizar algunos ajustes basados en experiencias pasadas, una sugerencia es
distribuir el 100% de los puntos de función en porcentajes cuyos valores pueden variar en función del
equipo de personas con el que se cuenta, su nivel de experiencia, su valor por hora de trabajo.
En el anexo 2 puede observar un ejemplo desarrollado para una aplicación pequeña de ventas de una
compañía que vende sus productos a través de un sistema de ventas directas con visita al cliente y
recomendaciones de quienes ya adquirieron sus productos, en ella se ha establecido todos los parámetros
antes indicados para realizar la estimación correspondiente.
Actividad recomendada.
Existen otros métodos de estimación que se pueden usar, entre ellos podemos mencionar
el método Wide Band Delphi, estimación para casos de uso, estimación para proyectos
orientado a objetos entre otros, por lo que se le sugiere investigar otras técnicas de
estimación. Investgue algunas de ellas y trate de aplicarlas al ejercicio del sistema de encustas o al de la
tienda del anexo 2, luego comare los resultados.
67
Autoevaluación 3
Una vez concluido el estudio de la planificación de proyectos, con toda seguridad hubieron
temas que le presentaron dificultades, antes de desarrollar la autoevaluación es recomendable
que haya resuelto sus dudas. Si esto lo ha cumplido, entonces es momento de proceder al
desarrollo de la presente autoevaluación.
Lea detenidamente cada una de las preguntas y seleccione la alternativa correcta, en algunos casos
deberá desarrollar la solución al problema planteado para encontrarla.
1. Una de las dificultades más grandes que puede afrontar un equipo de proyecto integrado por
personas de fuera de la organización es:
a. El costo
b. La fuga de la experiencia adquirida
c. La sobrecarga de actividades
2. Los riesgos de un proyecto deben atacarse en función de:
a. Su nivel probabilidad
b. Su nivel impacto
c. Su la combinación de la probabilidad y el impacto
3. ¿Puede calendarizarse un proyecto teniendo únicamente la lista de actividades? Escoja la mejor

alternativa.
a. Si se puede debido a que un cronograma es básicamente una lista de actividades

b. No porque el cronograma es resultado de un conjunto de datos como actividades, recursos,
secuencias, hitos y restricciones
c. Sí, porque los detalles se agregan durante el desarrollo del cronograma
4. ¿Cuál de las siguientes herramientas permite una mejor visualización de la dependencia entre
actividades?
a. El diagrama de red
b. El diagrama de Gantt
c. El calendario de recursos
68
5. ¿Qué ventajas tiene el diagrama de Gantt sobre el diagrama de red?
a. Permite una mejor visualización de la información del cronograma

b. Es una versión resumida del cronograma
c. Oculta información innecesaria
d. ¿Cuál de las siguientes técnicas de estimación utiliza índices de rendimiento para establecer
los valores posibles?
6. ¿Cuál de las siguientes técnicas de estimación utiliza como base índices de rendimiento para el
cálculo de costos o de tiempo?
a. Estimación análoga
b. Estimación paramétrica
c. Estimación por 3 valores
7. Si se determina que el tiempo optimista (To) para desarrollar una actividad es de 22 días, el
tiempo pesimista (Tp) es de 30 días y el tiempo más probable (Tm) es de 25 días, y asumiendo
una distribución beta, qué tiempo debería considerar el gerente de proyecto como estimado para
dicha actividad?
a. 12.83 días
b. 23,88 días
c. 25,33 días
8. En el modelo de estimación de costos COCOMO II, respecto de la reutilización de código, ¿por qué
se considera que el esfuerzo requerido para reutilizar el código caja negra es cero?
a. Porque no se necesita comprenderlo para utilizarlo

b. Porque se necesita comprenderlo para utilizarlo
c. Porque el esfuerzo requerido se anula con las ventajas que se obtiene al reutilizarlo
9. Respecto de la estimación basada en los puntos de función al valorar las entradas y consultas ¿en
qué casos se considera que una de estas presenta complejidad alta?
a. Cuando se accede a 0 ó 1 archivos y se maneja más de 15 atributos

b. Cuando se accede a más de dos archivos y maneja de 5 a 15 atributos
c. Cuando accede a 2 archivos y maneja entre 5 y 15 atributos
10. Se ha estimado que una aplicación comprende 120 puntos de función y la misma se desarrollará
en lenguaje C, ¿cuál es la estimación de esfuerzo más cercana para dicha aplicación?
a. 960 horas
b. 1800 horas
c. 3000 horas
69
Guía didáctica: Ingeniería de Software SEGUNDO BIMESTRE
SEGUNDO BIMESTRE
6.5. Competencias genéricas
Trabajo en equipo II: Contribuye en la consolidación y desarrollo del equipo, favoreciendo la

comunicación, el reparto equilibrado de tareas, el clima interno y la cohesión.
mm Actúa constructivamente para afrontar los conflictos del equipo.
70
6.6. Planificación para el trabajo del alumno
71
COMPETENCIAS
COMPETENCIAS CONTENIDOS CRONOGRAMA
ESPECIFICAS DEL
ESPECIFICAS DE ACTIVIDADES DE APRENDIZAJE INDICADORES DE APRENDIZAJE ORIENTATIVO (Tiempo
COMPONENTE (Unidades/Tema)
TITULACIÓN estimado)
EDUCATIVO
Describe modelos de Unidad 4: Gestión de la • Leer la unidad 4 de la guía • Comprende la importancia Semana 1 y 2
aseguramiento de calidad del software. didáctica, capítulo 24 del de los estándares de
8 horas de autoestudio
calidad aplicables a texto básico y capítulo 7 del aseguramiento y control de
4.1. Calidad de software
proyectos de ingeniería Swebok. calidad en proyectos de 8 horas de interacción
de software 4.2. Estándares del desarrollo de software.
software • Desarrollar las
autoevaluaciones
4.3. Revisiones e
inspecciones • Desarrollar actividades de
interacción en el EVA.
4.4. Medición y métricas
del software • Desarrollar la evaluación a
Construir modelos y
especificaciones de
objetiva.
software que permitan
validar un producto Establece sistemas de Unidad 5: Gestión de • Leer la unidad 5 de la guía • Comprende los procesos y Semana 3 y 4
previo a su control de versiones y cambios en requerimientos didáctica, capítulo 25 del procedimientos implicados
implementación. administración de de software. texto básico y capítulo 7 del en la gestión del cambio en
cambios para SWEBOK. el software. 8 horas de interacción
5.1. Administración del
ambientes de
cambio • Desarrollar las actividades • Conoce las políticas, procesos
desarrollo y
recomendadas y y herramientas para
producción. 5.2. Gestión de versiones
autoevaluaciones de la guía administrar las relaciones
5.3. Construcción del didáctica. entre la gestión de versión y
sistema la construcción de un
• Desarrollar la evaluación a
5.4. Gestión de entregas sistema.
de software objetiva y literal 1 y 2 de la
parte de ensayo
SEGUNDO BIMESTRE
COMPETENCIAS
COMPETENCIAS CONTENIDOS CRONOGRAMA
ESPECIFICAS DEL
ESPECIFICAS DE ACTIVIDADES DE APRENDIZAJE INDICADORES DE APRENDIZAJE ORIENTATIVO (Tiempo
72
COMPONENTE (Unidades/Tema)
TITULACIÓN estimado)
EDUCATIVO
Unidad 6: Mejora de • Leer la unidad 6 de la guía • Entiende los principios de la Semana 5 y 6
procesos de software. didáctica, capítulo 26 del mejora de procesos de
texto básico y capítulo 12 del software.
6.1. El proceso de MPS
SWEBOK. 8 horas de interacción
Elaborar soluciones Identifica 6.2. Evaluación y mejora • Relaciona los procesos de
alternativas de TIC para la oportunidades de de procesos software • Desarrollar las actividades desarrollo con estándares de
mejora de procesos mejora de procesos de recomendadas y mejora de procesos.
desarrollo de software 6.3. CMMI autoevaluaciones del a guía
empresariales.
de acuerdo al modelo didáctica.
CMMI
• Desarrollar la evaluación a
objetiva y literal 3 de la parte

de ensayo
Unidad 4 a la 6 • Revisar los contenidos como Semana 7 y 8
preparación para la
evaluación presencial.
8 horas de interacción
SEGUNDO BIMESTRE
6.7. Orientaciones específicas para el aprendizaje por competencias
UNIDAD 4. GESTION DE LA CALIDAD DEL SOFTWARE
Continuando con la materia, ponemos a disposición la presente unidad que tiene relación con los
conceptos de calidad del software, haremos un repaso general de los principales aspectos relacionados
con la calidad, puesto que de acuerdo a la malla curricular, es en otro componente educativo que se
analizan los temas al detalle.
Empecemos indicando que desde la década de los 60, se han dedicado grandes esfuerzos a tratar
el problema de la calidad con el afán de lograr que los proyectos en general se desarrollen de forma
apropiada. Por lo que durante años los autores han definido a la “calidad”, desde diferentes puntos de
vista y criterios.
En el (Swebok, 2004), se indica que el ingeniero de software debería entender el significado subyacente
de los conceptos, las características de calidad, su relevancia en el desarrollo y mantenimiento del
software.
Tal es así que, (Piattini, García, & Caballero, 2007) definen a la calidad como “Conjunto de propiedades o
características de un producto o servicio que le confieren aptitud para satisfacer unas necesidades
expresadas o implícitas”.
Estimado estudiante, es hora de ir al texto básico a leer la parte introductoria del

capítulo 24, dónde se indica la importancia relacionada con las actividades de la gestión
de la calidad. Observe y analice sobre los intereses que tiene la gestión de la calidad del
software para los sistemas software.
Una vez realizada la lectura, continuemos analizando y profundizando ciertos temas adicionales respecto
a la calidad.
De los conceptos que se han establecido por los gurús de la calidad, se puede destacar que la calidad
es multidimensional (Funcionalidad, Oportunidad y Coste), y que se presenta de forma transparente
cuando esta presente pero resulta fácilmente reconocible cuando está ausente, ante esta situación
(Garvin, 1984) propone las cinco “vistas” de la calidad:
• Vista trascendental.
• Vista de usuario.
• Vista de fabricante.
• Vista de producto.
• Vista basada en valor.
73
De igual manera hay que tener en cuenta que la calidad puede tener varios orígenes, tal como se indica
en la figura 4.1.
En definitiva, la gestión de la calidad requiere que estos componentes coincidan lo mas posible; ya que
todo lo que se encuentre fuera de dicha coincidencia será motivo de insatisfacción y/o gasto inapropiado.
Calidad de la
infraestructura
Calidad del Calidad de la

software gestión
Calidad de
Calidad de SI la empresa
Calidad de la Calidad del

información servicio
Calidad de los
Calidad del procesos de
personal negocio
soportados por SI
Figura 4.1: Orígenes de la calidad. (Piattini, García, & Caballero, 2007)
Es necesario hacer una diferencia entre lo que es “Aseguramiento de la calidad” (QA) y “Control de calidad”
(QC), ya que se tiende a confundir. Al aseguramiento de la calidad, se la define como el esfuerzo para
planear, organizar, dirigir y controlar la calidad en un sistema de producción cuyo objetivo es el de brindar
al cliente un producto con un nivel de calidad adecuada. Al control de calidad, se lo relaciona con todos
los mecanismos, acciones y herramientas para detectar errores en los sistemas. Es decir QA, es proactivo
(trata sobre los procesos y como prevenir defectos, por ejemplo: definición de procesos, entrenamiento,
auditorías, etc.), mientras que QC es reactivo (trata sobre los productos y como encontrar defectos, por
ejemplo: testing, revisiones por pares, inspecciones, etc.).
Se recomienda que los miembros de un equipo de QA no realicen actividades concernientes al equipo

de desarrollo para que su perspectiva del software sea abalizada de forma objetiva, sin influencias y
compromisos de cualquier índole. Esto depende mucho de las organizaciones en cuanto a tamaño del
equipo destinado a realizar estas actividades, ya que normalmente en empresas pequeñas puede que
algunos integrantes estén relacionados con actividades de desarrollo y calidad, lo cual no es lo adecuado.
Observando y analizando la figura 24.1, del texto básico claramente se pueden identificar ciertos
componentes que son utilizados por el proceso de gestión de calidad para verificar los entregables del
proceso de desarrollo de software. Recalcar también que los equipos de desarrollo están vinculados en
cierta medida con los equipos de control de calidad y los planes de calidad deben ser lo suficientemente
claros que permitan realizar los controles de forma adecuada.
74
4.1. Calidad del software
Desde años atrás varios son los informes donde se hace referencia a los desastres y fallos que el software
puede llegar a causar en las organizaciones, es así que el Standish Group, mediante sus informes recopila
información sobre las fallas en los proyectos y precisamente nos muestra que por ejemplo, en el 2011
solamente el 37% de todos los proyectos terminan con éxito, esto nos conduce a enfocar los esfuerzos
en elementos fundamentales sobre la calidad de los proyectos de software. En la tabla 4.1, se indican los
porcentajes de los proyectos terminados con éxito, deficiencias y fallas en determinados años.
Tabla 4.1: Situación de los proyectos de software.
Año Éxito(%) Deficiencias(%) Fallas(%)

1994 16 53 31
1996 27 33 40
1998 26 46 28
2000 28 49 23
2002 34 51 15
2004 29 53 18
2006 35 46 19
2009 32 44 24
2011 37 42 21
Ante esta situación varios autores se han preocupado sobre la definición de la “Calidad del software”, a
continuación se recogen dos conceptos que sería importante analizarlos de manera más detallada.
• (Pressman, 2010), define a la calidad del software como “Proceso eficaz de software que se
aplica de manera que crea un producto útil que proporciona valor medible a quienes lo
producen y a quienes lo utilizan.
• De igual manera en el IEEE Standard Glossary of Software Engineering Terminology, se

define a la calidad del software como “el grado con el que un sistema, componente o proceso
cumple los requerimientos especificados y las necesidades o expectativas del cliente o
usuario”.
Estimado estudiante, revise el tema “24.1 Calidad del software”, del texto básico, de tal
manera que pueda establecer los criterios de la calidad desde el punto de vista de los
procesos de desarrollo de software como de la gestión.
Reflexione sobre las preguntas relacionadas con la calidad del software (Apartado 24.1), que se indican
en el texto básico. Estas preguntas no se pueden responder si no se tiene los argumentos necesarios por
parte del equipo de gestión de calidad, ya que son los responsables de realizar las tareas para decidir si
el producto entra o no en funcionamiento.
Recuerde que la calidad de una aplicación se mide en función de sus atributos de calidad, que no son
otra cosa que las cualidades o propiedades de calidad que la aplicación debe satisfacer. Para poder medir
estos atributos durante la verificación, éstos pueden estar expresados de forma cuantitativa y cualitativa.
75
En (Piattini, García, & Caballero, 2007), se indica que la calidad de una empresa depende de la calidad de
sus procesos de negocio soportados por el sistema de información, así como la propia calidad de este.
En la figura 4.2, se indican las dimensiones de calidad de los sistemas de información.
Calidad
programada
Calidad GESTION DE LA
programada CALIDAD
Calidad
esperada
Calidad Calidad
realizada necesaria
Calidad Calidad
realizada necesaria
Figura 4.2: Dimensiones de calidad de SI. (Piattini, García, & Caballero, 2007)
El (IEEE Computer Society, 2004),especifica un desglose de los temas de calidad del software que
repercuten en los procesos de ciclo de vida del software, estos son:
• Fundamentos de la calidad del software

• Procesos de gestión de la calidad del software
• Consideraciones prácticas.
En la figura 4.3 se indica el desglose de los temas de calidad del software.
Fundamentos de la calidad del software
Los conceptos de calidad enfocados a la ingeniería del software permite que existan los acuerdos
necesarios sobre las exigencias de calidad. El ingeniero de software entiende y esta consiente de la
calidad en el desarrollo o mantenimiento del software. De tal forma que se esta consiente que son
los requerimientos de software los que definen las características de calidad que se requiere de ese
producto.
Procesos de gestión de la calidad del software
Como se ha indicado en los apartados anteriores, la gestión de la calidad del software gira en torno a
procesos de software, producto y recursos, que permiten definir:
• Procesos con sus respectivos propietarios y requerimientos.

• Medidas del proceso y sus correspondientes salidas.
• Canales de retroalimentación.
76
Las actividades del proceso de gestión de calidad del software permiten por un lado encontrar defectos
directamente mientras que otras actividades indican donde pueden resultar valiosas mas revisiones.
Calidad del
software
Fundamentos de calidad Consideraciones Procesos de gestión de

del software prácticas la calidad del software
Ingeniería del software, Aseguramiento de la Requerimientos de calidad

cultura y ética calidad del software del aplicaciones
Valor y coste de la calidad Verificación y validación Caracterización de defectos
Modelos y características Técnicas de gestión de

Revisiones y auditorias
de calidad calidad del software
Aseguramiento de la
Mejora de calidad
calidad del software
Figura 4.3: Desglose de los temas de Calidad del Software. (IEEE Computer Society, 2004)
Consideraciones prácticas
Tiene que ver con ciertas actividades relacionadas a la gestión de la calidad del software, herramientas y
técnicas que ayudan a un mejor control de los productos software.
Un sistema es de calidad no solamente si está en funcionamiento, sino que la calidad se refleja cuando
satisface ciertos atributos no funcionales del software. En la figura 24.2 del texto básico se listan los
atributos definidos por Boehm (en 1978). Adicionalmente en la tabla 4.2, se indican los diferentes
atributos de la calidad definidos por los gurús de la calidad.
Tabla 4.2: Atributos de calidad de los proyectos de software (Pressman, 2010).
Dimensiones de calidad de Factores de la calidad de McCall Factores de la calidad ISO 9126

Garvin
• Calidad del desempeño. • Corrección. • Funcionalidad.
• Calidad de las características. • Confiabilidad. • Confiabilidad.
• Confiabilidad. • Eficiencia. • Usabilidad.
• Conformidad. • Integridad. • Eficiencia.
• Durabilidad. • Usabilidad. • Facilidad de recibir
mantenimiento.
• Servicio. • Facilidad de recibir
mantenimiento. • Portabilidad.
• Estética.
• Flexibilidad.
• Percepción
• Susceptibilidad de someterse a
pruebas.
• Portabilidad.
• Reusabilidad.
• Interoperabilidad.
77
(Pressman, 2010) concluye que muchos de estos atributos son subjetivos, ya que se requiere de elementos
indirectos para poder determinarlos, sin embargo la evaluación de la calidad de una aplicación por
medio de estos atributos permite tener un indicio adecuado de ella (calidad).
Realice el ejercicio 24.1 del texto básico y luego comparta su análisis con sus compañeros y
el tutor mediante la herramienta de interacción EVA.
4.2. Estándares del software
Tanto para el proceso de desarrollo de software como para el producto software se deben definir o
seleccionar estándares que deberán ser aplicados apoyandose mediante el uso de herramientas y
métodos, que ayuden a obtener una “calidad” adecuada del software.
Estimado estudiante, revise el tema “24.2 Estándares de software”, del texto básico,
y ponga especial énfasis en la importancia de su definición y aplicación, como en la
clasificación de los mismos.
Cabe indicar que un elemento clave con respecto al proyecto son toda la documentación que se produce
y que debe estar basada en ciertos estándares para lograr un adecuado orden y entendimiento. En http://
softwareengineering-9.com/Web/QualityMan/docstandards.html se indica tres tipos de estándares de
documentación.
• Normas para documentar procesos.

• Normas de documento.
• Normas de intercambio de documentos
Figura 4.4: Modelo de sistema de gestión de calidad basado en procesos. (ISO 9001:2008)
78
Los estándares son definidos tanto para el proceso como para el producto. Muchos de los estándares se
han desarrollado de forma general con el fin de lograr la calidad en los productos. En el texto básico se
hace referencia al marco de estándares ISO 9001, adicionalmente en (ISO 9001:2008) se indica que ésta
norma promueve el acogimiento de un enfoque basado en procesos cuando se desarrolla, implementa
y mejora la eficacia de un sistema de gestión de la calidad, para aumentar la satisfacción del cliente
mediante el cumplimiento de sus requisitos. En la figura 4.4. se indica un modelo de un sistema de
gestión de calidad basado en procesos.
Consulte en la web sobre el estándar ISO 9001:2008, y elabore un mapa conceptual de las
partes que lo conforman.
Resuelva el ejercicio 24.2 del texto básico y luego comparta su análisis con sus compañeros
y el tutor mediante la herramienta de interacción EVA.
4.3. Revisiones e inspecciones
Tanto las revisiones como las inspecciones se realizan como parte de las actividades de QA, cuyo objetivo
es analizar la calidad de los entregables del proyecto.
Estimado estudiante, revise el tema “24.3 Revisiones e Inspecciones”, del texto básico,
ponga atención al proceso de revisión y a la forma en que se realiza las inspecciones.
Una vez analizado el tema, vamos a resumir la importancia de las revisiones e inspecciones.
4.3.1. Revisiones
Las revisiones de software sirven para validar la calidad y/o el estado de un producto. El producto a
revisar puede ser un documento, un módulo, un prototipo, etc. Existen distintos tipos de revisiones.
Cada una especializada en un determinado producto o escenario. Las revisiones ayudan a encontrar
falencias, y a identificar riesgos, que serían difíciles de encontrar de otra manera.
Considere:
• Leer y seguir el manual sobre “Protocolos de comunicación entre miembros del proyecto”
• Revisar el trabajo, no al autor.
• Buscar defectos, no formas de implementar sus ideas.
• Seguir las instrucciones del moderador, y los tiempos asignados a cada actividad.
• Que las críticas destructivas, no benefician a nadie.
Asuntos a Revisar (entre pares):
• Correctitud.
• Variables en desuso.
• Funciones omitidas.
• Práctica de programación pobre.
• Redundancia.
79
• Adhesión al estándar de escritura de código.

• Límite de tiempo: 60 min. (por sesión)
Auditorías
• Revisión formal, su objetivo es:

mm Evaluar el nivel de conformidad con estándares y planes.
mm Controlar que se han hecho los cambios programados.
mm Auditar el proyecto de forma interna y/o externa.
• El auditor es el responsable de verificar el proceso de auditoría, y las acciones derivadas de

ésta.
• Límite de tiempo: 60 min. (por sesión)
Inspecciones.
Las inspecciones de software:
• Es una técnica muy efectiva para descubrir errores.

• No se requiere que el sistema este en ejecución por lo que pueden ser aplicadas a cualquier
representación del sistema (requerimientos, diseño, datos de prueba, etc.).
• Varios y diferentes defectos pueden ser descubiertos en una sola inspección.
• Se resalta la reutilización y el conocimiento de programación de modo que los revisores
están preparados para ver aquellos tipos de errores que aparecen comúnmente.
• Las inspecciones y pruebas son complementarias y no técnicas de verificación opuestas, por
lo que deberían ser utilizadas en conjunto durante el proceso de verificación y validación.
• Las inspecciones pueden chequear conformidad con una especificación, pero no
conformidad con los requerimientos reales del cliente.
• Las inspecciones no pueden chequear características funcionales, como es: rendimiento,
usabilidad, etc.
• Las inspecciones sobrecargan el costo inicial pero producen ahorros cuando los equipos
adquieren experiencia en su utilización.
• Las inspecciones de programa, se encargan de detectar defectos, que consisten en: errores
lógicos, anomalías en el código o el no cumplimiento de estándares.
80
La inspección está
prevista por el
Planificación moderador.
El autor describe los

Panorama antecedentes del
general producto de trabajo.
Cada inspector examina el

producto de trabajo para
Preparación identificar posibles defectos
El lector da conocer por

Reunión de cada inspector cada uno de
Inspección los defectos encontrados.
El autor realiza cambios en el producto

Re- del trabajo de acuerdo con los planes
elaboración de acción de la reunión de inspección.
Los cambios efectuados por el autor

son revisados para asegurarse de
Seguimiento
que todo está correcto.
Figura 4.5: El proceso de inspección (Pressman, 2010)
Funciones de inspección
Durante la inspección se utilizan los siguientes roles.
• Autor: La persona que creó el producto del trabajo se está inspeccionando.

• Moderador: Es el líder de la inspección. El moderador de los planes de inspección y lo
coordina.
• Lector: La persona que lee a través de los documentos de uno en uno. Los otros inspectores
señalan los defectos.
• Grabador/Scribe: La persona que documenta los defectos que se encuentren durante la
inspección.
• Inspector: la persona que examina el producto de trabajo para identificar posibles defectos.
Amplificación y eliminación de defectos
En (Pressman, 2010) se sugiere usar un modelo de ampliación de defectos para ilustrar la generación y
detección de errores durante los pasos de diseño preliminar, diseño detallado y codificación del proceso
de ingeniería del software, tal como se indica en la figura 4.6.
81
Diseño preliminar
0 Diseño de detalle
15 8
0 0% 8 Código/prueba unitaria
22
___ 14
7
15 x = 1.5 50% 14
8
___ 29
____
25 x=3 50%
Prueba de integración
20
Prueba de validación
14
___
0 50% Prueba del sistema
7
___
0 0 50%
3
___
0 0 50%
Figura 4.6: Amplificación y eliminación de defectos.
Como se puede ver en la Figura 4.6, en el “Diseño de detalle”, vienen 15 errores de la etapa anterior, de
los cuales 7 afectan directamente por lo tanto éstos errores se amplifican a 10.5 (7 * 1.5), en total se tiene
44 errores en esta etapa pero al dar solución o corregir el 50% de los mismos a la siguiente etapa pasan
22 errores.
4.4. Medición y métricas del software
Las métricas del software se relacionan con una amplia gama de mediciones para el producto software.
La medición se puede aplicar al proceso de desarrollo de software con la intensión de mejorarlo de
forma continua.
Figura 4.5: Métricas de software
En un proyecto del software la medición se utiliza para: ayudar en la estimación, el control de calidad, la
evaluación de productividad y el control de proyectos. El ingeniero de software puede utilizar la medición
para evaluar la calidad de los resultados de trabajos técnicos y para la toma de decisiones táctica a
medida que el proyecto evoluciona.
Estimado estudiante, revise el tema “24.4 Medición y métricas de software”, del texto
básico.
82
Tenga presente que de acuerdo al texto básico, en éste apartado nos enfocaremos en las métricas de
predicción.
Medir el software es una actividad compleja. Toda magnitud física se puede medir, pero el software
requiere de obtener resultados de actividades intelectuales, también es cierto que de cara a la ingeniería
del software es bastante difícil ponerse de acuerdo en las medidas y como evaluarlas. Por lo que es
necesario disponer de diferentes unidades de medida que puedan ser útiles para caracterizar varias
funcionalidades del software que se requiere implementar, como es: el tamaño del proyecto, la evaluación
de la calidad y la factibilidad, etc.
Estimado estudiante para ampliar las métricas relacionadas al producto, vamos a realizar ejemplos de
dos métricas.
1. Métricas de diseño arquitectónico
Es una métrica del modelo de diseño, que se enfoca en las características de la arquitectura del programa.
A continuación se indica el un ejemplo.
Se ha establecido que un sistema tiene 1250 módulos, de los cuales 102 módulos realizan
funciones de control y coordinación y 485 cuya función dependen del procesamiento
previo. El sistema procesa aproximadamente 230 objetos de datos, cada uno de los
cuales tiene un promedio de cuatro atributos. Existen 142 ítems de base de datos únicos
y 92 de diferentes segmentos de base de datos. Finalmente, 605 módulos tienen puntos
de entrada y salida únicos. Calcule el ICED para este sistema.
El ICED, significa “índice de calidad de la estructura del diseño”, que se deriva de la información obtenida
de los diseños de datos y arquitectónico (elaborado por la comandancia de los sistemas de la fuerza
aérea estadounidense). Se requiere los siguientes datos:
Descripción Valor
Número total de módulos definidos en la arquitectura del programa. S1 1250
Número de módulos cuya función correcta depende de la fuente de S2 102
entrada de datos o que produce los datos que se van a utilizar en alguna
otra parte.
Número de módulos cuya función correcta depende del procesamiento S3 485
previo
Número de ítems de base de datos. S4 920
Número total de ítems de base de datos únicos. S5 142
Número de segmentos de base de datos. S6 92
Número de módulos con una sola entrada y salida. S7 605
83
Ahora es necesario calcular los siguientes valores intermedios, de acuerdo a lo siguiente:
Fórmula Valor
D1 = 1 ó 2 D1 = 1
S2 D2 = 0,92
D2 = 1 -
S1
S3 D3 = 0,61
D3 = 1 -
S1
S5 D4 = 0,85
D4 = 1 -
S4
S6 D5 = 0,90
D5 = 1 -
S4
S7
D6 = 1 - D6 = 0,52
S1
El ICED se calcula de aplicando la fórmula:
ICED = ∑ wi D i
wi es el peso relativo de importancia de cada uno de los valores intermedios. Vamos a asumir que todos los Di,
tienen el mismo peso, por lo que asumimos que wi = 0,167. De tal manera que:
ICED = 0,80
Los valores que comprenden este índice van desde 0 hasta 1. Si el sistema en cuestión (análisis), tiene
una buena estructura de diseño, el resultado se aproximará al valor 1, si la estructura es mala se acercará
a 0. Es una métrica muy objetiva y que se puede medir directamente, lo cual dice mucho a su favor.
2. Métricas de mantenimiento
En (Pressman, 2010) se indica el “índice de madurez de software” (IMS), que permite proporcionar cierta
información de estabilidad del producto software. Para aclarar vamos a resolver el siguiente caso:
Dado un sistema que tiene 940 módulos. El cual en la última liberación se realizó el cambio
de 90 de dichos módulos, además, se agregaron 40 nuevos módulos y se removieron 12
módulos antiguos. Calcular el índice de madurez para el sistema.
84
Es necesario la siguiente información:
Descripción Valor
Número de módulos en la liberación actual MT 940
Número de módulos en la liberación actual que cambiaron Fc 90
Número de módulos en la liberación actual que se agregaron Fa 40
Número de módulos en la liberación anterior que se borraron en Fd 12
la liberación actual.
El índice de madurez del software se calcula de la forma siguiente:
M T (Fa + Fc + Fd )
IMS = = 0,85
MT
Conforme el IMS tiende a 1,0 el producto comienza a estabilizarse.
85
Autoevaluación 4
Hemos finalizado la unidad, por lo que es necesario realizar la correspondiente autoevaluación

para determinar el conocimiento asimilado. Se recomienda resolver lo propuesto ya que es
posible que haya algunos temas que no se han comprendido a plenitud.
1. Los estándares de producto incluyen:
a. Estándares de documentos, documentación y de codificación.

b. Los procesos
c. Las normas
2. El proceso para poner en producción determinada versión del producto, es un estándar de:
a. Producto
b. Proceso
c. Documentación
3. El formato de encabezado de cada método implementado, es un estándar de:
a. Producto
b. Proceso
c. Documentación
4. El propósito de las revisiones e inspecciones es:
a. Valorar el rendimiento de los miembros del equipo

b. Socializar el desarrollo con los demás miembros del equipo
c. Mejorar la calidad del software
5. En la fase de “Actividades previas a la revisión”, del proceso de revisión entre las actividades que se
desarrollan tenemos:
a. Se analizan los conflictos y problemas surgidos

b. Establecer un equipo de revisión, obtener y distribuir los documentos a revisar, entre otras.
c. Se registran todas las acciones y decisiones que se decidan llevar a cabo
86
6. El número de mensajes de confirmación o error que presenta un producto, es un atributo:
a. Interno
b. Externo
c. Interno y Externo
7. La Administración de la configuración en el ISO 9001, es un proceso:
a. De entrega de producto
b. De soporte
c. De mantenimiento
8. El tamaño del código, es una métrica del tipo:
a. Estática
b. Dinámica
c. Estática y Dinámica
9. Las métricas que ayudan a estimar el esfuerzo requerido para hacer cambios en el software, se las
conoce como:
a. Predicción
b. Control
c. Verificación
10. Para el caso de las métricas de mantenimiento, asumiendo que el número de módulos de proceso
actual es de 200 y los demás parámetros son los que se indican en el ejercicio, del apartado 4.4
entonces el IMS tiende a indicarnos sobre un producto.
a. Estable
b. Inestable
c. Completo
d. Coherente
87
UNIDAD 5. ADMINISTRACIÓN DE LA CONFIGURACIÓN
Las aplicaciones de software, más que cualquier otro producto están sujetas a infinidad de cambios,
los cuales se deben a la corrección de errores, adaptación a múltiples plataformas, atención a nuevas
necesidades entre otras múltiples razones. Una misma aplicación de software puede requerir
configuraciones diferentes o modificaciones en distintas organizaciones.
Y esto naturalmente representa un gran reto para las empresas que se dedican al desarrollo de software
puesto que un proceso desordenado puede llevarlas al caos.
Para prevenir los problemas que se pudieran generar, la Ingeniería de Software ha adoptado la disciplina
denominada gestión de la configuración, la cual fue desarrollada originalmente por la Fuerza Aérea de
las Estados Unidos (USAF) en el año 1950 para materiales de hardware, actualmente esta disciplina ha
sido adoptada por todas las industrias.
En lo relacionado a la administración de la configuración para sistemas e Ingeniería de software el

estándar actual es el IEEE Std 828™-2012.
Los procesos de desarrollo más completos como el Proceso Unificado de Desarrollo RUP, la consideran
como una de sus disciplinas y lo que buscan es mantener un control exhaustivo de cambios, versiones
del sistema y la liberación de versiones pero para ello deben apoyarse de aplicaciones de software ya
que hacerlo manualmente sería muy tedioso.
El cuerpo de conocimiento de la Ingeniería de Software Computer Society (2004) define a la gestión de

la configuración como “La disciplina de identificar la configuración de un sistema en distintos puntos
de tiempo con el propósito de controlar sistemáticamente los cambios a la configuración, y mantener
la integridad y la rastreabilidad de la configuración a lo largo del ciclo de vida del sistema” y el mismo
texto cita la definición del estándar (IEEE610.12-900) que dice que la Gestión de la Configuración es
“Una disciplina que aplica dirección y vigilancia técnica y administrativa para: identificar y documentar
las características funcionales y físicas de un ítem de configuración, controlar los cambios a estas
características, registrar y reportar el procesamiento de cambios y el estatus de implementación y
verificar la conformidad con los requerimientos”19
Para el desarrollo de la presente capítulo, usaremos como base el capítulo 25 del texto básico y como
referencia el capítulo 7 del SWEBOK (2004).
Para comenzar, se le invita a realizar una lectura comprensiva de la introducción al

capítulo 25 del texto básico.
Luego de revisar esta introducción es momento propicio para reflexionar sobre algunas cuestiones
respecto de la gestión de la configuración, para lo cual se le pide que conteste a las siguientes preguntas:
• ¿Por qué se necesita la disciplina de administración de la configuración en la Ingeniería de

Software?
• ¿Cuáles son los principales problemas relacionados con la gestión de la configuración que
podríamos enfrentar si no se organiza estos procesos?
19 Citado por IEEE Computer Society (2004), pp 7-1
88
• ¿Para qué tipo de proyectos es necesaria la gestión de la configuración?
• ¿Qué aspectos contempla la gestión de la configuración?
• ¿Existen herramientas que ayuden con este proceso?
• ¿Qué estándares soportan la administración de la configuración?
• ¿Tiene algo que ver la gestión de la configuración con temas de calidad del software?
Mientras responde estas preguntas seguramente pensará que es un tema que no muchas de las veces se tiene
en cuenta en los equipos de desarrollo de software, aunque es muy probable que algunas de las actividades
relacionadas con esta disciplina si se consideren, sobre todo la administración de requerimientos.
Otros aspectos que es preciso acotar es que la gestión de la configuración se da a lo largo de todo el ciclo de
desarrollo de software y una versión comprende no solo el programa, sino los modelos, las herramientas y la
documentación asociadas a esa versión, el mantener esta información por tanto resulta vital al momento de
organizar la actividades de desarrollo y sobre todo de mantenimiento del sistema.
Gestión de
requerimientos
Gestión del
Diseño
proyecto
Operaciones y Gestión de la Implementación

mantenimiento Configuración
Transición,
reléase Integración
Verificación
Figura 5.1 Ejemplo de un ciclo de vida soportado por la administración de la configuración20
En la figura 5.1, se puede apreciar un ejemplo de un ciclo de vida de proceso soportado por la Gestión
de la Configuración, en ella se coloca a la gestión de la configuración como un proceso que coordina las
actividades de gestión de requerimientos, el diseño, la implementación, la integración, la verificación, la
liberación de versiones, las operación y mantenimiento del software e incluso la gestión del proyecto.
En resumen diremos que no podemos hablar de desarrollo profesional de software, si no se lleva estos
procesos, más aún en organizaciones grandes donde se tiene varios productos de software en desarrollo
y mantenimiento de otros.
Ahora compare la figura 25.1 del texto básico con la figura 5.1 de la guía didáctica, ¿podría identificar
en qué parte de las actividades de la gestión de la configuración calzan las actividades de desarrollo?
En este momento, se le invita a memorizar los términos de la figura 25.2 del texto básico, que serán
importantes para comprender el detalle de cada uno de los procesos de la gestión de la configuración.
20 IEEE Std 828-2012. Pp 6
89
5.1. Administración del cambio
Sin lugar a dudas las solicitudes de cambio, son los motivos más comunes para realizar modificaciones al
sistema, por lo que es necesario tener un proceso ordenado, en las compañías pequeñas o en aquellas en
las que se trabaja con una única aplicación a cargo de un técnico programador, las solicitudes de cambio
pueden llegar a través de una llamada telefónica, un mensaje de correo electrónico o una conversación
simple, y no hay una registro de la solicitud de cambio, y mucho menos y registro de que fue lo que
se cambió y cómo se podría volver a la versión anterior en caso de que esta petición de cambio sea
revocada.
Esta situación llevada a escenarios más grandes se volvería inmanejable, puesto que en primer lugar no
es una única persona la que está a cargo, sino que hay varios equipos de personas, de los cuales unos se
dedican a desarrollos nuevos y otros realizan los cambios solicitados al sistema, por lo que tanto para
unos como para otros es indispensable tener un proceso ordenado de control de cambios, y eso es
precisamente de lo que se trata esta unidad.
Comience realizado una lectura comprensiva de la sección 25.1 del texto básico, se le
sugiere que se fije sobre todo en los detalles de las distintas figuras del apartado.
Si se fija en la figura 25.3 el proceso de administración de requerimientos, involucra

tanto las solicitudes de cambio emitidas directamente por el cliente como aquellas generadas por el
equipo de soporte al cliente, que normalmente suelen darse por identificación de errores del sistema,
en cualquiera de los dos casos se recibe la solicitud de cambio (Change Request) y es valorada por un
comité control de cambios (CCB) teniendo como criterio sobre todo la valoración económica del cambio,
aunque no es el único criterio, sin embargo si es el que mayor peso tiene; este proceso puede variar sin
embargo vale la pena hacer énfasis en la presencia de un comité de control de cambios, un equipo de
soporte y un equipo de desarrollo, quienes tienen diferentes responsabilidades respecto del proceso de
gestión de cambios.
Otro aspecto que se considera importante en este proceso es el uso de formatos estandarizados dentro
de la organización de forma tal que se evite la informalidad, el hecho de contar con una forma como la
de la figura 25.4 hace que haya mucho mejor control y se puede establecer responsabilidades además
de que tiene mucha información valiosa para poder hacer el análisis.
Estos procesos de administración de cambios no solo tienen control sobre la documentación que da
origen al cambio, sino también sobre la documentación técnica e incluso el código con sus respectivos
comentarios como se muestra en la figura 25.5
Actividades recomendadas
Con el ánimo de mejorar su comprensión, se pide que resuelva las preguntas 25.1 a 25.4 de
los ejercicios del capítulo 25 del texto básico y comente en sus compañeros o con su tutor
los resultados.
Además uno de los puntos en los que se insiste mucho es en el uso de herramientas de software para la
gestión de la configuración, podría buscar herramientas de software que ayuden con este proceso de
administración de requerimientos, hay muchas que son con licencia y otras que son libres.
90
5.2. Gestión de versiones
Dos conceptos importantes a tener en cuenta para entender este apartado son el concepto de línea
base y el concepto de versión, para ello comencemos indicando que cada ítem del proceso de desarrollo
sea este un documento, una pieza de código ó una especificación tienen una versión, de forma tal que
en primer lugar cada versión se almacena en una archivo separado y es fácil identificar, por su parte una
línea base podemos decir que es un conjunto de ítems que está probado que funcionan en conjunto,
estas líneas base también tienen su versión, el objetivo de mantener las líneas base es asegurarse que
cada línea base cuenta con las versiones correctas de los componentes, de forma tal que si es necesario
volver a una línea base anterior para un nuevo desarrollo, esto no represente mayor dificultad.
En este momento se le invita a realizar una lectura comprensiva de la sección 25.2 del texto
básico en el cual se explica a detalle el tema de la gestión de versiones.
De lo que se puede apreciar en la figura 25.6 las líneas de código también mantienen su versión, de
forma tal que una vez establecida la línea base, esta versión de código no se cambia a no ser que sea
como una nueva versión, conservando la anterior.
Hay varias características que ofrecen los sistemas de gestión de versiones, usted puede estudiarlas y
como sugerencia buscar herramientas que trabajen este tipo de actividades, en Wikipedia se puede
encontrar un listado de herramientas de administración de la configuración en la dirección siguiente
http://en.wikipedia.org/wiki/Comparison_of_open-source_configuration_management_software que
se le recomienda consultar.
Un elemento común que tienen la herramientas de gestión de versiones es un repositorio, el cual

automáticamente guarda las diferentes versiones de un ítem y mediante procesos definidos como
check-in y check-out, evita los conflictos de versiones que se pudieran presentar entre los diferentes
participantes del proyecto.
En estas herramientas se puede encontrar aquellas que guardan diferentes versiones tanto del código
fuente como de la documentación asociada a esa versión del código.
Actividades recomendadas
Para complementar su estudio, se le recomienda desarrollar los ejercicios 25.4 a 25.6 del
texto básico, así como investigar sobre herramientas libres para la gestión de versiones.
5.3. Construcción del sistema
La construcción del sistema, es un proceso que está estrechamente relacionado con el manejo de
versiones, de hecho las suites de desarrollo de software integran herramientas de desarrollo con
herramientas de control de versiones y herramientas denominadas como Application Lifecycle
Management (ALM), que ayuda a controlar todo el ciclo de desarrollo de software e integran el control
de versiones de software.
A continuación, proceda a estudiar el apartado 25.3 del texto básico en el que se

especifica la forma en las aplicaciones de desarrollo de software debe comunicarse con
las herramientas de control de versiones.
91
Si observa con cuidado la figura 25.10 del texto básico, tenemos una infraestructura de desarrollo que
es capaz de combinar las herramientas de desarrollo con las herramientas de control de versiones que
producen los sistemas ejecutables, los cuales una vez en producción se constituyen en un release del
sistema, además cada elemento de código fuente se almacena en el gestor de versiones y se puede usar
o liberar con los procesos de check-in y chech-out.
En este apartado además se describe algunas características de lo que pueden incluir herramientas
integradas de administración de la configuración.
Sin lugar a dudas el uso de herramientas automatizadas para la administración de versiones es muy
importante para preservar la integridad del código y las diferentes versiones de los componentes de
software, además que facilitan el mantenimiento del software y evitan conflictos entre las diferentes
versiones del código haciendo posible el retorno a una versión anterior en caso de tener problemas con
alguna actualización.
En lo relacionado a la documentación hay algunas herramientas básicas que funcionan en la web que
podrían usarse como repositorios que además podría permitir el manejo de versiones como dropbox o
las herramientas google apps.
5.4. Gestión de entregas de software
Como se lo había mencionado antes, la puesta en producción de una línea base de software, es lo que se
conoce como un reléase del producto, los cuales incluyen el código, la documentación y los parámetros
de configuración.
Identificamos en primera instancia lo que es un reléase, que podemos decir que es una versión de un
producto de software que va a manos del cliente, estas versiones normalmente se numeran con un
sistema decimal de dos o tres niveles lo cual depende del fabricante.
Además se debe establecer una diferencia entre los que son los reléase del producto y las versiones beta,
estas últimas versiones de prueba que se entrega a la comunidad de usuarios con el fin de que prueben
su comportamiento y realizar mejoras antes de sacar los reléase de producción, o dicho de otra manera
las versiones comerciales o de usuario final.
La mayoría de productos de software pueden empezar a numerarse como reléase 1.0.0 y conforme
se va actualizando, corriendo errores o agregando funcionalidades las versiones de producción esta
numeración va cambiando, si las actualizaciones son menores, el número del reléase incrementa desde
su último dígito, por ejemplo se puede pasar del reléase 1.0.0 a 1.0.1, y en la medida en que estas mejoras
al producto se vuelven más importantes se puede cambiar a un reléase 1.1.0 y si el producto se renueva
totalmente, podría cambiarse al reléase 2.0.0.
Ejemplos de este sistema de numeración de versiones encontramos en la mayoría de productos de

software de los que se dispone.
Ahora es el momento de realizar lectura comprensiva de la sección 25.4 del texto básico.
Una vez realizada la lectura es importante resaltar la diferencia que hace el autor del
texto básico entre lo que es una liberación de un producto comercial como lo puede ser
aquellos fabricados por Microsoft, Apple, IBM o cualquier otro fabricante y las aplicaciones de software
a la medida, que normalmente deben responder a exigencias particulares en las cuales el impacto suele
ser mayor que en la liberación de una versión comercial del producto.
92
Si considera todo lo planteado en la presente unidad, la liberación de reléase es un proceso que debe
planificarse cuidadosamente, y hay muchos factores que se deben considerar para ello; entre estos
podemos considerar el nivel de criticidad de la actualización requerida, la capacidad operativa del
equipo para liberar la versión, la disponibilidad de la comunidad de usuarios para enfrentar los procesos
de capacitación, el impacto en los datos y cambios organizacionales, además en la tabla 25.13 del texto,
se describen algunas de los factores que pueden llevar a planificar la liberación de un nuevo reléase.
Otro aspecto de mucha importancia a considerar al momento de liberar un reléase tal como lo menciona
el autor es que esta no implica solamente la puesta en producción de la nueva versión, sino que incluye
actualizaciones de datos, inclusión de nuevos archivos, configuraciones adicionales, etc; las cuales
cuando se trata de software comercial por lo general son resueltas o ejecutadas por los paquetes
instaladores, sin embargo en las versiones de software personalizado o a la medida el proceso no resulta
tan fácil y si en el mejor de los casos se dispone de una herramienta automática que haga este tipo de
actualización será necesario llevar como mínimo una lista de verificación donde se registren
cuidadosamente todas las actualizaciones que habría que hacer para pasar de las versiones de desarrollo
a las versiones de producción, naturalmente el uso de aplicaciones web simplifica considerablemente
este proceso, sin embargo no evita la necesidad de tener las previsiones necesarias.
Actividades recomendadas:
Resuelva los ejercicios 25.7 a 25.10 del texto básico. Luego investigue si las mismas
previsiones que se tiene para el control de versiones y liberación de versiones se aplican
para las aplicaciones web que se implementan como servicios (SaaS), o para las aplicaciones
que liberan las tiendas de software en línea como Apple Store o Google Play.
93
Autoevaluación 5
Ha completado la unidad 5, la cual a pesar de sus sencillez, contempla aspectos

muy importantes de la ingeniería de software, revise cuánto ha logrado aprender
y nuevamente si al comparar con las soluciones dadas se presentan dudas, revise el
material y de ser necesario consulte a su tutor.
Para cada una de las siguientes preguntas seleccione la alternativa correcta.
1. ¿Cuál de las siguientes alternativas representa a la entidad que analiza y valora una petición de
cambio en el sistema?
a. El Change Control Board

b. El Change Request
c. Soporte al cliente
2. ¿Cuál de los siguientes se puede considerar un ítem de configuración?
a. El equipo de proyecto
b. La organización
c. El código
3. Con cuál de los siguientes términos se asocia los productos de software que van a manos de los
usuarios.
a. Versión
b. Reléase
c. Beta
4. El término línea de código (Codeline), hace referencia a:
a. Una línea de un programa fuente

b. Un conjunto de versiones de un componente de software y otros ítems de configuración de
los cuales depende dicho componente
c. La creación de una nueva versión de un componente de software
5. ¿Cuál de los siguientes es uno de los principales motivos para aceptar cambios a un producto de
software?
a. Los errores
b. Las mejoras a la apariencia del producto
c. Requerimientos podo trascendentes
94
6. ¿Cuál es un factor significativo que se debe tener en cuenta antes a probar un cambio?
a. La disponibilidad de tiempo
b. La disponibilidad de recursos
c. Las consecuencias de no realizar el cambio
7. ¿Cuál de los siguientes elementos es indispensable en un sistema de control de versiones?
a. El repositorio
b. Los nombres de archivo
c. Los nombre de los desarrollares a cargo
8. ¿Cuál de las siguientes operaciones le permite al programador acceso a componente restringiéndolo

para que nadie lo altere?
a. Check in
b. Check Out
c. Free
9. ¿Cuál es la diferencia entre un reléase y una versión beta?
a. La versión beta se libera directo a la comunidad de usuarios finales

b. El reléase es la versión del software que está probada para pasar a manos del cliente
c. El reléase es un producto no adecuado para la comunidad de usuarios
10. Si un producto que actualmente se encuentra en el reléase 2.5.8, ¿Cuál debería ser el número del
reléase en caso de recibir una actualización menor?
a. 2.6.0
b. 2.5.9
c. 2..5.7
95
UNIDAD 6. MEJORA DE PROCESOS SOFTWARE
Finalizamos el estudio del presente componente educativo con un importante tema que tiene que ver
con mejorar los procesos de desarrollo de software que se han establecido en las organizaciones.
Actualmente en la industria del software las pequeñas y microempresas tienen una importante
responsabilidad en el mercado mundial de productos software y servicios, ya que de acuerdo a
recientes estudios se estima que el 80% de las organizaciones de desarrollo de software son las PYMES
(Espinosa-Curiel, 2013), por lo que la competencia en el mercado del software fomenta a muchas de
estas organizaciones a iniciar una mejora de proceso software (SPI en inglés, MPS en español), cuyo
objetivo es:
• Aumentar la productividad y la calidad de sus procesos y productos de software.

• Reducir el tiempo y los costes asociados al desarrollo.
• Incrementar la satisfacción de los clientes
Estimado estudiante, es hora de ir al texto básico y leer la parte introductoria del capítulo
26, dónde se indica la importancia de la mejora de procesos software. Ponga especial
énfasis tanto en los enfoques como en los factores que afectan al producto.
Adicionalmente en (CMMI, 2010), se indica que el SEI (Software Engineering Institute), en su afán de
ayudar a las organizaciones a desarrollar y mantener productos y servicios de calidad, a identificado
varias dimensiones para mejorar su actividad. En la figura 6.1, se indican tales dimensiones.
Figura 6.1: Las tres dimensiones críticas (CMMI, 2010)
96
En (CMMI, 2010) se establece que uno de los paradigmas relacionados con la calidad dice: “La calidad de
un sistema (de software), está altamente influenciada por la calidad de los procesos que son utilizados
en su desarrollo y mantenimiento”, lo que a las claras podemos diferenciar la importancia del proceso sin
olvidar que tanto las personas como la tecnología son las que proporcionan los elementos necesarios
para producir mejoras sustanciales a los procesos de desarrollo.
La organización puede elegir un enfoque informal de MPS, pero la mayoría opta por los marcos
conceptuales de MPS. Un marco conceptual MPS valora la madurez del proceso en una organización. En
la figura 6.2 se indica un marco conceptual MPS típico.
Proceso de
Software
Identifica capacidades,
Identifica cambios a fortalezas y debilidades de
Lo examina
Identifica madurez de
Sugiere enfoque de
mejoramiento para
Valoración
Conduce a Conduce a
Estrategia de Determinación de
mejoramiento capacidad
Está basada para
Figura 6.2: Elementos de un marco conceptual MPS (Pressman, 2010)
No existe un marco conceptual MPS universal, en (Pressman, 2010) se establece seis diferentes grupos
de apoyo al MPS, estos son:
1. Certificadores de calidad
2. Formalistas
3. Defensores de las herramientas
4. Profesionales
5. Reformadores
6. Ideólogos
Desarrolle los ejercicios del 21.6 al 26.6, correspondientes al capítulo 26, del texto básico y
luego socialice su análisis con sus compañeros y el tutor.
97
6.1. El proceso de MPS.
Cuando las organizaciones han adoptado un proceso de desarrollo para los proyectos software, al
realizar el análisis de la forma en que se están desarrollando los proyectos, se podrá determinar que
existen actividades o procesos que se tendrán que mejorar.
Al implementar un proceso de mejora, éste ocasionará cambios en la organización, por lo que será
necesario administrar el cambio, esto es: planificar, socializar a los interesados y organizar el cambio
asignando responsabilidades a las personas que implementarán el cambio. La cultura organizacional
será uno de los factores a considerar ya que dependerá de éste el grado de resistencia al cambio que se
pueda encontrar al implementar las mejoras.
Estimado estudiante, es hora de ir al texto básico y leer el literal 26.1 El proceso de

mejora de procesos, ponga énfasis en los atributos de proceso y en el ciclo de mejora
de procesos.
Una vez finalizada la lectura analicemos la figura 26.2 “Atributos del proceso”, del texto básico, dónde se
indican ciertos atributos en los cuales se puede apoyar la mejora. Por ejemplo, el atributo “Compresión”,
tiene que ver con la definición del proceso para los involucrados y la forma de cómo éstos entienden.
Cuales son las acciones a tomar ante la pregunta ¿En que medida el proceso está definido explícitamente
y qué tan fácil es entender la definición del proceso?. Con respecto a la comprensión no es una pregunta
que se puede responder con un SI o NO, sino que requiere de un exhaustivo análisis en donde es
importante analizar el proceso con cada una de sus tareas y actividades desde el punto de vista de
los participantes para lograr una adecuada comprensión, puede ser que se requiera hacer un ajuste al
proceso y esto consecuentemente ocasiona que se tenga que hacer una adecuada planificación que se
acople a un proceso de mejora.
En el texto básico se indica que la mejora del proceso es cíclico, basado en tres subprocesos: Medición
del proceso, Análisis del proceso y cambio del proceso; esto no quiere decir que son los pasos sobre los
cuales se deben desarrollar las mejoras.
En (Pressman, 2010) se establece que la parte mas complicada del MPS es lograr el consenso para iniciar
MPS y definir una estrategia para implementar de forma continua a través de una organización de
software.
El SEI desarrolló un modelo de mejoramiento organizacional denominado IDEAL, que es representativo

de muchos modelos de procesos para MPS. Este modelo provee un enfoque disciplinado de ingeniería,
que se focaliza en el gerenciamiento del proyecto, mejorando y estableciendo los fundamentos para
una estrategia a largo plazo. El modelo consiste de cinco fases con sus respectivas actividades.21 En la
figura 6.3, se indica las fases de este modelo.
21 Software Engineering Intitute. (2009). The IDEAL Model. Recuperado de: http://www.sei.cmu.edu/library/assets/
idealmodel.pdf.
98
Figura 6.3: Fases del modelo IDEAL (CMMI, 2010)
El proceso de MPS de acuerdo al texto básico gira en torno a un proceso cíclico de: medición, análisis y
cambio; mientras que en (Pressman, 2010), se establece que el proceso MPS es una filosofía que requiere
que una organización:
a. Se observe en el espejo
b. Se vuelva mas astuta para tomar elecciones inteligentes
c. Seleccione el modelo de procesos
d. Ejemplifique el modelo en su entorno operativo
e. Evalúe lo que se realizó.
Adicionalmente se sugiere se revise temas relacionados con el modelo IDEAL, especialmente
el propuesto por el SEI y analice las interrogantes que se indican para que lo pueda
compartir con sus compañeros de estudio o con el tutor.
• ¿Por qué las empresas de desarrollo de software tienen muchos problemas y tienen que
gastar demasiado esfuerzo cuando se embarcan en un proyecto de mejora de procesos?
• Investigue sobre el proceso de madurez de procesos para empresas en la actualidad.

(Verifique en el sitio del SEI)
99
6.2. Evaluación y mejora de procesos software
Jacobson, indica que los procesos de software se ven limitados por lo siguiente:
• La ingeniería del software está bloqueada por prácticas inmaduras.

• Prevalecen más las modas que los procesos de ingeniería.
• Existe una división entre investigación e industria.
• Gran número de métodos y variantes con pequeñas diferencias artificialmente
magnificadas.
Los métodos de evaluación permiten conocer, a través de la ejecución de la evaluación, el estado actual
de la organización, la capacidad alcanzada por sus procesos y en base a éstos implementar un modelo de
mejora continua. Entre estos se mencionan: Modelo de Madurez de Capacidades de Software Integrado
(CMMI), Bootstrap, ISO / IEC 15504, PSP y TSP, Tickit, entre otros.
6.3. CMMI
Es una guía para los procesos gerenciales, técnicos y de soporte. El modelo CMMI es un modelo de
referencia para evaluar los procesos y ayudar a su mejora mediante una ruta evolutiva. Permite estructurar
las etapas por las que atraviesan las organizaciones de software. Además propone estrategias de mejora
a partir de la identificación de los puntos críticos para la calidad del software y la revisión constante del
proceso. (CMMI, 2010).
Estimado estudiante, es hora de ir al texto básico y leer el literal 26.5 El marco de trabajo para la
mejora de procesos CMMI.
Luego de realizar la lectura, adicionalmente podemos decir que el CMMI da soporte a dos caminos de
mejora usando niveles. Estos dos caminos de mejora están asociados con dos tipos de niveles: niveles de
capacidad y niveles de madurez. Estos niveles corresponden a dos aproximaciones de mejora de procesos
llamadas “representaciones”. Las dos representaciones se las conoce como: “continua” y “por etapas.” El
uso de la representación continua permite alcanzar “niveles de capacidad”. El uso de la representación
por etapas permite alcanzar “niveles de madurez”.
Tabla 5.1: Representaciones del modelo CMMI
Continua Por niveles

Permite a la organización elegir el orden del Permite a la organización tener un camino
proceso de mejora que mejor se adapte a las predefinido de mejora ya comprobado.
necesidades. Enfocado en proveer a la organización un
Mejora la visibilidad de las capacidades obtenidas conjunto de procesos con capacidades específicas
en cada área de proceso individual. representadas por un nivel de madurez.
El proceso de mejora puede ser realizado en Resume el resultado del proceso de mejora en un
ritmos diferentes según las áreas. único indicador: nivel de madurez
100
El metamodelo CMMI continuo describe un proceso en dos dimensiones, tal como se observa en la
figura 6.4, en la que cada área de proceso se valora formalmente contra metas y prácticas, permitiendo
clasificarse de acuerdo a los niveles:
• Nivel 0: Incompleto
• Nivel 1: Realizado
• Nivel 2: Administrado
• Nivel 3: Definido
• Nivel 4: Administrado cuantitativamente
• Nivel 5: Optimizado
Figura 6.4: Perfil de capacidad de área de proceso CMMI (Pressman, 2010).
Dependiendo de la organización CMMI puede implementar en tres constelaciones: CMMI para desarrollo,
CMMI para servicios y CMMI para adquisición. En la figura 6.5 se indican las constelaciones del CMMI.
CMMI for development (DEV)
Es el más utilizado, se emplea para la mejora de procesos de las organizaciones que desarrollan productos
y servicios de software y hardware. Contiene prácticas que cubren la administración de proyectos, de
procesos, ingeniería de software, de hardware, ingeniería de sistemas y procesos de soporte.
CMMI for services (SVC)
Esta dirigido principalmente a las empresas que se encuentran en el sector de servicios (consultoría,
capacitación, logística, recursos humanos, etc.), proporcionando las directrices para lograr administrar
y entregar servicios mediante procesos previamente definidos y controlados. Con el modelo se pueden
lograr los siguientes objetivos:
• Establecer un nuevo sistema o cambiarlo, sin afectar, de forma negativa, el servicio que se tiene
de antemano.
• Identificar las fallas dentro del servicio proporcionado y lograr prevenirlas en situaciones
posteriores.
101
CMMI for acquisition (ACQ)
Proporciona todas las pautas necesarias a las organizaciones que se dedican principalmente a adquirir
productos y servicios de otras empresas, para integrarlos en un producto final que cumpla con las
necesidades del cliente. Las empresas conocidas como “integradoras” podrían optar por este modelo.
Entre los objetivos del modelo es evitar o eliminar barreras y problemas en el proceso de adquisición,
mediante mejoras en la eficiencia operativa.
Figura 6.4: Constelaciones del CMMI (CMMI, 2010)
Para dar soporte a aquellas organizaciones que utilizan la representación continua, todos los modelos
CMMI reflejan niveles de capacidad en su diseño y contenido. Los cuatro niveles de capacidad, cada uno
es una capa base para la mejora de procesos en curso, se denominan por los números del 0 al 3:
0. Incompleto.
1. Realizado.
2. Gestionado.
3. Definido.
Un nivel de madurez es una plataforma evolutiva definida para la mejora de procesos de la organización.
Cada nivel de madurez desarrolla un subconjunto importante de procesos de la organización,
preparándola para pasar al siguiente nivel de madurez. Los niveles de madurez se miden mediante el
logro de las metas específicas y genéricas asociadas con cada conjunto predefinido de áreas de procesos.
Los cinco niveles de madurez, cada uno de ellos como base para la mejoras de proceso en curso, se
denominan por los números del 1 al 5:
1. Inicial.
2. Gestionado.
3. Definido.
4. Gestionado cuantitativamente.
102
5. En optimización.
• Enfocado en la mejora
continua del proceso.
5 Optimizado • Procesos mejorados
continuamente - organización
ágil eficaz y eficiente.
Gestionado • Enfocado en la mejora continua del proceso.

4 cuantitativa • Procesos mejorados continuamente -
mente organización ágil eficaz y eficiente.
• Enfocado en la mejora continua del proceso.

3 Definido • Procesos mejorados continuamente - organización ágil eficaz y
eficiente.
• Enfocado en la mejora continua del proceso.

2 Gestionado • Procesos mejorados continuamente - organización ágil eficaz y eficiente.
• Procesos impredecibles y pobremente controlados, organización reactiva.

1 Inicial
• Poca disciplina, compromisos mal establecidos - no se puede reproducir los éxitos
Figura 6.6: Niveles de madurez (CMMI, 2010)
Áreas de proceso
Cada área de proceso identifica un conjunto de actividades relacionadas, que realizadas en forma
colectiva alcanzan un conjunto de metas consideradas de importancia para mejorar la capacidad del
proceso. Son 22 áreas de procesos en total, agrupadas en 4 categorías, tal como se indica en la tabla 6.2.
Tabla 6.2: Áreas de proceso por categoría.
Categoría Área Nivel

Gestión de requerimientos (REQM) 2
Integración del Producto (PI) 3
Desarrollo de Requisitos (RD) 3
Ingeniería
Solución Técnica (TS) 3
Validación (VAL) 3
Verificación (VER) 3
Monitorización y Control del Proyecto (PMC) 2
Planificación del Proyecto (PP) 2
Gestión de Gestión de Acuerdos con Proveedores (SAM) 2
proyectos Gestión Integrada del Proyecto (IPM) + IPPD 3
Gestión de Riesgos (RSKM) 3
Gestión Cuantitativa del Proyecto (QPM) 4
Formación en la Organización (OT) 3
Definición de Procesos de la Organización (OPD)+IPPD 3
Gestión de
Enfoque en Procesos de la Organización (OPF) 3
procesos
Rendimiento de Procesos de la Organización (OPP) 4
Innovación y despliegue organizacional (OID) 5
Gestión de la Configuración (CM) 2
Medición y Análisis (MA) 2
Aseguramiento de la Calidad del Proceso y del Producto
Soporte
(PPQA) 2
Análisis de Decisiones y Resolución (DAR) 3
Análisis Causal y Resolución (CAR) 5
103
Desarrolle los ejercicios del 26.7 al 26.10, correspondientes al capítulo 26, del texto básico
y luego socialice su análisis con sus compañeros y el tutor mediante la herramienta e
interactividad EVA.
6.4. Otros marcos conceptuales MPS
Como se indicó anteriormente, adicionalmente al CMMI existen otros modelos que también se usan con
cierta frecuencia. A continuación vamos a realizar una ligera descripción:
• SPICE
Proporciona un marco de valoración basado en el estándar ISO 15504:2003 e ISO 12207, incluye:
• Modelo para la gestión de procesos

• Lineamiento para realizar una valoración y clasificación del proceso bajo consideración
• Construcción
• Selección y uso de instrumentos y herramientas de valoración
• Capacitación para asesores
• Bootstrap
Este marco permite evaluar un proceso de software usando un conjunto de mejores prácticas de
ingeniería del software como base para la valoración. Proporciona un nivel de madurez de proceso
empleando los resultados de cuestionarios que recopilan información acerca del proceso y proyectos
de software.
• PSP y TSP
Estos marcos resaltan la necesidad de recopilar datos continuamente acerca del trabajo que se realiza y
de usar dichos datos para desarrollar estrategias para su mejoramiento.
• TickiT
Es un método de auditoría que garantiza el cumplimiento del ISO 9001:2000 para software, que adopta
un ciclo de “planificar-hacer-verificar-actuar” que se aplica a los elementos de gestión de la calidad de un
proyecto software.
Elabore una tabla con marcos conceptuales MPS adicionales que existan y que se estén
utilizando. Utilice la web y luego comparta con los compañeros y con el tutor.
104
Autoevaluación 6
Hemos finalizado la unidad, por lo que es necesario realizar la correspondiente autoevaluación

para determinar el conocimiento asimilado. Se recomienda resolver lo propuesto ya que es
posible que existan temas que no se han comprendido a plenitud.
1. Cuando los riesgos causan problemas inesperados pero el proceso puede continuar sin incidencias,
entonces el proceso posee la característica de:
a. Robustez
b. Rapidez
c. Comprensión
2. Con respecto al proceso de MPS se tiene que dichos procesos reflejan resultados que son
observables de forma clara y externamente, entonces se refiere a que se posee la característica de:
a. Fiabilidad
b. Estandarización
c. Visibilidad
3. Con respecto al ciclo de mejora de procesos, el análisis del proceso se refiere a:
a. Medir los atributos del proyecto actual o del producto.

b. Valorar el proceso actual e identificar las debilidades y los cuellos de botella del proceso.
c. Se elaboran las propuestas para atacar algunas de las debilidades identificadas del proceso.
4. La métrica “El número de ocurrencias de un evento particular”, se puede determinar cuando se

tiene:
a. El tiempo total dedicado al proceso

b. El costo de recursos de cómputo
c. El numero de defectos encontrados al momento de realizar la inspección.
5. Con respecto al paradigma GQM (Meta-Pregunta-Métrica), “El avance real del proyecto se
monitoriza considerando como base el plan del proyecto”, esto se lo considera como:
a. Meta
b. Pregunta
c. Métrica
105
6. Si tenemos la meta de acortar los tiempos de matricula de un estudiante, ante la pregunta ¿Dónde
están los cuellos de botella del proceso?, una de las mediciones sería:
a. Cantidad de defectos descubiertos mediante la ejecución de pruebas

b. Tiempo que tarda en completarse la actividad de matricula
c. Cantidad de defectos corregidos
7. El número de reuniones entre clientes y usuarios podría ser considerado como una:
a. Meta
b. Pregunta
c. Métrica
8. A que nivel de madurez corresponde la existencia de planes de proyecto que indiquen claramente
las metas del proyecto:
a. Incompleto
b. Realizado
c. Gestionado
9. Con respecto al proceso de “cambios al proceso”, cuando la organización decide realizar la gestión
de requerimientos mediante el uso de herramienta con lo cual diseña sus procesos para el
adecuado uso. Esto se enmarca dentro de la etapa de:
a. Identificación de mejoras
b. Introducción de cambios a los procesos
c. Priorización de las mejoras
10. Una de las técnicas mas usadas para el análisis del proceso, cuando se requiere observar a los
participantes mientras desarrollan sus actividades, es la:
a. Estudios etnográficos
b. Cuestionarios
c. Entrevistas
106
Guía didáctica: Ingeniería de Software SOLUCIONARIO
7. Solucionario
PRIMER BIMESTRE
Unidad 1: Terminología básica de la gestión de proyectos
Autoevaluación 1
Pregunta Respuesta
1. B
2. C
3. B
4. A
5. C
6. B
7. C
8. A
9. B
10. A
107
Unidad 2: Proyectos de Ingeniería de software
Autoevaluación 2
Pregunta Respuesta
1. B
2. C
3. C
4. C
5. B
6. C
7. A
8. A
9. B
10. C
108
Unidad 3: Planificación de proyectos software.
Autoevaluación 3
Pregunta Respuesta
1. B
2. C
3. B
4. A
5. A
6. B
7. C
8. A
9. B
10. C
109
SEGUNDO BIMESTRE
Unidad 4: Gestión de la calidad del software
Autoevaluación 4
Pregunta Respuesta
1. A
2. B
3. A
4. C
5. B
6. A
7. B
8. A
9. A
10. A
110
Unidad 5: Administración de la configuración
Autoevaluación 5
Pregunta Respuesta
1. A
2. C
3. B
4. B
5. A
6. C
7. A
8. A
9. B
10. B
111
Unidad 6: Mejora de procesos software
Autoevaluación 6
Pregunta Respuesta
1. A
2. C
3. B
4. C
5. A
6. B
7. C
8. C
9. A
10.
112
Guía didáctica: Ingeniería de Software ANEXOS
8. Anexos
DI CTI ONARY
TH ESA UR US
El presente material ha sido reproducido con fines netamente didácticos,

cuyo objetivo es brindar al estudiante mayores elementos de juicio para la
comprensión de la materia, por lo tanto no tiene fin comercial.
Anexo 1: Soluciones a ejercicios
Soluciones a ejercicios por unidad
PRIMER BIMESTRE
EJERCICIO 1.1
Con el ánimo de evitar la confusión entre lo que es un proyecto y lo que son las operaciones, indique si los elementos de
la tabla 1.1 corresponden a proyectos o a operaciones:
Descripción Categoría Explicación

Es una tarea de rutina, no genera
Venta de computadores Operación
nada nuevo.
Aunque se hace en períodos
específicos, no se considera proyecto
puesto que no genera ningún
Control de inventarios Operación
producto, servicio o resultado
único, además es tarea operativa del
personal a cargo.
Se desarrolla porque no se lo tiene,
hay un plazo para ello y los recursos
Desarrollo de un portal WEB. Proyecto empleados se liberarán o se ocuparán
en otra actividad una vez completado
el mismo.
Operación diaria del administrador de
El respaldo a una base de datos. Operación
base de datos.
La corrección de errores aunque
puede ser tarea de un proyecto, no
se asume por si sola como proyecto,
La corrección de errores de una aplicación de
Operación además el producto (software) ya
software.
está terminado, la corrección no crea
un producto nuevo, por tanto es
operación
Para un proyecto de construcción se
puede requerir ese permiso, pero la
La obtención de un permiso de construcción. Operación tarea no puede considerarse proyecto,
simplemente es una actividad que se
cumple.
Se va a construir un elemento que no
existe, tiene un presupuesto, recursos
La construcción de un puente. Proyecto
y plazo específicos, por tanto es
proyecto.
113
Se desarrolla un modelo de vehículo

que no se ha hecho antes con
El diseño de un nuevo vehículo Proyecto
recursos, plazo y restricciones
específicas, por lo tanto es proyecto.
Son operaciones diarias que se
realizan en la Universidad, esto
Las clases presenciales en la universidad. Operación
independiente de lo novedosa que
pueda ser la clase.
Es proyecto puesto que al ser nuevo
disco, significa que es un resultado
único, además hay un plazo,
El lanzamiento de un nuevo disco de música. Proyecto
presupuesto y recursos determinados,
una vez lanzado el disco pasa e
producción que son las ventas.
Ejercicio 1.2
Este ejercicio no tiene una solución específica, por lo que si tiene dudas es mejor que consulte a su tutor.
Ejercicio 1.3
Nro. Entregable SI/NO Razón

1 Documento de requerimientos SI El cliente debe aprobar los requerimientos.
Diseño arquitectónico Tiene sentido para el cliente porque especifica
2 SI
cómo será la solución esperada.
Diagrama entidad relación. Los interesados no entienden y es importante
3. NO para ellos saber como de modelaron los datos, a
ellos les interesa que funcione.
Diagrama de casos de uso. Similar al documento de requerimientos, se ven
4. SI
las funcionalidades del sistema.
Plan de comunicaciones Aunque es importante, eso no define ningún
5. NO
aspecto del sistema.
6. Esquema de base de datos. NO Es un tema interno que no interesa al cliente.
7. Pantalla de ingreso de usuarios. SI Es lo que el usuario recibirá para trabajar.
Instalación de la aplicación Si la aplicación no está instalada, es lo mismo que
8. SI
no haber hecho el trabajo.
9 Interface con sistema financiero SI Componente necesario y evidente.
10. Manual de usuario SI Lo necesitan los usuarios.
114
Tareas Actividad
Se encarga de supervisar el trabajo para asegurarse que se están Planeación del proyecto.
utilizando los estándares adecuados.
Establece las formas de trabajo. Gestión de personal.
Valorar los riesgos que afectan al proyecto. Gestión del riesgo.
Informar el avance del proyecto tanto a los clientes como a los Informes.
directivos de la organización.
Se encarga de describir los objetivos del proyecto y la forma en que Redactar propuestas.
se realizará.
Se encarga de elegir los integrantes del equipo. Gestión de personal.
Controlan que el desarrollo de las actividades estén a tiempo y dentro Planeación del proyecto
del presupuesto.
115
Anexo 2: Ejemplo
Ejemplo de estimación de costos basado en el método de puntos de función. La aplicación aquí planteada
es una aplicación real desarrollada como parte de un proyecto de la asignatura de Fundamentos de
Ingeniería de Software y el cálculo se lo hizo utilizando una herramienta desarrollada por estudiantes
de la asignatura de Gestión Avanzada de Proyectos, ambos de la modalidad presencial de la UTPL, en el
período Abril – Agosto 2013.
Se ha cambiado el nombre de la aplicación con el propósito de guardar la confidencialidad de la

información.
Especificación de la aplicación
La aplicación es un sistema de ventas puerta a puerta en la cual el vendedor realiza visitas a los posibles
compradores durante las cuales se hace una demostración del producto y en caso de cerrar la venta
se hace el pedido del producto y se acuerda la forma de pago, los pagos pueden hacerse en efectivo,
con tarjeta de crédito o a través de un crédito bancario gestionado por la misma empresa. Al final de la
venta, el comprador recomienda a otros posibles compradores y en caso de cerrar alguna venta con un
recomendado, el comprador recibe un obsequio.
Entre las necesidades más importantes los clientes esperan pode gestionar las citas, coordinar las
demostraciones, gestionar la ventas y apoyo en el trámite de crédito bancario para el cliente.
Luego del análisis correspondiente se ha establecido que la aplicación contará con 6 componentes que
se listan a continuación:
• Gestión de Ventas
• Gestión de Demostraciones
• Gestión de Citas
• Gestión de Usuarios
• Gestión de Trámites Bancarios
• Gestión de Reportes
Representado estos componentes en la aplicación se obtiene la siguiente estructura de componentes:
Aplicación
Gestión de Gestión de Gestión de Gestión de Gestión de

ventas demostraciones citas usuarios reportes
Con la información recolectada sobre cada uno de los componentes de la aplicación los valores
establecidos para cada una de las funciones del programa son los siguientes:
Gestión de Ventas
Entradas Externas: 1 archivo con petición de 9 atributos =1B
1 archivo con petición de 3 atributos =1B
116
TOTAL : 2 BAJAS
Salidas Externas: 1 Archivos con salida de 6 atributos =1BAJA
Consultas Externas: 1 Archivo con 4 consultas
1 Archivo con 2 consultas
TOTAL: 2 BAJAS
Archivos Lógicos Internos: 1 Archivos con 4 atributos =1BAJA
1 Archivo con 6 atributos= 1BAJA
TOTAL: 2 BAJAS
Archivos de Interfaz externos: 0
Gestión de Demostraciones
Entradas Externas: archivo con petición de 13 atributos =1B
TOTAL: 2 BAJAS
Consultas Externas: 1 Archivo con 4 consultas =1BAJA
1 Archivo con 2 consultas =1BAJA
TOTAL: 2 BAJAS
Archivos Lógicos Internos: 0
Gestión de Citas
TOTAL: 2 BAJAS
Consultas Externas: 1 Archivo con 1 consulta =1BAJA
1 Archivo con 1 consulta =1BAJA
TOTAL: 2 BAJAS
Archivos Lógicos Internos: 0
117
Gestión de Usuarios
TOTAL: 2 BAJAS
1 Archivo con 1 consulta =1BAJA
TOTAL: 2 BAJAS
Archivos Lógicos Internos: 1 archivo con 10 atributos = 1BAJO
Gestión de Trámites Bancarios
Archivos Lógicos Internos: 1 archivo con 10 atributos = 1BAJO
Gestión de Reportes
Entradas Externas: 0
Salidas Externas: 0
Consultas Externas: 0
Archivos Lógicos Internos: 2 archivo con 12 atributos = 1 BAJO
118
Estos datos los resumimos en la siguiente tabla:
Parámetro del Complejidad Complejidad Complejidad Total

Sistema Baja Media Alta
Entradas
9*3 0 0 27
Externas (EI)
Salidas Externas
5*4 0 0 20
(EO)
Consultas
9*3 0 0 27
Externas (EQ)
Archivos lógicos
6*7 0 0 42
internos (ILF)
Archivos
de interfaz 0 0 0 0
externos (EIF)
Puntos de función sin ajustar (PFSA) 116
Ahora pasamos a establecer los factores de complejidad para determinar el facto de ajuste.
Valor
Nro. Factor de complejidad
(0 – 5)
1 Comunicación de datos 0
2 Proceso Distribuido 0
3 Objetivos de rendimiento 0
4 Configuración operacional compartida 0
5 Tasa de transacciones 2
6 Entrada de datos en línea 5
7 Eficiencia con el usuario final 0
8 Actualizaciones en línea 0
9 Lógica de proceso interno compleja 0
10 Reusabilidad de código 4
11 Conversión e instalación contempladas 0
12 Facilidad de operación 0
13 Instalaciones múltiples 0
14 Facilidad de cambios 0
TOTAL ACT 11
Luego calculamos el factor de ajuste considerando la fórmula dada:
FA = 0.65 + (0.01*11)
FA = 0,76
119
Ahora calculamos los puntos de función ajustados con la fórmula:
PFA = PFSA * FA
PFA = 116*0,76
PFA = 88,16
El siguiente paso es calcular el número de horas hombre de acuerdo a los puntos de función obtenidos.
Suponiendo que la aplicación la desarrollará un solo programador en PHP y HTML que son lenguajes
de tercera generación, la recomendación estándar de ISO para el valor equivalente a horas hombre/ PF,
nos dice que debe estar entre un rango de 10 a 20 PF/hora.
La aplicación será realizada mediante PHP y HTML, siendo estimado un 40 % de la aplicación HTML y un
60 % PHP. Por lo tanto se elige la opción para cálculo por valores porcentuales.
El programador que desarrollará la aplicación tiene un 70% de habilidades con el lenguaje PHP y un 90%
de conocimientos sobre html, por lo tanto se colocan los siguientes valores:
Porcentaje Nro. Puntos de Estimación Total Horas

Función Esfuerzo
60 52,896 13 687,648
40 35,264 11 387,904
Total esfuerzo en horas (E) 1075,552
Con esto hemos obtenido el número de horas requeridas, pudiendo redondear el número de horas 1076
horas de esfuerzo de una persona.
Nuevamente este cálculo no nos sirve para establecer la duración del tiempo en meses aunque
pudiéramos dividirlo para el número de horas al mes y para un cierto número de personas, esto no
resulta práctico debido a que no se trata de actividades mecánicas, sino que el desarrollo de software
comprende un gran número de actividades con secuencias lógicas que sólo podemos establecer cuando
se desarrolla el cronograma.
Lo que si podemos obtener con este valor es el costo, para lo cual debemos establecer un precio por hora
de esfuerzo, el cual nuevamente no tiene un estándar que lo defina, simplemente podríamos hablar de
una tasa de valor por hora establecida de acuerdo a la realidad de la empresa desarrolladora.
Si asumimos como tasa estándar 6 USD por hora de trabajo, entonces podríamos obtener el siguiente
costo aproximado del proyecto.
Costo = E*CostoHora
Costo = 1076 * 6
Costo = 6456 USD
Nuevamente estos valores son estimados y pueden estar sujetos a modificaciones, sin embargo si usted
conoce los procesos de planificación considerará este valor como referencia puesto que al igual que en la
estimación de tiempos es necesario realizar algunos procesos, en el presupuesto es necesario considerar
otros parámetros como los recursos que se usarán, la rentabilidad que se espera obtener.
120
Los valores por concepto de uso de servicios básicos, internet, uso de equipos, etc, se pueden establecer
como incluidos en el costo por hora de trabajo, con lo cual se simplifica mucho la estimación.
121
Anexo 3. Ejemplo de riesgos
122
Id. Riesgo Categoría Tipo riesgo Probabilidad Impacto Nivel Expos. Acción
Añadir nuevas características desde
R01 marketing (sin conocer las características Producto Requerimientos Media Alto 0,24 Plan de mitigación
específicas)
Proyecto
R02 Planificación demasiado optimista. Estimación Baja Medio 0,08 Plan de mitigación
Producto
Proyecto
R03 Diseño inadecuado (hay que volver a diseñar) Requerimientos Alta Alto 0,32 Plan de contingencia
Producto
Las nuevas herramientas de programación no Producto
R04 Herramientas Media Muy alto 0,36 Plan de contingencia
producen el ahorro prometido Empresa
Añadir un requisito para la actualización
R05 Producto Requerimientos Muy baja Bajo 0,02 Ninguna
automática desde el servidor
Escalas de impacto Escalas de probabilidad

Muy bajo 5% Muy baja 20%
Bajo 10% Baja 40%
Medio 20% Media 60%
Alto 40% Alta 80%
Muy alto 60% Muy alta 100%
Rango de tolerancia
Normal 0,01 - 0,06
Medio 0,07 - 0,31
Alto 0,32 - 1
MPAE-MESE/mcn/2013-08-14/122
pdf interactivo/gjmp/2018-08-22/123
ANEXOS
ISBN-10: 9942-04-423-X

Guia Didactica

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Guia Didactica

Cargado por

Copyright:

Formatos disponibles

Informática

Modalidad Abierta y a Distancia

La Universidad Católica de Loja

Facultad de Ingenieria y Arquitectura

UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA

Diagramación y Diseño digital:

6.1. Competencias genéricas........................................................................................................ 14

UNIDAD 1. TERMINOLOGÍA BÁSICA DE LA GESTIÓN DE PROYECTOS.................................... 18

UNIDAD 2. PROYECTOS DE INGENIERÍA DEL SOFTWARE...................................................... 32

UNIDAD 3. PLANIFICACIÓN DE PROYECTOS DE SOFTWARE.................................................. 48

UNIDAD 4. GESTION DE LA CALIDAD DEL SOFTWARE........................................................... 73

UNIDAD 5. ADMINISTRACIÓN DE LA CONFIGURACIÓN......................................................... 88

UNIDAD 6. MEJORA DE PROCESOS SOFTWARE..................................................................... 96

El componente educativo de Ingeniería de Software es una asignatura troncal de carrera que se

A lo largo de su carrera ha tenido la oportunidad de estudiar varios componentes educativos de la línea

En la Unidad 2 se plantea el desarrollo de aspectos esenciales respecto de los proyectos de desarrollo

La Unidad 3 se centra en los procesos de planificación y se intenta combinar técnicas y herramientas

1 Project Management Institute, www.pmi.org

• Sommerville, I. (2011). Ingeniería de Software. México: Pearson.

Guía didáctica elaborada para la materia de Ingeniería del software de la titulación de

• Project Management Institute. (2004). Guía de los fundamentos de la dirección de proyectos.

Tercera edición de la guía de los fundamentos de la dirección de proyectos, se usa sobre

Guía de los fundamentos de la dirección de proyectos del PMI, es un estándar internacional

Cuerpo de conocimiento de la ingeniería de software, de la IEEE computer Society, esta

• Pressman, R. (2010). Ingeniería del Software. Un enfoque práctico. México: McGrawHill.

• Texto relacionado ampliamente con los tema de desarrollo y gestión de proyectos de

• Publicación relacionada con la forma de gestionar los riesgos en un proyecto de desarrollo

• Sánchez, P. (2010). Gestión de riesgos. MATESCO.

• Estudio que aborda la diferencia de la gestión del riesgo entre el mantenimiento y el

• McConnell, S. (1997). Desarrollo y Gestion de Proyectos Informaticos. México: McGraw Hill.

• Silberman, A. (2011). Administración de riesgos en proyectos de desarrollo de software.

• Guía practica sobre la gestión de los riesgos en proyectos de desarrollo de software.

• Universidad de California. (2013). Introduction to project management. Recuperado de http://

• Universidad de Murcia. (2009). Fundamentos de Ingeniería del Software. Recuperado de

Curso de Ingeniería de software que le servirá para complementar su estudio en los

5. Orientaciones generales para el estudio

A lo largo del presente documento encontrará los siguientes focalizadores:

Cuando encuentre este focalizador deberá desarrollar alguna actividad como un

Cuando encuentre este ícono deberá desarrollar la autoevaluación de unidad, las

Este llamará su atención cuando el párrafo en cuestión denote aclaraciones

El sistema de estudios de la modalidad abierta y a distancia de la Universidad Técnica Particular de Loja

6. Proceso de enseñanza-aprendizaje para el logro de competencias

6.1. Competencias genéricas

Trabajo en equipo II: Contribuye en la consolidación y desarrollo del equipo, favoreciendo la

§§ Acepta y cumple las normas del grupo

§§ Contribuye al establecimiento y aplicación de los procesos de trabajo del equipo.

alcance, costo, tiempo,

6.3. Sistema de evaluación de la asignatura (primero y segundo bimestre)

Formas de evaluación 2. Heteroevaluación

investigación (cita fuentes de

pORCENTAJE 10% 20% 30% 70%

6.4. Orientaciones específicas para el aprendizaje por competencias

UNIDAD 1. TERMINOLOGÍA BÁSICA DE LA GESTIÓN DE PROYECTOS

1.1. Conceptos básicos de la gestión de proyectos

4 Project Management Institute, www.pmi.org

• La construcción de una casa.

• Oferta las asignaturas,

Indique si los elementos de la tabla 1.1 corresponden a proyectos o a operaciones:

Tabla 1.1: Lista de conceptos y operaciones.

Para comprobar sus respuestas puede remitirse al anexo 1. Soluciones a ejercicios.

Ciclo de vida del proyecto

6 Project Management Institute (2013) pp. 38

Figura 1.1 Modelo de ciclo de vida de proyectos7