INGENIERÍA EN SISTEMAS

COMPUTACIONALES

Métodos y Herramientas de Ingeniería de

Software

Daniel Rosas Mialma 2016110025

Sergio Sánchez Yañez 2016110033

José Alfredo Rodríguez Córdova 2016110029

Juan Carlos Urban Romero 2016110035

6 CUATRIMESTRE

Hotel Trivago

04/Octubre/2018

1
Índice
Índice de Tabla...............................................................................................2
Descripción del Software................................................................................3
Objetivo General.............................................................................................3
Objetivo Específico.........................................................................................3
Solicitudes de Cambio....................................................................................4
Solicitudes de Cambio....................................................................................5
Evaluación de las Solicitudes de Mantenimiento...........................................7
Plan de Cambios..........................................................................................10
Calendario de Actividades............................................................................11
Pruebas de Caja Blanca...............................................................................13

Índice de Tabla
Tabla 1. Solicitudes de Cambio. ................................................................ 4
Tabla 2. Plan de Cambios. ........................................................................ 9
Tabla 3. Grafo Base de Datos. ............................................................... 13 Tabla
4. Grafo Base de Datos. ................................................................ 13
Tabla 5. Grafo de Login. .......................................................................... 14
Tabla 6. Grafo de Login. .......................................................................... 15
Tabla 7. Grafo de Inserción de Datos. ..................................................... 17
Tabla 8. Grafo de Inserción de Datos. ..................................................... 17

2
1.Descripción del Software
El Sistema está diseñado a través de 3 interfaces cada una desempeña
una tarea independiente Se comienza con el proceso de login, la
segunda interfaz funciona para hacer una reservación o conectarse con
el bot Vago y la última tiene todos los datos necesarios para realizar el
registro de la reservación, con el cual, se hace una conexión con una
base de datos para guardar los registros y al final el bot se encarga de un
servicio para contestar dudas acerca de la reservación del Hotel.

2. Objetivo General
Definir los tipos de mantenimiento del software que se implementarán al
programa para mejorar el rendimiento y facilitar el entorno de los usuarios.

3. Objetivo Específico
• Analizar los tipos de mantenimiento
• Aplicar los tipos de mantenimiento
• Costos de mantenimiento de software
• Realizar la predicción de manteamiento y sus métricas.

3
 4. Solicitudes de Cambio
Tabla dePrioridades
Prioridad Tipo de Problema
5 reingeniería Sólo se Realizará una reingeniería
si los cambios son muy radicales y
los beneficios son a largo plazo.
3 correctivo Reparar algunos botones de la
interfaz que no funciona como
debería y la corrección de la
validación de datos dentro de la
base de datos.
2 perfectivo Mejorar el listado de preguntas y
respuestas del bot Vago.
Diseñar y corregir la base de
datos que enlaza la conexión con
la interfaz.
4 preventivo Mejorar la seguridad dentro de la
interface de login.
5 evolutivo En caso de mayores solicitudes de
registro y conexiones con el bot se
tendrá que realizar una mejora en
el tiempo de respuesta de los
servicios.

Tabla 1. Solicitudes de Cambio.

4
 5. Solicitudes de Cambio
Solicitud de Modificación

Sección 1
Número de Mr. Nombre de Solicitante: Recepción Sistemas: Creador:
1 Ángel Castro Flores 15/09/2018 Trivago DASU inc.

Descripción del Problema Prioridad: Menor

El programa cuenta con un fondo de interfaz el
cual desvía la atención de nuestros clientes

Sección 2
Número de Mr. Mantenedor Prioridad Tipo de Mantenimiento

1
Carlos Urban Romero Menor Correctivo

Sección 3
ID Petición Estado Del MR Fecha de Recepción

VAGO_14 Petición 15-sep

Análisis de
petición de El fondo interfiere en el desempeño visual de la interfaz por la gama
cambio de colores seleccionados.
Solicitud Cambio: Tabla 1.
Solicitud de Modificación

Sección 1
Número de Mr. Nombre de Solicitante: Recepción Sistemas: Creador:
2 Ángel Castro Flores 15/09/2018 Trivago DASU inc.
Descripción del Problema Prioridad: Menor

Podría mejorar el sistema de registro para que

no se abran más pestañas

Sección 2
Número de Mr. Mantenedor Prioridad Tipo de Mantenimiento

5
 2
Sergio Sanchez Yañez Menor Correctivo

Sección 3
ID Petición Estado Del MR Fecha de Recepción

VAGO_15 Petición 15-sep

Análisis de
petición de Es necesario debido a que al registrar es bastante tedioso el cambiar de
cambio ventanas
Solicitud cambio: Tabla 2.
Solicitud de Modificación

Sección 1
Número de Mr. Nombre de Solicitante: Recepción Sistemas: Creador:
3 Ángel Castro Flores 15/09/2018 Trivago DASU inc.
Descripción del Problema Prioridad: Menor

Los botones son poco intuitivos y difíciles de

manejar

Sección 2
Número de Mr. Mantenedor Prioridad Tipo de Mantenimiento

3
Alfredo Rodríguez Córdoba Menor Correctivo

Sección 3
ID Petición Estado Del MR Fecha de Recepción

VAGO_16 Petición 15-sep

Análisis de
petición de Es razonable debido al mal diseño de los botones lo que no permite una
cambio navegación fluida en la aplicación.
Solicitud cambio: Tabla 3.

Posibles cambios en el transcurso del tiempo, es decir, se comentarán

sobre los errores para que puedan ser detectados a tiempo y no le

6
perjudique al cliente abarcando desde los controles, interfaz, base de
datos, etc.

6. Evaluación de las Solicitudes de Mantenimiento

Análisis de las Solicitudes de Modificación

Nombre del Sistema Trivago

Responsable Daniel Rosas Mialma

Fecha de Recepción del Mr. 15/09/2018

Fecha de Aprobación/Negado 17/09/2018

Fecha de Cierre 30/09/2018

Descripción de la Motivo del

Número de Mr. ID MR Solución Estado del MR: Rechazo
Cambiar la imagen
1 VAGO-14 llamativa de la interfaz En progreso

Responsable del Análisis Carlos Urban Romero

Análisis de las Solicitudes de El fondo interfiere en el desempeño visual de la
Modificación interfaz por la gama de colores seleccionados.

Evaluación de las solicitudes: Tabla 1.

Análisis de las Solicitudes de Modificación

Nombre del Sistema Trivago

7
Responsable Carlos Urban Romero

8
Fecha de Recepción del Mr. 15/09/2018

Fecha de Aprobación/Negado Aprobado

9
Fecha de Cierre 30/09/2018

Descripción de la Motivo del

Número de Mr. ID MR Solución Estado del MR: Rechazo
Cambiar la imagen
2 VAGO-14 llamativa de la interfaz En progreso

Responsable del Análisis Sergio Sanchez Yañez

10
Análisis de las Solicitudes de Es necesario debido a que al registrar es bastante
Modificación tedioso el cambiar de ventanas.

Evaluación de las solicitudes: Tabla 2.

11
 Análisis de las Solicitudes de Modificación

Nombre del Sistema Trivago

Responsable Carlos Urban Romero

Fecha de Recepción del Mr. 15/09/2018

Fecha de Aprobación/Negado Aprobado

Fecha de Cierre 30/09/2018

Descripción de la Motivo del

Número de Mr. ID MR Solución Estado del MR: Rechazo
Cambiar la imagen
1 VAGO-14 llamativa de la interfaz En progreso

Responsable del Análisis Sergio Sanchez Yañez

Análisis de las Solicitudes de Es razonable debido al mal diseño de los botones lo
Modificación que no permite una navegación fluida en la interfaz.
Evaluación de las solicitudes: Tabla 3.

Se realizarán las actualizaciones cada determinado tiempo para que

nuestro software no tenga problemas al momento de ser utilizado por el

cliente, tomando en cuenta los siguientes puntos de la tabla realizada.

7. Plan de Cambios
Registros de Cambios

12
Nombre del Sistema
Trivago
Descripción del Sistema
Sistema de búsqueda de habitaciones de hotel
Responsable
Inicio de Fin de
Número Mr. ID Mr. Mantenimiento del Duración
Modificación Modificación
Mantenimiento
VAGO_ Carlos Urban
1 14 Correctivo Romero 15/09/2018 30/09/2018 15 días
VAGO_ Sergio Sanchez
2 15 Perfectivo Yañez 05/10/2018 25/10/2018 20 días
VAGO_ Alfredo
3 16 Correctivo Rodríguez 30/10/2018 20/11/2018 30 días

Tabla 2. Plan de Cambios.

Se validarán los posibles cambios al software que el cliente solicite considerando

el siguiente formato.

8. Calendario de Actividades
SEPTIEMBRE

13
 Lunes Martes Miércoles Jueves Viernes
17/09/2018 18/09/2018 19/09/2018 21/09/2018

Corre tv Prevén Perfec

24/09/2018 25/09/2018 26/09/2018 28/09/2018

EntreviC Preven

OCTUBRE

Lunes Martes Miércoles Jueves Viernes

01/10/2018 02/10/2018 03/10/2018 05/10/2018

Evolut Correctv

22/10/2018 23/10/2018 24/10/2018 26/10/2018

Perfect Preven EntreviC

NOVIEMBRE

Lunes Martes Miércoles Jueves Viernes

12/11/2018 13/11/2018 14/11/2018 16/11/2018

Corretv Preven Evolut

19/11/2018 20/11/2018 21/11/2018 23/11/2018

Corretv Perfect

26/11/2018 27/11/2018 28/11/2018 30/07/2018

Preven EntreviC

DICIEM

Lunes Martes Miércoles Jueves Viernes

10/12/2018 11/12/2018 12/12/2018 13/12/2018

Evolut Perfect

14
 16/12/2018 17/12/2018 18/12/2018

Corretv Reing

Tabla 5. Cronograma.

Cronograma de actividades a seguir para llevar un orden del

mantenimiento que se le realizará al software, posibles entrevistas con el
cliente para saber si se realizan modificaciones hasta una posible
reingeniería.
9. SIMBOLOGÍA
Entrev C = Entrevistas al cliente

Corr ectv= Correctivo

Prevent= Preventivo

Perfect= Perfectivo

Evolut= Evolutivo

Reing= Reingeniería

15
 10. Pruebas de Caja Blanca
Grafo Base de Datos

Hotel Primer case que encapsula todo

el programa
Trivago

Case que contiene el test de

Conexión
conexión a MySQL
DB

Case que contiene las

instrucciones de inserción
Agregar
para una consulta SQL
registro

Case que contiene las

Mostrar instrucciones de consulta de SQL
registro

Grafo 1. Conexión con base de datos.

Nuestro Grafo Principal se centra en la conexión de base de datos con el

código de la interfaz por lo cual nuestro grafo es secuencial donde se
muestra los métodos para realizar la inserción de datos y las consultas.

class ConexBD
{
MySqlConnection conn = new MySqlConnection();

String conexion = "Database=trivago; Data Source= localhost; User

Id=root;”;
String commandStr;
MySqlCommand command;

16
 MySqlDataReader reader;
MySqlDataAdapter da;
DataSet ds;

public void AgregarRegistro(String Instruccion)

{
conn.ConnectionString = conexion;
conn.Open(); commandStr =
Instruccion;

command = new MySqlCommand(commandStr, conn);

reader = command.ExecuteReader();
reader.Close(); conn.Close();
} public void
MostrarRegistros(String Comando)

En la tabla se muestra las operaciones realizadas para comprobar que el grafo

es correcto, donde se muestra los caminos y el resultado esperado.

Número de camino Camino independiente Resultado

C1 1-2-3-4 Registro insertado con

éxito

C2 1-2 Error
Tabla 3. Grafo Base de Datos.

V(G)=Número de regiones=1

17
V(G)=Aristas-nodos+2= 3-4+2=1 V(G)=Nodos predicado

+ 1 = 0+1 =1

Caminos:

C1: 1-2-3-4

C2: 1-2

Complejidad Evaluación Nivel de riesgo

ciclo matica

01-10 Programa Simple Sin riesgo

11-20 Programa más complejo Moderado

21-50 Programa complejo Alto

Más de 50 Programa no testeable Muy alto

Tabla 4. Grafo Base de Datos.

Por lo cual al evaluar en la tabla de riesgos se puede concluir que el programa es

de bajo riesgo.

18
Grafo de Login

Grafo 2. Login.

Nuestro Grafo de login se centra en el inicio de sesión de un usuario por

lo cual nuestro grafo contiene un if el cual se encarga de la lógica de
verificar si el usuario registro la contraseña correctamente y poder
acceder al formulario de registro.

19
 N.Camino Camino Resultado
independiente

C1 1 -2 -4 2

C2 1 -3 -5 2

Tabla 5. Grafo de Login.

V(G) Número de regiones= 2

V(G) Aristas – Nodos+2= 5 – 5 +2=2

V(G) Nodos predicados= 2 Posibles caminos:
C1: 1-2-4
C2: 1-3-5
En la tabla anterior se muestra las operaciones realizadas para
comprobar que el grafo es correcto, donde se muestra los caminos y el
resultado esperado donde a partir de un if el cual es un nodo predicado y
sus dos regiones del grafo se basa la lógica del código.
Complejidad Evaluación Nivel de riesgo
ciclomática

01-10 Programa Simple Sin riesgo

11-20 Programa más complejo Moderado

21-50 Programa complejo Alto

Más de 50 Programa no testeable Muy alto

Tabla 6. Grafo de Login.

Por lo cual al evaluar en la tabla de riesgos se puede concluir que la evaluación

del programa es de bajo riesgo.

20
Grafo de Inserción de Datos

Grafo 3. Inserción de datos.

El Grafo de inserción de datos se centra en el proceso de inserción de

datos dentro de los registros de la mayoría de nuestros formularios hacia
nuestra base de datos por lo cual nuestro diseño es secuencial.

21
En esta tabla se muestra las operaciones realizadas para comprobar que
el grafo es correcto, donde se muestra los caminos y el resultado
esperado donde a partir de un orden secuencial a través de los caminos
en donde se basa la lógica del código.
Camino Camino Resultado
independiente

C1 1-2-3-4-5-6-7-8-9-10- 11
11
Tabla 7. Grafo de Inserción de Datos.

V(G) Número de regiones= 1

V(G) Aristas – Nodos+2= 10 – 11 +2=1 V(G)
Nodos predicados= 0+1 =1 Posibles
caminos:
C1: 1-2-3-4-5-6-7-8-9-10-11

Complejidad Evaluación Nivel de riesgo

ciclomática

01-10 Programa Simple Sin riesgo

11-20 Programa más complejo Moderado

21-50 Programa complejo Alto

Más de 50 Programa no testeable Muy alto

Tabla 8. Grafo de Inserción de Datos.

Por lo cual al evaluar en la tabla de riesgos se puede concluir que la evaluación

del programa es de bajo riesgo.

22
 11. Métricas de tamaño
Definir medidas dentro de nuestro software es elemental para la posterior
evaluación del mismo, de manera en que se podrían obtener sus
características, que sería mejorable y realizar predicciones de algún
comportamiento no deseado.
Proyecto LOC Esfuerzo $(000) PP.doc Errores Defectos Personal

Hotel
Trivago 3
227 7 1 25 6 4
* * * * * * * *

* * * * * * * *

Tabla 9. Métricas del software.

En esta pequeña tabla demostramos que se hizo un análisis de métrica

de software donde se hacen visibles los errores del proyecto, el esfuerzo
aplicado al proyecto, los costos que este ha tenido, el número de páginas
documentadas y el número de personas que han participado en la
elaboración del mismo.

12. Métricas para la calidad del software

Estas métricas permiten ver los errores por áreas de procesos del
software y por lo tanto las correcciones necesarias en orden de entregar
un mejor producto final.

23
 Tabla 10. Tabla de métricas para la calidad del software.

De acuerdo a la información anteriormente recabada comprobando los

factores de calidad, el software es bastante flexible, lo cual permite una
corrección de errores y adición de nuevas funciones sin comprometer el
código del software a un mal funcionamiento, también cuenta con una
simplicidad que permite un mantenimiento que cumpla correctamente los
requerimientos del software.

13. Revisiones
Se evaluará el desempeño que el software tiene por diferentes rubros que se
tendrán presentes durante esta misma, además de que durante estas revisiones el

24
desarrollador deberá defender el porqué de la manera de programar y que función
en específico tiene, además de justificar por qué ese método es el más eficiente y
objetivo para este tipo de problema.

14. Revisiones informales

Descripción
Se hizo una revisión de código y de sentencias lógicas para corroborar que sea lo
más eficiente y solo lo necesario para lograr la máxima eficiencia.

Objetivo
Corregir errores y aumentar la eficiencia al corregir los errores y hacer énfasis en la
revisión del código en general.

Mecanismos
Lectura de código y revisión de los grafos, además de un conteo de líneas de
código, todo esto para revisar la eficiencia y la correcta aplicación de las
soluciones.

Descripción de la verificación de escritorio simple.

Se revisaron las diferentes características el lunes 5 de noviembre de 2018 de
12:10 a 12:30 pm en la Universidad Politécnica metropolitana.

Conjunto de listas de revisión.

Revisar si la mejora a la interfaz de registro fue realizada y aplicada la solución
sugerida.

Preguntas generales.
1.- ¿Se han seguido las buenas prácticas durante la elaboración del software?
Si se han seguido para que cualquiera que trabaje en el equipo pueda modificarlo.

2.- ¿Se han aplicado las soluciones en tiempo según lo planeado?

Todo se ha seguido conforme a las actividades marcadas en el calendario de
actividades.

25
 15. Revisiones formales
Descripción
Se evaluará el desempeño del programa junto con su trabajo y además se
evaluará la eficiencia y eficacia con las que fueron aplicadas las soluciones a los
problemas establecidos, el tiempo en el que se aplican y la manera.

Objetivo
Revisar si se aplican correctamente las soluciones o mejoras que se le planearon,
además de averiguar si están aplicadas de la manera más eficiente posible.

Mecanismos
Revisar el código y hacer un conteo de líneas, revisión de estructuras lógicas
usadas y un testeo de que tan estable son las mejoras y soluciones.

¿Qué fue lo que se revisó?

Las mejoras al software y las correcciones de errores planeadas de dentro del
calendario de actividades.

¿Quién lo reviso y cuándo?

Se revisará por parte de Daniel Rosas Mialma el día Lunes 5 de noviembre de
2018.

¿Cuáles fueron los descubrimientos y las conclusiones?

Aun por anexar.

16. Análisis de Aseguramiento de la Calidad

En esta tabla se describe los métodos y las descripciones de las pruebas y
correcciones que se realizaron con esto se podrá comprobar de los avances dentro
del proyecto.
Definiendo el problema, con el responsable, problema y seguimiento de los
avances de las correcciones.
Donde se revisó problemas desde el documento hasta la revisión del código donde
se siguió con los requerimientos de caja negra.

26
 Responsable Problemas Producto
Responsable
Seguimiento correctivo
Daniel Rosas Fallos Documento Sergio Se corrigió el
Mialma. en plan de Sanchez documento.
redacción. mantenimiento. Yañez.
Juan Carlos Fallos en el Programa hotel Juan Carlos Se corregirá el
Urban código. Trivago. Urban código.
Romero. Romero.
Alfredo Errores Programa hotel Alfredo Se modificarán
Rodríguez de Trivago. Rodríguez las interfaces.
Córdoba. diseño de la Córdoba.
interfaz.
Tabla 11. Métricas para la calidad del software.

17. Gestión de riesgos

El objetivo presente en esta área radica en asegurarse de que la gestión de riesgos
se realice y se haga de forma correcta.
Gestión de la calidad del software: Determina y aplica la política de calidad. El
aseguramiento de la calidad de software es el conjunto de actividades necesarias
para aportar la confianza en que el producto será suficientemente bueno para
satisfacer los requisitos de calidad.
Conjunto de actividades para evaluar el proceso mediante el cual se desarrolla el
producto. [IEEE].

27
 18. Evaluación de riesgos en el proyecto
En nuestro proyecto los riesgos más comunes detectados son los errores de
lógica, además de las demoras en entrega de avances o del producto lo cual
ocasiona una pérdida de dinero y crea una mala reputación.

Área Encarga Riesgo Priori Contingencia Entregable

do dad
Programación Juan Mala Alta Corrección de Plan de
Carlos programa errores. cambios.
Urban ción.
Romero
Diseño Daniel Interfaz Alta Revisión de Plan de
Rosas poco interfaces. cambios.
Mialma Intuitiva.
Pruebas Alfredo Uso de Alta Revisión de Plan de
Rodrígue metodos los métodos pruebas.
z incorrectos. usados.
Córdoba
Redacción Sergio Faltas de Medi Corrección de Documentación.
Sanchez ortografía y a los
Yañez mala errores de
redacción. redacción.
Tabla 12. Tabla de evaluación de riesgos en el proyecto.

28
19. Correspondencia de plan con el estándar IEEE
730
Secciones del estándar IEEE 730 Secciones de este plan
Propósito. Propósito.
Acrónimos abreviaturas, se agrega a Acrónimos abreviaturas, se agrega a
este plan. este plan.
Referencias. Referencias.
Gestión. Gestión.
Documentación. Documentación.
Estándares y métricas. Estándares y métricas.
Revisiones y auditorias. Revisiones y auditorias.
Test. Test.
Reporte de problemas y acción Reporte de problemas y acción
correctiva. Correctiva.
Gestión de riesgos. Gestión de riesgos.
Tabla 13. Tabla de plan con el estándar IEEE 730.

29
 20. Acrónimos y abreviaturas
• SQA: Aseguramiento de la calidad del software.
• SCM: Gestión de configuración del software.
• GP: Gestión del proyecto.

30
 21. Referencias
IEEE Std 730-1998, IEEE Standard of Software Quality Assurance Plans.
IEEE Std 730-1-1995, IEEE Guide for Software Quality Assurance Planning.
IS-1(2001) - Proyecto de Ingeniería de software.
IS-2(2001) - Modelo de calidad.

31
 22. Anexos
Minuta 5 de octubre
Fecha Número de Horario Lugar Observaciones
Revisión y Acuerdos
30 de 1 12:30 Salón, Se revisará los
Octubre UPMP avances del
documento
formales e
informales. Y
se preparara
para el debate
de revisión.
Tabla 14. Primera minuta.

Bitácora

Fecha Número de Horario Lugar Observaciones

Revisión
30 de 1 12:30 Salón, Verificación
Octubre UPMP del documento
y preparación
para la
realización del
debate.
5 de 2 12:20 Salón, Se realizó
Octubre UPMP revisión de
código y
documentos
además del
calendario y
tabla de caja
negra y se
realizó debate
correctamente.

32
Fecha Número de Horario Lugar Observaciones
Revisión
12 de 1 12:30 Salón, Comentario de
noviembre UPMP código y
(Fecha a aumentar
cambiar) respuestas
posibles del
bot, corregir el
documento.

Tabla 15. Tercera minuta.

33
 23. Modelo de capacidad y madurez integrada (CMMI).
El modelo (CMMI) es un modelo de referencia de prácticas maduras usadas para
evaluar y mejorar la capacidad de los procesos. Es una ruta evolutiva de
implementación de las mejores practicas en los procesos organizacionales.
Se utiliza para:
 Identificación de fortalezas y debilidades de organización.
 Identificación de contratistas a partir de su nivel (CMMI).
 Comprensión de las actividades necesarias para la mejora de procesos.
Este modelo se uso dentro del proyecto para conocer el estado en el que se
encuentra el software que estamos desarrollando
Software:
Debilidades Fortalezas
La interfaz es bastante compleja. La interfaz permite una
personalización superior a la
esperada.
El sistema de pago es lento. El sistema de pago es seguro para
evitar posibles robos.
Nuestro software no tiene un nivel de Software enriquecido con cuatro
complejidad muy alto. puntos de vista diferentes.
Tabla 16. Comparación de fortalezas y debilidades del software.

Debilidades Fortalezas

Muchos desacuerdos. Cooperación absoluta.

Falta de experiencia. Toma de decisiones clara.

Pocos conocimientos acerca de los Aportación de cada integrante en su

estándares. respectiva área.
Tabla 17. Comparación de fortalezas y debilidades del equipo.

34
 24. Proceso personal de software (PSP).
El proceso personal de software, PSP, es un conjunto de prácticas disciplinadas
para la gestión del tiempo y mejora de la productividad personal de los
programadores o ingenieros de software, en tareas de desarrollo y
mantenimiento de sistemas, mediante el seguimiento del desempeño predicho
frente al desempeño real. Está alineado y diseñado para emplearse en
organizaciones con modelos de procesos CMMI o ISO 15504.

Uno de los aspectos fundamentales de PSP es el uso de datos históricos para

analizar y mejorar el desempeño del proceso. La recolección de datos para PSP
es soportada por cuatro elementos importantes:

 Guiones.
 Métricas.
 Estándares.
 Formatos.

Los guiones de PSP proveen una guía de nivel experto para seguir los pasos del
proceso, los guiones proveen un marco de trabajo para aplicar las mediciones.
En PSP hay cuatro mediciones esenciales:

 Tamaño – el tamaño de una parte del producto, medido en líneas de

código (LOC) o piezas de software equivalentes (proxies) que facilitan la
medición.
 Esfuerzo – el tiempo requerido para cumplir una tarea, se suele medir en
minutos.
 Calidad – la cantidad de defectos en el producto.
 Agenda – una medición de progresión del proyecto, comparación de lo
planeado contra las fechas de cumplimiento actuales.

35
 25. Proceso para equipos de software (tsp).
En combinación con el Personal Software Process (PSP), el llamado Team
Software Process (TSP) proporciona un marco de trabajo de procesos definidos
que está diseñado para ayudarle a equipos de gerentes e ingenieros a organizar
y producir proyectos de software de gran escala, que tengan tamaños mayores a
varios miles de líneas de código. El objetivo del TSP es mejorar los niveles de
calidad y productividad de un proyecto de desarrollo de software de un equipo,
con el fin de ayudarlos a alcanzar los acuerdos de costos y tiempos en dicho
desarrollo.

Nombre Cargo Actividades

desarrolladas
Daniel Rosas Mialma Directiva Encargado de modelar
las ideas y supervisar
la correcta realización
de las mismas.
Juan Carlos Urban Programación Realizar el código del
Romero software y corregir los
errores.
José Alfredo Pruebas Comprobar que el
Rodríguez Córdoba código funcione
adecuadamente.
Sergio Sanchez Yañez Documentación Redactar los
documentos donde
explique los avances
del proyecto.

36
 25. Conclusión.
El software con nombre Trivago ha tenido realizados documentos como
solicitudes de mantenimiento, modificación, plan de cambios, pruebas de caja
blanca y negra, métricas acerca del equipo de desarrollo y del mismo producto
además de aseguramiento de la calidad del software.
Gracias a todos estos documentos los errores se hicieron mas que evidentes y
esto permitió poder realizar el mantenimiento y mejoramiento de software
alcanzando una mejor calidad.
Además de que se ha aprendido a realizar documentos para futuros proyectos.

37