SlideShare ist ein Scribd-Unternehmen logo
1 von 17
Downloaden Sie, um offline zu lesen
PASO 8 – PROPUESTA AMPLIADA
Presentado por:
MARIA ANGELICA REYES
CRISTIAM HUMBERTO GOMEZ
JHON FREDDY MALDONADO
JORGE ALBERTO REYES
JEAN CARLOS VEGA
Presentado a:
DIANA CARDONA ROMAN
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD
INGENIERIA DE SISTEMAS
BUCARAMANGA
2019
CONTENIDO
ANTECEDENTES...................................................................................................................3
ESTADO DEL ARTE..............................................................................................................4
MARCO TEORICO.................................................................................................................7
MARCO CONCEPTUAL.........................................................................................................8
MARCO TECNOLOGICO.......................................................................................................9
TIPO DE INVESTIGACION..................................................................................................10
ENFOQUE DE INVESTIGACION ........................................................................................10
POBLACION Y MUESTRA...................................................................................................10
FORMULACION DE HIPOTESIS.........................................................................................10
DISEÑO DE INSTRUMENTOS DE INDAGACION .............................................................11
METODOLOGIA...................................................................................................................11
PRESUPUESTO...................................................................................................................14
CRONOGRAMA ...................................................................................................................16
REFERENCIAS ....................................................................................................................17
ANTECEDENTES
Los procesos y actividades en las organizaciones han llevado a la creación de un
sin número de herramientas informáticas que permitan un mejor desempeño de las
mismas, dado lo anterior muchas empresas desarrolladoras han entrado en auge
con la creación de aplicaciones que satisfagan las necesidades de sus clientes, sin
embargo esto también ha ocasionado que muchas empresas sufran ataques
cibernéticos, la especialista en seguridad informática Silvia M. Diaz en su artículo
titulado Pruebas de seguridad en aplicaciones web como imperativo en la calidad
de desarrollo del software publicado en el 2013 menciona lo siguiente “Las
aplicaciones web están expuestas a un gran número de amenazas, tales como el
mal uso por parte de los usuarios, ataques de seguridad, mala calidad del software
o falta de un proceso de desarrollo estructurado” y por tal motivo indicaba que es
necesario que durante el ciclo de desarrollo de software se implementara un modelo
que permitiera realizar por así decirlo un acompañamiento en cada fase del ciclo.
Una guía elaborada para OWASP Foundation (2008), menciona lo siguiente “Las
organizaciones de desarrollo no incluyen pruebas de seguridad como parte de su
proceso de desarrollo de software estándar… Las pruebas han demostrado ser un
ingrediente clave en cualquier organización que necesita confiar en el software que
produce o utiliza” como vemos esta guía concientiza por la necesidad de las pruebas
de seguridad y por tanto en su guía muestra una serie de buenas prácticas que
ayudan a mitigar los ataques cibernéticos.
Un tercer trabajo elaborado por los ingenieros Pablo Andrés Vaca, Calixto
Maldonado, Claudia Inchaurrondo, Juan Peretti, María Soledad Romero y Matías
Bueno, destacan la importancia de los Test-Driven Development (TDD), la cual la
describen de la siguiente manera “práctica iterativa de diseño de software orientado
a objetos” y que consta de tres fases, test firts aquí se escribe una prueba y se
verifica que las pruebas fallan, después, se implementa el código que hace que la
prueba pase satisfactoriamente, la segunda fase es la automatización y esta en
particular es la que más nos interesa, esta hace referencia a la ejecución automática
de las pruebas (código) y por ultimo refactorizar, lo cual permite que se mantenga
la calidad.
El objetivo del anterior trabajo es estudiar y enmarcar las metodologías TDD en la
industria, con el fin de mostrar sus particularidades, así como los proyectos donde
aplicarlos, sus ventajas y desventajas.
ESTADO DEL ARTE
TEMA
Test-Driven Development - Una aproximación para entender su
utilidad en el proceso de desarrollo de Software.
AUTOR
Ing. Pablo Andrés Vaca, Ing. Calixto Maldonado, Ing. Claudia
Inchaurrondo, Ing. Juan Peretti, Ing. María Soledad Romero,
Ing. Matías Bueno
FUENTE
http://www.conaiisi.unsl.edu.ar/portugues/2013/158-524-1-
DR.pdf
AÑO Octubre de, 2013
RESUMEN
El desarrollo de software plantea muchos desafíos a los equipos
de trabajo, estos retos van desde entender lo que el mercado y
los clientes necesitan, hasta brindar soluciones integrales que
cubran todos los aspectos de una organización manteniendo los
costos controlados y brindando mejoras a las organizaciones.
Uno de los desafíos más grandes es lograr garantizar la calidad
de los productos de software y mejorar la productividad a lo largo
del ciclo de vida del mismo, desde el comienzo del desarrollo
hasta las etapas de mantenimiento. Este es un reto enorme ya
que actualmente los requerimientos son mucho más volátiles
que en el pasado, lo cual convierte a los cambios en el software
en un momento en el cual potencialmente se introducen muchos
errores, ocasionando que funcionalidades ya implementadas
empiecen a fallar, aparecen muchas fallas o errores, llamados
“Bugs” en la etapa de mantenimiento. En respuesta a esto se
introducen más equipos de pruebas para realizar todo tipo de
ellas, desde pruebas exploratorias hasta pruebas de regresión
extensivas, las cuales toman mucho tiempo. Esto ocasiona que
en muchos casos no se puedan utilizar metodologías ágiles,
tales como eXtreme Programming (XP), ya que éstas se basan
en períodos de desarrollo cortos (dos a cuatro semanas) y al
final de los mismos se entrega un producto de software
funcional. Esta práctica es posible sólo si se logra incorporar
herramientas que agilicen la ejecución de grandes cantidades
de casos de pruebas en cuestión de minutos, permitiendo a los
miembros del equipo efectuar un desarrollo incremental y
continuo del software, manteniendo la integridad del producto.
PROBLEMA DE LA
INVESTIGACION
Desarrollos Ágiles, Testing, Automatización de pruebas,
Automatización. Automation Tests, Unit Tests, BDD, TDD,
Scrum.
PRINCIPALES
CONCEPTOS
Automatización: las pruebas deben ser escritas en código, y esto
permite que se ejecuten automáticamente las veces que sea
necesario, y el solo hecho de ejecutar las pruebas1 debe
mostrar si la ejecución fue correcta o no
METODOLOGIA
Para llevar a cabo esta propuesta se realizó una revisión
sistematizada de la literatura existente. Una revisión
sistematizada es un estudio empírico de trabajos primarios y
secundarios publicados, para ello, hemos utilizado como soporte
de guía un trabajo de un grupo de investigadores de Gran
Bretaña [1] y otro trabajo conjunto de un grupo de investigadores
españoles y Croatas [2]. Además, nos hemos basado en las
guías que se proveen en el trabajo “PRESENTACIÓN POR
ESCRITO DE LA REVISIÓN BIBLIOGRÁFICA
TITULO
Pruebas de seguridad en aplicaciones web como imperativo en la
calidad de desarrollo del software
AUTOR Silvia Margarita Díaz Díaz
FUENTE
https://www.unab.edu.co/sites/default/files/MemoriasGrabadas/papers
/capitulo7_paper_13.pdf
AÑO 2014
RESUMEN
Las aplicaciones tanto sin son web o no están expuestas a una gran
cantidad de amenazas, bien sean por ataques o por mal uso de los
usuarios. Para mitigar este tipo de amenazas es necesario que desde
el inicio del ciclo de desarrollo de software se implementen por así
decirlo medidas que permitan mitigarlas. Aquí es donde entran las
pruebas de seguridad, ya que en un gran porcentaje estas son dejadas
para la fase final del ciclo (teasting), pero hacer esto solo aumentaría
el riesgo en el incremento de los costos de mantenimiento o
corrección.
Esto lo que busca es ofrecer un software de calidad que garantice la
integridad de los datos de las empresas y el manejo de buenas
practicas de la empresa desarrolladora.
PROBLEMA DE
LA
INVESTIGACION
Seguridad de las aplicaciones, vulnerabilidades, pruebas en el ciclo de
SW
PRINCIPALES
CONCEPTOS
seguridad de la información. Garantía de calidad (QA).
Aplicaciones web. Garantía de calidad del software. Prueba segura
prácticas
METODOLOGIA Investigación científica
CONCLUSIONES
Las pruebas de seguridad deben ser tenidas desde el principio hasta
el fin de un proyecto con el fin de garantizar el cumplimiento de lo
requerido, adicionalmente el realizar estas pruebas permite la
detección temprana de errores y evita repetición de procesos en el
futuro para corregirlos ahorrando costos innecesarios a futuro.
TITULO OWASP TESTING GUIDE
AUTOR Fundación OWASP ™
FUENTE https://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf
AÑO 2008
RESUMEN Muchas empresas desarrolladoras no incluyen las pruebas de
seguridad como parte de su proceso de desarrollo, siendo estas de
vital importancia para evitar futuros ataques y brindar confianza en
las empresas que terminan siendo los usuarios finales. Por eso
mediante el uso de buenas prácticas propuestas por Open Web
Application Security Project (OWASP), permite la creación de
aplicaciones mas seguras, desde la verificación de código desde el
principio del ciclo de desarrollo de software.
El propósito de OWASP es determinar que hace a un software o
aplicación inseguro y de esta manera ayudar a brindar soluciones.
PROBLEMA DE
INVESTIGACION
El problema de investigación está relacionado con la seguridad en
las aplicaciones informáticas.
PALABRAS
CLAVES
Software inseguro, Vulnerabilidades, herramientas de seguridad
METODOLOGIA Guía OWASP - proyecto investigacion
MARCO TEORICO
Proyecto: “Un proyecto es una herramienta o instrumento que busca recopilar, crear,
analizar en forma sistemática un conjunto de datos y antecedentes, para la
obtención de resultados esperados. Es de gran importancia porque permite
organizar el entorno de trabajo". ("Evaluación Social de Proyectos", 12a Edición,
Ernesto R. Fontaine, Editorial Alfaomega).
Costos: “hace referencia al momento en el que una empresa invierte dinero en la
producción de un bien, servicio o producto”. (Laura Valentina Navarro Olaya 2019-
10-28T14:04:24-05:00 Febrero 5th, 2018)
Gestión: “gestión se refiere a todos aquellos trámites que se realizan con la finalidad
de resolver una situación o materializar un proyecto. En el entorno empresarial o
comercial, la gestión es asociada con la administración de un negocio”.
(Recuperado de: https://conceptodefinicion.de/gestion/. Consultado el 17 de
noviembre del 2019)
Alcance del Proyecto: “El alcance de un proyecto tiene como finalidad
la determinación clara, sencilla y concreta de los objetivos que se intentarán
alcanzar, a lo largo del desarrollo del proyecto en cuestión, cuyo cumplimiento
generará la culminación exitosa de dicho proyecto. “(Recuperado de:
https://www.ubjonline.mx/en-que-consiste-el-alcance-del-proyecto/)
MARCO CONCEPTUAL
Desarrollo Software
Implantación del
Sistema
Investigación
Preliminar
Determinación de
Requerimientos
Diseño del Sistema
Desarrollo del
Sistema
Prueba del Sistema
MARCO TECNOLOGICO
En un proceso de pruebas formal, suelen confundirse con mucha facilidad, los
niveles de pruebas con los tipos de prueba, y a pesar de que se encuentren
íntimamente relacionadas, tienen connotaciones diferentes en el proceso.
Para entender un poco más, vamos a partir del hecho de que las pruebas pueden
ejecutarse en cualquier punto del proceso de desarrollo de software, y es aquí
donde los niveles de prueba nos permiten entender con claridad los diferentes
puntos o etapas en donde pueden ejecutarse ciertos tipos de prueba. Por lo
anterior, es común que algunas personas se refieran a los niveles de pruebas o
intenten clasificarlos como: pruebas de desarrollador, pruebas funcionales y
pruebas de usuario final.
Sin embargo, la terminología apropiada para referirse a los diferentes niveles
corresponde a la siguientes cuatro (4) clasificaciones que son: pruebas unitarias,
pruebas de integración, pruebas de sistema y pruebas de aceptación.
En cada uno de estos niveles de prueba, se podrán ejecutar diferentes tipos de
prueba tales como: pruebas funcionales, no funcionales, de arquitectura y
asociadas el cambio de los productos.
A continuación, una breve descripción de cada nivel de prueba:
Pruebas Unitarias o de Componente: este tipo de pruebas son ejecutadas
normalmente por el equipo de desarrollo, básicamente consisten en la ejecución de
actividades que le permitan verificar al desarrollador que los componentes unitarios
están codificados bajo condiciones de robustez, esto es, soportando el ingreso de
datos erróneos o inesperados y demostrando así la capacidad de tratar errores de
manera controlada. Adicionalmente, Las pruebas sobre componentes unitarios,
suelen denominarse pruebas de módulos o pruebas de clases, siendo la convención
definida por el lenguaje de programación la que influye en el término a utilizar. Por
último, es importante que toda la funcionalidad de cada componente unitario sea
cubierta, por al menos, dos casos de prueba, los cuales deben centrarse en probar
al menos una funcionalidad positiva y una negativa.
Pruebas de Integración: este tipo de pruebas son ejecutas por el equipo de
desarrollo y consisten en la comprobación de que elementos del software que
interactúan entre sí, funcionan de manera correcta.
Pruebas de Sistema: este tipo de pruebas deben ser ejecutadas idealmente por un
equipo de pruebas ajeno al equipo de desarrollo, una buena práctica en este punto
corresponde a la tercerización de esta responsabilidad. La obligación de este
equipo, consiste en la ejecución de actividades de prueba en donde se debe verificar
que la funcionalidad total de un sistema fue implementada de acuerdo a los
documentos de especificación definidos en el proyecto. Los casos de prueba a
diseñar en este nivel de pruebas, deben cubrir los aspectos funcionales y no
funcionales del sistema. Para el diseño de los casos de prueba en este nivel, el
equipo debe utilizar como bases de prueba entregables tales como: requerimientos
iniciales, casos de uso, historias de usuario, diseños, manuales técnicos y de
usuario final, etc. Por último, es importante que los tipos de pruebas ejecutados en
este nivel se desplieguen en un ambiente de pruebas / ambiente de pre-producción
cuya infraestructura y arquitectura sea similar al ambiente de producción, evitando
en todos los casos utilizar el ambiente real del cliente, debido principalmente, a que
pueda ocasionar fallos en los servidores, lo que ocasionaría indisponibilidad en otros
servicios alojados en este ambiente.
Pruebas de Aceptación: En los casos en que las pruebas de aceptación del
producto se hayan ejecutado en el ambiente del proveedor, el aplicativo no podrá
salir a producción, sin que se hayan ejecutados las respectivas pruebas Beta en el
ambiente del cliente, de lo anterior es importante concluir, que las pruebas Alpha
son opcionales, pero las pruebas Beta son obligatorias.
TIPO DE INVESTIGACION
Descriptiva: llegar a conocer las situaciones, costumbres y actitudes
predominantes a través de la descripción exacta de las actividades, objetos,
procesos y personas. Su meta no se limita a la recolección de datos, sino a la
predicción e identificación de las relaciones que existen entre dos o más variables.
ENFOQUE DE INVESTIGACION
Cuantitativa: Busca cuantificar los datos y en general aplicar alguna forma de
análisis estadístico señalar, entre ciertas alternativas, usando magnitudes
numéricas que pueden ser tratadas mediante herramientas del campo de la
estadística.
POBLACION Y MUESTRA
Población: Grupo de programadores y desarrollo de software Bucaramanga.
Muestra: Estudiantes sistemas Universidad Nacional Abierta y a Distancia.
FORMULACION DE HIPOTESIS
En un proyecto de desarrollo de software pueden aparecer errores en cualquier de
las etapas del ciclo de vida, algunos de ellos incluso permanecen sin ser
descubiertos, de ahí la importancia de las pruebas en desarrollo de software.
DISEÑO DE INSTRUMENTOS DE INDAGACION
 Observación sistemática
 Análisis de contenido
 Test estandarizados y no estandarizados.
 Prueba de rendimiento
 Pruebas estadísticas
METODOLOGIA
Metodología de Pruebas
Los procesos de aseguramiento de calidad de un producto de software suelen
dividirse en lo que respecta a su componente analítico en pruebas estáticas y
dinámicas. La diferencia fundamental entre estos tipos de pruebas, radica en que
las pruebas estáticas se centran en evaluar la calidad con la que se está generando
la documentación del proyecto, por medio de revisiones periódicas, mientras que
las pruebas dinámicas, requieren de la ejecución del software con el fin de medir el
nivel de calidad con la que este fue codificado y el nivel de cumplimiento en relación
con la especificación del sistema.
Realizar pruebas dinámicas a un producto de software, suele en la mayoría de los
casos confundirse con una simple actividad de ejecución de pruebas y reporte de
incidencias, sin embargo, para productos de complejidad media en adelante, lo
recomendable es implementar de manera formal una metodología de pruebas que
se ajuste y acople uniformemente con la metodología de desarrollo seleccionada
por la firma desarrolladora.
Para procesos de desarrollo basados en la metodología RUP o métodos
tradicionales, implementar una metodología de pruebas es totalmente viable,
teniendo en cuenta que estas metodologías están orientadas a la documentación y
a la formalización de todas las actividades ejecutadas. Si por el contrario, la firma
desarrolladora guía su proceso bajo lineamientos basados en metodologías ágiles,
será necesario reevaluar la conveniencia de ejecutar todas las actividades que
implica un proceso de pruebas formal, lo que en la mayoría de los casos, conlleva
a reducir al mínimo las actividades relacionadas con un proceso de pruebas,
circunstancia que naturalmente puede desencadenar en la liberación de productos
con bajos niveles de calidad.
Un proceso de pruebas formal, está compuesto, cuando menos por las siguientes 5
típicas etapas:
 Planeación de pruebas.
 Diseño de pruebas.
 implementación de pruebas.
 Evaluación de criterios de salida.
 Cierre del proceso.
Planeación de Pruebas.
Es la etapa en donde se ejecutan las primeras actividades correspondientes al
proceso de pruebas y tiene como resultado un entregable denominado plan de
pruebas el cual debe estar conformado en cuando menos por aspectos tales como:
Alcance de la prueba: determina que funcionalidades del producto y/o software
serán probadas durante el transcurso de la prueba. Este listado de funcionalidades
a probar se extrae con base a un análisis de riesgos realizado de manera previa,
que tienen en cuenta variables tales como el impacto que podría ocasionar la falla
de una funcionalidad y la probabilidad de falla de una funcionalidad. Producto de
este análisis, se cuenta con información adicional que permite determinar además
del alcance detallado del proceso de pruebas, la prioridad con la que las
funcionalidades deben probarse y la profundidad de las pruebas.
Tipos de Prueba: en este punto se debe determinar qué tipos de pruebas requeriría
el producto. No todos los productos de software requieren la aplicación de todos los
tipos de pruebas que existen, por esta razón, es estrictamente necesario que el líder
de pruebas se plantee preguntas que le permitan determinar qué tipos de prueba
son aplicables al proyecto en evaluación. Los posibles tipos de prueba a aplicar son:
pruebas de stress, pruebas de rendimiento, pruebas de carga, pruebas funcionales,
pruebas de usabilidad, pruebas de regresión, entre otros.
Estrategia de Pruebas: teniendo en cuenta que no es viable probar con base a
todas las posibles combinaciones de datos, es necesario determinar a través de un
análisis de riesgos sobre que funcionalidades debemos centrar nuestra atención.
Adicionalmente, una buena estrategia de pruebas debe indicar los niveles de
pruebas (ciclos) que aplicaremos y la intensidad o profundidad a aplicar para cada
nivel de pruebas definido. En este punto también es importante definir los criterios
de entrada y salida para cada ciclo de pruebas a ejecutar.
Criterios de Salida: entre las partes involucradas en el proceso, se define de
manera formal, bajo qué condiciones se puede considerar que una actividad de
pruebas fue finalizada. Los criterios de salida se deben definir para cada nivel de
pruebas a ejecutar. Algunos ejemplos de criterios de salida que pueden ser
utilizados son: porcentaje de funcionalidades de alto riesgo probadas con éxito,
número defectos críticos y/o mayores aceptados, etc.
Otros aspectos: tal y como se realiza en cualquier plan de proyecto, se debe incluir
una estimación de tiempos, los roles y/o recursos que harán parte del proceso, la
preparación del entorno de pruebas, cronograma base, etc.
Diseño de Pruebas: una vez elaborado y aprobado el plan de pruebas, el equipo
de trabajo debe iniciar el análisis de toda la documentación existente con respecto
al sistema, con el objeto de iniciar el diseño de los casos de prueba. Los entregables
claves para iniciar este diseño pueden ser: casos de uso, historias de usuario,
arquitectura del sistema, diseños, manuales de usuario (si existen), manuales
técnicos (si existen). El diseño de los casos, debe considerar la elaboración de
casos positivos y negativos. Los casos de prueba negativos permiten validar cómo
se comporta el sistema ante situaciones atípicas y permite verificar la robustez del
sistema, atributo que constituye uno de los requerimientos no funcionales
indispensable para cualquier software. Por último, es necesario definir cuáles son
los datos de prueba necesarios para la ejecución de los casos de prueba diseñados.
Implementación y Ejecución de Pruebas: la ejecución de pruebas debe iniciar
con la creación de los datos de prueba necesarios para ejecutar los casos de prueba
diseñados. La ejecución de estos casos, puede realizarse de manera manual o
automatizada; en cualquiera de los casos, cuando se detecte un fallo en el sistema,
este debe ser documentado y registrado en una herramienta que permita gestionar
los defectos (Bug Tracker). Una vez el defecto ha sido corregido por la firma
desarrolladora en su respectivo proceso de depuración, es necesario realizar un re-
test que permita confirmar que el defecto fue solucionado de manera exitosa. Por
último, es indispensable ejecutar un ciclo de regresión que nos permita garantizar,
que los defectos corregidos en el proceso de depuración de la firma, no hayan
desencadenado otros tipos de defectos en el sistema.
Evaluación de Criterios de Salida: los criterios de salida son necesarios para
determinar si es posible dar por finalizado un ciclo de pruebas. Para esto, es
conveniente definir una serie de métricas que permitirán al finalizar un proceso de
pruebas, comparar los resultados obtenidos contra las métricas definidas, sí los
resultados obtenidos no superan la métrica definida, no es posible continuar con el
siguiente ciclo de pruebas.
Existen varios tipos de criterios de salida dentro de los cuales se pueden mencionar:
cubrimiento de funcionalidades en general, cubrimiento de funcionalidades críticas
para el sistema, Número de defectos críticos y mayores detectados, etc. También
es importante aclarar que el proceso de pruebas puede ser suspendido y/o
paralizado, debido entre otros, a aspectos relacionados con el presupuesto y la
calidad mínima del sistema requerida para el inicio formal de pruebas.
Cierre del proceso: durante este periodo de cierre el cual históricamente se ha
comprobado que se le destina muy poco tiempo en la planeación, se deben cerrar
las incidencias reportadas, se debe verificar si los entregables planeados han sido
entregados y aprobados, se deben finalizar y aprobar los documentos de soporte
de prueba, analizar las lecciones aprendidas para aplicar en futuros proyectos, etc.
PRESUPUESTO
IMPACTO QUE GENERA LA SOLUCIÓN DE LA PROBLEMÁTICA
Es imprescindible poner en marcha mecanismos de control y mejora continua
que permitan medir su calidad. Estos mecanismos deben utilizarse
sistemáticamente para conocer todos los aspectos claves en el desarrollo del
proceso asistencial:
• Si su variabilidad se mantiene dentro de unos márgenes aceptables.
• Si la efectividad del proceso es la deseada, es decir, si los indicadores de
resultados o de valoración integral del proceso son satisfactorios.
• Si los usuarios están satisfechos: se han eliminado espaciosen blanco, tiempos
de espera innecesarios, se garantiza la accesibilidad a los clientes, ...
• Si se mantienen los niveles de eficiencia previstos, y los indicadores
demuestran una mejor utilización de los recursos.
• Si se escucha la opinión de los profesionales y las personas que intervienen
en el desarrollo del proceso consideran que su trabajo ha mejorado.
CRONOGRAMA
REFERENCIAS
Yuni, J. A., & Urbano, C. A. (2014). Identificar posibles preguntas del área
roblema.Técnicas para investigar: recursos metodológicos para la preparación de
proyectos de investigación (pp. 70-92). Córdoba, Argentina: Editorial Brujas.
Recuperado de
http://bibliotecavirtual.unad.edu.co:2051/login.aspx?direct=true&db=e000xww&AN
=847670&lang=es&site=ehost-live&ebv=EB&ppid=pp_70.
Ferreyro, A., & Longhi, A. D. (2014). ¿Qué tipos de diseños de investigación se
pueden plantear? Metodología de la investigación (pp. 91-104). Córdoba, Argentina:
Encuentro Grupo Editor. Recuperado de
http://bibliotecavirtual.unad.edu.co:2051/login.aspx?direct=true&db=e000xww&AN
=84 7673&lang=es&site=ehost-live&ebv=EB&ppid=pp_91
Diaz, Silvia M. (2014) Pruebas de seguridad en aplicaciones web como imperativo
en la calidad de desarrollo del software. Recuperado de:
https://www.unab.edu.co/sites/default/files/MemoriasGrabadas/papers/capitulo7_p
aper_13.pdf
UNAD (2011) Líneas de investigación recuperado de
https://drive.google.com/open?id=0B1ZfL1NdK6EMeDJPSDRjLWFLLUU

Weitere ähnliche Inhalte

Was ist angesagt?

Metodologia xp
Metodologia xpMetodologia xp
Metodologia xpfiremas
 
Documentacion de las pruebas normas y certificaciones de software.
Documentacion de las pruebas normas y certificaciones de software.Documentacion de las pruebas normas y certificaciones de software.
Documentacion de las pruebas normas y certificaciones de software.Isabel Gómez
 
Monografia Metodologia Agil XP
Monografia Metodologia Agil XPMonografia Metodologia Agil XP
Monografia Metodologia Agil XPJorw Yengle
 
Monografia metodologia agil xp oficial
Monografia metodologia agil xp oficialMonografia metodologia agil xp oficial
Monografia metodologia agil xp oficialHarry G Portales
 
Trabajo diapositiva modulo 3 de josue
Trabajo diapositiva modulo 3 de josueTrabajo diapositiva modulo 3 de josue
Trabajo diapositiva modulo 3 de josueJosue Zelaya
 
Fundamentos de Pruebas de Software - Capítulo 3
Fundamentos de Pruebas de Software - Capítulo 3Fundamentos de Pruebas de Software - Capítulo 3
Fundamentos de Pruebas de Software - Capítulo 3Professional Testing
 
Presentación comercial S-SQUARE S.A.
Presentación comercial S-SQUARE S.A.Presentación comercial S-SQUARE S.A.
Presentación comercial S-SQUARE S.A.Luis Trejos
 
Aceptación del cliente
Aceptación del clienteAceptación del cliente
Aceptación del clienteRulosfc
 
76765984 ejecucion-de-pruebas-original
76765984 ejecucion-de-pruebas-original76765984 ejecucion-de-pruebas-original
76765984 ejecucion-de-pruebas-originalJordi Calpe Corts
 
Unidad 5 ingenieria de software
Unidad 5 ingenieria de softwareUnidad 5 ingenieria de software
Unidad 5 ingenieria de softwareRobeks Robjenns
 
Fundamentos de Pruebas de Software - Capítulo 5
Fundamentos de Pruebas de Software - Capítulo 5Fundamentos de Pruebas de Software - Capítulo 5
Fundamentos de Pruebas de Software - Capítulo 5Professional Testing
 
Control de Calidad del Software
Control de Calidad del SoftwareControl de Calidad del Software
Control de Calidad del SoftwareTonymx
 
Fundamentos de Pruebas de Software - Capítulo 6
Fundamentos de Pruebas de Software - Capítulo 6Fundamentos de Pruebas de Software - Capítulo 6
Fundamentos de Pruebas de Software - Capítulo 6Professional Testing
 
Software Testing - Panorama Actual
Software Testing - Panorama ActualSoftware Testing - Panorama Actual
Software Testing - Panorama ActualTestingBaires
 
Metodologia xp (tarea msmad)
Metodologia xp (tarea msmad)Metodologia xp (tarea msmad)
Metodologia xp (tarea msmad)Renata Briseño
 

Was ist angesagt? (20)

Metodologia xp
Metodologia xpMetodologia xp
Metodologia xp
 
Documentacion de las pruebas normas y certificaciones de software.
Documentacion de las pruebas normas y certificaciones de software.Documentacion de las pruebas normas y certificaciones de software.
Documentacion de las pruebas normas y certificaciones de software.
 
Monografia Metodologia Agil XP
Monografia Metodologia Agil XPMonografia Metodologia Agil XP
Monografia Metodologia Agil XP
 
Monografia metodologia agil xp oficial
Monografia metodologia agil xp oficialMonografia metodologia agil xp oficial
Monografia metodologia agil xp oficial
 
Trabajo diapositiva modulo 3 de josue
Trabajo diapositiva modulo 3 de josueTrabajo diapositiva modulo 3 de josue
Trabajo diapositiva modulo 3 de josue
 
Fundamentos de Pruebas de Software - Capítulo 3
Fundamentos de Pruebas de Software - Capítulo 3Fundamentos de Pruebas de Software - Capítulo 3
Fundamentos de Pruebas de Software - Capítulo 3
 
Pruebas de software
Pruebas de softwarePruebas de software
Pruebas de software
 
Presentación comercial S-SQUARE S.A.
Presentación comercial S-SQUARE S.A.Presentación comercial S-SQUARE S.A.
Presentación comercial S-SQUARE S.A.
 
Aceptación del cliente
Aceptación del clienteAceptación del cliente
Aceptación del cliente
 
76765984 ejecucion-de-pruebas-original
76765984 ejecucion-de-pruebas-original76765984 ejecucion-de-pruebas-original
76765984 ejecucion-de-pruebas-original
 
Unidad 5 ingenieria de software
Unidad 5 ingenieria de softwareUnidad 5 ingenieria de software
Unidad 5 ingenieria de software
 
Fundamentos de Pruebas de Software - Capítulo 5
Fundamentos de Pruebas de Software - Capítulo 5Fundamentos de Pruebas de Software - Capítulo 5
Fundamentos de Pruebas de Software - Capítulo 5
 
Control de Calidad del Software
Control de Calidad del SoftwareControl de Calidad del Software
Control de Calidad del Software
 
Fundamentos de Pruebas de Software - Capítulo 6
Fundamentos de Pruebas de Software - Capítulo 6Fundamentos de Pruebas de Software - Capítulo 6
Fundamentos de Pruebas de Software - Capítulo 6
 
Pst metodologia xp
Pst metodologia xpPst metodologia xp
Pst metodologia xp
 
Capacitacitación Tester - QA 1
Capacitacitación Tester - QA 1Capacitacitación Tester - QA 1
Capacitacitación Tester - QA 1
 
Testing - Ing. Gabriela Muñoz
Testing - Ing. Gabriela MuñozTesting - Ing. Gabriela Muñoz
Testing - Ing. Gabriela Muñoz
 
Software Testing - Panorama Actual
Software Testing - Panorama ActualSoftware Testing - Panorama Actual
Software Testing - Panorama Actual
 
Metodologia xp (tarea msmad)
Metodologia xp (tarea msmad)Metodologia xp (tarea msmad)
Metodologia xp (tarea msmad)
 
Metodologia xp
Metodologia xpMetodologia xp
Metodologia xp
 

Ähnlich wie Paso 8 actividad colaborativa - propuesta ampliada

Plantilla trabajo final_Ana_Jesus
Plantilla trabajo final_Ana_JesusPlantilla trabajo final_Ana_Jesus
Plantilla trabajo final_Ana_JesusAnnie Mrtx
 
Capitulo 17 estrategias_de_prueba_de_software
Capitulo 17 estrategias_de_prueba_de_softwareCapitulo 17 estrategias_de_prueba_de_software
Capitulo 17 estrategias_de_prueba_de_softwareAndres Valencia
 
pruebas de calidad.pdf
pruebas de calidad.pdfpruebas de calidad.pdf
pruebas de calidad.pdfChirmi1
 
Estrategias prueba de software
Estrategias prueba de softwareEstrategias prueba de software
Estrategias prueba de softwareCentro Líbano
 
practica 9 de fundamento.pdf
practica 9 de fundamento.pdfpractica 9 de fundamento.pdf
practica 9 de fundamento.pdfEduinGamer
 
Calidad y Pruebas VIEWNEXT
Calidad y Pruebas VIEWNEXTCalidad y Pruebas VIEWNEXT
Calidad y Pruebas VIEWNEXTViewnext
 
Desarrollode software (1)
Desarrollode software (1)Desarrollode software (1)
Desarrollode software (1)turlahackers
 
Guia de calidad para desarrollo de software
Guia de calidad para desarrollo de softwareGuia de calidad para desarrollo de software
Guia de calidad para desarrollo de softwareAndres Epifanía Huerta
 
PROCESO DE DESARROLLO DE SOFTWARE.pptx
PROCESO DE DESARROLLO DE SOFTWARE.pptxPROCESO DE DESARROLLO DE SOFTWARE.pptx
PROCESO DE DESARROLLO DE SOFTWARE.pptxjuan gonzalez
 

Ähnlich wie Paso 8 actividad colaborativa - propuesta ampliada (20)

Plantilla trabajo final_Ana_Jesus
Plantilla trabajo final_Ana_JesusPlantilla trabajo final_Ana_Jesus
Plantilla trabajo final_Ana_Jesus
 
Paso 9 actividad colaborativa
Paso 9   actividad colaborativaPaso 9   actividad colaborativa
Paso 9 actividad colaborativa
 
Ensayo sobre la calidad de software
Ensayo sobre la calidad de softwareEnsayo sobre la calidad de software
Ensayo sobre la calidad de software
 
Ensayo sobre la calidad de software
Ensayo sobre la calidad de softwareEnsayo sobre la calidad de software
Ensayo sobre la calidad de software
 
Ensayo sobre la calidad de software
Ensayo sobre la calidad de softwareEnsayo sobre la calidad de software
Ensayo sobre la calidad de software
 
Capitulo 17 estrategias_de_prueba_de_software
Capitulo 17 estrategias_de_prueba_de_softwareCapitulo 17 estrategias_de_prueba_de_software
Capitulo 17 estrategias_de_prueba_de_software
 
pruebas de calidad.pdf
pruebas de calidad.pdfpruebas de calidad.pdf
pruebas de calidad.pdf
 
Estrategias prueba de software
Estrategias prueba de softwareEstrategias prueba de software
Estrategias prueba de software
 
Taba norma grama calidad software
Taba norma grama calidad softwareTaba norma grama calidad software
Taba norma grama calidad software
 
A1 u1 tablas comparativa
A1 u1  tablas comparativaA1 u1  tablas comparativa
A1 u1 tablas comparativa
 
Actividad 1
Actividad 1Actividad 1
Actividad 1
 
Desarrollo de software
Desarrollo de softwareDesarrollo de software
Desarrollo de software
 
Proceso desarrollo software
Proceso desarrollo softwareProceso desarrollo software
Proceso desarrollo software
 
Tarea 1 Reconocimiento
Tarea 1 ReconocimientoTarea 1 Reconocimiento
Tarea 1 Reconocimiento
 
practica 9 de fundamento.pdf
practica 9 de fundamento.pdfpractica 9 de fundamento.pdf
practica 9 de fundamento.pdf
 
Técnicas de prueba.docx
Técnicas de prueba.docxTécnicas de prueba.docx
Técnicas de prueba.docx
 
Calidad y Pruebas VIEWNEXT
Calidad y Pruebas VIEWNEXTCalidad y Pruebas VIEWNEXT
Calidad y Pruebas VIEWNEXT
 
Desarrollode software (1)
Desarrollode software (1)Desarrollode software (1)
Desarrollode software (1)
 
Guia de calidad para desarrollo de software
Guia de calidad para desarrollo de softwareGuia de calidad para desarrollo de software
Guia de calidad para desarrollo de software
 
PROCESO DE DESARROLLO DE SOFTWARE.pptx
PROCESO DE DESARROLLO DE SOFTWARE.pptxPROCESO DE DESARROLLO DE SOFTWARE.pptx
PROCESO DE DESARROLLO DE SOFTWARE.pptx
 

Paso 8 actividad colaborativa - propuesta ampliada

  • 1. PASO 8 – PROPUESTA AMPLIADA Presentado por: MARIA ANGELICA REYES CRISTIAM HUMBERTO GOMEZ JHON FREDDY MALDONADO JORGE ALBERTO REYES JEAN CARLOS VEGA Presentado a: DIANA CARDONA ROMAN UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD INGENIERIA DE SISTEMAS BUCARAMANGA 2019
  • 2. CONTENIDO ANTECEDENTES...................................................................................................................3 ESTADO DEL ARTE..............................................................................................................4 MARCO TEORICO.................................................................................................................7 MARCO CONCEPTUAL.........................................................................................................8 MARCO TECNOLOGICO.......................................................................................................9 TIPO DE INVESTIGACION..................................................................................................10 ENFOQUE DE INVESTIGACION ........................................................................................10 POBLACION Y MUESTRA...................................................................................................10 FORMULACION DE HIPOTESIS.........................................................................................10 DISEÑO DE INSTRUMENTOS DE INDAGACION .............................................................11 METODOLOGIA...................................................................................................................11 PRESUPUESTO...................................................................................................................14 CRONOGRAMA ...................................................................................................................16 REFERENCIAS ....................................................................................................................17
  • 3. ANTECEDENTES Los procesos y actividades en las organizaciones han llevado a la creación de un sin número de herramientas informáticas que permitan un mejor desempeño de las mismas, dado lo anterior muchas empresas desarrolladoras han entrado en auge con la creación de aplicaciones que satisfagan las necesidades de sus clientes, sin embargo esto también ha ocasionado que muchas empresas sufran ataques cibernéticos, la especialista en seguridad informática Silvia M. Diaz en su artículo titulado Pruebas de seguridad en aplicaciones web como imperativo en la calidad de desarrollo del software publicado en el 2013 menciona lo siguiente “Las aplicaciones web están expuestas a un gran número de amenazas, tales como el mal uso por parte de los usuarios, ataques de seguridad, mala calidad del software o falta de un proceso de desarrollo estructurado” y por tal motivo indicaba que es necesario que durante el ciclo de desarrollo de software se implementara un modelo que permitiera realizar por así decirlo un acompañamiento en cada fase del ciclo. Una guía elaborada para OWASP Foundation (2008), menciona lo siguiente “Las organizaciones de desarrollo no incluyen pruebas de seguridad como parte de su proceso de desarrollo de software estándar… Las pruebas han demostrado ser un ingrediente clave en cualquier organización que necesita confiar en el software que produce o utiliza” como vemos esta guía concientiza por la necesidad de las pruebas de seguridad y por tanto en su guía muestra una serie de buenas prácticas que ayudan a mitigar los ataques cibernéticos. Un tercer trabajo elaborado por los ingenieros Pablo Andrés Vaca, Calixto Maldonado, Claudia Inchaurrondo, Juan Peretti, María Soledad Romero y Matías Bueno, destacan la importancia de los Test-Driven Development (TDD), la cual la describen de la siguiente manera “práctica iterativa de diseño de software orientado a objetos” y que consta de tres fases, test firts aquí se escribe una prueba y se verifica que las pruebas fallan, después, se implementa el código que hace que la prueba pase satisfactoriamente, la segunda fase es la automatización y esta en particular es la que más nos interesa, esta hace referencia a la ejecución automática de las pruebas (código) y por ultimo refactorizar, lo cual permite que se mantenga la calidad. El objetivo del anterior trabajo es estudiar y enmarcar las metodologías TDD en la industria, con el fin de mostrar sus particularidades, así como los proyectos donde aplicarlos, sus ventajas y desventajas.
  • 4. ESTADO DEL ARTE TEMA Test-Driven Development - Una aproximación para entender su utilidad en el proceso de desarrollo de Software. AUTOR Ing. Pablo Andrés Vaca, Ing. Calixto Maldonado, Ing. Claudia Inchaurrondo, Ing. Juan Peretti, Ing. María Soledad Romero, Ing. Matías Bueno FUENTE http://www.conaiisi.unsl.edu.ar/portugues/2013/158-524-1- DR.pdf AÑO Octubre de, 2013 RESUMEN El desarrollo de software plantea muchos desafíos a los equipos de trabajo, estos retos van desde entender lo que el mercado y los clientes necesitan, hasta brindar soluciones integrales que cubran todos los aspectos de una organización manteniendo los costos controlados y brindando mejoras a las organizaciones. Uno de los desafíos más grandes es lograr garantizar la calidad de los productos de software y mejorar la productividad a lo largo del ciclo de vida del mismo, desde el comienzo del desarrollo hasta las etapas de mantenimiento. Este es un reto enorme ya que actualmente los requerimientos son mucho más volátiles que en el pasado, lo cual convierte a los cambios en el software en un momento en el cual potencialmente se introducen muchos errores, ocasionando que funcionalidades ya implementadas empiecen a fallar, aparecen muchas fallas o errores, llamados “Bugs” en la etapa de mantenimiento. En respuesta a esto se introducen más equipos de pruebas para realizar todo tipo de ellas, desde pruebas exploratorias hasta pruebas de regresión extensivas, las cuales toman mucho tiempo. Esto ocasiona que en muchos casos no se puedan utilizar metodologías ágiles, tales como eXtreme Programming (XP), ya que éstas se basan en períodos de desarrollo cortos (dos a cuatro semanas) y al final de los mismos se entrega un producto de software funcional. Esta práctica es posible sólo si se logra incorporar herramientas que agilicen la ejecución de grandes cantidades de casos de pruebas en cuestión de minutos, permitiendo a los miembros del equipo efectuar un desarrollo incremental y continuo del software, manteniendo la integridad del producto.
  • 5. PROBLEMA DE LA INVESTIGACION Desarrollos Ágiles, Testing, Automatización de pruebas, Automatización. Automation Tests, Unit Tests, BDD, TDD, Scrum. PRINCIPALES CONCEPTOS Automatización: las pruebas deben ser escritas en código, y esto permite que se ejecuten automáticamente las veces que sea necesario, y el solo hecho de ejecutar las pruebas1 debe mostrar si la ejecución fue correcta o no METODOLOGIA Para llevar a cabo esta propuesta se realizó una revisión sistematizada de la literatura existente. Una revisión sistematizada es un estudio empírico de trabajos primarios y secundarios publicados, para ello, hemos utilizado como soporte de guía un trabajo de un grupo de investigadores de Gran Bretaña [1] y otro trabajo conjunto de un grupo de investigadores españoles y Croatas [2]. Además, nos hemos basado en las guías que se proveen en el trabajo “PRESENTACIÓN POR ESCRITO DE LA REVISIÓN BIBLIOGRÁFICA TITULO Pruebas de seguridad en aplicaciones web como imperativo en la calidad de desarrollo del software AUTOR Silvia Margarita Díaz Díaz FUENTE https://www.unab.edu.co/sites/default/files/MemoriasGrabadas/papers /capitulo7_paper_13.pdf AÑO 2014 RESUMEN Las aplicaciones tanto sin son web o no están expuestas a una gran cantidad de amenazas, bien sean por ataques o por mal uso de los usuarios. Para mitigar este tipo de amenazas es necesario que desde el inicio del ciclo de desarrollo de software se implementen por así decirlo medidas que permitan mitigarlas. Aquí es donde entran las pruebas de seguridad, ya que en un gran porcentaje estas son dejadas para la fase final del ciclo (teasting), pero hacer esto solo aumentaría el riesgo en el incremento de los costos de mantenimiento o corrección. Esto lo que busca es ofrecer un software de calidad que garantice la integridad de los datos de las empresas y el manejo de buenas practicas de la empresa desarrolladora. PROBLEMA DE LA INVESTIGACION Seguridad de las aplicaciones, vulnerabilidades, pruebas en el ciclo de SW
  • 6. PRINCIPALES CONCEPTOS seguridad de la información. Garantía de calidad (QA). Aplicaciones web. Garantía de calidad del software. Prueba segura prácticas METODOLOGIA Investigación científica CONCLUSIONES Las pruebas de seguridad deben ser tenidas desde el principio hasta el fin de un proyecto con el fin de garantizar el cumplimiento de lo requerido, adicionalmente el realizar estas pruebas permite la detección temprana de errores y evita repetición de procesos en el futuro para corregirlos ahorrando costos innecesarios a futuro. TITULO OWASP TESTING GUIDE AUTOR Fundación OWASP ™ FUENTE https://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf AÑO 2008 RESUMEN Muchas empresas desarrolladoras no incluyen las pruebas de seguridad como parte de su proceso de desarrollo, siendo estas de vital importancia para evitar futuros ataques y brindar confianza en las empresas que terminan siendo los usuarios finales. Por eso mediante el uso de buenas prácticas propuestas por Open Web Application Security Project (OWASP), permite la creación de aplicaciones mas seguras, desde la verificación de código desde el principio del ciclo de desarrollo de software. El propósito de OWASP es determinar que hace a un software o aplicación inseguro y de esta manera ayudar a brindar soluciones. PROBLEMA DE INVESTIGACION El problema de investigación está relacionado con la seguridad en las aplicaciones informáticas. PALABRAS CLAVES Software inseguro, Vulnerabilidades, herramientas de seguridad METODOLOGIA Guía OWASP - proyecto investigacion
  • 7. MARCO TEORICO Proyecto: “Un proyecto es una herramienta o instrumento que busca recopilar, crear, analizar en forma sistemática un conjunto de datos y antecedentes, para la obtención de resultados esperados. Es de gran importancia porque permite organizar el entorno de trabajo". ("Evaluación Social de Proyectos", 12a Edición, Ernesto R. Fontaine, Editorial Alfaomega). Costos: “hace referencia al momento en el que una empresa invierte dinero en la producción de un bien, servicio o producto”. (Laura Valentina Navarro Olaya 2019- 10-28T14:04:24-05:00 Febrero 5th, 2018) Gestión: “gestión se refiere a todos aquellos trámites que se realizan con la finalidad de resolver una situación o materializar un proyecto. En el entorno empresarial o comercial, la gestión es asociada con la administración de un negocio”. (Recuperado de: https://conceptodefinicion.de/gestion/. Consultado el 17 de noviembre del 2019) Alcance del Proyecto: “El alcance de un proyecto tiene como finalidad la determinación clara, sencilla y concreta de los objetivos que se intentarán alcanzar, a lo largo del desarrollo del proyecto en cuestión, cuyo cumplimiento generará la culminación exitosa de dicho proyecto. “(Recuperado de: https://www.ubjonline.mx/en-que-consiste-el-alcance-del-proyecto/)
  • 8. MARCO CONCEPTUAL Desarrollo Software Implantación del Sistema Investigación Preliminar Determinación de Requerimientos Diseño del Sistema Desarrollo del Sistema Prueba del Sistema
  • 9. MARCO TECNOLOGICO En un proceso de pruebas formal, suelen confundirse con mucha facilidad, los niveles de pruebas con los tipos de prueba, y a pesar de que se encuentren íntimamente relacionadas, tienen connotaciones diferentes en el proceso. Para entender un poco más, vamos a partir del hecho de que las pruebas pueden ejecutarse en cualquier punto del proceso de desarrollo de software, y es aquí donde los niveles de prueba nos permiten entender con claridad los diferentes puntos o etapas en donde pueden ejecutarse ciertos tipos de prueba. Por lo anterior, es común que algunas personas se refieran a los niveles de pruebas o intenten clasificarlos como: pruebas de desarrollador, pruebas funcionales y pruebas de usuario final. Sin embargo, la terminología apropiada para referirse a los diferentes niveles corresponde a la siguientes cuatro (4) clasificaciones que son: pruebas unitarias, pruebas de integración, pruebas de sistema y pruebas de aceptación. En cada uno de estos niveles de prueba, se podrán ejecutar diferentes tipos de prueba tales como: pruebas funcionales, no funcionales, de arquitectura y asociadas el cambio de los productos. A continuación, una breve descripción de cada nivel de prueba: Pruebas Unitarias o de Componente: este tipo de pruebas son ejecutadas normalmente por el equipo de desarrollo, básicamente consisten en la ejecución de actividades que le permitan verificar al desarrollador que los componentes unitarios están codificados bajo condiciones de robustez, esto es, soportando el ingreso de datos erróneos o inesperados y demostrando así la capacidad de tratar errores de manera controlada. Adicionalmente, Las pruebas sobre componentes unitarios, suelen denominarse pruebas de módulos o pruebas de clases, siendo la convención definida por el lenguaje de programación la que influye en el término a utilizar. Por último, es importante que toda la funcionalidad de cada componente unitario sea cubierta, por al menos, dos casos de prueba, los cuales deben centrarse en probar al menos una funcionalidad positiva y una negativa. Pruebas de Integración: este tipo de pruebas son ejecutas por el equipo de desarrollo y consisten en la comprobación de que elementos del software que interactúan entre sí, funcionan de manera correcta. Pruebas de Sistema: este tipo de pruebas deben ser ejecutadas idealmente por un equipo de pruebas ajeno al equipo de desarrollo, una buena práctica en este punto corresponde a la tercerización de esta responsabilidad. La obligación de este equipo, consiste en la ejecución de actividades de prueba en donde se debe verificar que la funcionalidad total de un sistema fue implementada de acuerdo a los documentos de especificación definidos en el proyecto. Los casos de prueba a
  • 10. diseñar en este nivel de pruebas, deben cubrir los aspectos funcionales y no funcionales del sistema. Para el diseño de los casos de prueba en este nivel, el equipo debe utilizar como bases de prueba entregables tales como: requerimientos iniciales, casos de uso, historias de usuario, diseños, manuales técnicos y de usuario final, etc. Por último, es importante que los tipos de pruebas ejecutados en este nivel se desplieguen en un ambiente de pruebas / ambiente de pre-producción cuya infraestructura y arquitectura sea similar al ambiente de producción, evitando en todos los casos utilizar el ambiente real del cliente, debido principalmente, a que pueda ocasionar fallos en los servidores, lo que ocasionaría indisponibilidad en otros servicios alojados en este ambiente. Pruebas de Aceptación: En los casos en que las pruebas de aceptación del producto se hayan ejecutado en el ambiente del proveedor, el aplicativo no podrá salir a producción, sin que se hayan ejecutados las respectivas pruebas Beta en el ambiente del cliente, de lo anterior es importante concluir, que las pruebas Alpha son opcionales, pero las pruebas Beta son obligatorias. TIPO DE INVESTIGACION Descriptiva: llegar a conocer las situaciones, costumbres y actitudes predominantes a través de la descripción exacta de las actividades, objetos, procesos y personas. Su meta no se limita a la recolección de datos, sino a la predicción e identificación de las relaciones que existen entre dos o más variables. ENFOQUE DE INVESTIGACION Cuantitativa: Busca cuantificar los datos y en general aplicar alguna forma de análisis estadístico señalar, entre ciertas alternativas, usando magnitudes numéricas que pueden ser tratadas mediante herramientas del campo de la estadística. POBLACION Y MUESTRA Población: Grupo de programadores y desarrollo de software Bucaramanga. Muestra: Estudiantes sistemas Universidad Nacional Abierta y a Distancia. FORMULACION DE HIPOTESIS En un proyecto de desarrollo de software pueden aparecer errores en cualquier de las etapas del ciclo de vida, algunos de ellos incluso permanecen sin ser descubiertos, de ahí la importancia de las pruebas en desarrollo de software.
  • 11. DISEÑO DE INSTRUMENTOS DE INDAGACION  Observación sistemática  Análisis de contenido  Test estandarizados y no estandarizados.  Prueba de rendimiento  Pruebas estadísticas METODOLOGIA Metodología de Pruebas Los procesos de aseguramiento de calidad de un producto de software suelen dividirse en lo que respecta a su componente analítico en pruebas estáticas y dinámicas. La diferencia fundamental entre estos tipos de pruebas, radica en que las pruebas estáticas se centran en evaluar la calidad con la que se está generando la documentación del proyecto, por medio de revisiones periódicas, mientras que las pruebas dinámicas, requieren de la ejecución del software con el fin de medir el nivel de calidad con la que este fue codificado y el nivel de cumplimiento en relación con la especificación del sistema. Realizar pruebas dinámicas a un producto de software, suele en la mayoría de los casos confundirse con una simple actividad de ejecución de pruebas y reporte de incidencias, sin embargo, para productos de complejidad media en adelante, lo recomendable es implementar de manera formal una metodología de pruebas que se ajuste y acople uniformemente con la metodología de desarrollo seleccionada por la firma desarrolladora. Para procesos de desarrollo basados en la metodología RUP o métodos tradicionales, implementar una metodología de pruebas es totalmente viable, teniendo en cuenta que estas metodologías están orientadas a la documentación y a la formalización de todas las actividades ejecutadas. Si por el contrario, la firma desarrolladora guía su proceso bajo lineamientos basados en metodologías ágiles, será necesario reevaluar la conveniencia de ejecutar todas las actividades que implica un proceso de pruebas formal, lo que en la mayoría de los casos, conlleva a reducir al mínimo las actividades relacionadas con un proceso de pruebas, circunstancia que naturalmente puede desencadenar en la liberación de productos con bajos niveles de calidad.
  • 12. Un proceso de pruebas formal, está compuesto, cuando menos por las siguientes 5 típicas etapas:  Planeación de pruebas.  Diseño de pruebas.  implementación de pruebas.  Evaluación de criterios de salida.  Cierre del proceso. Planeación de Pruebas. Es la etapa en donde se ejecutan las primeras actividades correspondientes al proceso de pruebas y tiene como resultado un entregable denominado plan de pruebas el cual debe estar conformado en cuando menos por aspectos tales como: Alcance de la prueba: determina que funcionalidades del producto y/o software serán probadas durante el transcurso de la prueba. Este listado de funcionalidades a probar se extrae con base a un análisis de riesgos realizado de manera previa, que tienen en cuenta variables tales como el impacto que podría ocasionar la falla de una funcionalidad y la probabilidad de falla de una funcionalidad. Producto de este análisis, se cuenta con información adicional que permite determinar además del alcance detallado del proceso de pruebas, la prioridad con la que las funcionalidades deben probarse y la profundidad de las pruebas. Tipos de Prueba: en este punto se debe determinar qué tipos de pruebas requeriría el producto. No todos los productos de software requieren la aplicación de todos los tipos de pruebas que existen, por esta razón, es estrictamente necesario que el líder de pruebas se plantee preguntas que le permitan determinar qué tipos de prueba son aplicables al proyecto en evaluación. Los posibles tipos de prueba a aplicar son: pruebas de stress, pruebas de rendimiento, pruebas de carga, pruebas funcionales, pruebas de usabilidad, pruebas de regresión, entre otros. Estrategia de Pruebas: teniendo en cuenta que no es viable probar con base a todas las posibles combinaciones de datos, es necesario determinar a través de un análisis de riesgos sobre que funcionalidades debemos centrar nuestra atención. Adicionalmente, una buena estrategia de pruebas debe indicar los niveles de pruebas (ciclos) que aplicaremos y la intensidad o profundidad a aplicar para cada nivel de pruebas definido. En este punto también es importante definir los criterios de entrada y salida para cada ciclo de pruebas a ejecutar. Criterios de Salida: entre las partes involucradas en el proceso, se define de manera formal, bajo qué condiciones se puede considerar que una actividad de pruebas fue finalizada. Los criterios de salida se deben definir para cada nivel de pruebas a ejecutar. Algunos ejemplos de criterios de salida que pueden ser
  • 13. utilizados son: porcentaje de funcionalidades de alto riesgo probadas con éxito, número defectos críticos y/o mayores aceptados, etc. Otros aspectos: tal y como se realiza en cualquier plan de proyecto, se debe incluir una estimación de tiempos, los roles y/o recursos que harán parte del proceso, la preparación del entorno de pruebas, cronograma base, etc. Diseño de Pruebas: una vez elaborado y aprobado el plan de pruebas, el equipo de trabajo debe iniciar el análisis de toda la documentación existente con respecto al sistema, con el objeto de iniciar el diseño de los casos de prueba. Los entregables claves para iniciar este diseño pueden ser: casos de uso, historias de usuario, arquitectura del sistema, diseños, manuales de usuario (si existen), manuales técnicos (si existen). El diseño de los casos, debe considerar la elaboración de casos positivos y negativos. Los casos de prueba negativos permiten validar cómo se comporta el sistema ante situaciones atípicas y permite verificar la robustez del sistema, atributo que constituye uno de los requerimientos no funcionales indispensable para cualquier software. Por último, es necesario definir cuáles son los datos de prueba necesarios para la ejecución de los casos de prueba diseñados. Implementación y Ejecución de Pruebas: la ejecución de pruebas debe iniciar con la creación de los datos de prueba necesarios para ejecutar los casos de prueba diseñados. La ejecución de estos casos, puede realizarse de manera manual o automatizada; en cualquiera de los casos, cuando se detecte un fallo en el sistema, este debe ser documentado y registrado en una herramienta que permita gestionar los defectos (Bug Tracker). Una vez el defecto ha sido corregido por la firma desarrolladora en su respectivo proceso de depuración, es necesario realizar un re- test que permita confirmar que el defecto fue solucionado de manera exitosa. Por último, es indispensable ejecutar un ciclo de regresión que nos permita garantizar, que los defectos corregidos en el proceso de depuración de la firma, no hayan desencadenado otros tipos de defectos en el sistema. Evaluación de Criterios de Salida: los criterios de salida son necesarios para determinar si es posible dar por finalizado un ciclo de pruebas. Para esto, es conveniente definir una serie de métricas que permitirán al finalizar un proceso de pruebas, comparar los resultados obtenidos contra las métricas definidas, sí los resultados obtenidos no superan la métrica definida, no es posible continuar con el siguiente ciclo de pruebas. Existen varios tipos de criterios de salida dentro de los cuales se pueden mencionar: cubrimiento de funcionalidades en general, cubrimiento de funcionalidades críticas para el sistema, Número de defectos críticos y mayores detectados, etc. También es importante aclarar que el proceso de pruebas puede ser suspendido y/o paralizado, debido entre otros, a aspectos relacionados con el presupuesto y la calidad mínima del sistema requerida para el inicio formal de pruebas.
  • 14. Cierre del proceso: durante este periodo de cierre el cual históricamente se ha comprobado que se le destina muy poco tiempo en la planeación, se deben cerrar las incidencias reportadas, se debe verificar si los entregables planeados han sido entregados y aprobados, se deben finalizar y aprobar los documentos de soporte de prueba, analizar las lecciones aprendidas para aplicar en futuros proyectos, etc. PRESUPUESTO
  • 15. IMPACTO QUE GENERA LA SOLUCIÓN DE LA PROBLEMÁTICA Es imprescindible poner en marcha mecanismos de control y mejora continua que permitan medir su calidad. Estos mecanismos deben utilizarse sistemáticamente para conocer todos los aspectos claves en el desarrollo del proceso asistencial: • Si su variabilidad se mantiene dentro de unos márgenes aceptables. • Si la efectividad del proceso es la deseada, es decir, si los indicadores de resultados o de valoración integral del proceso son satisfactorios. • Si los usuarios están satisfechos: se han eliminado espaciosen blanco, tiempos de espera innecesarios, se garantiza la accesibilidad a los clientes, ... • Si se mantienen los niveles de eficiencia previstos, y los indicadores demuestran una mejor utilización de los recursos. • Si se escucha la opinión de los profesionales y las personas que intervienen en el desarrollo del proceso consideran que su trabajo ha mejorado.
  • 17. REFERENCIAS Yuni, J. A., & Urbano, C. A. (2014). Identificar posibles preguntas del área roblema.Técnicas para investigar: recursos metodológicos para la preparación de proyectos de investigación (pp. 70-92). Córdoba, Argentina: Editorial Brujas. Recuperado de http://bibliotecavirtual.unad.edu.co:2051/login.aspx?direct=true&db=e000xww&AN =847670&lang=es&site=ehost-live&ebv=EB&ppid=pp_70. Ferreyro, A., & Longhi, A. D. (2014). ¿Qué tipos de diseños de investigación se pueden plantear? Metodología de la investigación (pp. 91-104). Córdoba, Argentina: Encuentro Grupo Editor. Recuperado de http://bibliotecavirtual.unad.edu.co:2051/login.aspx?direct=true&db=e000xww&AN =84 7673&lang=es&site=ehost-live&ebv=EB&ppid=pp_91 Diaz, Silvia M. (2014) Pruebas de seguridad en aplicaciones web como imperativo en la calidad de desarrollo del software. Recuperado de: https://www.unab.edu.co/sites/default/files/MemoriasGrabadas/papers/capitulo7_p aper_13.pdf UNAD (2011) Líneas de investigación recuperado de https://drive.google.com/open?id=0B1ZfL1NdK6EMeDJPSDRjLWFLLUU