El resultado del benchmark se puede ver entrando en el siguiente link:
http://browser.primatelabs.com/geekbench2/2289491
miércoles, 11 de septiembre de 2013
martes, 3 de septiembre de 2013
sábado, 31 de agosto de 2013
Calidad de las personas que trabajan en la construccio de un producto de software
Cada
integrante del proceso de construcción de un software debe de tener claro cuál
es su papel y no desviarse en cuanto a lo que le corresponde, ya que un
proyecto de software necesita de todas las cualidades que tienen los que
participan en este.
Como
ejemplo de lo antes mencionado, se encuentra la identificación específica de
cada persona que hace parte de la construcción de un aplicativo:
Analista:
Esta persona debe de tener una buena comunicación con el cliente para poder interpretar
lo que este quiere en requisitos relevantes para desarrollar el aplicativo
deseado.
Programador:
Es capaz de comprender la información generada por el analista para plasmarla
en la construcción del producto, es decir, la codificación del software.
Diseñador:
Esta persona debe de darle una apariencia “atractiva” y “amigable” al trabajo
hecho por el programador.
Web
master: Debe de dar a conocer el producto en la web y también ofrecer servicios
en esta plataforma. Además tiene la capacidad de actualizar y dar soporte a la página
web de la institución para la cual está trabajando.
Tester:
Está en condiciones de evaluar con criterio el producto de software para poder
identificarle sus falencias y defectos y así mejorar lo el proceso que lleva
dicho aplicativo.
La calidad de estas personas
se centra en que su trabajo es complementario, cada uno necesita de la labor
del otro para cumplir con su objetivo, por esta razón al principio se mencionó
de que no hay que desviarse en la tarea que tiene cada persona que participa en
la construcción de un software ya que todo funciona de forma secuencial y
progresiva.
Pruebas de caja negra (Diseño)
Santiago
Ramírez
Krishna
Galvis
Facebook
Pruebas
de análisis de valores límite
1)
Control del número de amigos
- Rango
0 y 5000 amigos
- Casos
de prueba para agregar amigos si se tienen 0,1 y 5000.
2)
Login del programa. Comprobar la función
de ingreso al sistema
-Entrada: caja de texto usuario y de
contraseña y botón entrar.
-Casos de prueba: Pulsar el botón “entrar”
con el usuario y contraseña. válidos, incorrectos y con sus respectivas cajas
de texto vacías.
3)
Conversaciones simultaneas
- Entrada:
De 1 a 20 conversaciones simultaneas
- Casos
de prueba: Hacer 1, 4, 20 y 21 conversaciones simultaneas.
4)
Peso permitido para enviar archivos
adjuntos
- Entrada:
Rango entre 1 byte y 25mb.
- Casos
de prueba: Cargar archivos de 1mb, 25mb y 26mb.
Partición
equivalente
1) Numero
de amigos, Valido 1 a 5000, Invalido más de 5000 amigos.
2) Tamaño
de archivos adjuntos Valido 1 byte a 25mb, Invalido más de 25mb.
3) Opciones
de fotos videos e imágenes, Valido: “Me gusta” “Compartir” “Comentar”,
Invalido: otros valores.
4) Entrada
al sistema, Valido: Usuario y contraseña correctos, Invalido: Usuario y
contraseña incorrectos.
5) Archivos
para la portada del perfil, Valido: archivos con extensiones de imagen,
Invalido: archivos con otros formatos como audio o video.
Jdownloader
Pruebas
de análisis de valores límite
1) Numero
de descargas simultaneas (El usuario puede configurar el limite)
- Entrada:
El usuario modifico el rango entre 1 y 20 descargas
- Casos
de prueba: Descargar 1, 20 y 22 archivos simultáneamente.
2) Archivos
existentes: Preguntar para cada archivo
-Entrada:
20 archivos existentes
-Casos
de prueba: Agregar 1, 2, 20 archivos iguales
3) Límite
de velocidad de descargas (Configurada por el usuario)
-Entrada: 1kb/s a 500kb/s
-Casos
de prueba: Probar el límite de velocidad con 1, 2 y 3 descargas diferentes.
4) Extractor
de archivos.rar una finalizada su descarga Cada vez que se finaliza la descarga
de un archivo comprimido, cada archivo descargado s automáticamente se
descomprime.
-Entrada:
1 a 20 lotes de archivos.
-Casos
de prueba: Descargar 1, 2, 20 archivos para comprobar que todos se extraen.
5) Tiempo
restante de las descargas
-Entrada:
Tiempo restante que aparece en cada descarga
-Casos
de prueba: Comparar el tiempo restante de 1, 2 y 4 descargas con lo que aparece
en el aplicativo.
Partición equivalente
1)
Descargar simultaneas (Configuración del
usuario: más 20 descargas), Valido: tener hasta 20 descargas simultaneas,
Invalido: tener más de 20 descargas simultaneas.
2)
Descargas de servidores Valido:
Servidores que tengan archivos vigentes, Invalido: Archivos removidos del
servidor.
3)
Agregar archivos y descargarlos con
otras descargas en curso, Valido: Parar
la descarga y agregar los nuevos archivos e iniciar de nuevo las descargas,
Invalido: Iniciar la descarga de los nuevos archivos sin parar la actual.
4)
Captchas de enlaces, Valido: Escribir el
captcha para descargar el archivo, Invalido: Cancelar el captcha.
martes, 27 de agosto de 2013
Caracteristicas de la calidad interna y externa del software
El ingeniero David alfonso nos da varios ejemplos[1] de caracteristicas internas y externas de la calidad del software las cuales son:
Ejemplos de características internas son:
[1] http://www.davidalfonso.es/la-calidad-del-software/
Ejemplos de características internas son:
- La legibilidad del código.
- La flexibilidad para cambiar la forma de usarlo.
- La facilidad de mantenerlo.
- La portabilidad.
- La reusabilidad.
- Su capacidad de ser probado.
- Su facilidad de ser comprendido a un alto nivel.
Krishna Galvis.
[1] http://www.davidalfonso.es/la-calidad-del-software/
Ciclos de vida del software
Imagen tomada de: http://es.kioskea.net/contents/223-ciclo-de-vida-del-software
Modelo
V
Imagen tomada de: http://es.kioskea.net/contents/223-ciclo-de-vida-del-software
Prototipado
Espiral
Santiago Ramírez, Krishna Galvis
Técnicas de pruebas de software
TECNICAS
DE PRUEBAS DE SOFTWARE
PRUEBA
DE LA CAJA BLANCA
La prueba de la caja blanca
es un método de diseño de casos de prueba que usa la estructura de control del
diseño procedimental para derivar los casos de prueba. Técnicas de prueba
Las pruebas de caja blanca
intentan garantizar que:
• Se ejecutan al menos una
vez todos los caminos independientes de cada módulo
• Se utilizan las decisiones
en su parte verdadera y en su parte falsa
• Se ejecuten todos los
bucles en sus límites
• Se utilizan todas las
estructuras de datos internas
PRUEBA
DEL CAMINO BÁSICO
El método del camino básico
(propuesto por McCabe) permite obtener una medida de la complejidad de un
diseño procedimental, y utilizar esta medida como guía para la definición de
una serie de caminos básicos de ejecución, diseñando casos de prueba que
garanticen que cada camino se
ejecuta al menos una vez.
PRUEBA
DE BUCLES
Los bucles son la piedra
angular de la inmensa mayoría de los algoritmos implementados en software, por
lo que tenemos que prestarles una atención especial a la hora de realizar la
prueba del software. La prueba de bucles es una técnica de prueba de caja
blanca que se centra en la validez de las construcciones de los bucles.
Se pueden definir cuatro
tipos de bucles diferentes:
• Bucles simples
• Bucles concatenados
• Bucles anidados
• Bucles no estructurados
PRUEBA
DE LA CAJA NEGRA
Las pruebas de caja negra se
llevan a cabo sobre la interfaz del software, obviando el comportamiento
interno y la estructura del programa.
Los casos de prueba de la
caja negra pretenden demostrar que:
• Las funciones del software
son operativas
• La entrada se acepta de
forma correcta
• Se produce una salida
correcta
• La integridad de la
información externa se mantiene
A continuación se derivan
conjuntos de condiciones de entrada que utilicen todos los requisitos
funcionales de un programa.
Las pruebas de caja negra
pretenden encontrar estos tipos de errores:
• Funciones incorrectas o
ausentes
• Errores en la interfaz
• Errores en estructuras de
datos o en accesos a bases de datos externas
• Errores de rendimiento
• Errores de inicialización
y de terminación
Los tipos de prueba de cana
negra que vamos a estudiar son:
• Prueba de partición
equivalente
• Prueba de análisis de
valores límites
Tomado de: http://indalog.ual.es/mtorres/LP/Prueba.pdf
Medidas en el software
Medidas
en el software
La
medición juega un papel fundamental en las organizaciones que pretenden
incrementar el grado de madurez en sus procesos a través de la mejora de
procesos de software. Este hecho se demuestra observando el tratamiento e importancia
que los modelos relacionados con la mejora de procesos de software le dan al
proceso de medición, entre los que se destacan:
•La norma
ISO/IEC 12207 [6] describe los procesos del ciclo de vida del software y
explícitamente define en el grupo de procesos de gestión un “proceso de
medición”; el propósito de ́este es recolectar y analizar los datos relacionados con los
productos desarrollados y procesos implementados al interior de la organización
en sus proyectos, y a poyar la gestión efectiva de los procesos y demostrar
objetivamente la calidad de los productos.
•CMMI [7]
incluye un ́área clave de proceso en el nivel dos de madurez denominada “medición
y análisis”. El alcance es mucho más amplio y explıcito que el tratamiento de
la medición en el modelo CMM. Esta incorporación proporciona una gestión con el
enfoque y la visibilidad que las organizaciones necesitan para guiar el uso de
la medición en sus esfuerzos de mejora. El objetivo de esta ́área es desarrollar
y establecer una capacidad de medición
que se pueda usar para dar soporte a las necesidades de información de la organización.
• Es
importante mencionar los modelos para mejorar la capacidad de procesos de
software desarrollados explícitamente para pequeñas empresas, como es el caso
del proyecto COMPETISOFT [8], el cual considera la medición del software como
un elemento neurálgico para incrementar la capacidad de los procesos y, por
ende, la madurez de la organización. Además, hay otros trabajos que abordan la
medición del nivel de capacidad de proceso en pequeñas empresas.
•ISO 9000:2000 establece la necesidad de
implementar el proceso de medición con el objetivo de controlar la calidad del
producto, la capacidad del proceso y la satisfacción del cliente. La gestión
usa medidas como una entrada fundamental para la planificación, control y gestión
del proyecto; todo ello orientado a la mejora continua del proceso.
Santiago Ramirez / Krishna Galvis
Tomado de http://publicaciones.eafit.edu.co/index.php/ingciencia/article/view/338/342 el lunes 19 de agosto a las 6:00 PM
Tomado de http://publicaciones.eafit.edu.co/index.php/ingciencia/article/view/338/342 el lunes 19 de agosto a las 6:00 PM
lunes, 26 de agosto de 2013
Retos y oportunidades del TLC para el software
Revisando en internet los requisitos establecidos por el TLC encontramos segun Paola Restrepo :
"El
TLC abriga grandes oportunidades para los desarrolladores colombianos de
software, pero estas solo se podrían aprovechar si están preparados y certificados
internacionalmente para competir en el mercado estadounidense.
Es
por esto que desde Fedesoft se vienen desarrollando diferentes acciones y
programas de capacitación como el desarrollado en conjunto con Intersoftware y
el apoyo del Servicio Nacional de Aprendizaje SENA para el fortalecimiento del
capital humano de las compañías del sector a nivel nacional.
Uno
de estos programas fue la implementación de prácticas TSP (Team Software
ProcessSM) y PSP (Personal Software ProcessSM), procesos personales y de equipo
para desarrollo de software en el 2011.
Así
mismo, en el segundo semestre del 2012 se viene desarrollando el
Programa de Formación Especializada para Apoyar la Implementación de CMMI,
(Capability Maturity Model for Integration).
Este
es el Modelo Integrado de Madurez y de Capacidad para las empresas de
desarrollo de software.
Para
estos dos programas, los profesionales recibieron certificados otorgados por
el Instituto de Ingeniería de Software (SEI) de la universidad Carnegie
Mellon de Estados Unidos, plataforma para lograr que la industria del software
colombiana sea altamente competitiva a nivel internacional, basada en altos
niveles de calidad."[1]
Da a entender que el TLC con estados unidos requiere que aquellos que desean participar deberan estar certificados internacionalmente, algunas de las certificaciones necesarias son TSP, PSP y CMMI entre otros.
[1]
Publicado en Octubre 4, 2012 en http://www.larepublica.co/asuntos-legales/retos-y-oportunidades-del-tlc-para-el-software_22176
sábado, 17 de agosto de 2013
Definición de términos
Funcionalidad
Es la capacidad del producto software para proveer
funciones que cumplen las necesidades expresadas o implícitas cuando el
software se utiliza en determinadas condiciones. [ISO 9126]
Dentro de la funcionalidad tenemos que un software debe ser:
Precisión: capacidad de dar el mismo resultado en mediciones diferentes realizadas en las mismas condiciones.
Adecuado: es la capacidad de un producto software de suministrar un conjunto apropiado de funciones para actividades especificadas y objetivos de usuario. [ISO 9126]
Interoperabilidad: El Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) define interoperabilidad como la habilidad de dos o más sistemas o componentes para intercambiar información y utilizar la información intercambiada.
Conformidad: Es la capacidad de los programas informáticos para satisfacer su aplicación prevista cuando estos se utilicen en las actividades de seguimiento y medición de los requisitos especificados.
Seguridad: Son los atributos de productos software que se refieren a su capacidad para prevenir accesos no autorizados, sean accidentales o deliberados, a programas y datos. [ISO 9126]
Fiabilidad
Es la habilidad de un producto software para llevar a
cabo aquellas funciones requeridas en condiciones establecidas para un período
de tiempo específico, o para un número específico de operaciones. [ISO 9126]
Dentro de fiabilidad tenemos que un software debe cumplir con:
Madurez: El estándar del IEEE 982.1-1988 sugiere un índice de madurez del software (IMS) como métrica específica de mantenimiento. Esta métrica proporciona una indicación de la estabilidad de un producto software. A medida que el IMS se aproxima a 1, el producto comienza a estabilizarse, y por lo tanto, menos esfuerzo de mantenimiento requerirá.
Tolerancia a errores: Se debe conseguir que el sistema continúe funcionando aunque se
produzcan fallos.
Recuperabilidad: Es la capacidad de un producto software para restablecer un nivel específico de rendimiento y recuperar la información directamente afectada en caso de fallo. [ISO 9126]
Usabilidad
Es la capacidad del software para ser comprendido,
aprendido, utilizado y atractivo al usuario cuando es utilizado bajo
condiciones especificadas. [ISO 9126]
nos referimos a estos términos como:
Comprensibilidad: Es la capacidad del producto software para facilitar al usuario apreciar si el software es adecuado y cómo puede ser utilizado para tareas y condiciones de uso específicas. [ISO 9126]
Aprendibilidad: Es la capacidad del producto software de permitir al usuario aprender su forma de uso. [ISO 9126]
Operabilidad: Es la capacidad de un producto software para permitir al usuario manejarlo y controlarlo. [ISO 9126]
Atractividad: es la capacidad del producto software de ser atractivo al usuario. [ISO 9126]
Eficiencia
Es la capacidad del producto software para proporcionar
un rendimiento apropiado, relativo a la cantidad de recursos usados bajo
condiciones establecidas. [ISO 9126].
Para que un software sea cumpla con esto debe tener:
Tiempo de respuesta: Un software no debe tardar mucho en realizar una tarea que el usuario le pida realizar.
Utilización de recursos: Es la capacidad de un producto software para hacer uso de cantidades y tipos de recursos apropiados, por ejemplo cantidad de memoria principal y secundaria utilizada por el programa y tamaños requeridos de archivos temporales, cuando el software realiza su función en condiciones establecidas. [Según ISO 9126].
Manentibilidad
Es la facilidad con la que un producto software puede ser
modificado para corregir defectos, cumplir con nuevos requisitos, hacer más
sencillo el mantenimiento futuro o ser adaptado a un entorno modificado. [ISO
9126]
Dentro de matentibilidad tenemos que un software debe ser:
Analizable: es la capacidad de un producto software de ser diagnosticado por deficiencias o causas de fallos en el software, o para las partes a ser modificadas o identificadas. [ISO 9126]
Cambiable: es la capacidad de un producto de software para cambiar pequeñas partes de sus componentes para ajustarse a diferentes situaciones.
Estabilidad: Estabilidad es la capacidad del producto software de evitar efectos inesperados producidos por modificaciones del software. [ISO 9126]
Portabilidad
Es la facilidad con la que un producto software puede ser
transferido de un entorno hardware o software a otro. [ISO 9126]
Dentro de la portabilidad tenemos que un software debe tener:
Adaptabilidad: Es la capacidad del producto software de ser adaptado a diferentes entornos sin la aplicación de acciones o medios distintos de los aportados para este propósito por el software considerado. [ISO 9126]
Instabilidad: Es la capacidad del producto software para ser instalado en un entorno especificado. [ISO 9126]
Coexistencia: Es la capacidad del producto software de coexistir con otro software independiente en un entorno común compartiendo recursos comunes. [ISO 9126]
Reemplazable: es la capacidad de un producto software para ser usado en lugar de otro software especificado, con el mismo propósito en el mismo entorno. [ISO 9126]
Krishna Galvis / Santiago Ramirez
Suscribirse a:
Entradas (Atom)