Entrega FinalCalidad de Software PDF

FACULTAD DE INGENIERÍA Y CIENCIAS BÁSICAS
PROYECTO GRUPAL Institución Universitaria Politécnico Gran colombiano
TRABAJO COLABORATIVO PRUEBAS Y CALIDAD DE SOFTWARE
DAYANA MARCELA COGARIA BOADA
HOOLIBER FERNANDO RODRIGUEZ
ALVARO SANTIAGO OROZCO RODRIGUEZ
DIEGO FERNANDO SANCHEZ BAYONA
CRISTIAN ANDRES GARZON ROJAS
JOSE RODRIGO VELOSA
POLITÉCNICO GRAN COLOMBIANO

FACULTADA DE DISEÑO E INNOVACIÓN
PROGRAMA DE INGENIERIA DE SOFTWARE
BOGOTA D.C.
2020
pág. 1
RESUMEN
El desarrollo de software a día de hoy brinda muchas herramientas que permiten a las empresas
llegar a los objetivos de sistematizar sus productos y servicios ofreciendo una mejor calidad con
la que cubrir las necesidades y expectativas de los clientes. El presente trabajo tiene el objetivo de
mejorar los procesos de calidad para la empresa BREAK S.A.S en donde tomaremos como
primer indicador unas entrevistas realizadas en la empresa con el fin de realizar una comparación
entre los modelos de calidad para seleccionar el que más se adecue a las necesidades de la
empresa y con este insumo construir nuestro plan de trabajo. La posibilidad implementar las
buenas prácticas de desarrollo aprendidas durante el módulo, nos ofrece la oportunidad de
mejorar la competitividad y la calidad de software en Colombia.
PALABRAS CLAVES: Calidad de software, plan de trabajo, buenas prácticas, sistematizar,

clientes.
CONTENIDO
pág. 2
1. Introducción .......................................................................................................................................... 7
2. Entrega semana 3 .................................................................................................................................. 8
2.1. Primer Punto. ..................................................................................................................................... 8
2.2.Segundo Punto ..................................................................................... ¡Error! Marcador no definido.
2.3. Tercer Punto ........................................................................................ ¡Error! Marcador no definido.
2.4. Cuarto Punto ....................................................................................... ¡Error! Marcador no definido.
3. Bibliografia.............................................................................................. ¡Error! Marcador no definido.
pág. 3
LISTA DE TABLAS
Tabla 1: Modelos de Calidad de Software. ................................................................................................... 8
pág. 4
LISTA DE ILUSTRACIONES
Ilustración 1: Carpeta principal del proyecto repositorio en la nube ............ ¡Error! Marcador no definido.3
Ilustración 2: Subcarpetas repositorio en la nube ......................................... 1¡Error! Marcador no definido.
pág. 5
INTRODUCCIÓN
El creciente enfrentamiento entre organizaciones por ofrecer los productos de mayor calidad,
afecta de igual manera al mundo del software, por esto las empresas implementan modelos con
los cuales cubrir la optimización de recursos, la disminución de costos y la satisfacción del
cliente, esto se logra con la planificación desde el inicio de diferentes tareas divididas entre el
equipo de trabajo, esto nos sitúa en un plan de calidad con el objetivo de alcanzar los objetivos
estipulados para lograr una mejor calidad del software.
pág. 6
3. ENTREGA SEMANA 3
3.1 Primer Punto
Describa los elementos de los diversos modelos de calidad que se pueden aplicar al desarrollo de
productos de software, que le permitan realizar un comparativo entre ellos y determine los pro y
contras de cada uno en esfuerzo, tiempo, costo y beneficios.
MODELOS DE CALIDAD DE SOFTWARE

MODELO CARACTERISTICAS VENTAJAS DESVENTAJAS
Se basa en que el software• Une • Es un modelo
debe hacer lo que el usuarioelementos de otrosmuy costoso
BOEHM quiere que haga. El modelomodelos • Genera mucho
es incremental dividido en• Contiene untiempo el análisis
fases y cada fase tiene unalto rango de• Funciona
conjunto de tareas. características mejor en proyectos
primitivas grandes
Es el modelo donde se• Aumento de• Muy costoso
establecen las mejoresproductividad en tiempo y esfuerzo
CMMI prácticas de la industria• Mejora en la• Requiere
provee a las organizacionescalidad del producto mayor inversión para
aquellos elementos• Los clientesser implementado
esenciales para los procesosviven más
de negocio. informados.
Establece cinco• Proporciona • Genera mayor
características comouna vista común yuso de tiempo y costos
factores de calidad que son:comparable que semás elevados.
Funcionalidad, Usabilidad,reutiliza en cada• Tiene poca
FURPS Confiabilidad, Prestación yproyecto flexibilidad ya que
soporte las cuales son las• Sus criteriosasume que bastara
que le da su nombre son de fácilsiempre con un
compresión y ellosubconjunto de
facilita sufactores
implementación • Gran cantidad
de métricas que tiene
el modelo
CMM Es un modelo de• Reducción de• Desviaciones
evaluación de procesos deerrores y tiempo en plazo
una organización es el• Costo
modelo más utilizado midereducido
la capacidad del proceso
seguido para desarrollar
pág. 7
software
MAC CALL El modelo se basa en la• Practico y• Las

descomposición delfácil de entender ycaracterísticas son en
concepto genérico deaplicar general propiedades
calidad en tres capacidades• Focaliza en elabstractas mediante
importantes todo desde laproducto final métricas.
mirada del usuario • Focaliza • No siempre
medias precisas deexiste una relación
alto nivel. lineal entre valores de
las métricas y la
característica.
EFQM El modelo se puede aplicar• Favorece la• Rechazo inicial
con los objetivos decompetitividad ypor el nivel de
autoevaluación de lacalidad en la gestión. exigencia y mejora
organización, realizada por• Genera continua.
terceros. motivación y
participación interna.
DEMING Cada empresa realice su• Evaluación, • Toma mucho
autoevaluación, tieneefectividad, tiempo y esfuerzo
políticas de despliegue enconsistencia, desarrollarlo.
relación con la gestión decontinuidad y• Escala
calidad minuciosidad diseñada para un
• Los puesto ya que su
procedimientos dandiseño es
como resultadoespecíficamente para
escalas con un altoeste.
nivel de validez
SPICE/ISO/IEC Establece un marco de• Modelo de• No contiene
15504 requisitos para cualquierdos dimensiones. una estrategia de
proceso. Proporciona• Modelo másmejora del proceso.
requisitos para los modelosconsensuado y• Poco
de evaluación de losprobado. reconocimiento en el
procesos de las• Coherencia mercado
organizaciones. con otros modelos de• Permite que el
calidad yadominio de procesos
implementados sea tan amplio que se
hace difícil el manejo
de los procesos.
pág. 8
Tabla 1. Modelos de Calidad de Software.
3.2 Segundo Punto
Lleve a cabo las entrevistas necesarias en la empresa para determinar: debilidades, fortalezas,
oportunidades y amenazas. En general, conocer el modo de lograr una mejora en los procesos de
la empresa.
Nos hemos basado en la empresa “Break S.A.S” es una empresa con un amplio conocimiento en
el área tecnológica presta diferentes servicios, pero se centra en el desarrollo de Software.
La Empresa “Break S.A.S” en el desarrollo de software se centra solo en desarrollar para

empresas dedicadas al sector salud y asegurador para efectuar sus procesos administrativos,
manejan solo un lenguaje de programación y un administrador de base datos para crear sus
aplicaciones.
También implementan softwares para ERP como SAP y Dynamics 365 prestando soporte sobre
el mismo además de la mejora e incorporación de nuevos recursos solicitados por los clientes de
los softwares ya realizados anteriormente.
Los empleados tienen bien diferenciado sus funciones lo que hace que la empresa sea productiva
a nivel de desarrollo está el líder de proyecto, los desarrolladores, diseñadores web
administradores de base de datos
DEBILIDADES:
• El proceso de desarrollo no es tan rápido y ágil ya que no se establece un plan de trabajo

por lo que retrasa la implementación.
• La comunicación con el cliente no es muy asertiva.
• La toma de decisiones no las realiza el líder del proyecto si no el gerente lo que hace que
sea más demorado el proceso.
FORTALEZAS:
• Cuenta con experiencia en aplicaciones de ERP incluyendo Dynamics 365

• Sus desarrollos no presentan tantos problemas en la fase de pruebas
• Tienen una amplia red de soporte a usuarios que tienen problemas o requieren nuevas
funciones.
OPORTUNIDADES:
pág. 9
• El crecimiento de las plataformas ERP

• Gran rentabilidad con los desarrollos a los cuales los clientes pueden solicitar nuevas
funciones
• Una estable confianza con el cliente.
AMENAZAS:
• Demora en la toma de decisiones lo que conlleva al que el cliente no espere ese tiempo
• Mayor competitividad con otras empresas que mejoran sus procesos y utiliza nuevas
tecnologías.
• Los Recursos de capital pueden ser bajos por ser una empresa pequeña.
3.3 Tercer Punto
Establezca varios criterios que le permitan validar el estado de avance de su empresa (puede
tomar las KPA del modelo CMM y otros adicionales que considere afecten su decisión) frente a
cada modelo y los elementos que describió. Indique los dos modelos que considere más
adecuados para lograr la calidad en los productos de software que su empresa desarrolla ya sean
internos o externos.
Al utilizar el modelo CMM podemos mejorar y direccionar el desarrollo del proyecto para que
tengamos una orientación hacia un proceso estándar repetible y, por lo tanto, podamos reducir el
tiempo de aprendizaje sobre cómo hacer lo planteado, conforme al desarrollo de esto podamos
ejecutar los niveles del CMM satisfactoriamente sobre esta metodología de calidad de software.
En los criterios que podemos evidenciar el avance de la empresa debemos tener en cuenta las
debilidades y las oportunidades que en resumen nos indican un desarrollo sin metodologías agiles
en las cuales se evidencia la poca comunicación con el cliente. Con un modelo de calidad y
optimización podemos solventar esta problemática para que ambas partes ganen. En ese orden de
ideas esta empresa se encuentra en el nivel 2 de CMM donde los requerimientos del proyecto no
suelen ser claros, comprendidos y controlados.
Criterios Hallazgos o elementos

Gestión de requisitos El modelo actual de la empresa no es eficiente lo que
hace que los tiempos de gestión sean altos y en
ocasiones no podamos cumplir con lo pactado en
fechas estipuladas con los clientes
Planeación del proyecto No son claras las instrucciones ni el plan de trabajo
pág. 10
para seguir por el líder del proyecto, esto conlleva a

que las diferentes áreas involucradas tengan una mala
comunicación y no trabajen en sincronía.
Seguimiento y supervisión del proyecto El control de los avances no es óptimo lo que hace que
los desarrolladores pierdan tiempo y tengan que
realizar más cambios de los que deberían
Garantía de calidad de Software Al no tener control y seguimiento claro sobre los
desarrollos se pueden escapar detalles fundamentales
que pueden influir en el éxito del proyecto
Definición el proceso de la organización Se evidencia que no se tienen controlados todos los
criterios anteriores estamos teniendo falencias en la
organización lo que nos lleva a tener que invertir más
dinero del que deberíamos y alargar nuestros procesos
de desarrollo
Gestión de calidad de software Este es de los criterios principales ya que a pesar de
que se tenga una buena organización sin la calidad de
software no habría ningún avance, en la empresa
como tal no se evidencia actualmente un proceso de
gestión de calidad, se sugiere que se tenga como
prioridad.
Prevención de defectos Siguiendo por la parte de la gestión de calidad
tampoco evidenciamos alguna prevención de defectos
en el desarrollo. Esto nos provocara futuros
desarrollos y gasto de presupuestos que no tenemos
en cuenta a la hora del desarrollo inicial.
Partiendo de lo anterior se procederá a trabajar con los modelos Sm3 y PPQA en los cuales se
tendrá como prioridad el proceso del mantenimiento del software con el modelo de madurez y
teniendo en cuanta todos aspectos al momento del desarrollo con el modelo de calidad en cual
podamos optimizar los recursos y utilizarlos de la manera productiva, estos nos permitirán tener
un estándar y un control para las necesidades del cliente.
pág. 11
3.4 Cuarto Punto
Establezca la lista de actividades, procesos y procedimientos a lo largo del ciclo de vida del
desarrollo de productos de software que requieren de definición en su empresa para permitir la
implantación de un proceso de pruebas que aumenten la calidad y permita que un plan de pruebas
fluya
• Definición de requisitos
• Pruebas de Aceptación
• Diseño Funcional del Sistema
• Pruebas de Sistema
• Diseño Técnico del Sistema
• Pruebas de Integración
• Especificación de Componentes
• Programación
• Definición de la metodología de pruebas
• Definición de herramientas (Mantis, Teslink, Jira etc.)
• Proceso de pruebas:
1. PLANEACIÓN
i.Histórico del proyecto

ii.Documentos Base del proyecto
iii.Actas de contextualización
iv.Documento de estrategia de pruebas
v.Estimación de tiempos
2. DISEÑO
i.Histórico
ii.Set de datos del proyecto
iii.Matriz de casos de prueba
3. EJECUCIÓN
i.Ciclo 1
ii.Ciclo 2
iii.Ciclo de regresión
iv.UAT
pág. 12
v.Carta de certificación del proyecto
4. EVALUACIÓN Y GESTIÓN
i.Actas de reunión
ii.Informes de avance
iii.Bitácora de definiciones realizadas durante la vida del proyecto
iv.Matriz de gestión de riesgos
Repositorio centralizado en la nube para el manejo de proyectos de software.
Ilustración 1. Carpeta principal del proyecto repositorio en la nube
Ilustración 2. Subcarpetas repositorio en la nube
pág. 13
Modelo Iterativo
Las actividades: definición de requisitos, diseño, desarrollo y pruebas se segmentan en pasos

reducidos y se ejecutan de forma continua, se debe alcanzar el consentimiento del cliente tras
cada interacción con el objeto de poder modificar el proyecto si fuera necesario.
Modelo Prototipado: Desarrollo rápido de una representación del sistema que pudiera ser objeto
de uso, seguida de modificaciones sucesivas hasta que el sistema sea finalizado
pág. 14
5. ENTREGA SEMANA 5
De acuerdo con las necesidades establecidas en la entrega anterior, documente las

actividades, procesos y procedimientos que se requieran para llevar a cabo la mejora de la
calidad en el desarrollo de productos de software en la empresa.
5.1. RESPONSABLES DE LAS PRUEBAS

• El Líder de Certificación
Realiza la lectura, validación y verificación de los entregables en los casos en los que aplique.
Contextualiza las pruebas a realizar al ingeniero o analista de certificación y realiza seguimientos
periódicos durante todo el proceso de certificación.
• Líder Encargado
Realiza control sobre las actividades de certificación y aclara inquietudes sobre el alcance y
algunas validaciones a tener en cuenta sobre la solución desarrollada.
• Líder Técnico
Aclara inquietudes sobre el alcance y algunas validaciones a tener en cuenta sobre la solución
desarrollada, asegura la ejecución de las pruebas unitarias de parte de los desarrolladores
• Líder de Proyecto
Realiza seguimiento por requerimiento funcional y en caso de que certificación no dé el aval para
la puesta en producción, solicita al comité de control de cambios la revisión respectiva para poder
generar el plan de acción correspondiente.
• El Analista o Ingeniero de Certificación
Realiza la lectura, validación y verificación de los entregables, realiza la ejecución de los casos
de prueba, en los casos donde asistió a la reunión de entendimiento y realizó la estimación de
tiempos es quien contextualiza las pruebas a realizar al ingeniero o analista de certificación.
realiza los reportes de gestión de incidentes, mantiene informado al Líder Encargado con los
avances de la ejecución, brinda soporte a las pruebas de aceptación ejecutadas por el cliente y
realiza revisión final de los entregables.
pág. 15
5.2. TIPOS DE PRUEBAS

Los tipos de pruebas que se aplicarán sobre los productos de desarrollo serán los siguientes:
• Pruebas unitarias. Pruebas realizadas en componentes individuales en la etapa de desarrollo.
• Pruebas funcionales. Estas pruebas incluyen lo siguiente:
A) Pruebas funcionales (pueden incluir smoke test)
B) Pruebas funcionales de seguridad
• Pruebas de regresión. Consiste en repetir la ejecución de un conjunto de casos de prueba para
verificar que unos cambios en los componentes mantengan la funcionalidad. La cantidad de
casos de prueba ejecutados en una prueba de regresión dependerá del impacto del cambio. Se
realizarán cuando se encuentren fallas en las pruebas de liberación de cada entregable.
• Pruebas funcionales con VISA
• Análisis de vulnerabilidades. Tiene como objetivo determinar si existen debilidades desde el
punto de vista de seguridad en componentes de software. La ejecución de pruebas de
vulnerabilidad se debe realizar como mínimo en todas las aplicaciones que están de cara al
usuario final, estas pruebas estarán a cargo del Ingeniero de Seguridad. Las etapas para el
manejo de las vulnerabilidades son:
a) Ejecutar las pruebas de vulnerabilidad.
b) Revisar las vulnerabilidades para determinar cuáles se deben tratar y cuáles son falsos
positivos.
c) Tratar e las vulnerabilidades con nivel de calificación alto y medio.
d) Implementar las remediaciones a las vulnerabilidades en ambiente de certificación.
e) Ejecutar pruebas de vulnerabilidades para verificar que se hayan remediado
5.3 ANALISIS DE PRUEBAS

En esta fase debemos conocer el histórico del proyecto y solicitamos al PMO los diferentes
documentos los cuales almacenamos en nuestro repositorio compartido, con el fin de garantizar la
trazabilidad. De la misma forma se anexan actas, documentos de estrategia de pruebas y la
estimación de tiempo aprobada.
pág. 16
5.4 DISEÑO DE PRUEBAS

En este apartado se especifica la cantidad de las pruebas, la cual permitirá; definir y asignar
prioridades como alta, media o baja además de establecer un orden de trabajo y dar una
estimación del tiempo en probar cada funcionalidad. También se recopila el set de datos a utilizar
en las pruebas, se crea la matriz de casos de prueba y se gestiona la aprobación de la misma por
correo.
5.5 EJECUCIÓN DE PRUEBAS

En esta fase definimos los ciclos (C1,C2…Cn) que se requieren para garantizar la calidad del
producto hasta llegar a un ciclo de Regresión donde se seleccionan solo un porcentaje sobre los
casos fallados en ciclos anteriores. Luego se realiza las pruebas UAT y aceptación de usuario
pág. 17
para finalmente emitir la carta de Certificación y pasar el proyecto a PRODUCCIÓN. En el

repositorio se almacena cada uno de los artefactos.
5.6 MANEJO DE DEFECTOS

Los defectos detectados por el equipo de pruebas o por el cliente durante UAT, serán
documentados formalmente en ALM. ALM a su vez, enviará un correo electrónico automático al
desarrollador o quien realice sus veces, con los detalles y los adjuntos necesarios a reproducir y
corregir el defecto.
Los defectos se clasificarán de acuerdo con las siguientes severidades:
• Alta Estos defectos son considerados como "Show Stoppers" y deben corregirse
inmediatamente. Ningún proyecto debe ser liberado al ambiente de producción con defectos de
alta severidad.
• Mediana Defectos que no impiden seguir probando el proyecto, pero que deben ser corregidos
en la próxima versión del código de software que se probará.
• Baja Defectos que son típicamente estéticos y no necesariamente impactan la funcionalidad
pág. 18
PLANTILLA DE ESTIMACIÓN DE TIEMPOS
pág. 19
pág. 20
PLANTILLA DE CASOS DE PRUEBA
PLANTILLA DE TOMA DE EVIDENCIAS
pág. 21
FORMATO DE ACTA DE REUNIONES
pág. 22
Semana 7
En resumen, el proceso de pruebas propuesto consta de las siguientes fases:
Nota: Dichas fases pueden sobreponerse y/o ocurrir al mismo tiempo.
• La planeación es la actividad de verificar la misión, definir los objetivos y especificar las

actividades de las pruebas.
• Se determina el alcance (Estimación de tiempos, recursos y presupuesto) de la prueba y los
riesgos.
• Se establece la estrategia de pruebas y las herramientas a utilizar
• Se determinan los criterios de salida
• La planeación puede ser actualizada teniendo en cuenta los resultados de las actividades de
control.
• Los objetivos de las pruebas se convierten en casos de pruebas tangibles. Constan de las
siguientes actividades:
o Revisar la base de las pruebas (requerimientos, arquitectura, diseño e interfaces).
o Identificar y priorizar las condiciones de prueba basado en análisis de elementos de
prueba, le especificación, comportamiento y estructura. O la viabilidad de crear datos de
prueba.
o Diseñar y priorizar casos de prueba e identificar los casos de prueba
o Diseñar la configuración del ambiente de prueba e identificar la infraestructura y
herramientas requeridas.
o Evaluar la testeabilidad de pruebas de la base de pruebas.
pág. 23
• Es la fase en la que se ejecutan los casos de prueba combinando en un orden particular, con
todos los elementos que hemos preparado previamente.
• Se debe configurar con el ambiente configurado
• Esta fase cuenta con las siguientes actividades principales
o Ejecutar ya sea manual o automático
o Preparar y validar ambientes de pruebas, datos, script automatizados etc.
• Crear los casos de prueba (test suite - escenario).
• Registrar los resultados de la ejecución
• Comparar los resultados obtenidos con los esperados.
• Reportar incidentes y analizarlos
• Repetir las actividades de prueba según corresponda.
• Verificar que los defectos se solucionaron y no se inyectaron nuevos.
• Se evalúan las respuestas obtenidas contra los objetivos definidos

• Se debe realizar la evaluación por cada nivel de prueba
• La evaluación de prueba tiene las siguientes actividades:
o Verificar los registros de prueba con los criterios de salida
o Evaluar si se requieren más pruebas o si los criterios deben ser modificados
o Realizar informe de resumen de las pruebas y compartirlo con las personas involucradas.
• Se consolida la información de la prueba y se recopilan las experiencias como lecciones

aprendidas.
• Se elabora informe post-mortem de la prueba.
• Se generan estadísticas, conclusiones de los resultados obtenidos.
• Verificar entregables planeados vs entregados, cierre de reportes de incidentes o registros de
cambios abiertos y la documentación de aceptación.
• Dar por terminado y archivar los soportes de pruebas, del ambiente de pruebas y la
infraestructura de pruebas para un uso posterior.
• Entrega de utensilios
pág. 24
• Analizar las enseñanzas aprendidas.
LISTA DE CHEQUEO:
Debemos dejar claramente establecidas los aspectos más importantes y de los cuales realizaremos el
control con ayuda de la lista, como los aspectos a resaltar tenemos las actividades realizadas donde se
evalúan los procedimientos, las incidencias donde tenemos la oportunidad de mejorar procesos, y la
entrega donde verificamos que cumplimos las expectativas del cliente, con estos datos almacenados a lo
largo del tiempo podremos generar gráficos, comparativos, dispersiones, histogramas y tendencias.
CONTROL DE CALIDAD DE SOFTWARE
Ítem/s inspeccionado/s: Fecha:

Puntos chequeados: 1 2 3 Revisor:
1. Actividades realizadas
¿Se siguieron los procedimientos? SI NO N/A
¿Se usaron las revisiones vigentes de los SI NO N/A
procedimientos?
¿Se compararon procedimientos anteriores? SI NO N/A
2. Incidencias
¿Éxito en las pruebas realizadas? SI NO N/A
¿Existe alguna incidencia relacionada? SI NO N/A
¿Hubo retrasos en el desarrollo? SI NO N/A
Código incidencias relacionadas:
3. Entrega
¿Código validado por el equipo? SI NO N/A
¿Producto conforme a las especificaciones del SI NO N/A
cliente?
Observaciones
NOTA: N/A = No aplicable.
pág. 25
CONTROL DE REUNIONES
El ritmo de trabajo de hoy día no dice que debemos utilizar nuestro tiempo lo más eficientemente
posible para brindarle el mejor servicio a los clientes, por esta razón en la actualmente contamos con
herramientas que nos facilitan la organización de reuniones, actas asistencias, etc. Por estos motivos se
decidió utilizar un organizador de reuniones basado en la nube para gestionar de manera óptima el
proyecto.
Registro y planificación de reuniones, se comunicara a los responsables vía correo electrónico
Se tomará asistencia de las reuniones además de asignar tareas basadas en los reportes realizados
durante el evento.
pág. 26
Utilizando estas métricas obtendremos el objetivo de organizar y gestionar al máximo el tiempo

invertido en este tipo de encuentros de trabajo.
pág. 27
Bibliografía
Cuadro comparativo de Modelos de Calidad - Modulo Evaluación RED. (2020). Retrieved 21

September 2020, from https://sites.google.com/site/moduloevaluacionred/home/modelo-de-
calidad-del-producto-software-segun-iso-iec-9126
Modelo de Calidad McCall. (2020). Retrieved 21 September 2020, from https://modelos-de-evaluacion-

de-los-red-grupo-8-udes.fandom.com/es/wiki/Modelo_de_Calidad_McCall
Capability Maturity Model. (2020). Retrieved 21 September 2020, from

https://es.wikipedia.org/wiki/Capability_Maturity_Model#:~:text=El%20Modelo%20de%20Madurez%20d
e,Software%20Engineering%20Institute%20(SEI).
(2020). Retrieved 21 September 2020, from

https://www.ctr.unican.es/asignaturas/MC_OO/Doc/OO_08_I2_Proceso.pdf
rafaelfreites gonzalez, M. (2020). Procesos de software - Monografias.com. Retrieved 21 September

2020, from https://www.monografias.com/trabajos96/procesos-software/procesos-software.shtml
pág. 28

Entrega FinalCalidad de Software PDF

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

Entrega FinalCalidad de Software PDF

Cargado por

Copyright:

Formatos disponibles

FACULTAD DE INGENIERÍA Y CIENCIAS BÁSICAS

PROYECTO GRUPAL Institución Universitaria Politécnico Gran colombiano

TRABAJO COLABORATIVO PRUEBAS Y CALIDAD DE SOFTWARE

DAYANA MARCELA COGARIA BOADA

HOOLIBER FERNANDO RODRIGUEZ

ALVARO SANTIAGO OROZCO RODRIGUEZ

DIEGO FERNANDO SANCHEZ BAYONA

CRISTIAN ANDRES GARZON ROJAS

JOSE RODRIGO VELOSA

POLITÉCNICO GRAN COLOMBIANO

PROYECTO GRUPAL Institución Universitaria Politécnico Gran colombiano

PALABRAS CLAVES: Calidad de software, plan de trabajo, buenas prácticas, sistematizar,

PROYECTO GRUPAL Institución Universitaria Politécnico Gran colombiano

PROYECTO GRUPAL Institución Universitaria Politécnico Gran colombiano

PROYECTO GRUPAL Institución Universitaria Politécnico Gran colombiano

PROYECTO GRUPAL Institución Universitaria Politécnico Gran colombiano

PROYECTO GRUPAL Institución Universitaria Politécnico Gran colombiano

3.1 Primer Punto

MODELOS DE CALIDAD DE SOFTWARE

PROYECTO GRUPAL Institución Universitaria Politécnico Gran colombiano

MAC CALL El modelo se basa en la• Practico y• Las

PROYECTO GRUPAL Institución Universitaria Politécnico Gran colombiano

Tabla 1. Modelos de Calidad de Software.

3.2 Segundo Punto

La Empresa “Break S.A.S” en el desarrollo de software se centra solo en desarrollar para

• El proceso de desarrollo no es tan rápido y ágil ya que no se establece un plan de trabajo

• Cuenta con experiencia en aplicaciones de ERP incluyendo Dynamics 365

PROYECTO GRUPAL Institución Universitaria Politécnico Gran colombiano

• El crecimiento de las plataformas ERP

3.3 Tercer Punto

Criterios Hallazgos o elementos

PROYECTO GRUPAL Institución Universitaria Politécnico Gran colombiano

para seguir por el líder del proyecto, esto conlleva a

PROYECTO GRUPAL Institución Universitaria Politécnico Gran colombiano

3.4 Cuarto Punto

i.Histórico del proyecto

PROYECTO GRUPAL Institución Universitaria Politécnico Gran colombiano

v.Carta de certificación del proyecto

Repositorio centralizado en la nube para el manejo de proyectos de software.

Ilustración 1. Carpeta principal del proyecto repositorio en la nube

Ilustración 2. Subcarpetas repositorio en la nube

PROYECTO GRUPAL Institución Universitaria Politécnico Gran colombiano

Las actividades: definición de requisitos, diseño, desarrollo y pruebas se segmentan en pasos

PROYECTO GRUPAL Institución Universitaria Politécnico Gran colombiano

De acuerdo con las necesidades establecidas en la entrega anterior, documente las

5.1. RESPONSABLES DE LAS PRUEBAS

PROYECTO GRUPAL Institución Universitaria Politécnico Gran colombiano

5.2. TIPOS DE PRUEBAS

5.3 ANALISIS DE PRUEBAS

PROYECTO GRUPAL Institución Universitaria Politécnico Gran colombiano

5.4 DISEÑO DE PRUEBAS

5.5 EJECUCIÓN DE PRUEBAS

PROYECTO GRUPAL Institución Universitaria Politécnico Gran colombiano

para finalmente emitir la carta de Certificación y pasar el proyecto a PRODUCCIÓN. En el

5.6 MANEJO DE DEFECTOS

PROYECTO GRUPAL Institución Universitaria Politécnico Gran colombiano

PLANTILLA DE ESTIMACIÓN DE TIEMPOS

PROYECTO GRUPAL Institución Universitaria Politécnico Gran colombiano

PROYECTO GRUPAL Institución Universitaria Politécnico Gran colombiano

PLANTILLA DE CASOS DE PRUEBA

PLANTILLA DE TOMA DE EVIDENCIAS

PROYECTO GRUPAL Institución Universitaria Politécnico Gran colombiano

FORMATO DE ACTA DE REUNIONES