Bitácora del Curso: Aseguramiento de la Calidad [IC6831]

noreply@blogger.com (Anonymous) — Fri, 12 Oct 2018 05:20:00 +0000

Imagen de prueba

Automatización de pruebas

noreply@blogger.com (Anonymous) — Mon, 23 Oct 2017 04:58:00 +0000

Automatización de pruebas

La automatización de pruebas consiste en el uso de software especial, diseñado con el fin u propósito de controlar la ejecución de pruebas y la comparación entre los resultados obtenidos y los resultados esperados. La automatización de pruebas permite incluir pruebas repetitivas y necesarias dentro de un proceso formal de pruebas ya existente o bien adicionar pruebas cuya ejecución manual resultaría difícil.

La automatización de prueba es ventajosa en situaciones en las cuales el software se modifica constantemente, dado que hasta las modificaciones menores pueden ocasionar que funcionalidad ya desarrollada deje de funcionar.

Existen dos aproximaciones a las pruebas automatizadas:

Pruebas manejadas por el código: Se prueban las interfaces públicas de las clases, módulos o bibliotecas con una variedad amplia de argumentos de entrada y se valida que los resultados obtenidos sean los esperados.

Pruebas de Interfaz de Usuario: Un marco de pruebas genera un conjunto de eventos de la interfaz de usuario, tales como teclear, hacer click con el ratón e interactuar de otras formas con el software y se observan los cambios resultantes en la interfaz de usuario, validando que el comportamiento observable del programa sea el correcto.

Lo interesantes de esto es como con el auge que está tomando el desarrollo ágil de software, representado en marcos de trabajo como Scrum, la Programación extrema (XP) y el Agile Testing, cada vez es más crítico contar con la posibilidad de realizar constantes refactorizaciones e integraciones de código. Ya que cada vez es más crítico ir a la par de los exigentes tiempos de entrega y cambios demandados por las áreas de negocio. Y pues para lograr esto, es necesario automatizar las pruebas funcionales y de regresión, con la finalidad que estas pruebas se puedan ejecutar de forma rápida y repetitiva.

Los principales atributos de las herramientas y la automatización son, según Ron Patton (2001):

Velocidad: Piense en cuánto tiempo le llevaría probar manualmente unos miles de casos de prueba para la Calculadora de Windows. Puede promediar un caso de prueba cada 5 segundos más o menos. La automatización podría ejecutar 10, 100 o incluso 1000 veces más rápido.

Eficiencia: Mientras estás ocupado ejecutando casos de prueba, no puedes estar haciendo nada más. Si tiene una herramienta de prueba que reduce el tiempo que lleva realizar las pruebas, tiene más tiempo para planificar las pruebas y pensar en nuevas pruebas.

Exactitud y precisión: Después de probar unos cientos de casos, su capacidad de atención disminuirá y comenzará a cometer errores. Una herramienta de prueba realizará la misma prueba y verificará los resultados perfectamente, todas y cada una de las veces.

Implacabilidad: Las herramientas de prueba y la automatización nunca se cansan ni se rinden. Son como los conejitos de anuncios de televisión que funcionan con baterías que pueden seguir y seguir

Las herramientas simplemente les facilitan el trabajo y hacen que el trabajo resultante sea de mayor calidad. Las herramientas de prueba de software operan de la misma manera. Es por eso que siempre se debe de tener como recordatorio, que las herramientas de prueba de software no son un sustituto de los probadores de software, solo ayudan a los evaluadores de software a realizar mejor su trabajo. Es importante tener en cuenta que el uso de herramientas de prueba no siempre es la respuesta correcta. A veces no hay sustituto para las pruebas manuales.

Herramientas para la automatización de pruebas de software

1. Selenium

Es un framework para pruebas de aplicaciones Web, descargable de forma gratuita desde su sitio web. Proporciona una herramienta de gabración y playback, que permite desarrollar pruebas sin necesidad de aprender un lenguaje de Scripting. Incluye características como grabación, playback, selección de campos, auto completar formularios, pruebas de recorrido (Walkthrough), debug, puntos de control, scripts ruby y otros formatos.

2. HP Quicktest Professional (QTP)

Proporciona la capacidad de automatizar pruebas funcionales y pruebas de regresión para software y ambientes de prueba. Proporciona la capacidad de definir Scripts de prueba y posee una interfaz gráfica que le permiten al usuario emular la funcionalidad que desea probar, incluyendo el uso de interfaces de usuario de las aplicaciones a probar. Incluye características como: Vista de experto, pruebas de procesos de negocio, grabado de pantalla (para captura de las evidencias de prueba), entre otras posibilidades.

3. Watir

Pronunciado “Water”, es una familia de librerías Ruby de Código Abierto (Open Source) para la automatización de navegadores web. Le permite a su usuario escribir pruebas fáciles de leer y mantener. Sencilla y flexible. Tiene la capacidad de hacer clic en enlaces, llenar formularios de pantallas con datos y presionar botones. Watir también revisa los resultados, incluyendo verificar si los textos esperados se muestran en las páginas. Tiene la capacidad de enlazarse con bases de datos, leer archivos de datos y hojas de cálculo, exportar XML y estructurar los códigos como librerías reutilizables.

4. Visual Studio Test Proffessional

Conjunto de herramientas de pruebas integradas desarrolladas por Microsoft, que proporcionan soporte a todo el ciclo de planificación, ejecución y registro de pruebas, con facilidades de colaboración entre analistas de prueba (testers) y desarrolladores en la herramienta. Proporciona capacidad de realizar pruebas manuales, reutilización de pruebas manuales, integración con el “team foundation server”, gestión de ciclo de vida de aplicaciones, entre otros.

5. Rational Functional Tester

Herramienta de automatización de pruebas funcionales y de regresión. Proporciona capacidades de pruebas de interfaz gráfica, pruebas manejadas por datos (Data Driven), pruebas funcionales y puebas de regresión. Algunas de sus características son:

Simplificación de creación y visualización de pruebas.

Pruebas de tipo storyboards.

Trazabilidad en todo el ciclo de vida.

Validación de data dinámica (por medio de un wizard).

E inclusive capacidad de definir scripts (por medio de lenguajes de Scripting).

6. UFT (Unified Functional Testing)

Hace que tus pruebas automatizadas sean más eficientes a la vez que ayuda a los desarrolladores y responsables de pruebas a colaborar (algo muy beneficioso, y que cada vez se instaura más gracias a la filosofía Devops). Esta herramienta nos permite la importación de activos de pruebas manuales como grabaciones convirtiendo en activos de automatización de pruebas reutilizables para pruebas de regresión e integración.

Beneficios que aporta la automatización de pruebas

Una suite de pruebas, un sistema de pruebas de regresión automatizadas que permite una ejecución de las pruebas rápida, frecuente y completa, sin necesidad de presencia continua de los equipos de QA.

Mayor eficiencia de las herramientas de testing utilizadas dentro de su organización.

Mejor calidad en la ejecución de pruebas. No existen dudas de si el tester ha olvidado algún caso de prueba o de si, por error, ha entrado mal los datos.

Reducción de los costes de mantenimiento de pruebas. El mantenimiento y la flexibilidad son los dos objetivos principales a la hora de diseñar una suite de pruebas.

Los responsables del negocio pueden mantener los casos de prueba sin necesidad de conocimientos de automatización de pruebas.

Un enfoque repetible para la automatización de pruebas. Un diseño de la suite de pruebas que incluya componentes reutilizables proporciona una base que facilita la creación más fácil y de menor coste de futuras suites.

Factores clave del éxito de la automatización de pruebas

La experiencia nos demuestra que para llevar a cabo un proyecto de automatización de pruebas éxitoso es necesario contar con:

Compromiso.

Test estructurado (técnicas y métodos contrastados).

Conocimientos necesarios (test estructurado, herramientas e infraestructura).

Desarrollo rápido de nuevos test automatizados.

Capacidad para mantener la automatización mediante la modulación y la reutilización.

Conclusión

Actualmente la automatización es algo que se da día con día, es parte esencial de la ejecución de pruebas, ya que es de gran ayuda como lo hemos visto, pero como probar el software, lo decide cada empresa o cada uno de nosotros, ya que hoy en día estamos expuesto a una amplia gama de herramientas de prueba, claramente habrá unas a las que simplemente no podemos acceder pero habrá otras a las que si. Por lo tanto los tipos de herramientas que posiblemente usaremos se basan en el tipo de software que está probando y si está realizando pruebas de caja negra o de caja blanca.

Personalmente, las herramientas de prueba es que no siempre son necesarias, también el ser humano es capas de realizar ese tipo de tareas, aunque siendo sincero la automatización si que ayuda, pero aun así existen expertos que son mejores que este tipo de pruebas, ni haciendo cientos de pruebas de automatización pueden llegar a realizar el trabajo de estos ejecutan, claro el tiempo y los costos son mayores, pero el resultado no podría ser mejor.

Referencias Bibliográficas

Henostroza, G. (25 de febrero de 2017). Slideshare. Obtenido de Automatizacion de Pruebas: https://es.slideshare.net/guino3/automatizacion-de-pruebas

Informatica, P. (5 de noviembre de 2012). Pmo Informatica. Obtenido de 5 Herramientas para la automatización de pruebas de software: http://www.pmoinformatica.com/2012/11/5-herramientas-para-la-automatizacion.html

López, E. (s.f.). Globe. Obtenido de Automatización: ¿Cuándo implementarla?: https://www.globetesting.com/2016/02/automatizacion-cuando-implementarla-2/

Oterino, A. M. (23 de enero de 2015). Javier Garzás.com. Obtenido de “Vamos a automatizar pruebas”. ¿Qué significa esto? ¿Realmente por dónde deberíamos empezar a automatizar?: http://www.javiergarzas.com/2015/01/automatizacion-pruebas.html

Salazar, A. N. (29 de abril de 2011). Slideshare. Obtenido de Pruebas Automatizadas: https://es.slideshare.net/snahider/pruebas-automatizadas-de-software

Patton, R. (2001). Software Testing. Indianapolis, Indiana: Sams Publishing.

Plan de Pruebas Y Plantilla de Plan de Pruebas

noreply@blogger.com (Anonymous) — Mon, 16 Oct 2017 05:57:00 +0000

Pruebas

Las pruebas de software o también conocidas como software testing son aquellas investigaciones empíricas y técnicas cuyo objetivo es proporcionar información objetiva e independiente sobre la calidad del producto a la parte interesada o stakeholder. Donde básicamente las pruebas son un conjunto de actividades dentro del desarrollo de software, estas dependerán del tipo de pruebas como ya lo hemos comentado anteriormente, estas actividades podrán ser implementadas en cualquier momento de dicho proceso de desarrollo.

1. Analizar los requerimientos de desarrollo de software

Para elaborar un plan de pruebas de software lo primero que se debe hacer es entender los requerimientos de usuario que componen la iteración o proyecto, que son el sujeto de la verificación de calidad que se va a realizar. Se deberá analizar toda la información de la ingeniería de requisito, incluyendo la matriz de trazabilidad, especificaciones y diseño funcional, requisitos funcionales, no funcionales, casos de uso etc. También es muy importante realizar entrevistas con el equipo encargado de la ingeniería de requisitos para aclarar dudas y ampliar la información que sea necesaria. Ademas de las preguntas especificas de cada requisito, es importante hacer preguntas de alcance general, por ejemplo

¿Es un sistema nuevo o existente?

¿Cuáles funcionalidades existentes están siendo modificadas?

¿Cuáles son los requisitos no funcionales? Entre otras.

2. Identificar las funcionalidades nuevas a probar

A partir de la documentación del análisis de requisitos y de las entrevistas con el equipo de ingeniería de requisitos y desarrollo, se deben de identificar e incluir en el plan de pruebas de software la lista de las funcionalidades (características) totalmente nuevas. En el caso de desarrollos de software integrados a un sistema existente es necesario que se revise con los analistas de negocio y también con los arquitectos de software las funcionalidades que forman parte del desarrollo de software, en todas las capas de la arquitectura.

3. Identificar las funcionalidades de sistemas existentes que deben aprobarse

Se debe identificar las funcionalidades existentes que estén siendo impactadas por el desarrollo de alguna forma, considerando todos los componentes afectados en todas las capas de la arquitectura de software. Existen dos situaciones que se puede encontrar al identificar estas funcionalidades:

Funcionalidades modificadas de cara al usuario: Por ejemplo si una funcionalidad está siendo modificada agregando más pantallas o cambios a su flujo de proceso, debe ser incluida en el plan de pruebas de software.

Funcionalidades modificadas en sus componentes internos: Son funcionalidades no modificadas de cara al usuario, manteniendo la misma interfaz gráfica y flujo de procesos, sin embargo, si se modifican componentes internos que comparten con otras funcionalidades del sistema, en las capas de lógica de negocio o acceso a datos. Estas deben incluirse en el plan de pruebas de software para determinar a partir de ellas pruebas de regresión a realizar.

Se debe de considerar que quienes pueden suministrar la información serán los Analistas de negocio o Arquitectos de software, familiarizados con el sistema informático implementado en entorno de producción.

4. Definir la estrategia de pruebas

Consiste básicamente en seleccionar cuáles son los tipos de pruebas de software que se deben realizar. Se recomienda seguir un marco de referencia para determinar los tipos de prueba, como por ejemplo los tipos de pruebas de software definidos por el ISTQB.

Pruebas funcionales: Se determinan los conjuntos de pruebas a realizar, correspondiente con cada funcionalidad nueva o existente que se esté modificando. Se tienen distintos tipos de pruebas funcionales, por ejemplo, las pruebas de sistema (o pruebas integradas de sistemas), que se realizan después que el equipo de desarrollo ha integrado los componentes de distintas capas. Las pruebas funcionales son definidas por el ISTQB como pruebas basadas en especificación. Son diseñadas usando técnicas de diseño de pruebas de caja negra. Aquí te compartimos un artículo interesante que habla sobre el tema.

5. Definir los criterios de inicio, aceptación y suspensión de pruebas

Criterios de aceptación o rechazo:

Para definir los criterios de aceptación o rechazo, es necesario definir el nivel de tolerancia a fallos de calidad. Si la tolerancia a fallos es muy baja puede definirse como criterio de aceptación que el 100% de los casos de prueba estén sin incidencias. Lograr este margen en todos los casos de prueba principales y casos borde será muy difícil, y podría comprometer los plazos del proyecto (incrementa los riesgos), pero asegura la calidad del producto. Por otra parte, puede ser que la intención sea realizar un Soft Launch, o un mínimo producto viable, en ese caso se podría definir como criterio de aceptación el 100% de los casos de prueba principales (considerados clave) y 20% de casos de prueba no principales (casos borde). Una vez logradas las condiciones, se darán por aceptadas las pruebas y el desarrollo de software.

Criterios de inicio o reanudación:

Definen las condiciones que deben cumplirse para dar inicio o reanudar las pruebas. Por ejemplo, en el caso de inicio la condición podría ser la instalación de los componentes de software en el ambiente y que los casos de pruebas de verificación de ambiente sean exitosos. Para el caso de la reanudación las condiciones están relacionadas, se determina a partir de cuales criterios de suspensión se presentaron para detener las pruebas. Una vez que estás condiciones ya no existan (sean solventadas) se procede con la reanudación.

Criterios de suspensión:

Las condiciones van a depender de los acuerdos de nivel de servicio (SLAs) internos de la organización y también de los acuerdos establecidos en cada proyecto individual. Por ejemplo, si se tiene un equipo de pruebas que comparte su esfuerzo entre varios proyectos, se puede definir un criterio de suspensión exigente, un determinado porcentaje de casos fallidos que resulten en incidencias. Si la condición se cumple, se detienen las pruebas y se dedica el personal a otras actividades, Por otra parte si se tiene un equipo de pruebas con personal dedicado, el criterio de suspensión puede ser poco exigente, por ejemplo solo ocurriendo si se bloquean por incidencia todos los casos de prueba.

6.- Identificar los entornos (ambientes) requeridos

Posteriormente se definen y documentan las características de los entornos de Hardware y Software necesarios para realizar la ejecución de las pruebas de software. Esta información se obtiene a partir del equipo de desarrollo y de los arquitectos de software, quienes pueden suministrar los requisitos mínimos y óptimos para la operación del sistema. Como mejor práctica, el ambiente de pruebas de software debería ser lo más similar posible al ambiente de producción, sin embargo, no siempre es posible debido a limitaciones de recursos (financieros). En estos casos debe estudiarse cuales son los requisitos que aseguran un mínimo de confiabilidad de estas pruebas respecto al entorno de producción.

Además en esta sección del plan de pruebas, también se definen los requisitos de sistemas operativos, software y herramientas de las estaciones de trabajo de los Testers. Si el alcance del proyecto incluye pruebas de aplicaciones (Apps) para móviles, es necesario definir los emuladores y teléfonos inteligentes, con sus respectivos requisitos. También deben definirse los requisitos de harware y software para los siguientes componentes:

Herramienta de gestión de calidad de software.

Herramientas para automatización de pruebas.

Herramientas de BDD, TDD y Testing de Web Services).

7.- Determinar necesidades de personal y entrenamiento

Debe completarse previamente la estimación del esfuerzo de pruebas a partir del diseño de casos de prueba. Si aún no se cuenta con la estimación, se puede comenzar por definir los tipos de perfiles de habilidades y conocimientos en Software Testing que se necesitan. Para ello se puede buscar la respuesta a las siguientes preguntas:

¿Qué conocimientos de procesos de negocio se necesitan?

¿Qué sistemas se están probando y quienes tienen experiencia en su funcionamiento?

¿Se necesitan conocimientos específicos en pruebas de requisitos no funcionales? Por ejemplo para pruebas de desempeño o estrés.

¿Cual herramientas de gestión de calidad de software se va a utilizar?

¿Se necesitan conocimientos en herramientas técnicas como Lenguajes de programación o herramientas de pruebas de webservices?

¿Se necesitan conocimientos en herramientas de pruebas automatizadas?

8.- Establecer la metodología y procedimientos de prueba

La metodología de pruebas de software dependerá de la que se esté utilizando para la gestión del proyecto. Si se está utilizando una metodología predictiva, las pruebas de software comenzaran con la estimación del esfuerzo de pruebas, diseño y luego la ejecución de las pruebas. Si se están utilizando metodologías ágiles de desarrollo de software, debe estar alineada con el manifiesto ágil, como te contamos e nuestra serie de artículos de Agile Testing. Luego se seleccionar la metodología de referencia, se documentan los procedimientos para diseño y ejecución, siguiendo el orden de los pasos definidos, flujos de procesos, condiciones para tomar decisiones, y demás aspectos.

9.- Elaborar la planificación de las pruebas

La planificación de las pruebas abarca:

Matriz de responsabilidades: Puede usarse una Matriz RACI o Matriz RAM como plantilla. Esta se define con perfiles genéricos o inclusive con el equipo de trabajo si ya se conoce cuál es el que será asignado. Las tareas del plan de pruebas deben estar alineadas con las habilidades y conocimientos de cada persona.

Cronograma: Elaborado a partir de la estimación de las actividades de Software Testing realizada por el equipo. Para elaborar un cronograma real, es importante definir actividades críticas como por ejemplo los tiempos de instalación de versiones en los entornos de pruebas, pruebas de validación de ambientes antes de comenzar a hacer las pruebas y las iteraciones por incidencias, que es el tiempo invertido en volver a probar los casos de prueba fallidos.

Premisas: Son las condiciones que deben cumplirse para que el cronograma sea realizable, estas se determinan a partir de la documentación de entornos y de los requisitos de personal. Por ejemplo disponibilidad de ciertos entornos, disponibilidad de personal con algún conocimiento técnico especifico, la metodología que se va a utilizar, premias que deben cumplirse para poder aplicarla, entre otros.

10. Identificar los riesgos y definir planes de respuesta

Para el Software Testing, los riesgos por lo general están vinculados con factores como:

Posibles dificultades en la disponibilidad de entornos.

Pruebas que dependen de factores externos al proyecto y la organización.

Disponibilidad de personal con conocimientos especializados en alguna herramienta, o en la funcionalidad especifica que se está desarrollando.

Dependencias con otros proyectos.

Posibilidad que alguna premisa no se cumpla.

Para identificar los riesgos es necesario enumerar cada una de estas dependencias y por medio de mesas de trabajo y tormentas de ideas pensar en las posibilidades de que algo salga mal (u oportunidades para que salga bien). Luego de la identificación, es necesario también definir planes de respuesta, los cuales deben ser específicos para cada situación particular y riesgo.

Plantilla del plan de pruebas de software

En el desarrollo de software, la fase de pruebas es crítica para asegurar que el producto sea enviado a ambiente de producción con la calidad esperada por el cliente. Es por esto que hoy en día es indispensable contar con un Plan de Pruebas de Software para especificar minuciosamente las funciones a probar, como serán ejecutadas esas pruebas, quienes serán los responsables y el cronograma para su ejecución. El Plan de Pruebas de Software puede aplicarse a todo el Proyecto de Desarrollo de Software, o puede acotarse a una iteración o conjunto de casos. Además, puede definir jerarquías de casos de prueba a considerar.

A continuación se presenta un propuesta acerca de una plantilla de plan de pruebas

1. Historial de versiones: El histórico de las versiones del Plan de Pruebas de Software, indicando quien elaboró la versión y la fecha.

2. Ficha del proyecto: Información sobre el nombre del proyecto, departamento o área organizacional, Líder o Gerente del Proyecto, el Patrocinador (Sponsor) y el Gerente o Líder de Pruebas.

3. Aprobaciones: Lista de las personas que deben aprobar el Plan de Pruebas de Software, indicando su nombre, cargo, departamento y espacio para su firma.

4. Resumen ejecutivo: Resumen de todo el contenido del plan de Pruebas de Software, describe cuál es su propósito, establece si es un plan maestro o un plan detallado, identifica el alcance del plan de pruebas en relación con el plan de Proyecto de Software, restricciones (por ejemplo de recursos o presupuesto), alcance del esfuerzo de pruebas entre otros aspectos.

5. Alcance de las pruebas: Elementos de pruebas: Listado de todos los módulos, componentes o elementos que se van a probar. Si es de alto nivel, se listan las áreas funcionales (módulos o procesos que cubre el Testing), por otro lado, si es de un nivel detallado se listan los programas, unidades o módulos.

6. Nuevas funcionalidades que probar: Es un listado de lo que se va a probar “Desde el Punto de vista del Usuario”. No es una descripción técnica del software sino sus características y funcionalidades. Se incluyen tanto las que son nuevas como las que se están modificando.

7. Pruebas de regresión: Listado de las funcionalidades no directamente involucradas en el desarrollo, pero cuyos componentes están siendo afectados y por ende deben probarse para asegurar que continúan funcionando adecuadamente. Al igual que en el punto anterior, se describen desde el punto de vista del usuario. Las pruebas de regresión son de particular importancia al realizar pruebas nuevamente después que el equipo de desarrollo ha corregido, la omisión de estas pruebas y la no identificación de errores que no han sido corregidos es el error más frecuente cometido en los procesos de seguimiento de incidencias.

8. Funcionalidades a no probar: Listado de las funcionalidades que NO se van a probar. Debe incluir información de las razones por las cuales no se van a probar y los riesgos que se están

asumiendo.

9. Enfoque de pruebas (Estrategia): La Estrategia de Pruebas puede definirse como un documento aparte, o puede ser incluido dentro del Plan de Pruebas según su extensión. Aquí pueden definirse los tipos de pruebas a realizar (funcionales, de desempeño, de interfaces, pruebas no funcionales, etc.), requerimientos especiales de las pruebas, configuraciones a probar, subconjuntos de datos a considerar, nivel de pruebas de regresión, entre otros aspectos.

10. Criterios de aceptación o rechazo:

Criterios de aceptación o rechazo: Son los criterios de aceptación que serán considerados para dar por completado el Plan de Pruebas de Software, por ejemplo: Completar 100% de pruebas unitarias, cierto porcentaje de casos exitosos, cobertura de todos los componentes y líneas de código, porcentaje de defectos corregidos, entre otros.

Criterios de suspensión: Establece claramente bajo qué condiciones se detienen un conjunto de casos de pruebas, por ejemplo en caso de existir defectos que impidan la ejecución de más casos de pruebas, cierto porcentaje de casos fallidos, o cualquier otro que se especifique.

Criterios de reanudación: Luego de haber suspendido las pruebas, aquí se establece bajo qué criterios se reanudaran.

11. Entregables: Establece que se entregará como parte de la ejecución del plan, por ejemplo: Documento de Plan de Pruebas, Casos de Pruebas, Especificación de Diseño de Casos, Logs de errores, Reportes de errores (bugs), evidencias de pruebas, reportes emitidos por herramientas de pruebas y cualquier otro que se establezca.

12. Recursos:

Requerimientos de entornos – Hardware: Lista de los requerimientos de equipos, hardware y red necesarios para completar las actividades del Plan de Pruebas de Software. Incluye Servidores de Aplicación, Bases de Datos, Equipos de PC que necesitan los Testers, Conectividad a la red (incluyendo accesos), entre otros.

Requerimientos de entornos – Software: Lista de los requerimientos de software necesarios para completar las actividades de prueba, puede incluir accesos a Sistemas (en entorno de pruebas) y Bases de Datos, así como instalación de software en los Computadores asignados a los Testers.

Herramientas de pruebas requeridas: Especifica las herramientas de software, metodologías o técnicas especiales empleadas en las pruebas, por ejemplo las herramientas de gestión de casos de pruebas. Adicionalmente, si se está haciendo uso de software de automatización, aquí también se especifican las Herramientas de Automatización de Pruebas.

Personal: Lista del personal necesario para completar las actividades de pruebas, especificando sus roles, por ejemplo: Un (1) Líder de Pruebas, Cinco (5) Analista de Pruebas (Testers), Dos (2) especialistas en automatización de pruebas, entre otros.

Entrenamiento: Necesidades de entrenamiento en el Sistema o Aplicación que se está desarrollando, así como en las herramientas de prueba a utilizar.

13. Planificación y Organización:

Procedimientos para las pruebas: Especifica los procedimientos o metodología de pruebas de software a emplear durante la ejecución del plan de pruebas de software.

Matriz de responsabilidades: Lista cada una de las personas integrantes del equipo de QA y sus responsabilidades. Se puede hacer uso de una Matriz RACI (Responsable, Aprobador, Consultado, Informado).

Cronograma: Debe estar basado en estimaciones de actividades realizadas por el equipo de prueba. En él se Identifican los hitos relevantes en las pruebas de software, se establecen las dependencias (actividades predecesoras) y demás aspectos componentes de un cronograma.

Premisas: Las premisas relacionadas con las tareas de pruebas de software, incluyendo limitaciones de tiempo, disponibilidad de recursos que se asumen, uso de una metodología de pruebas, uso de una herramienta, entre otros.

Dependencias y Riesgos: Aquí se listan los riesgos identificados en el proceso de pruebas de software, por ejemplo, algunas fuentes de riesgos suelen ser:

Dependencias con Desarrollos.
Dependencias con otros proyectos.
Disponibilidad de recursos.
Restricciones de tiempo.
Premisas que resulten no ser ciertas.

Los riesgos se pueden clasificar en función de su probabilidad e impacto, cada uno debe contemplar un plan de mitigación para evitar que ocurra o plan de contingencia cuando el riesgo no puede mitigarse y tiene que aceptarse.

14. Referencias: Lista de todos los documentos que pueden citarse como apoyo o para ampliar el contenido del plan de pruebas. Algunos ejemplos de lo que se puede hacer referencia aquí son:

Plan de Proyecto.

Especificaciones de Requerimientos. o Matriz de trazabilidad de requisitos

Diseño General.

Diseño Detallado.

Procedimientos y estándares de Desarrollo.

Procedimientos y estándares de Pruebas.

Metodologías, Procedimientos y estándares corporativos.

15. Glosario: Definiciones de términos usados en la documentación, y general sobre el área de pruebas.

Referencias Bibliográficas

choselin. (9 de diciembre de 2012). Slideshare. Obtenido de Plan de Pruebas: https://es.slideshare.net/choselin/plan-de-pruebas-15563690

PMOinformatica. (19 de mayo de 2014). PMOinformatica.com. Obtenido de Plantilla del plan de pruebas de software: http://www.pmoinformatica.com/2014/05/plan-de-pruebas-de-software.html

PMOinformatica. (18 de enero de 2016). PMOinformatica.com. Obtenido de Pruebas de software: 10 pasos para elaborar el plan de pruebas: http://www.pmoinformatica.com/2016/01/elaborar-plan-pruebas-software.html

Ramos, O. (28 de junio de 2012). Slideshare. Obtenido de Plan de pruebas: https://es.slideshare.net/iguamba666/plan-de-pruebas

Rojas, E. (6 de septiembre de 2012). Slideshare. Obtenido de Plan de pruebas de software: https://es.slideshare.net/edgardohrojas/plan-de-pruebas-de-software

Pruebas de Software

noreply@blogger.com (Anonymous) — Mon, 09 Oct 2017 05:46:00 +0000

Pruebas de Software

Básicamente son los procesos que permiten verificar y revelar la calidad de un producto software antes de su puesta en marcha. Básicamente, es una fase en el desarrollo de software que consiste en probar las aplicaciones construidas. Las pruebas de software se integran dentro de las diferentes fases del ciclo de vida del software dentro de la Ingeniería de software. En este sentido, se ejecuta el aplicativo a probar y mediante técnicas experimentales se trata de descubrir qué errores tiene. Para determinar el nivel de calidad se deben efectuar unas medidas o pruebas que permitan comprobar el grado de cumplimiento respecto de las especificaciones iniciales del sistema.

Una prueba es una actividad en la que un sistema o un componente es ejecutado bajo condiciones especificadas, los resultados son observados o registrados, y una evaluación es realizada de un aspecto del sistema o componente. [IEEE Std.610.12-1990].

Otras definiciones de diferentes especialistas de pruebas manifiestan que las pruebas de software son actividades claves para que los procesos de validación y verificación tengan éxito, ya que ayudan a entregar el producto con la calidad suficiente para satisfacer las necesidades del cliente y con la certeza de que el producto cumple las especificaciones definidas.

Por lo que considero que las pruebas pueden considerarse como un proceso que intenta proporcionar confianza en el software y cuyo objetivo fundamental es demostrar al desarrollador y al cliente que el software satisface sus requisitos. Algo importante que se debe tener en cuenta es que las pruebas de software nunca se deben realizar en un entorno de producción.

Pruebas Unitarias

La prueba de unidad es la primera fase de las pruebas dinámicas y se realizan sobre cada módulo del software de manera independiente. Su objetivo es identificar errores introducidos por la combinación de programas o componentes probados unitariamente, para asegurar que la comunicación, enlaces y los datos compartidos ocurran apropiadamente. Se diseñan para descubrir errores o completitud en las especificaciones de las interfaces.

Descripción de la Prueba

Particionar los módulos en pruebas en unidades lógicas fáciles de probar.

Por cada unidad hay que definir los casos de prueba (pruebas de caja blanca).

Para esto los casos de prueba deben diseñarse de forma tal que se recorran todos los caminos de ejecución posibles dentro del código bajo prueba; por lo tanto, el diseñador debe construirlos con acceso al código fuente de la unidad a probar.

Los aspectos que considerar son los siguientes: Rutinas de excepción, Rutinas de error, Manejo de parámetros, Validaciones, Valores válidos, Valores límites, Rangos, Mensajes posibles.

Técnicas de la prueba

Comparar el resultado esperado con el resultado obtenido.

Si existen errores, reportarlos.

Criterio de completitud

Todas las pruebas planeadas han sido ejecutadas.

Todos los defectos que se identificaron han sido tenidos en cuenta.

Consideraciones Especiales

Para la elaboración de pruebas unitarias en java se puede utilizar el JUNIT y CACTUS.

Pruebas de sistema

Esta prueba tiene como objetivo verificar que se han integrado adecuadamente todos los elementos del sistema y que realizan las operaciones apropiadas funcionando como un todo. Básicamente la idea de estas pruebas es asegurar la apropiada navegación dentro del sistema, ingreso de datos, procesamiento y recuperación.

Descripción

Las pruebas del sistema deben enfocarse en requisitos que puedan ser tomados directamente de casos de uso y reglas y funciones de negocios. El objetivo de estas pruebas es verificar el ingreso, procesamiento y recuperación apropiado de datos, y la implementación apropiada de las reglas de negocios. Este tipo de pruebas se basan en técnicas de caja negra, esto es, verificar el sistema (y sus procesos internos), la interacción con las aplicaciones que lo usan vía GUI y analizar las salidas o resultados.

En esta prueba se determina qué pruebas de Sistema (usabilidad, volumen, desempeño, etc.) asegurarán que la aplicación alcanzará sus objetivos de negocio.

La prueba de Sistema incluye:

Prueba funcionalidad.

Prueba de Usabilidad

Prueba de Performance.

Prueba de Documentación y Procedimientos.

Prueba de Seguridad y Controles.

Prueba de Volumen.

Prueba de Esfuerzo (Stress).

Prueba de recuperación.

Prueba de múltiples sitios.

Para sistemas web se recomienda especialmente realizar mínimo el siguiente grupo de pruebas de sistema:

Humo.

Usabilidad.

Performance.

Funcionalidad

La prueba de sistemas es compleja por que intenta validar un numero de caracteriticas al mismo tiempo, a diferencia de otras pruebas que solo se centran en uno o dos aspectos del sistema al mismo tiempo.

Técnica

Ejecute cada caso de uso, flujo básico o función utilizando datos válidos e inválidos, para verificar que:

Los resultados esperados ocurren cuando se utiliza un dato válido.

Los mensajes de error o de advertencia aparecen en el momento adecuado, cuando se utiliza un dato inválido.

Cada regla de negocios es aplicada adecuadamente

Pruebas de Desempeño

El objetivo de esta prueba es validar el tiempo de respuesta para las transacciones o funciones de negocios bajo las siguientes dos condiciones:

Volumen normal anticipado.

Volumen máximo anticipado.

Descripción de la prueba

Las pruebas de desempeño miden tiempos de respuesta, índices de procesamiento de transacciones y otros requisitos sensibles al tiempo. El objetivo de las pruebas de desempeño es verificar y validar los requisitos de desempeño que se han especificado (en este caso, el desempeño ofrecido por el proponente). Las pruebas de desempeño usualmente se ejecutan varias veces, utilizando en cada una, carga diferente en el sistema. La prueba inicial debe ser ejecutada con una carga similar a la esperada en el sistema. Una segunda prueba debe hacerse utilizando una carga máxima. Adicionalmente, las pruebas de desempeño pueden ser utilizadas para perfilar y refinar el desempeño del sistema como una función de condiciones tales como carga o configuraciones de hardware

Las principales actividades son:

Comparar el desempeño del sistema actual con los requisitos,

Poner a punto el sistema para mejorar las métricas de desempeño y proyectar la capacidad futura de carga del sistema.

Los objetivos de nivel de servicio definidos deben guiar la prueba de performance. Algunas características que afectan el desempeño son:

Errores lógicos.

Procesamiento ineficiente.

Diseño pobre: muchas interfases, instrucciones y entradas/salidas.

Cuellos de botella en discos, CPU ó canales de entrada/salida.

Salidas del sistema.

Tiempos de respuesta.

Capacidad de almacenamiento.

Etc.

Técnica

Utilizar los procedimientos de prueba desarrollados para las pruebas del modelo del negocio (Pruebas del Sistema).

Modificar archivos de datos (para incrementar el número de transacciones) o los scripts para incrementar el número de veces que ocurre cada transacción.

Los scripts deben ser ejecutados en una máquina y deben ser repetidos con múltiples clientes.

Pruebas de Carga

Para este caso, el objetivo de la prueba se basa en que se debe verificar el tiempo de respuesta del sistema para transacciones o casos de uso de negocios, bajo diferentes condiciones de carga.

Descripción de la Prueba

Las pruebas de carga miden la capacidad del sistema para continuar funcionando apropiadamente bajo diferentes condiciones de carga. La meta de las pruebas de carga es determinar y asegurar que el sistema funciona apropiadamente aún más allá de la carga de trabajo máxima esperada. Adicionalmente, las pruebas de carga evalúan las características de desempeño (tiempos de respuesta, tasas de transacciones y otros aspectos sensibles al tiempo).

Técnica

Use los scripts desarrollados para Pruebas del Negocio.

Modifique archivos de datos (para incrementar el número de transacciones o veces que cada transacción ocurre).

Pruebas de Stress

Objetivo de la Prueba: Verificar que el sistema funciona apropiadamente y sin errores, bajo estas condiciones de stress:

Memoria baja o no disponible en el servidor.

Máximo número de clientes conectados o simulados (actuales o físicamente posibles).

Múltiples usuarios desempeñando la misma transacción con los mismos datos.

Descripción de la Prueba

Las pruebas de stress se proponen encontrar errores debidos a recursos bajos o completitud de recursos. Poca memoria o espacio en disco puede revelar defectos en el sistema que no son aparentes bajo condiciones normales. Otros defectos pueden resultar de incluir recursos compartidos, como bloqueos de base de datos o ancho de banda de la red. Las pruebas de stress identifican la carga máxima que el sistema puede manejar. El objetivo de esta prueba es investigar el comportamiento del sistema bajo condiciones que sobrecargan sus recursos. No debe confundirse con las pruebas de volumen: un esfuerzo grande es un pico de volumen de datos que se presenta en un corto período de tiempo.

Aunque muchas pruebas de esfuerzo representan condiciones que el programa encontrará realmente durante su utilización, muchas otras serán en verdad situaciones que nunca ocurrirán en la realidad. Esto no implica, sin embargo, que estas pruebas no sean útiles. Si se detectan errores durante estas condiciones “imposibles”, la prueba es valiosa porque es de esperar que los mismos errores puedan presentarse en situaciones reales, algo menos exigentes.

Técnica

Usar los scripts utilizados en las pruebas de desempeño.

Para probar recursos limitados, las pruebas se deben correr en un servidor con configuración reducida (o limitada).

Para las pruebas de stress restantes, deben utilizarse múltiples clientes, ya sea corriendo los mismos scripts o scripts complementarios para producir el peor caso de volumen de transacciones.

Pruebas de Volumen

Se basan en su objetivo de verificar que la aplicación funciona adecuadamente bajo los siguientes escenarios de volumen:

Máximo (actual o físicamente posible) número de clientes conectados (o simulados), todos ejecutando la misma función (peor caso de desempeño) por un período extendido.

Máximo tamaño de base de datos (actual o escalado) y múltiples consultas ejecutadas simultáneamente.

Descripción de la Prueba

Las pruebas de volumen hacen referencia a grandes cantidades de datos para determinar los límites en que se causa que el Sistema falle. También identifican la carga máxima o volumen que el sistema puede manejar en un período dado. El objetivo de esta prueba es someter al sistema a grandes volúmenes de datos para determinar si el mismo puede manejar el volumen de datos especificado en sus requisitos.

Técnica

Utilizar los scripts diseñados para las pruebas de desempeño.

Deben usarse múltiples clientes, ya sea corriendo las mismas pruebas o pruebas complementarias para producir el peor caso de volumen por un período extendido.

Se utiliza un tamaño máximo de Base de datos y múltiples clientes para correr consultas simultáneamente para períodos extendidos.

Pruebas de Seguridad y Control de Acceso

Objetivos de la Prueba

Nivel de seguridad de la aplicación: Verifica que un actor solo pueda acceder a las funciones y datos que su usuario tiene permitido.

Nivel de Seguridad del Sistema: Verificar que solo los actores con acceso al sistema y a la aplicación están habilitados para accederla.

Descripción de la Prueba

Las pruebas de seguridad y control de acceso se centran en dos áreas claves de seguridad:

Seguridad del sistema, incluyendo acceso a datos o Funciones de negocios y

Seguridad del sistema, incluyendo ingresos y accesos remotos al sistema.

Las pruebas de seguridad de la aplicación garantizan que, con base en la seguridad deseada, los usuarios están restringidos a funciones específicas o su acceso está limitado únicamente a los datos que está autorizado a acceder. Las pruebas de seguridad del sistema garantizan que solamente aquellos usuarios autorizados a acceder al sistema son capaces de ejecutar las funciones del sistema a través de los mecanismos apropiados.

Debido a la creciente preocupación de la sociedad por la privacidad de la información, muchos programas tienen objetivos específicos de seguridad. El objetivo de esta prueba es evaluar el funcionamiento correcto de los controles de seguridad del sistema para asegurar la integridad y confidencialidad de los datos. El foco principal es probar la vulnerabilidad del sistema frente a accesos o manipulaciones no autorizadas. Una manera de encontrar esos casos de prueba es estudiar problemas conocidos de seguridad en sistemas similares y tratar de mostrar la existencia de problemas parecidos en el sistema que se examina.

Algunas consideraciones de prueba son:

Controles de acceso físico.

Acceso a estructuras de datos específicas a través de los programas de aplicación.

Seguridad en sitios remotos.

Existencia de datos confidenciales en reportes y pantallas.

Controles manuales, incluyendo aquellos para autorización y aprobación, formularios, documentación numerada, transmisión de datos, balances y conversión de datos.

Técnica

Funciones / Seguridad de Datos: Identificar cada tipo de usuario y las funciones y datos a los que se debe autorizar.

Crear pruebas para cada tipo de usuario y verificar cada permiso, creando transacciones específicas para cada tipo de usuario.

Modificar tipos de usuarios y volver a ejecutar las pruebas. En cada caso, verificar si los datos o funciones adicionales quedan correctamente permitidos o denegados.

Conclusión

Como hemos notado, este tema de pruebas de software es muy amplio y con muchas ramas por las cuales nosotros podemos recorrer y entender como estas funcionan y que tan importantes pueden llegar a ser. Como hemos visto las pruebas de sistemas tienen varios tipos de prueba, lo interesante aquí es como todas las pruebas siempre llegan al mismo objetivo, como a pesar de diferentes nombres siempre se están unidas unas de otras, incluso algunas trabajan en conjunto para maximizar los resultados, a lo cual llegamos a obtener resultados óptimos. En conclusión, cualquier tipo de prueba que exista, es de gran importancia para la ingeniería de software ya que estas nos ayudan a detectar gran cantidad de errores, los cuales pueden llegar a convertirse en un gran dolor de cabeza, pero gracias a las pruebas de software este número de errores se reduce considerablemente, y es aquí donde nos damos cuenta de lo valiosas que son.

Referencias Bibliográficas

Pérez, Cervantes, Urbano, Moya. (3 de marzo de 2012). Obtenido de Pruebas de Rendimiento: Tipos y objetivos: http://qatecnico.blogspot.com/2012/03/pruebas-de-rendimiento-tipos-y.html

aracelij. (13 de agosto de 2009). Slideshare. Obtenido de Pruebas De Software: https://es.slideshare.net/aracelij/pruebas-de-software

Gonzales, M. A. (1 de julio de 2014). Slideshare. Obtenido de Pruebas de software: https://es.slideshare.net/miluskaazabachegonzales/pruebas-de-software-36522714

Lemus, G. (27 de abril de 2012). Slideshare. Obtenido de Tipos de pruebas de software: https://es.slideshare.net/GuillermoLemus/tipos-de-pruebas-de-software

Mansilla, R. (4 de novimebre de 2009). Slideshare. Obtenido de Pruebas De Software: https://es.slideshare.net/cliceduca/pruebas-de-software-2420588

Londoño, J. H. (06 de abril de 2005). Obtenido de TIPOS DE PRUEBAS DE SOFTWARE: http://ing-sw.blogspot.com/2005/04/tipos-de-pruebas-de-software.html

catalinocordero. (29 de diciembre de 2014). Slideshare. Obtenido de Tecnicas de Pruebas: https://es.slideshare.net/catalinocordero/unidad-10-tecnicas-de-pruebas

Rodriguez, G. (27 de julio de 2012). Slideshare. Obtenido de Pruebas del software: https://es.slideshare.net/gladisha/pruebas-del-software-13780265

DevOps

noreply@blogger.com (Anonymous) — Mon, 02 Oct 2017 05:18:00 +0000

Breve Historial

El término DevOps se populariza a raíz de los primeros eventos DevOps Days que se suceden en Bélgica desde 2009, y que se han ido extendiendo de forma global. Su aparición está estrechamente relacionada con:

La adopción de la filosofía de producción ajustada, a nivel empresarial, y de las metodologías ágiles, en los equipos de desarrollo.

La demanda de incrementar el radio de publicación de nuevas versiones de los productos.

La amplia oferta de infraestructuras de virtualización y computación en la nube.

El incremento del uso de herramientas para la automatización de los centros de datos y de las herramientas de configuración.

Pues bien, este acrónimo significa Development Operation, esta metodología fue inicialmente creada por Patrick Debois y Andrew Clay los cuales la llamaron Agile Ops. Posteriormente iniciaron una serie de conferencias y foros llamados Devops Day, las cuales dieron nacimiento a finalmente dio origen al famoso termino, el cual se ha hecho muy popular, de hecho, es uno de los más mencionados actualmente en el entorno de TI.

Durante todo este tiempo, el movimiento DevOps se ha desplazado sobre los siguientes puntos:

Definición: Evidentemente, uno de los intereses fue concretar a qué se refería. Aún hay, de vez en cuando, bastantes discusiones sobre este tema.

Despliegue y aprovisionamiento: Centrándose en la presión constante del resto de departamentos de producción, concretar cómo se puede conectar el desarrollo, integración y despliegue continuos, a fin de satisfacer las necesidades y expectativas del negocio. Una consecuencia de esta etapa es la enorme evolución que las herramientas de integración y despliegue continuos han sufrido en los últimos años.

Monitorización: En este campo se han centrado enormes esfuerzos por mantener el control sobre los aspectos realmente importantes de la producción y operación del producto.

¿Qué es Devops?

DevOps es una metodología con la que se cambia el modo en el que se gestiona el ciclo de desarrollo de software, a nivel tecnológico, pero sobre todo a nivel cultural. Los equipos de desarrollo y de Operaciones (o sistemas) eliminan el trabajo “en silos” y comienzan a trabajar de una manera colaborativa y bidireccional. Entre todos cubren el ciclo completo de desarrollo de software, garantizando procesos mucho más rápidos y seguros, entregas más fiables y productos de calidad. Para conseguirlo, se introducen nuevas herramientas que contribuyen a la automatización de tareas repetitivas y al trabajo en equipo, ayudando a agilizar los procesos y evitar trabajo duplicado y la introducción de nuevos errores.

Esta metodología se puede representar de una manera muy sencilla, visualmente, ya que mediante la implementación de los famosos diagramas de Venn, se puede mostrar cómo está estructurado DevOps, en este se da la intersección de desarrollo (ingeniería de software), operaciones y control de calidad. Esto es de gran ayuda, ya que nos permite entender cómo se relacionan estas tres áreas que son como corazones para el desarrollo de sistemas, lo interesante de esto es que en las empresas es muy difícil que se encuentra esta integración., pero con DevOps esto queda en el pasado ya que este promueve un conjunto de procesos y métodos para tener una comunicación y colaboración entre el desarrollo, el control de calidad y las operaciones de TI.

La adopción de DevOps está siendo impulsada por factores tales como:

El uso de los procesos de desarrollo ágiles y otras metodologías.

El incremento de una mayor tasa de versiones de producción por parte de las unidades interesadas de aplicación y de negocios.

Amplia disponibilidad de virtualización y la infraestructura cloud computing de proveedores internos y externos.

Aumento del uso de la automatización del data center y las herramientas de gestión de configuración.

Objetivo

DevOps establece una “intersección” entre Desarrollo, Operaciones y Calidad, pero no se rige por un marco estándar de prácticas, sino que permite una interpretación mucho más flexible en la medida en que cada organización quiera llevarlo a la práctica, según su estructura y circunstancias.

Su principal objetivo es promover un conjunto de procesos y métodos para mejorar la comunicación y la colaboración entre departamentos.

Tres ideas claves sobre DevOps:

DevOps es una metodología para creación de software.

DevOps se basa en la integración entre desarrolladores software y administradores de sistemas.

DevOps permite fabricar software más rápidamente, con mayor calidad, menor coste y una altísima frecuencia de releases.

Cómo gestionar DevOps para extraerle el máximo rendimiento.

Recomendaciones de expertos en DevOps

1. Los programadores también deben tener conocimientos en administración de sistemas y bases de datos: para que la creación del software sea exitosa, es importante que los programadores de la codificación también tengan ciertos conocimientos sobre tratamiento de bases de datos y sistemas..

2. El paso de desarrollo a producción debe estar totalmente verificado: resulta imprescindible que exista un procedimiento autorizado y 100% seguro para que el código del salto desde el departamento de desarrollo al de producción. La idea es evitar los altísimos costes que supone tener que encontrar un error dentro del código.

3. Fomentar entre los programadores una capacidad de testeo alta: la metodología DevOps hace que cada cambio deba pasar por todo un ciclo de pruebas. Por eso, los programadores deben ser los primeros analistas de su propio código, ya que cualquier pequeño cambio puede suponer una pérdida de tiempo muy elevada si debe pasar por todo el ciclo de pruebas.

4. Crecimiento del software de forma sostenida: tal y como recomiendan muchos expertos, el inicio de cualquier proyecto de software debe contar con una codificación sencilla capaz de ir evolucionando de forma sostenible junto al proyecto. El diseño, por su parte, debe ser ambicioso y estar todo lo desacoplado posible de la programación. De esta forma, se podrán introducir modificaciones sin que las partes estructurales del software se vean directamente modificadas.

5. El software resultante tiene que ser fácil de auditar y depurar: esa es la esencia de DevOps, ya que, al eliminar las barreras entre departamentos anteriormente independientes, se pueden corregir ciertos aspectos de una forma muy fácil.

6. El sistema debe ser capaz de tener una cierta autodefensa: ante ataques o errores externos imprevistos. El objetivo, por lo tanto, es que el software siga funcionando pase lo que pase.

7. Debe existir siempre un protocolo para contener los daños en casos de emergencia: tal y como se ha comentado en pasos previos, el paso entre desarrollo y producción es muy importante y antes de enviarlo se deben de tener en cuenta todos los posibles errores que puedan producirse con el tiempo.

Conclusión

En conclusión, el termino DevOps, como lo mencionamos se ha vuelto muy popular actualmente y es algo que está tomando mucha fuerza, y que además está siendo muy influenciado en áreas de la computación como lo son el QA, desarrollo y operaciones. Así que, personalmente, este término se volverá en pieza fundamental de la ingeniería de software.

En la imagen anterior vemos como existe una pared de ladrillos que separa a dos personas, les impide comunicarse, y esto incluye todo, la comunicación entre miembros de un equipo de trabajar es algo primordial. Por eso DevOps está rompiendo este muro, gracias a sus metodologías y herramientas, se puede cambiar el modo en el que se gestiona el ciclo de desarrollo de software ya sea a nivel tecnológico, pero lo más importante es que se dé un cambio drástico a nivel cultural. De tal manera que los equipos de desarrollo y de Operaciones y QA eliminen el trabajo individual, que no se de esa arrogancia de decir que voy a hacerlo yo solo, sino que se comience a trabajar de una manera colaborativa y bidireccional, para así lograr cubrir el ciclo completo de desarrollo de software de una manera distinta a la tradicional.

Referencias Bibliográficas

Araujo, J. G. (18 de febreo de 2011). Obtenido de Que demonios es eso de Devops (y porquedebería interesarme): https://es.slideshare.net/therobot/que-demonios-es-eso-de-devops-y-porquedebera-interesarme

Bello, C. (30 de enero de 2017). Obtenido de ¿Sabes realmente qué es DevOps?: https://www.xeridia.com/blog/sabes-realmente-que-es-devops

Bruna, P. (23 de octubre de 2013). Obtenido de ¿Qué es DevOps?: http://blog.itlinux.cl/blog/2013/10/23/que-es-devops/

Fosch, I. (2 de noviembre de 2013). ENTRE DEV Y OPS. Obtenido de ¿Qué es DevOps?: http://www.entredevyops.es/posts/que-es-devops.html

Jones, M. (3 de octubre de 2010). Obtenido de DevOps: https://es.slideshare.net/geekle/devops-5348895

Lent, J. (s.f.). Obtenido de Definición de DevOps: mejor explicamos lo que no es: http://searchdatacenter.techtarget.com/es/consejo/Definicion-de-DevOps-mejor-explicamos-lo-que-no-es

Mueller, E. (8 de abril de 2015). Obtenido de DevOps 101: https://es.slideshare.net/mxyzplk/devops-101

NA. (19 de junio de 2017). Obtenido de Consejos para gestionar DevOps de manera efectiva: http://devopsfactory.es/2017/06/19/gestionar-devops-de-forma-efectiva/

Oterino, A. M. (5 de diciembre de 2014). Obtenido de Vayamos al grano, ¿qué es eso de DevOps?: http://www.javiergarzas.com/2014/12/devops-en-10-min.html

Comunidad/Software Libre

noreply@blogger.com (Anonymous) — Mon, 25 Sep 2017 00:40:00 +0000

¿Qué es una Comunidad de Software Libre?

Una Comunidad de Software Libre es un grupo de personas que cooperan entre sí en distintas áreas relacionadas con el Software Libre. Estas personas pueden ser usuarios, desarrolladores, distribuidores, soportistas, traductores entre otras cosas. Las comunidades pueden abarcar todas estas áreas, o enfocarse en algunas específicas.

En resumen, básicamente una comunidad de software libre es:

Un conjunto difuso de personas (no instituciones o empresas);

con diferentes grados de implicación a nivel temporal, de intereses, de gobierno, etc.;
con una estructura bien definida y una “cultura social” específica de la comunidad;
con liderazgos individuales o colectivos fuertes;
con individuos compartidos entre comunidades.

Son redes sociales muy evolucionadas.

Objetivos de una comunidad de software

Los objetivos de una comunidad de desarrollo de software es aglutinar una serie de individuos cuya intención es promover el acceso y distribución de una herramienta software permitiendo la libertad de su uso, estudio, copia, modificación y redistribución a todo aquel que lo desee. La cooperación entre estas personas en todos los ámbitos de la producción del software (usuarios, desarrolladores, documentadores, testers, traductores, …) permite generar las sinergias necesarias para conseguir una mejora sustancial de la calidad del software, así como de una mayor difusión y sostenibilidad en el tiempo, y primando el beneficio de la sociedad sobre cualquier otro.

Así, dependiendo del área de la comunidad, sus objetivos van a variar. Pero todas tienen en común el espíritu cooperativo, la búsqueda continua del mejoramiento y difusión del software libre y del conocimiento, y que su principal interés es la libertad de los usuarios. Entre las actividades comunes que realiza una Comunidad de Software Libre están conferencias, festivales de instalación, capacitaciones y un largo etc.

Características del software libre

Todo el mundo tiene derecho de usarlo sin costo alguno.

Todo el mundo tiene derecho a acceder a su diseño y aprender de él. Es como obtener las instrucciones para construir un carro.

Todo el mundo tiene derecho de modificarlo: si el software tiene limitaciones o no es adecuado para una tarea, es posible adaptarlo a necesidades específicas y redistribuirlo libremente.

No tiene un costo asociado (gratuito).

Es de libre distribución (cualquier persona puede regalarlo, venderlo o prestarlo).

Usualmente en el software propietario hay que pagar una “licencia de uso” al creador (como el pago de derechos por el uso de una patente) y se está sujeto a las condiciones del fabricante. Normalmente estas condiciones no otorgan ningún derecho al usuario final. Los derechos mencionados anteriormente tienen una serie de efectos colaterales sobre el Software:

Tiende a ser muy eficiente (porque mucha gente lo optimiza, mejora).

Tiende a ser muy robusto (mucha gente puede arreglarlo, no solamente el creador o la compañía que lo produce). Mucha gente tiende a contribuir, porque es en el interés de todos mejorar esta base común.

Tiende a ser muy diverso: la gente que contribuye tiene muchas necesidades diferentes y esto hace que el software esté adaptado a una cantidad más grande de problemas.

Tipos de licencia del software libre

Existen diferentes tipos de licencias del software libre, para ello tenemos que conocer a que nos referimos con la palabra licencia de un software.

¿Que es la licencia de un software libre?

Según Anguiano Diego y Huenuqueo Nicolás: “Es el procedimiento de conceder a otra persona o entidad el derecho de usar un software con fines industriales, comerciales o personales, de acuerdo con las cláusulas que en ella aparezcan. No es más que obtener la determinada licencia o autorización que le permita el uso legal de determinado programa. Esta licencia es un documento bien sea electrónico o número de serie autorizado por el autor. Podemos tener cualquier cantidad de programas instalados en nuestro ordenador, pero necesitaremos un documento o número de serie legal que nos autorice su uso.”

Anguiano Diego y Huenuqueo Nicolás. Licencias de software, Argentina: Universidad Nacional del sur, 2011. Pag. 4.

Licencias de software libre

Proporciona la libertad de:

Ejecutar el programa, para cualquier propósito.
Estudiar el funcionamiento del programa, y adaptarlo a sus necesidades.
Redistribuir copias.
Mejorar el programa, y poner sus mejoras a disposición del público, para beneficio de toda la comunidad.

En la actualidad existe una organización llamada Free Software Foundation, o Fundación para el Software Libre, que introdujo el concepto de licencia GPL (General Public License, Licencia Pública General) y que establece los derechos de uso del Software Libre.

El Software Libre no tiene por qué ser gratuito. De hecho, su denominación de Libre se debe a que se tratan de programas de Código Abierto (Open Source) y es ahí donde reside la esencia de su Libertad: los programas bajo licencias GPL, una vez adquiridos, pueden ser usados, copiados, modificados y redistribuidos libremente. GNU es el proyecto principal de esta organización, que intenta crear un sistema operativo completamente libre.

Formas de distribución

Existen diferentes formas de distribución del software, entre ellas están el Freeware y shareware. Estas dos clasificaciones afectan a la forma en la que los programas son comercializados, y son independientes de la licencia de software a la que pertenecen.

Se define como Freeware todo aquel programa que se distribuya gratuitamente, con ningún coste adicional. Nota: Existe una diferencia notable entre software libre y freeware, el conflicto nace de la palabra en ingles free, que significa libre o gratuito, por ello mismo como ya se mencionó antes, software libre no significa que sea gratis, como freeware no significa que sea libre.

El Shareware es otra modalidad de comercialización todavía más extendida, el programa se distribuye con limitaciones, bien como versión de demostración o evaluación, con funciones o características limitadas o con un uso restringido a un límite de tiempo establecido (por ejemplo 30 días). Así, se le da al usuario la oportunidad de probar el producto antes de comprarlo y, más tarde, adquirir la versión completa del programa.

Tipos de licencia

A continuación, se darán a conocer los tipos de licencias más reconocidas en el uso del software libre, la cuales son: GPL, MPL, BSD.

1. LICENCIA GPL: Con la licencia GPL (Licencia Pública General de GNU) el autor conserva su derecho de propiedad y permite la redistribución y modificación bajo términos diseñados para asegurarse de que todas las versiones modificadas del software permanezcan bajo los términos más restrictivos de la propia GNU GPL.

2. LICENCIA BSD: Es la licencia de software otorgada principalmente para los sistemas BSD. (Distribución de software para sistemas). Pertenece al grupo de licencias de Software Abierto y la principal diferencia con la GPL radica en que tiene menos restricciones. Una característica de la licencia BSD es que permite el uso del código fuente en Software Cerrado.

3. LICENCIA MPL: La licencia MPL (Licencia Pública de Mozilla) es una licencia de código abierto y Software Libre. La licencia MPL cumple completamente con la definición de software de código abierto y con las cuatro libertades del Software Libre. Sin embargo la MPL deja abierto el camino a una posible reutilización no libre del software sin restringir la reutilización del código bajo la misma licencia.

Como ya se mencionó antes, Actualmente existe una fundación, la Free Software Fundation (FSF), que es la entidad que indica si una licencia es libre o no.

1. Existe también el Software Abierto, (Open Source): cuyo principal exponente es la licencia BSD. El software abierto permite la redistribución del código y el software, sin ningún tipo de discriminación, pero no garantiza que siempre se pueda acceder al código fuente del mismo.

2. COPYLEFT: La mayoría de las licencias usadas en la publicación de software libre permite que los programas sean modificados y redistribuidos. Estas prácticas están generalmente prohibidas por la legislación internacional de copyright, que intenta impedir que alteraciones y copias sean efectuadas sin la autorización del o los autores.

Ventajas Comunidades de software libre

De forma general, las ventajas que presenta el desarrollo de software libre son:

Uso de tecnologías seguras y actuales, frente al software privativo que suele sobre explotar económicamente la tecnología elegida y por tanto, va sufriendo obsolescencia a un ritmo más elevado.

Proyectos con alto nivel de crecimiento. La aportación de la comunidad permite ampliaciones constantes del software.

Proporciona al usuario independencia en cuanto a la elección del proveedor del servicio.

Permite hacer uso del software de forma individual sin la necesidad de ningún otro intermediario.

Los costes de desarrollo se difuminan entre los voluntarios, por lo que suponen un reducido (o nulo) TCO para el usuario final, y por consiguiente, un retorno de la inversión (ROI) más rápido.

Mayores garantías de continuidad del software. Al disponer una extensa red de desarrolladores, usuarios, etc, la “supervivencia” del software no está condicionada a la subsistencia de una única empresa.

Las comunidades de software libre son más sanas y amplias que las del software propietario, que en ocasiones son incluso inexistentes.

Los desarrollos no están condicionados a criterios exclusivamente de rentabilidad, sino que cumplen una función más amplia y pueden ser solicitados y realizados por cualquiera.

Abre todas las posibilidades a la customización para el usuario final, frente a las restricciones del software propietario.

El desarrollo Open Source atrae talentos al proyecto, no siendo tan sensible como el privativo a la pérdida de recursos humanos clave en el proyecto.

Inconvenientes Comunidades de desarrollo de software libre

En cuanto a las desventajas e inconvenientes del software libre con respecto al propietario:

Posibilidad de descontinuación del proyecto o fork que arrastre a gran parte de la comunidad.

Garantías y responsabilidades no definidas. No siempre dispone del mismo nivel de acuerdos de servicio (SLA) como los prestados por una empresa de software privativo.

El alcance de muchos software de fuentes abiertas (SFA) a nivel de funcionalidad no suele cubrir los módulos de un ERP II, debiendo usar conectores para integrar con otras herramientas.

Ciertas tareas quedan relegadas por considerarse de bajo reconocimiento, tales como el testeo, la documentación, las traducciones.

La implementación de funcionalidades no está sujeto a un criterio de necesidad. Así, se podría dar la paradoja de que ciertos cambios legales de obligado cumplimiento, no encuentre desarrolladores para llevarlas a cabo.

Conclusión

En mi opinión todo lo que este relacionado con el software libre es muy útil y con grandes ventajas, ciertamente hay desventajas, pero con el open Source, el poder compartir con la demás persona, poder aprender de lo que ha hecho otra gente, es grandioso, es un manera totalmente nueva de aprender diversas tecnologías, herramientas y maneras de trabajar con una comunidad que se esmera por poder compartir, a decir verdad debe ser una gran experiencia poder formar parte de una comunidad de software libre. Creo que una de las maneras más efectivas de fortalecer cualquier comunidad de software libre ya sea en un periodo corto o para un largo plazo, es primordial difundir la comprensión del valor de la libertad, algo que es esencial en estas área del software libre ya que la libertad de compartir algo, es poder enseñar a más gente a reconocer que el software que no es libre puede ser reemplazado por software libre, en fin todo es dinero, ya que las grandes compañías se hacen rico a costas de licencias que valen miles de dólares. Creo que las personas que valora la libertad son personas abiertas, que les gusta compartir y ayudar a los demás. Además, respecto al software libre, a decir verdad, la mayoría de la gente puede prefiere el software libre debido a que se puede modificar y desarrollarlo a la medida que el usuario necesita. Aun así, también está el software privado, que también es muy utilizado, pero lo que no nos ofrece este es la variedad, mientras que el software libre nos brinda una gran variedad de recursos, podemos estudiarlo, modificarlo y compartir nuestra experiencia para agregar nuevas mejoras, con la finalidad de adaptarlo a nuestras necesidades, ya que tiene como propósito la libertad de distribución por parte de los usuarios, y todo esto lo podemos redistribuir a la comunidad que se desee.

Referencias Bibliográficas

[1] ejordi. (19 de mayo de 2010). Slideshare. Obtenido de Comunidades software libre + Comunidad OpenERP: https://es.slideshare.net/ejordi/comunidades-software-libre-comunidad-openerp

[2] Libre, R. C. (s.f.). softwarelibrecr.org. Obtenido de ¿Qué es una Comunidad de Software Libre?: http://softwarelibrecr.org/preguntas-frecuentes/que-es-una-comunidad-de-software-libre/#sthash.NsVZurLl.g8uBjyUn.dpbs

[3] Martínez, S. (s.f.). Mundo.erp . Obtenido de Las comunidades de desarrollo de software: http://mundoerp.com/blog/comunidades-de-desarrollo-de-software/

[4] Puebla, B. U. (12 de noviembre de 2013). slideshare. Obtenido de El Software Libre: https://es.slideshare.net/Mike_94/el-software-libre-28171007

[5] Stallman, R. (12 de abril de 2014). GNU Operating System. Obtenido de The Free Software Community After 20 Years: : https://www.gnu.org/philosophy/use-free-software.en.html

Pruebas Exploratorias

noreply@blogger.com (Anonymous) — Mon, 18 Sep 2017 04:55:00 +0000

Pruebas exploratorias

El término “testing exploratorio” fue introducido por Cem Kaner, se refiere a ejecutar las pruebas a medida que se piensa en ellas, sin gastar demasiado tiempo en preparar o explicarlas, confiando en los instintos.

De hecho, Según Cem Kaner “El testing exploratorio es un estilo de testing que enfatiza la libertad personal y la responsabilidad del tester para optimizar continuamente la calidad de su trabajo tratando el aprendizaje a través de las pruebas, el diseño de las pruebas, la ejecución de las pruebas y la interpretación del resultado de las pruebas como actividades que se apoyan mutuamente y que se ejecutan en paralelo a lo largo del proyecto”.

Cem Kaner

Es decir, es una técnica de prueba en la cual quien la efectúa controla activamente el diseño durante el proceso y utiliza la información obtenida en la exploración para diseñar nuevas y mejores pruebas. Durante este proceso la persona que prueba es quién diseña los tests en la misma medida en que logra desentrañar los misterios del software que evalúa, es decir que en un momento inicial puede que el líder del grupo de establezca la misión de las pruebas exploratorias, pero él que prueba es el responsable del camino a seguir el cuál puede ir modificando durante el proceso. Debido a esta particularidad del testing o pruebas exploratorias es que se hace necesario que los “probadores” posean una mente abierta, pensamiento crítico, ser un buen observador, ideas variadas, ser curioso para poder detectar incidentes y evaluar los riesgos. Deben hacer uso de heurísticas en la producción de ideas variadas de forma que las pruebas sean lo más diversas posible y acorde con las características del producto que se está probando.

¿Por qué usarlo?

Apoyo al proceso de programación detectando riesgos adicionales que no vienen recogidos en el diseño de pruebas.
Para evaluar el producto final, encontrar insuficiencias y áreas de mejora, para obtener más funcionalidades.
Sencillo y se puede hacer en momentos tempranos del sprint, herramienta natural.
Es dinámico y se obtiene un feedback rápido para los entregables del sprint.

Funciones a realizar durante las pruebas exploratorias

Para conocer más el producto y facilitar el trabajo se determinarán distintas funciones a realizar durante las pruebas exploratorias:

Funciones primarias: se asocian con la funcionalidad del producto y son esenciales para un objetivo en concreto. Un conjunto de funciones pueden constituir una función primaria, por ejemplo, las distintas funciones de una barra de herramientas no se consideran primarias, pero toda la barra de herramientas si puede considerarse una función primaria.

Funciones contributivas: colaboran con la funcionalidad del producto, pero no se consideran primarias.

Fases principales de las pruebas exploratorias

1. Exploración del producto: para conocer a fondo cómo cumplir con los requisitos hay que registrar los objetivos, las funciones, los tipos de datos que se procesan y las zonas de inestabilidad del producto. Para llevar a cabo esta exploración, hay que contar con la compresión general de la tecnología, la información sobre el producto y la cantidad de tiempo en el que se va a realizar el trabajo.

2. Diseño de pruebas: crear diferentes estrategias para observar y evaluar por completo el producto.

3. Ejecución de pruebas: explorar el producto para poder formular una hipótesis de cómo funciona y cuáles pueden ser sus puntos débiles.

4. Heurística: reglas generales que ayudarán a cómo probar correctamente el producto.

5. Resultados revisables: cuando se finalicen las pruebas exploratorias, el tester debe ser capaz de explicar cualquier aspecto del programa y mostrar cómo se cumplen los requisitos indicados en el procedimiento. De manera que, todos los requisitos hayan sido probados al menos una vez durante todo el proceso de trabajo.

Técnicas dentro del proceso de pruebas exploratorias

Existen diferentes técnicas dentro del proceso de pruebas exploratorias, aun cuando es posible aplicar el estilo libre a la hora de poner en realizarlas, existen otras modalidades de aplicación, por ejemplo:

1. Pruebas exploratorias basada en sesiones: esta técnica originalmente llamada “Session Based Test Management” de James Bach, consiste en organizar el proceso en sesiones documentadas adecuadamente. Una sesión de prueba comprende generalmente un itinerario, que se establece a partir de la misión y eventualmente, algunas de las heurísticas a ser usadas. Su principal ventaja radica en que, a pesar de su bajo costo relativo, permite elaborar reportes de avance, registrar el itinerario seguido, gestionar y medir el proceso. Es, además, adaptable y flexible. Estas características son especialmente importantes cuando se está haciendo pruebas independientes para un cliente. Su desventaja es que depende fuertemente de las habilidades y preparación de los probadores o evaluadores.

2. Prueba funcional parcial: Se usa para testear funcionalidades individuales inmediatamente luego de implementadas, con el objetivo de decidir sobre su conformidad con los requerimientos y concepciones reales del diseño. Permite una rápida retroalimentación a los desarrolladores en etapas tempranas del ciclo de desarrollo.

3. Pruebas exploratorias realizadas por usuarios: En muchas organizaciones, los usuarios exploran si las diferentes funcionalidades se adecuan a los escenarios reales de su trabajo. Estos usuarios tienen además del conocimiento del negocio, roles y responsabilidades variadas, que determinan naturalmente misiones específicas para las pruebas que desenvuelven, no es preciso simularlas.

4. Pruebas de humo exploratorias: Se utiliza para tener una visión global y rápida sobre el nivel de calidad de una nueva versión de un producto, liberada para probar, en particular cuando las actualizaciones se producen periódica y frecuentemente. Se recorre la lista de funcionalidades básicas para detectar defectos o cambios en las funcionalidades. Por otra parte, se recorre la lista de las correcciones para verificar que realmente se hayan realizado, así como las mejoras para verificar su comportamiento desde la perspectiva del usuario final.

5. Pruebas de regresión exploratorias: Cuando existen fuertes restricciones de tiempo, recursos humanos o financieros para realizar una prueba de regresión exhaustiva, el proceso se concentra en las correcciones y mejoras desarrolladas. Se basa fuertemente en la experiencia del probador para explorar la posible introducción de nuevos defectos o el surgimiento de efectos negativos colaterales.

Ventajas de la aplicación de las pruebas exploratorias.

No se necesitan productos formales previos (determinadas entregas documentales) para la realización del proceso de pruebas, lo que cual supone una disminución del esfuerzo realizado por el equipo de proyecto.

Producen una mayor motivación en el equipo que realiza las pruebas, ya que no se limitan a ejecutar paso a paso casos de prueba redactados por otros y verificar que el resultado coincide con el indicado y además permite obtener un conocimiento funcional del sistema que resulta fundamental independientemente de quien redacte los planes de prueba.

Inconvenientes de las pruebas exploratorias.

El conocimiento funcional de determinados sistemas puede ser muy complejo, lo cual podría provocar que en las primeras pruebas realizadas por el equipo, determinados aspectos funcionales de importancia, que no han sido bien desarrollados, no se detecten.

Si no se documentan de alguna manera las pruebas que se están realizando puede provocar que en el futuro sea complicado volver a repetirlas.

Posibles aplicaciones de las pruebas exploratorias.

Las pruebas exploratorias son técnicas adaptables ya que con mayor o menor efectividad se puede aplicar en la mayoría de los proyectos y, además, será la única opción posible (aunque se pueda combinar con otras técnicas) en proyectos donde los requisitos o especificaciones del sistema no se hayan recogido de manera formal o no se disponga de dicha información.

Esta técnica también se aplica cuando se quiere complementar las tareas realizadas por un equipo de pruebas con las realizadas por otro independiente. El primer resultado puede tener un carácter más estricto, dejando el segundo para descubrir posibles errores no especificados en casos de prueba.

También resultan válidas en sistemas de información, que, por su complejidad, no requieren de un proceso formal para la realización de las pruebas, pudiéndose aplicar pruebas exploratorias a la globalidad del mismo o bien a partes concretas, dejando en este caso algunos aspectos funcionales que se puedan considerar más importantes para verificarse mediante casos de prueba específicos diseñado para ellos.

Conclusión

En conclusión, es claro que se debe de tener muy claro que lo que es el testing exploratorio y como requiere su planificación, limitación de tiempo y objetivo, es importante también documentar de la mejor manera todos los tipos de pruebas que se van y se han realizado. Si no se realizan las pruebas no obtendremos resultados. Algo a destacar es que debemos de lograr obtener la satisfacción del cliente en cualquier proyecto, y considerar siempre que el proyecto haya logrado completarse de la mejor manera como, totalmente exitoso. Respecto a lo que son las pruebas exploratorias es claro que se necesitara un equipo de testing, este debe estar formado por personas con grandes capacidades, las cuales ayuden a superar obstáculos tales como el desconocimiento de la aplicación a probar de algunos de sus miembros y la corta duración del proyecto. Además, es notorio como realizar este tipo de pruebas conlleva mucho trabajo y esfuerzo por parte del grupo de trabajo, pero ciertamente si se logra desarrollar las diferentes actividades de la mejor manera, siempre teniendo en cuenta no gastar demasiado tiempo en preparar o explicarlas, lo que nos puede atrasar y ser posibles atascos para el proyecto. Si logramos evitar lo mencionado anteriormente, es muy probable que los resultados nos lleven a que los errores sean menos comunes y más fáciles de detectar.

Referencias Bibliográficas

C. Kaner, J. Falk, H. Nguyen, “Testing Computer Software, 2nd Edition”, ISBN: 0471358460, Editorial Wiley, 1999.

atSistemas. ( 10 de abril de 2017). Slideshare. Obtenido de Pruebas Exploratorias en Entornos Ágiles: https://www.slideshare.net/atSistemas/pruebas-exploratorias-en-entornos-giles

Bermúdez, Y. D. (s.f.). Revista TINO. Obtenido de LAS PRUEBAS EXPLORATORIAS O TESTING EXPLORATORIO: https://revista.jovenclub.cu/las-pruebas-exploratorias-o-testing-exploratorio/

Microsof. (julio de 2012). msdn microsof. Obtenido de Pruebas exploratorias del software: https://msdn.microsoft.com/es-es/library/jj620911(v=vs.120).aspx

NA. (s.f.). Globe. Obtenido de Pruebas exploratorias: https://www.globetesting.com/2012/03/pruebas-exploratorias/

Pérez B, P. A. (2007). Obtenido de Testing exploratorio en la práctica : http://www.ces.com.uy/documentos/JIISIC-2007.pdf

Pruebas de Caja Blanca

noreply@blogger.com (Anonymous) — Sun, 10 Sep 2017 20:26:00 +0000

¿Que es?

Las pruebas de caja blanca se centran en diseñar casos de prueba, para la comprensión de la estructura y lógica interna del sistema, por lo que su diseño está fuertemente ligado al código fuente. En estas se dan evaluaciones de pruebas dinámicas para la búsqueda de fallos en el software, además la prueba de caja blanca se basa en un detallado examen y revisión del código con el fin de conocer la lógica del software desarrollado.

De tal forma que se puedan diseñar casos de prueba para la evaluación verdadera o falsa de todas las sentencias que se ejecuten en el programa. Es por ello por lo que se considera a la prueba de Caja Blanca como uno de los tipos de pruebas más importantes que se le aplican al software, logrando como resultado que disminuya en un gran porciento(%) el número de errores existentes en los sistemas y por ende una mayor calidad y confiabilidad.

Pero a pesar de todas las ventajas que se pueden obtener de las pruebas de caja blanca, hay que tener claro que no todos los errores de software se pueden descubrir verificando todas las rutas de un programa, hay errores que se descubren al integrar unidades del sistema y pueden existir errores que no tengan relación con el código específicamente.

¡Pero!

Hay errores que se descubren al integrar unidades del sistema y pueden existir errores que no tengan relación con el código específicamente.

Objetivo de la técnica

El objetivo de la técnica es diseñar casos de prueba para que se ejecuten, al menos una vez, todas las sentencias del programa, y/o todas las condiciones tanto en su vertiente verdadera como falsa.

Características

En resumen, esta prueba usa la estructura de control del diseño procedimental para obtener los casos de prueba. También conocidas como: como pruebas de caja de cristal o pruebas estructurales. Mediante la prueba de la caja blanca se debe garantizar lo siguiente:

Que se ejercita por lo menos una vez todos los caminos independientes de cada módulo, programa o método.
Que se ejerciten todas las decisiones lógicas en sus vertientes verdadera y falsa.
Que se ejecuten todos los bucles en sus límites operacionales.
Que se ejerciten las estructuras internas de datos para asegurar su validez.

Ventajas

Es recomendable hacer estas pruebas, si se tiene la oportunidad,ya que por estas pruebas se conoce el funcionamiento interno de un sistema, lo que en el caso de la caja negra este funcionamiento se aísla los campos de un sistema (componentes), mientras que en la caja blanca se puede hacer una prueba a cada componente lo que en consecuencia puede llegar a da el funcionamiento de ese sistema o cómo es qué se trabaja.

Desventajas

Para hacer una prueba de caja blanca se debe tener mucho cuidado en examinar los componentes de un sistema ya que cualquier dato incorrecto o datos perdidos ya sea por no vistos o incorrecto uso puede llevar a un sistema al colapso y si el sistema no es ensamblado correctamente puede tenerse por seguro que el sistema no cumplirá o bien todas sus funciones o no las cumplirá correctamente o simplemente no las cumplirá. Estos es del punto de visto físico pero a estudiar un sistema del punto de vista logarítmico, solo se deben aislar los logaritmos e identificar su funcionamiento aparte y luego su funcionamiento como un todo.

Criterios de coberturas

Puede ser impracticable realizar una prueba exhaustiva de todos los caminos o sentencias de un programa, ya que se han definido distintos criterios de cobertura lógica, que permiten decidir qué sentencias o caminos se deben examinar con los casos de prueba (basados en la cobertura):

Técnicas de cobertura de caminos: Esta técnica se encarga de realizar una secuencia de sentencias desde el inicio hasta el fin del software. Para esta técnica se tiene en cuenta los siguientes criterios: Todos los caminos, Cobertura de sentencias, Ramas, etc.
Técnicas de control de flujo: el análisis de control de flujo es una técnica para determinar las estructuras de control de un programa, estructurada de la siguiente forma: Decisión, Condiciones, Decisión/Condición y de Condición Múltiple.
Técnicas de cobertura de ciclos, que es el tema a profundizar, respectivamente a lo que son las técnicas de prueba de caja blanca.

Cobertura de ciclos

La Cobertura de ciclos es una técnica de Caja Blanca, en donde el objetivo es verificar los ciclos de un programa software. Estas técnicas se caracterizan por usar grafos para describir su funcionamiento. Estos grafos siempre se componen de: Aristas, Nodos y Regiones.

Para realizar una evaluación del software con esta técnica se debe tener el código del programa, con el fin de buscar los algoritmos que contengan los ciclos para proceder a dibujar el grafo y poder identificar la lógica del código. Es importante tener en cuenta que hay diferentes tipos de ciclos.

Simples.
Anidados.
Concatenados.
Y No Estructurados.

Adicional, también hay que tener las diferentes sentencias que hay para representar un ciclo:

While.
Repeat.
For.

¿Usar esta técnica?

Para usar esta técnica es importante tener el código del programa que estamos evaluando, buscando los algoritmos que contengan los ciclos. Una vez seleccionados los segmentos de código que contienen ciclos se procede a dibujar el grafo, esto se hace para poder identificar el recorrido lógico del código. Con el grafo y el código se identifica que criterio usar para aplicar pruebas. A continuación, se explican los diferentes tipos de ciclos y sentencias que se usan como criterios para evaluar ciclos.

1. Pruebas para Bucles simples: Estos ciclos son sencillos, generalmente tienen una condición. Para probar estos ciclos tenemos unas reglas. Teniendo en cuenta que n es el número de iteraciones del ciclo:

Pasar por alto el bucle.
Pasar una sola vez.
Pasar 2 veces por el bucle.
Pasar m veces por el bucle, siendo m<n.
Pasar n-1.

2. Pruebas para Bucles anidados:Estos ciclos son aquellos que tienen un ciclo en su interior. Tenemos las siguientes reglas:

Comenzar con el bucle más interno, estableciendo los demás bucles a los valores mínimos.
Llevar a cabo las pruebas de bucles simples para el bucle más interno, conservando los valores de iteración de los bucles más externos a los valores mínimos.
Progresar hacia fuera en el siguiente bucle más externo, y manteniendo los bucles más externos a sus valores mínimos.
Continuar hasta que se hayan probado todos los bucles.

3. Pruebas para Bucles concatenados: Estos ciclos son aquellos que tienen un ciclo en su interior, pero a diferencia del anterior vuelve no hasta el inicio del ciclo externo, si no hasta si mismo. Para estos hay que verificar que forma de concatenación tiene, si es concatenación independiente se prueba igual que los bucles simples, pero si es concatenación no independiente, se trata como bucles anidados.

4. Ciclos No Estructurados: Estos ciclos son aquellos que utilizan programación no Estructurada. Para este tipo de bucles se recomienda no hacer pruebas y replantearlos, pues son una muy mala práctica de programación y seria altamente riesgoso para el software.

Sentencias:

1. Sentencias de ciclo While: A este tipo de sentencias, por teoría se les deben aplicar como

mínimo 3 pruebas:

De cero ejecuciones.
De 1 ejecución.
De más de 1 ejecución

2. Sentencias de ciclo Repeat: A este tipo de sentencias, por teoría se les deben aplicar como mínimo 2 pruebas:

De 1 Ejecución.
De más de 1 Ejecución.

3. Sentencias de ciclo For: Con este aparentemente sería sencillo sólo se tendría que hacer

1 prueba, pues él ya tiene el número de veces que se va ejecutar en la cabecera, y las decisiones se pueden revisar con la técnica de cobertura de ramas, pero el For tiene sus "trampitas", como que en su interior la variable incremente más de lo debido, que existan Loop, Goto, Exit, Breaks, que alteraría por completo el comportamiento del ciclo, por lo tanto, no podría hablar de 1 prueba, si no de un número incalculable de pruebas.

Conclusión

Las diferentes técnicas de pruebas en caja blanca, son muy importantes para detectar de manera eficiente y practica los diferentes problemas u error que puede aparecer en el desarrollo del los proyectos, estas pruebas software nos permiten ejecutar un programa cuya intención principal es detectar errores presentes en el software con el fin de disminuirlos y obviamente corregirlos, de tal manera que se mejore la calidad con la que se producen los proyectos. Estas pruebas deben ser ejecutadas de manera planeada, las pruebas de caja blanca no solo evalúan el comportamiento del usuario con la interfaz, sino que busca errores en el código fuente, recordando que esta posee criterios basados en el contenido y la estructura del código. Para concluir, tenemos que tener algo muy claro, no es posible garantizar que un software o sistema falle, tan solo se puede realizar pruebas que disminuyan el riesgo.

Referencias Bibliográficas

[1] Andrades, J. B. (1 de noviembre de 2012). Slideshare. Obtenido de Realizacion de pruebas: https://es.slideshare.net/jabenitez88/8realizacion-de-pruebas-14981770

[2] Cano, J. E. (1 de noviembre de 2013). Slideshare. Obtenido de cobertura de bucles. https://es.slideshare.net/juanestebanpuertacano/cobertura-de-bucles

[3] Carmona, C. R. (2 de julio de 2013). Slideshare. Obtenido de Prueba caja blanca: https://es.slideshare.net/cristalramirezcarmona/prueba-caja-blanca

[4] GAVIRIA, B. F. (2013). Universidad del Valle. Obtenido de CLASE # 5 Tecnicas de Caja Blanca: https://campusvirtual.univalle.edu.co/moodle/pluginfile.php/480081/mod_resource/content/1/2013A_TPSW_Clase05_CajaBlanca.pdf

[5] López, R. (13 de enero de 2017). Slideshare. Obtenido de Estructuras repetitivas(while, for, repeat): https://es.slideshare.net/RommelLpez/estructuras-repetitivaswhile-for-repeat

[6] Luna, J. M. (3 de junio de 2009). ingenierogestion.blogspot.com. Obtenido de Pruebas de Caja Negra y Caja Blanca: http://ingenierogestion.blogspot.com/2009/06/pruebas-de-caja-negra-y-caja-blanca.html

Reporte de Pruebas

noreply@blogger.com (Anonymous) — Fri, 01 Sep 2017 20:08:00 +0000

Reporte de pruebas

Un reporte de pruebas es un documento formal que resume los resultados de todos los esfuerzos de prueba para un ciclo de prueba particular de un proyecto u módulo o un sub-módulo. Generalmente, los conductores de prueba o los encargados de la prueba preparan este documento al final del ciclo de prueba. Algunos gerentes de prueba lo preparan al final del proyecto. Además, según Software Testing Help, define un reporte como “Informe de resumen de prueba es un producto importante que se prepara al final de un proyecto de prueba, o más bien después de completar la prueba. El principal objetivo de este documento es explicar varios detalles y actividades sobre las pruebas realizadas para el proyecto, a los respectivos actores como la Alta Dirección, el Cliente, etc.”

Estas pruebas de documentación incluyen los planes, resultados y pruebas de un sistema o componente del sistema. Incluye especificaciones de casos de prueba, planes de prueba, procedimientos de prueba, informes de prueba y registros de prueba. Se trata de la comprobación de todos los documentos que establecen, definen, explican y notifican o validan los requisitos, los procedimientos seguidos y los resultados. Estas pruebas incluyen verificar la ortografía y la gramática para revisar cualquier ambigüedad o inconsistencia entre qué funcionalidad realiza y qué se supone que debe hacer. Existen cuatro áreas clave para probar un documento estas incluyen: instrucciones, ejemplos, mensajes y muestras. Se necesitarán instrucciones para ejecutar paso a paso los escenarios de prueba para buscar errores o su omisión. Se pueden proporcionar otros ejemplos para elaborar los componentes GUI, sintaxis, comandos e interfaces para mostrar salidas ejecutadas o puntos de pin. Las incoherencias también necesitaban ser atendidas con errores, ya que pueden confundir a los usuarios y estas ambigüedades causarán mucho daño si el usuario del sistema será un usuario novato. Los ejemplos serán necesarios en caso de cualquier problema que ocurra al usuario, en particular los usuarios principiantes que los usuarios principiantes comprobarán la documentación para cualquier confusión.

La documentación para las pruebas de software ayuda a estimar el esfuerzo de prueba requerido, la cobertura de la prueba, el rastreo de los requisitos, etc. Esta sección describe algunos de los artefactos documentados de uso común relacionados con pruebas de software como:

Plan de prueba.
Escenario de prueba.
Caso de prueba.
Matriz de trazabilidad.

Plan de prueba:

Un plan de prueba describe la estrategia que se utilizará para probar una aplicación, los recursos que se utilizarán, el entorno de prueba en el que se realizarán las pruebas y las limitaciones de las pruebas y el calendario de las actividades de prueba. Normalmente, el jefe del equipo de garantía de calidad será responsable de escribir un plan de prueba. Un plan de prueba incluye lo siguiente:

Introducción al documento del Plan de Prueba.
Suposiciones durante la prueba de la aplicación.
Lista de casos de prueba incluidos en la prueba de la aplicación.
Lista de características a probar.
¿Qué tipo de enfoque utilizar al probar el software.
Lista de entregas que deben ser probadas.
Los recursos asignados para probar la aplicación.
Cualquier riesgo involucrado durante el proceso de prueba.
Un calendario de tareas e hitos a lograr.

Escenario de prueba:

Es una instrucción de una línea que notifica qué área de la aplicación será probada. Los escenarios de prueba se utilizan para asegurar que todos los flujos de proceso se prueban de extremo a extremo. Un área particular de una aplicación puede tener tan poco como un escenario de prueba a unos pocos cientos de escenarios dependiendo de la magnitud y complejidad de la aplicación.

Los términos "escenario de prueba" y "casos de prueba" se usan indistintamente, sin embargo, un escenario de prueba tiene varias etapas, mientras que un caso de prueba tiene un solo paso. Desde esta perspectiva, los escenarios de prueba son casos de prueba, pero incluyen varios casos de prueba y la secuencia en la que deben ejecutarse. Aparte de esto, cada prueba depende de la salida de la prueba anterior.

Caso de prueba:

Los casos de prueba implican un conjunto de pasos, condiciones e insumos que se pueden utilizar durante la realización de las tareas de prueba. El objetivo principal de esta actividad es asegurar que un software pase o no en términos de funcionalidad y otros aspectos. Hay muchos tipos de casos de prueba tales como funcional, negativo, error, casos de prueba lógica, casos de prueba física, casos de prueba de UI, etc. Además, los casos de prueba se escriben para realizar un seguimiento de la cobertura de pruebas de un software. Generalmente, no hay plantillas formales que se puedan utilizar durante la escritura del caso de prueba. Sin embargo, los siguientes componentes están siempre disponibles e incluidos en cada caso de prueba:

Identificación del caso de prueba.
Módulo de producto.
Versión del producto.
Revisión histórica.
Propósito.
Suposiciones.
Condiciones previas.
Pasos.
Gastos esperados.
Resultado real.
Post condiciones.

Muchos casos de prueba pueden derivarse de un único escenario de prueba. Además, a veces se escriben varios casos de prueba para un solo software que se conocen colectivamente como suites de prueba.

Matriz de trazabilidad:

Matriz de Trazabilidad (también conocida como Matriz de Trazabilidad de Requisitos - RTM) es una tabla que se utiliza para rastrear los requisitos durante el Ciclo de Vida de Desarrollo de Software. Puede usarse para el rastreo directo (es decir, desde Requisitos para diseño o codificación) o hacia atrás (es decir, desde la codificación a los requisitos). Hay muchas plantillas definidas por el usuario para RTM. Cada requisito en el documento RTM está vinculado con su caso de prueba asociado de modo que las pruebas se pueden hacer según los requisitos mencionados. Además, Bug ID también está incluido y enlazado con sus requisitos asociados y caso de prueba. Los objetivos principales de esta matriz son:

Asegúrese de que el software se ha desarrollado según los requisitos mencionados.
Ayuda a encontrar la raíz de cualquier error.
Ayuda a rastrear los documentos desarrollados durante las diferentes fases del SDLC (“Systems Development Life Cycle”, también conocido como “System Design Life Cycle”).

¿Qué es la prueba?

La prueba es el proceso de evaluar un sistema o sus componentes con la intención de determinar si satisface o no los requisitos especificados. En palabras simples, la prueba está ejecutando un sistema para identificar cualquier laguna, error o requisito faltante en contra de los requerimientos reales. De acuerdo con la norma ANSI / IEEE 1059, Testing se puede definir como: - “Un proceso de análisis de un elemento de software para detectar las diferencias entre las condiciones existentes y las requeridas (defectos / errores / errores) y evaluar las características del elemento de software.”

¿Quién hace la prueba?

Depende del proceso y de las partes asociadas del (de los) proyecto (s). En la industria de TI, las grandes empresas tienen un equipo con responsabilidades para evaluar el software desarrollado en el contexto de los requisitos dados. Además, los desarrolladores también llevan a cabo las pruebas que se denomina Pruebas unitarias. En la mayoría de los casos, los siguientes profesionales están involucrados en probar un sistema dentro de sus respectivas capacidades:

Probador de software.
Desarrollador de software.
Jefe de Proyecto / Gerente.
Usuario final.

Diferentes empresas tienen diferentes designaciones para las personas que prueban el software sobre la base de su experiencia y conocimiento, tales como Software Tester, Software Quality Assurance Engineer, QA Analyst, etc.

¿Cuándo comenzar la prueba?

Un comienzo temprano de la prueba reduce el costo y el tiempo para volver a trabajar y producir software libre de errores que se entrega al cliente. Sin embargo, en el ciclo de vida de desarrollo de software (SDLC), las pruebas se pueden iniciar desde la fase de recopilación de requisitos y continuar hasta el despliegue del software. También depende del modelo de desarrollo que se está utilizando. La prueba se realiza en diferentes formas en cada fase de SDLC:

Durante la fase de recopilación de requisitos, el análisis y la verificación de los requisitos también se consideran como pruebas.
La revisión del diseño en la fase de diseño con la intención de mejorar el diseño también se considera como una prueba.
Las pruebas realizadas por un desarrollador al finalizar el código también se clasifican como pruebas.

¿Cuándo dejar de probar?

Es difícil determinar cuándo parar las pruebas, ya que la prueba es un proceso interminable y nadie puede afirmar que un software es probado al 100%. Los siguientes aspectos deben ser considerados para detener el proceso de prueba:

Plazos de prueba.
Finalización de la ejecución del caso de prueba.
Completar la cobertura funcional y de código hasta cierto punto.
La tasa de errores cae por debajo de un cierto nivel y no se identifican errores de alta prioridad.
Decisión de gestión.

¿Qué contiene un informe de resumen de prueba contiene?

Una plantilla de Informe de Prueba típica contendrá la siguiente información, sin embargo, según el formato y la práctica de cada empresa, el contenido puede variar. También he proporcionado ejemplos reales para una mejor comprensión. Al final de este artículo, puede descargar un ejemplo de informe de resumen de prueba.

1. Propósito del documento: Breve descripción del objetivo de la preparación del documento.

2. Descripción general de la aplicación: Breve descripción de la aplicación probada.

3. Ámbito de prueba:

3.1 En Alcance: Pruebas funcionales para los siguientes módulos están en el ámbito de la prueba.

3.2 Fuera de alcance: No se realizaron pruebas de rendimiento para esta aplicación.

3.3 Artículos no probados: Verificación de la conectividad con el sistema de terceros, Esto se puede verificar durante UAT (User Acceptance Testing) donde la conectividad está disponible o se puede establecer.

Esta sección explica las funciones / módulos en el alcance y fuera del alcance para la prueba; Cualquier elemento que no se pruebe debido a limitaciones, dependencias, restricciones.

4. Métricas: Las métricas ayudarán a entender los resultados de la ejecución de la prueba, el estado de los casos de prueba y defectos, etc. Las métricas requeridas se pueden agregar según sea necesario. Gráficos / gráficos se pueden adjuntar para una mejor representación visual.

5. Tipos de pruebas realizadas:

5.1 Pruebas de humo: Esta prueba se realizó cada vez que se recibe una compilación (desplegada en el entorno de prueba) para probar para asegurarse de que la funcionalidad principal está funcionando bien, se puede aceptar la compilación y se puede iniciar la prueba.

5.2 Pruebas de integración del sistema:

Esta es la Prueba realizada en la Aplicación bajo prueba, para verificar que la aplicación entera funciona según los requisitos.
Los escenarios de negocio críticos se probaron para asegurarse de que la funcionalidad importante en la aplicación funciona como se pretende sin errores.

5.3 Prueba de Regresión:

Se realizaron pruebas de regresión cada vez que se implementa una nueva compilación para pruebas que contiene correcciones de defectos y nuevas mejoras, si las hubiera.
La prueba de regresión se está realizando en toda la aplicación y no sólo en la nueva funcionalidad y correcciones de defectos.
Esta prueba garantiza que la funcionalidad existente funciona bien después de la corrección de defectos y se añaden nuevas mejoras a la aplicación existente.
Los casos de prueba para la nueva funcionalidad se añaden a los casos de prueba existentes y se ejecutan.

Describir los diversos tipos de pruebas realizadas para el proyecto. Esto asegurará que la aplicación se esté probando correctamente a través de los tipos de prueba acordados según la estrategia de prueba.

6. Ambiente de prueba y herramientas: Proporcione detalles sobre el entorno de prueba en el que se realiza la prueba. Servidor, Base de datos, URL de la aplicación, etc. Si se utilizaron Herramientas como Quality Center (ahora HP ALM) para registrar defectos.

7. Lecciones aprendidas: Esta sección se utiliza para describir los problemas críticos enfrentados y sus soluciones (cómo se resolvieron durante la prueba). Las lecciones aprendidas ayudarán a tomar decisiones proactivas durante la próxima prueba, evitando estos errores o encontrando una solución adecuada.

8. Recomendaciones: Cualquier solución o sugerencias pueden mencionarse aquí.

9. Mejores Prácticas: Habrá muchas actividades realizadas por el equipo de pruebas durante el proyecto. Algunos de ellos podrían haber ahorrado tiempo, algunos han demostrado ser una buena y eficiente manera de trabajar, etc. Estos pueden ser documentados como un 'Valor Agregado' para mostrar el caso a los Stakeholders.

10. Criterios de Salida: Criterios de salida se define como una finalización de la prueba cumpliendo ciertas condiciones, como Todos los casos de prueba planificados se ejecutan; Todos los defectos críticos están cerrados, etc.

11.Conclusión / Cerrar sesión: Esta sección indicará si el equipo de pruebas está de acuerdo y da una señal verde para la aplicación a "Go Live" o no, una vez que se cumplieron los criterios de salida. Si la aplicación no cumple con los criterios de salida, entonces se puede mencionar como - "La aplicación no se sugiere a 'Go Live'. Se quedará con la decisión de la alta dirección y el cliente y otras partes interesadas involucradas para tomar la llamada sobre si la aplicación puede 'Go Live' o no.

12. Definiciones, Siglas y Abreviaturas: Esta sección menciona los significados de los términos abreviados usados en este documento y cualquier otra nueva definición.

Conclusión

Las pruebas de software son documentos que son muy importantes, estos mismos siempre juegan un papel importante en la fase de desarrollo y pruebas del proyecto. Por lo tanto, siempre mantener las cosas documentadas de la mejor manera, siempre que sea posible realizar este tipo de documentación. No confiar en la comunicación verbal es algo que se tiene que tener en cuenta todo el tiempo, las casa habladas son solo eso, cosas habladas, así que, a la hora de la comunicación, se tiene siempre que tomar nota de todos los detalles y hacer constar que lo conversado por las partes es correcto. También algo interesante sobre la importancia es que debemos estar siempre en el lado seguro, no hay que desconfiar acerca de lo que se está haciendo y como se está haciendo, ya que si tanto el trabajo como los reportes que se están realizando cumplen con todas los requerimientos, la documentación no sólo ahorrará, sino también ayudara a la organización(es) a largo plazo a ahorrar miles de dólares en formación y sobre todo; en la fijación de problemas causados debido a la falta de desarrollo y pruebas de documentos. Por lo tanto, hay que tener algo muy claro lo cual es que no se tienen que documentar sólo para evitar problemas en los cuales se apunte a su persona.

Además, tenemos que tener en cuenta siempre que las fallas de software pueden ocurrir en cualquier momento, estas pueden ocasionar perdidas económicas que van a afectar el desarrollo del proyecto, estas pérdidas pueden ser de 100 a 1000 veces más costosas de encontrar y reparar después de la implementación del proyecto. Por lo tanto, debemos tener presenta los reportes de pruebas, cada caso de prueba debe definir el resultado de la salida esperada, de lo contrario se detectará una anomalía, y es aquí donde se da la relevancia de los reportes.

Referencias Bibliográficas

NA. (17 de abril de 2017). Software Testing Help. Obtenido de A Simple 12 Steps Guide to Write an Effective Test Summary Report: http://www.softwaretestinghelp.com/test-summary-report-template-download-sample/

NA. (17 de abril de 2017). Software Testing Help. Obtenido de Why Documentation is Important in Software Testing: http://www.softwaretestinghelp.com/why-documentation-is-important-in-software-testing/

NA. (s.f.). tutorialspoint. Obtenido de Software Testing - Quick Guide: https://www.tutorialspoint.com/software_testing/software_testing_quick_guide.htm

Software Testing Stuff. (s.f.). Obtenido de Test Summary Report: http://www.softwaretestingstuff.com/2013/08/test-summary-report.html

Revisiones Estáticas - IEEE-1028: revisiones de software & Modelos de desarrollo

noreply@blogger.com (Anonymous) — Sun, 27 Aug 2017 21:45:00 +0000

Revisiones Estáticas

Beneficios de las Revisiones

La razón para buscar defectos en productos tempranos es porque éstos se traducen en defectos en el producto final. Es decir, defectos en los requisitos se traducirán en defectos en el sistema final. Veamos una analogía con la arquitectura de edificios. Si en un plano el color de una línea indica su significado, una confusión en el color se traducirá en un error en el edificio. Por ejemplo, si el azul indica tuberías de agua y el amarillo cables eléctricos y el arquitecto comete un error usando el azul en una conducción eléctrica, los electricistas que usen el plano como guía para su trabajo no colocarán cables eléctricos mientras que los fontaneros colocarán tuberías de agua donde no debían ir. El plano de un edificio es el artefacto equivalente al diseño de un producto software. Si un diseño contiene defectos, seguramente estos defectos se trasmitirán al código cuando los programadores usen ese diseño como guía para su trabajo.

La detección temprana de errores acarrea grandes beneficios. Si las revisiones únicamente se aplican al código mejoran la calidad y producen ahorros en los costos del proyecto. Pero los ahorros son mayores si se inspeccionan artefactos tempranos del desarrollo. Estudiando los resultados publicados sobre ahorros con las revisiones, puede afirmarse que la utilización de inspecciones de código produce un ahorro del 39% sobre el coste de detectar y corregir defectos, frente a únicamente utilizar la evaluación dinámica. Sin embargo, el ahorro es del 44% si se inspecciona también el diseño. La experiencia demuestra que entre el 30% y el 70% de los defectos, de diseño y código son detectados por las técnicas estáticas. Esto supone un gran ahorro, pues la corrección es más fácil y menos costosa durante la evaluación estática que durante la dinámica. Nótese que cuando durante la evaluación dinámica del sistema se detecta un fallo en un programa, lo que se detecta es el fallo, no la falta que lo provoca. Es decir, tras la detección del fallo, se requiere una labor de localización en el programa de la falta que provocó el fallo. Sin embargo, con las técnicas estáticas, lo que se detecta son directamente faltas. Por tanto, una vez detectada, se puede pasar a la fase de corrección. Es decir, desaparece la tarea de localización de la falta.

Esto significa, que las técnicas estáticas son más baratas por falta que las dinámicas. Las revisiones también proporcionan beneficios más generales. Entre éstos se pueden citar están:

Evaluación del progreso del proyecto.
Potencia las capacidades de los participantes.
Mejoran la comunicación entre el equipo de desarrollo, aumentando su motivación, pues los productos pasan a ser documentos públicos.
Proporciona aprendizaje, retroalimentación y prevención.
Forma y educa a los participantes

En el caso concreto de las revisiones de código, éstas, además, permiten localizar secciones críticas, lo que permitirá dedicar un mayor esfuerzo a ellas en la fase de pruebas.

Objetivos de la Evaluación Estática

La evaluación estática de los distintos artefactos o productos que se generan en el desarrollo de software (especificación de requisitos, modelos conceptuales, diseño, código, etc.) pretende comprobar su calidad. distintos. Del mismo modo que la calidad de un plano y la calidad de una casa significa cosas distintas. En un plano de un futuro edificio se desea que sea claro (se entienda suficientemente bien como para servir de guía a la construcción del edificio), que sea correcto (por ejemplo, que las líneas que identifican paredes indiquen, a escala, efectivamente el lugar donde se desea que vayan las paredes), que no tenga inconsistencias (por ejemplo, entre las distintas hojas que forman el plano; si una página se focaliza, digamos, en una habitación que en otra página aparecía sólo sus cuatro paredes, que las medidas de las líneas en ambas páginas se correspondan con la misma medida de la realidad), etc.. Sin embargo, de una casa se espera que sea robusta (por ejemplo, que no se caiga), usable (por ejemplo, que los peldaños de las escaleras no sean tan estrechos que provoquen caídas) etc. Por tanto, cuando se esté evaluando estáticamente un producto software, es importante que el evaluador tenga en mente qué tipo de defectos está buscando y cuál sería un producto de ese tipo de calidad adecuada. Digamos que si uno no sabe lo que busca (por ejemplo, inconsistencias al revisar la calidad de un plano) es difícil que lo encuentre, aunque lo tenga delante.

Los defectos que se buscan al evaluar estáticamente los productos software son:

1. Para los requisitos:

Corrección: Los requisitos especifican correctamente lo que el sistema debe hacer. Es decir, un requisito incorrecto es un requisito que no cumple bien su función. Puesto que la función de un requisito es indicar qué debe hacer el sistema, un requisito incorrecto será aquel que, o bien pide que el sistema haga algo que no es lo que debe hacer, o pide que haga algo que no deba hacer.
Compleción: Especificación completamente el problema. Está especificado todo lo que tiene que hacer el sistema y no incluye nada que el sistema no deba hacer. En dos palabras: no falta nada; no sobra nada Consistencia. No hay requisitos contradictorios.
Ambigüedad: Los requisitos no pueden estar sujetos a interpretación. Si fuese así, un mismo requisito puede ser interpretado de modo distinto por dos personas diferentes y, por tanto, crear dos sistemas distintos. Si esto es así, los requisitos pierden su valor pues dejan de cumplir su función (indicar qué debe hacer el sistema). Las ambigüedades provocan interpretación por parte de la persona que use o lea los requisitos. Por tanto, una especificación debe carecer de ambigüedades.
Claridad: Se entiende claramente lo que está especificado.

2. Para el diseño:

Corrección: El diseño no debe contener errores. Los errores de corrección se pueden referir a dos aspectos. Defectos de “escritura”, es decir, defectos en el uso de la notación de diseño empleada (el diseño contiene detalles prohibidos por la notación). Defectos con respecto a los requisitos: el diseño no realiza lo que el requisito establece. Hablando apropiadamente, los primeros son los puros defectos de corrección, mientras que los segundos son defectos de validez.
Compleción: El diseño debe estar completo. Ya sea que diseña todo el sistema marcado por los requisitos; ya sea no diseñando ninguna parte no indicada en los requisitos. De nuevo, nada falta, nada sobra.
Consistencia: Al igual que en los requisitos, el diseño debe ser consistente entre todas sus partes. No puede indicarse algo en una parte del diseño, y lo contrario en otra.
Factibilidad: El diseño debe ser realizable. Debe poderse implementar.
Trazabilidad: Se debe poder navegar desde un requisito hasta el fragmento de diseño donde éste se encuentra representado.

3. Para el Código Fuente:

Corrección: El código no debe contener errores. Los errores de corrección se pueden referir a dos aspectos. Defectos de “escritura”, es decir, lo que habitualmente se conoce por “programa que no funciona”. Por ejemplo, bucles infinitos, variable definida de un tipo, pero utilizada de otro, contador que se sale de las dimensiones de un array, etc. Defectos con respecto al diseño: el diseño no realiza lo que el diseño establece.

IEEE-1028: revisiones de software

El propósito de esta norma es definir revisiones sistemáticas y auditorías aplicables a la adquisición, suministro, desarrollo, operación y mantenimiento de software. Esta norma describe cómo realizar una revisión. Otras normas o la administración local definen el contexto dentro del cual se realiza una revisión y el uso que se hace de los resultados de la revisión. Las revisiones de software se pueden utilizar en apoyo de los objetivos de gestión de proyectos, ingeniería de sistemas (por ejemplo, asignación funcional entre hardware y software), verificación y validación, gestión de configuración, garantía de calidad y auditoría. Los diferentes tipos de revisiones reflejan diferencias en las metas de cada tipo de revisión. Las revisiones sistemáticas se describen por sus procedimientos definidos, alcance y objetivos.

Términos y definiciones

1. Revisión de la gestión: Una evaluación sistemática de un producto o proceso de software realizado por o en nombre de la administración que monitorea el progreso, determina el estado de los planes y horarios, confirma los requisitos y su sistema de asignación o evalúa la efectividad de los enfoques de manejo utilizados para alcanzar la aptitud para su respectivo propósito, el cual es; una revisión de una gestión es monitorear el progreso, determinar el estado de los planes y los horarios, o evaluar la efectividad de los enfoques de manejo usados para lograr la adecuación al propósito. Las revisiones de la gerencia apoyan decisiones sobre acciones correctivas, cambios en la asignación de recursos, o cambios en el alcance del proyecto. Las revisiones de gestión identifican la coherencia y las desviaciones de los planes, o las adecuaciones e insuficiencias de los procedimientos de gestión. El conocimiento técnico puede ser necesario para llevar a cabo un exitoso examen de la gestión. El examen puede requerir más de una reunión. El examen no necesita abordar todos los aspectos del producto o proceso de software.

2. Revisión técnica: Una evaluación sistemática de un producto de software por un equipo de personal calificado que examina la idoneidad del producto de software para su uso previsto e identifica discrepancias de especificaciones y estándares. El propósito de una revisión técnica es evaluar un producto de software por un equipo de personal calificado para determinar su idoneidad para el uso previsto e identificar discrepancias con las especificaciones y estándares. Proporciona a la dirección pruebas para confirmar el estado técnico del proyecto. Las revisiones técnicas también pueden proporcionar la recomendación y el examen de varias alternativas, que pueden requerir más de una reunión. El examen no necesita abordar todos los aspectos del producto.

3. Inspección: Un examen visual de un producto de software para detectar e identificar anomalías de software, incluidos errores y desviaciones de las normas y especificaciones. El propósito de una inspección es detectar e identificar anomalías de productos de software. Una inspección es un examen sistemático de pares que realiza uno o más de los siguientes:

Verifica que el producto de software cumple con sus especificaciones.
Verifica que el producto de software presenta atributos de calidad especificados.
Verifica que el producto de software cumple con las regulaciones, normas, directrices, planes, especificaciones y procedimientos aplicables.
Identifica las desviaciones de las disposiciones del punto 1, 2, y 3.
Recopila datos de ingeniería de software (por ejemplo, datos de anomalías y esfuerzo).
Proporciona los datos de ingeniería de software recopilados que se pueden utilizar para mejorar el propio proceso de inspección y su documentación de soporte (por ejemplo, listas de verificación).
Solicita u otorga exenciones por violación de estándares donde la adjudicación del tipo y el alcance de las violaciones se asignan a la jurisdicción de inspección.
Utiliza los datos como entrada para las decisiones de gestión de proyectos según sea apropiado (por ejemplo, para hacer concesiones entre inspecciones adicionales versus pruebas adicionales).

Las inspecciones constan de dos a seis participantes (incluido el autor). Una inspección es dirigida por un facilitador imparcial capacitado y capacitado en técnicas de inspección. La determinación de la acción correctiva o de investigación para una anomalía es un elemento obligatorio de una inspección de software, aunque la resolución no debe ocurrir en la reunión de inspección. La recopilación de datos con el fin de analizar y mejorar los procedimientos de ingeniería de software es un elemento obligatorio de las inspecciones de software.

4. Paso a paso: una técnica de análisis estático en la que un diseñador o programador dirige a los miembros del equipo de desarrollo y otras partes interesadas a través de un producto de software y los participantes hacen preguntas y hacen comentarios sobre posibles anomalías. Con el propósito de educar a una audiencia con respecto a un producto de software. Los principales objetivos son los siguientes:

Encontrar anomalías.
Mejorar el producto de software.
Considerar implementaciones alternativas.
Evaluar la conformidad con las normas y especificaciones.
Evaluar la usabilidad y accesibilidad del producto de software.

Otros objetivos importantes del walk-through incluyen intercambio de técnicas, variaciones de estilo y entrenamiento de los participantes. Un walk-through puede señalar deficiencias (por ejemplo, problemas de eficiencia y legibilidad en el producto de software, problemas de modularidad en diseño o código o especificaciones no comprobables).

5. Auditoría: Un examen independiente de un producto de software, un proceso de software o un conjunto de procesos de software realizados por un tercero para evaluar el cumplimiento de especificaciones, estándares, acuerdos contractuales u otros criterios. El propósito de una auditoría de software es proporcionar una evaluación independiente de la conformidad de los productos y procesos de software con las regulaciones, normas, directrices, planes, especificaciones y procedimientos aplicables. Ejemplos de productos de software sujetos a auditoría incluyen, pero no se limitan a, lo siguiente:

Planes de copia de seguridad y recuperación,
Planes de Contingencia.
Contratos.
Quejas de clientes o usuarios.
Planes de desastre.
Planes de rendimiento del hardware.
Planes de instalación.
Procedimientos de instalación.
Etc.

Modelos en los procesos de software

Modelo cascada

Primer Modelo en el Proceso de Desarrollo de Software. Debido a la cascada de una fase a otra, se conoce como: “modelo en cascada” o “ciclo de vida del software”. En ingeniería de software el desarrollo en cascada es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software. Se popularizó en la década de los 70 y guía la mayor parte de la práctica actual. El proceso es una “cascada” de fases, donde el producto de una fase es la entrada de la siguiente.

Este sugiere un enfoque sistemático, secuencial hacia el desarrollo del software, que se inicia con la especificación de requerimientos del cliente y que continúa con la planeación, el modelado, la construcción y el despliegue para culminar en el soporte del software terminado. Este modelo es aplicable en donde existen ocasiones en que los requisitos de un problema se entienden de una manera razonable y deben estar bien definidos, también cuando el trabajo fluye desde la comunicación a través del despliegue de una manera casi lineal, esta situación se encuentra a veces cuando es necesario hacer adaptaciones o mejorías bien definidas a un sistema existente. El modelo en cascada es el paradigma más antiguo para la ingeniería del software. Sin embargo, en las décadas pasadas, las críticas a este modelo de proceso han ocasionado que aun sus más fervientes practicantes hayan cuestionado su eficacia.

Aplicación del modelo cascada:

Se sigue una secuencia lineal de etapas.
Las empresas establecen los productos y documentos que deben producirse en cada etapa.
Estos productos y/o documentos permiten seguir el avance del proyecto.
También se establece qué métodos aplicar en cada etapa.

Estos métodos se organizan en forma coherente en lo que es la “metodología de desarrollo de la empresa

Variaciones del modelo cascada:

Sistemas de áreas conocidas pueden omitir el análisis de factibilidad.
Sistemas complejos y/o grandes requieren dividir su desarrollo en porciones más pequeñas que puedan desarrollarse en forma más controlada y rigurosa.
Un sistema con usuarios no especialistas puede requerir una etapa de entrenamiento y preparación de material de apoyo.

Desarrollo en cascada

Esta metodología elegida, de modelo en cascada, facilita una planificación sencilla. Podemos pasar por alto detalles concretos y después, en una nueva planificación, llevarlos a cabo. La calidad de este tipo de proyectos es muy alta dado que una vez terminada una versión puede mejorarse e incluso rediseñarse para que su funcionamiento sea más eficiente, fundamentalmente en las fases de interacción con el usuario del sistema y en la estructura del árbol de decisión. Además, esta metodología estuvo bastante acertada, pues los requisitos no los tuvimos completados hasta casi la fase final. También, dado el carácter del proyecto, principalmente descriptivo, no nos resultó muy traumático en el momento de hacer los cambios en la implementación.

1. Ingeniería y Análisis del Sistema:

Debido a que el software es siempre parte de un sistema mayor el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algún subconjunto de estos requisitos al software.

2. Análisis de Requisitos:

El proceso de recopilación de los requisitos se centra e intensifica especialmente en el software. recopilar, examinar y formular los requisitos del cliente y examinar cualquier restricción que se pueda aplicar. El ingeniero de software (Analistas) debe comprender el ámbito de la información del software, así como la función, el rendimiento y las interfaces requeridas.

En esta fase se analizan las necesidades de los usuarios finales del software para determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada SRD (documento de especificación de requisitos), que contiene la especificación completa de lo que debe hacer el sistema sin entrar en detalles internos. Es importante señalar que en esta etapa se debe consensuar todo lo que se requiere del sistema y será aquello lo que seguirá en las siguientes etapas, no pudiéndose requerir nuevos resultados a mitad del proceso de elaboración del software.

3. Diseño del Sistema:

Se descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseño del Software), que contiene la descripción de la estructura relacional global del sistema y la especificación de lo que debe hacer cada una de sus partes, así como la manera en que se combinan unas con otras. Es conveniente distinguir entre diseño de alto nivel o arquitectónico y diseño detallado. El primero de ellos tiene como objetivo definir la estructura de la solución (una vez que la fase de análisis ha descrito el problema) identificando grandes módulos (conjuntos de funciones que van a estar asociadas) y sus relaciones. Con ello se define la arquitectura de la solución elegida. El segundo define los algoritmos empleados y la organización del código para comenzar la implementación.

4. Diseño del Programa:

Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario, así como también los análisis necesarios para saber que herramientas usar en la etapa de Codificación.

5. Codificación:

Es la fase de programación o implementación propiamente dicha. Aquí se implementa el código fuente, haciendo uso de prototipos, así como pruebas y ensayos para corregir errores.

El diseño debe traducirse en una forma legible para la máquina. El paso de codificación realiza esta tarea. Si el diseño se realiza de una manera detallada la codificación puede realizarse mecánicamente. Dependiendo del lenguaje de programación y su versión se crean las bibliotecas y componentes reutilizables dentro del mismo proyecto para hacer que la programación sea un proceso mucho más rápido.

6. Pruebas:

Una vez que se ha generado el código comienza la prueba del programa. La prueba se centra en la lógica interna del software, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren. Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente y que cumple con los requisitos, antes de ser puesto en funcionamiento. Las empresas pueden establecer estándares de pruebas:

definición de un plan de pruebas.
criterios de pruebas (caja negra, caja blanca).
criterios de fin de las pruebas.
administración de los casos de prueba.

La depuración (“debugging”) es parte de esta etapa.
Es el control de calidad llevado a cabo en esta etapa.
Inspecciones para comprobar adhesión a los estándares.

Existen varios tipos de Pruebas:

Pruebas de unidad: ver que cada componente del programa cumpla con las especificaciones.
Pruebas de integración: se integra los componentes y se prueba el funcionamiento del sw.
Pruebas de sistema: Se prueban rendimiento y seguridades.
Pruebas de aceptación: los hace el cliente y el usuario para estar seguros de que el sw cumple con las necesidades.

7. Mantenimiento:

El software necesitará cambios después de la entrega.
El análisis de requisitos es una fuente de problemas, especialmente para los usuarios finales:

los requisitos son difíciles de especificar,
los requisitos cambian con el tiempo.

Muchos errores no son resueltos hasta después de instalar el software en el cliente:

es más caro corregir errores cuanto más tarde se detectan.

Los cambios son (casi) siempre posibles, pero también (casi) siempre muy difíciles.
El mantenimiento son todas las actividades que ocurren después que el software está instalado:

corregir errores,
agregar nueva funcionalidad

Los tipos de mantenimiento son:

Mantenimiento Preventivo y Perfectivo.
Mantenimiento Correctivo.
Mantenimiento Evolutivo.

Modelo espiral

El modelo en espiral del proceso del software que originalmente fue propuesto por Boehm (1988). El modelo en espiral es una de las más recomendables para el desarrollo y creación de un programa, ya que consta de pocas etapas o fases, las cuales se van realizando en manera continua y cíclica. Su Modelo de Ciclo de Vida en Espiral tiene en cuenta fuertemente el riesgo que aparece a la hora de desarrollar software. Para ello, se comienza mirando las posibles alternativas de desarrollo, se opta por la de riesgo más asumible y se hace un ciclo de la espiral. Si el cliente quiere seguir haciendo mejoras en el software, se vuelve a evaluar las distintas nuevas alternativas y riesgos y se realiza otra vuelta de la espiral, así hasta que llegue un momento en el que el producto software desarrollado sea aceptado y no necesite seguir mejorándose con otro nuevo ciclo.

Este es un modelo de proceso de software evolutivo donde se conjuga la naturaleza de construcción de prototipos con los aspectos controlados y sistemáticos del MODELO LINEAL y SECUENCIAL. Proporciona el potencial para el desarrollo rápido de versiones incrementales del software que no se basa en fases claramente definidas y separadas para crear un sistema. En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones la versión incremental podría ser un modelo en papel o un prototipo, durante las últimas iteraciones se producen versiones cada vez más completas del sistema diseñado.

EL modelo en espiral se divide en un número de actividades de marco de trabajo, también llamadas REGIONES DE TAREAS, Cada una de las regiones están compuestas por un conjunto de tareas del trabajo llamado CONJUNTO DE TAREAS que se adaptan a las características del proyecto que va a emprenderse en todos los casos se aplican actividades de protección.

Cada ciclo espiral se divide en 4 etapas:

1. Definición de objetivos: Para esta fase del proyecto se definen los objetivos específicos. Se identifican las restricciones del proceso y el producto, y es estipula un plan detallado de administración. Se identifican los riesgos, se planean estrategias alternativas.

2. Evaluación y reducción de riesgos: Se lleva a cabo un análisis detallado para cada uno de los riesgos del proyecto. Se definen los pasos para reducir dichos riesgos, Por ejemplo, si existe el riesgo de tener requerimientos inapropiados, se desarrolla un prototipo del sistema.

3. Desarrollo y validación: Después de la evaluación de riesgos en la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podría ser la construcción de prototipos evolutivos. Si los riesgos de protección son la principal consideración, un desarrollo basado en transformaciones formales podría ser el más apropiado, y así sucesivamente. El modelo de cascada es el más apropiado para el desarrollo si el mayor riesgo identificado es la integración de los subsistemas.

4. Planeación: El proyecto se revisa y se toma la decisión si se debe continuar con un ciclo posterior de la espiral. Si se decide continuar, se desarrollan los planes para la siguiente fase del proyecto. Con cada iteración alrededor de la espiral (comenzando en el centro y siguiendo hacia el exterior), se construyen sucesivas versiones del software, cada vez más completa y, al final, el propio sistema software totalmente funcional.

El modelo en espiral WINWIN de Boehm, define un conjunto de actividades de negociación al principio de cada paso alrededor de la espiral. Más que una simple actividad de comunicación con el cliente se definen las siguientes actividades:

Identificación del sistema o subsistemas clave de los directivos.
Determinación de las condiciones de victoria de los directivos.
Negociación de las condiciones de victoria de los directivos para reunirlas en un conjunto de condiciones para todos los afectados (incluyendo el equipo del proyecto de software).

El modelo en espiral WINWIN introduce tres hitos en el proceso, llamados puntos de fijación que ayudan a establecer la completitud de un ciclo alrededor de la espiral y proporcionan hitos de decisión.

Un ciclo de espiral comienza con la elaboración de los objetivos tanto funcionales como de rendimiento. Después se enumeran algunas formas posibles de alcanzar estos objetivos identificando las fuentes de riesgos posibles. El siguiente paso es resolver estos riesgos y llevar a cabo las actividades de desarrollo. Finalmente se planifica el siguiente ciclo de la espiral.

Trata de mejorar los ciclos de vida clásicos y prototipos.
Este modelo puede combinarse con otros modelos de proceso de desarrollo (cascada, evolutivo).
En cada giro se construye un nuevo modelo del sistema completo.
El análisis de riesgo requiere la participación de personal con alta cualificación.
Incorpora objetivos de calidad y gestión de riesgos.
Elimina errores y alternativas no atractivas al comienzo.
Permite iteraciones, vuelta atrás y finalizaciones rápidas.
Cada ciclo empieza identificando:

Los objetivos de la porción correspondiente.
Las alternativas.
Restricciones.

Modelo V

El propósito de este programa es definir las distintas fases intermedias que se requieren para validar el desarrollo dela aplicación, es decir, para garantizar que el software cumpla los requisitos para la aplicación y verificación de los procedimientos de desarrollo: se asegura de que los métodos utilizados son apropiados.

Este modelo tiene como objetivos:

Regular el proceso de desarrollo del software.
Minimización de los riesgos del proyecto.
Mejorar y Garantizar la Calidad del proyecto.
Reducción de los gastos totales durante todo el proyecto.
Mejorar la comunicación entre todos los inversionistas.

Descripción del modelo V:

Representación gráfica del ciclo de vida del desarrollo de un sistema. En él se resumen las principales medidas que deben adoptarse en relación con las prestaciones correspondientes en el marco del sistema informático de validación. Aquí se describen las actividades y resultados que deben producirse durante el desarrollo del proyecto. Es una variación del modelo en cascada que muestra cómo se relacionan las actividades de prueba con el análisis y el diseño.

La letra “V” significa «Verificación y validación».

El lado izquierdo de la V: representa la descomposición de las necesidades, yla creación de las especificaciones del sistema.
El lado derecho de la V: representa la integración de las piezas y su verificación.

V Es muy similar al modelo de la cascada clásico ya que es muy rígido y contiene una gran cantidad de iteraciones.

Partes del método:

La corriente de especificación consiste en:

Conceptos de operaciones: qué debe hacer el sistema a grandes rasgos.
Requisitos del sistema y arquitectura del mismo. Diseño detallado.

La corriente de pruebas consiste en:

Integración de las distintas partes, test y verificación de las mismas.
Verificación y validación del sistema en conjunto.
Mantenimiento del sistema.

Fases del diagrama

Fase #1: está orientado al “cliente”. El inicio del proyecto y el fin del proyecto constituyen los dos extremos del ciclo. Se componen del análisis de requisitos y especificaciones, se traduce en un documento de requisitos y especificaciones.

Fase #2: se dedica a las características funcionales del sistema propuesto. Puede considerarse el sistema como una caja negra, y caracterizarla únicamente con aquellas funciones que son directa o indirectamente visibles por el usuario final, se traduce en un documento de análisis funcional.

Fase #3: define los componentes es la fase de hardware y software del sistema final, a cuyo conjunto se denomina arquitectura del sistema.

Fase #4: es la fase de implementación en la que se desarrollan los elementos unitarios o módulos del programa.

Conclusión

Una vez vistos los temas tales como la revisión estática, los términos del IEEE y algunos de los modelos de desarrollo, primero que todo las revisiones estéticas son importantísimas ya que nos ayudan a detectar defectos u errores la en un tiempo prematura, respecto al proyecto en el que se esté trabajando. Ciertamente si logramos detectar a temprana “edad” lo errores, es probable que este nos lleve a obtener grandes beneficios ya sea en costos y tiempo, incluso en lo que respecta al desarrollo del código. Así que en mi opinión este tipo de revisiones son muy útiles si se desarrollan y aplican correctamente. Lo cual nos genera un desarrollo de software de alta calidad y con respaldo. Por otro lado, tenemos lo que es el IEEE 1028-2008, el cual nos comenta como su propósito la cual es definir revisiones sistemáticas y auditorías aplicables a la adquisición, suministro, desarrollo, operación y mantenimiento de software. Es decir, aquí nos damos cuenta sobre lo que son lo importante de las diferentes revisiones y sobre como esta norma describe cómo realizar una revisión. Posteriormente tenemos lo que son las revisiones de software en las cuales se pueden utilizar en apoyo de los objetivos de gestión de proyectos, ingeniería de sistemas de configuración, garantía de calidad y auditoría. Donde es de importante tener en cuenta como todas estas acciones que se pueden realizar van de la mano con una estandarización de procesos como lo establece esta norma, la cual es una de las más importantes en el mundo, una que refleja la altísima calidad que se puede obtener, de cumplir al pie de la letra con lo que nos solicitan.

Por último, pero no más importante tenemos los modelos de desarrollo los cuales ciertamente son una de las secciones más habituales, aun así son de muy utilidad a la hora de desarrollar proyectos, el mismo tipo de modelo que se desea trabajar conjuntamente dependerá de las necesidades del proyecto.

Conjuntamente estos tres temas son muy interesantes y dichosamente existe más información para informarse a futuro, lo cual nos ayudara como estudiantes en computación, ya que estos son unas de las tantas bases que nos ayudaran a realizar nuestra trabajo de la mejor manera, dando un respaldo de confianza y calidad en los trabajos futuros.

Referencias Bibliográficas

Cano, J. E. (13 de octubre de 2013). Slideshare. Obtenido de Técnicas Estáticas: https://es.slideshare.net/juanestebanpuertacano/tcnicas-estticas

Diez, E. (s.f.). Obtenido de Pruebas Estáticas: http://sistemas.unla.edu.ar/sistemas/sls/ls-4-optativa-algoritmos-y-lenguajes-prueba-del-software/pdf/Pruebas-de-Software-C03-Pruebas-estaticas.pdf

López, J. M. (2009). Obtenido de Verificación y Validación: https://www.ctr.unican.es/asignaturas/Ingenieria_Software_4_F/Doc/M7_09_VerificacionValidacion-2011.pdf

mendez45. (19 de mayo de 2010). slideshare. Obtenido de Modelo de cascada: https://es.slideshare.net/mendez45/modelo-de-cascadaa

NA. (s.f.). Obtenido de TÉCNICAS DE EVALUACIÓN ESTÁTICA: http://www.lsi.us.es/docencia/get.php?id=360

Ortega, M. (16 de abril de 2012). Slideshare. Obtenido de Modelo V: https://es.slideshare.net/MelissaOrtega5/modelo-v

Posligua, S. (14 de noviembre de 2013). Slideshare. Obtenido de Modelo en espiral: https://es.slideshare.net/soniaposligua/modelo-enespiral

Romero, M. (28 de julio de 2010). Slideshare. Obtenido de Modelo V: https://es.slideshare.net/grupo04/mtodo-v?next_slideshow=1

Committee, S. &. (2008). IEEE Standard for Software Reviews. New York, NY: IEEE-SA Standards Board.

Costos de Calidad

noreply@blogger.com (Anonymous) — Mon, 21 Aug 2017 04:35:00 +0000

Acontecimientos Históricos

Para empezar con todo lo que son los costos de la calidad, empezaremos hablando acerca de algunos antecedentes importantes para lo que fue el desarrollo de esta área, la cual es vital importancia actualmente, también conocido como QCs por sus siglas en inglés. En 1942 W.A. Shewhart de Bell Telephone Laboratorios diseñó una gráfica de estadísticas para controlar las variables de un producto, y así se inició la era del control estadístico de la calidad, luego en 1946, se fundó la sociedad estadounidense de Control de la calidad, ASQC (American society of quality control), la que, a través de publicaciones, conferencias y cursos de capacitación, ha promovido el control de la calidad en todo tipo de productos y servicios.

Posteriormente W. Edwards Deming en 1950 ofreció una serie de conferencias a ingenieros japoneses sobre métodos estadísticos y sobre la responsabilidad de la calidad a personal gerencial de alto nivel, en 1986 publica "Out of the Crisis" (Fuera de Crisis), donde explica su filosofía de calidad, productividad y posición competitiva, incluyendo sus famosos 14 puntos para la Administración, actualmente conocidos como los 14 puntos de Deming, entre los que se destacan: mejora continua, propósito constante y conocimiento profundo.

Luego en 1995 Jospeh M. Juran contribuyó a destacar el importante compromiso del área gerencial para el logro de la calidad, así como el que se capacite al personal en la gestión para la calidad, a un ritmo sin precedentes valiéndose de estos conceptos, los japoneses fijaron normas de calidad que después se adoptaron en todo el mundo. De hecho según Juran (1988) “afirma que la tendencia ha sido la de igualar el significado de estos con los de una pobre calidad, principalmente con los costos de hallar y corregir el trabajo defectuoso”

Ahora, continuando con el tema tenemos lo que es los costos de la calidad, el termino calidad es interpretado de diversas formas por los autores, unos la definen basada en el producto, percibiéndola como una característica o atributo que se puede cuantificar o medir, algunos consideran que no es solamente atribuible a producto, sino que la conforman el sistema que tenga la organización y en el caso mas amplio sera una entidad; otros se apoyan en el usuario, en la idea de que la calidad es un asunto individual y que los productos capaces de satisfacer estar preferencias son los de mas alta calidad.

Según Feigenbaum (1999) “El costo de la calidad consiste en identificar y cuantificar todos los costos derivados del esfuerzo de una compañía hacia la planeación de la calidad, los costos de verificar que los parámetros de calidad están siendo logrados, los costos de las fallas en proceso y los rechazos de los clientes”.

La ISO 9000:2000 define la calidad como el conjunto de características inherentes de un producto, sistema o proceso para satisfacer los requisitos de los clientes y otras partes interesadas. Resumen definitivo, que es el cumplimiento de los requisitos; en las normas ISO 9000:2000, se define el Sistema de Gestión de la Calidad (SGC) como el sistema de gestión para dirigir y controlar una organización con respecto a la calidad.

Los costos de la calidad debidamente calculados y representado constituyen una herramienta fundamental para atraer el interés de la dirección de hacia ellos. Los principales objetivos que impulsan la calidad son, según Juran (1988):

Cuantificar la importancia del problema en un lenguaje que impacte a la alta dirección.
Identificar las principales oportunidades para la reducción de costos.
Identificar oportunidades de reducción de la insatisfacción de los clientes y demás problemas similares, para aumentar la posibilidad de venta de los productos.
Ampliar el control presupuestario y de costos.
Estimular la mejora por medio de la publicación de datos.

Calculo del Costos de Calidad

Cuando se empezó a hablar de costos de la calidad, había una extendida opinión de que la calidad no podía ser prácticamente medida en términos de costos, uno de las razones de esta creencia era la tradicional contabilidad de costos que no había tratado de cuantificar la calidad y por lo tanto el costo de la calidad no se ajustaba fácilmente a las viejas estructuras de la contabilidad. Actualmente no solo se reconoce la capacidad de medición de los costos de la calidad, sino que se sabe que son básicos para la administración e ingeniería del control moderno de la calidad total, así como para la planeación estratégica del negocio. Los costos de la calidad proporcionan un común denominador económico por medio del cual la dirección y los encargado de los programas de control de calidad pueden comunicarse clara y efectivamente en términos de negocios. Básicamente son la base por medio de la cual se puede evaluar las inversiones en programas de calidad y su efecto en reducción de costos, aumento de las ganancias y otros beneficios para las empresas.

A continuación, se menciona la respectiva clasificación de los costos de calidad:

1. Costos de Prevención: son aquellos en los que incurre la organización para evitar y prevenir fallas, desviaciones y/o defectos, durante cualquier etapa del proceso de diseño, producción y administración. También se pueden considerar como los costos de todas las actividades específicamente diseñados para prevenir fallas de calidad en productos o servicios como: las labores y actividades de adquisición de insumos y materiales, en la mano de obra, en la creación de instalaciones y en todos aquellos aspectos que tienen que ver desde el inicio y diseño de un producto o servicio hasta su comercialización. En breve se mencionan los elementos integrales de este grupo:

Revisión del diseño, de los planes y de las especificaciones.
Calificación del producto.
Orientación de la ingeniería en función de la calidad.
Programas y planes de aseguramiento de la calidad.
Evaluación y capacitación a proveedores sobre calidad.
Entrenamiento y capacitación para la operación con calidad.

2. Costos de Evaluación: Son aquellos en los que incurre la organización, destinados a medir, verificar y evaluar la calidad delos materiales, partes, elementos productos y/o proceso, así como para mantener y controlar la producción dentro de niveles y especificaciones de calidad, previamente planeados y establecidos por el sistema de calidad y normas aplicables. En breve se mencionan los elementos integrales de este grupo:

Inspección y pruebas finales en proceso de recibo.
Laboratorio de inspección, medición y prueba.
Materiales e insumos para inspecciones y pruebas.
Pruebas de campo.

3. Costos por Fallas Internas: Son aquellos resultados de la falla, del defecto o incumplimiento de los requisitos establecidos delos materiales, elementos, partes, productos, servicios cuya falla o defecto es detectada DENTRO de la empresa antes de la entrega del producto o servicio.

Desperdicios ( materiales, insumos, recursos humanos, etc).
Reproceso.
Reparaciones.
Consultas técnicas con personal de la empresa.
Consultas técnicas con personal especializado.
Eliminación por rechazos.

4. Costos por Fallas Externas: Son aquellos en los que incurre la empresa una vez que el producto ha salido de la empresa y llego al consumidor final.

Atención a quejas.
Servicio de garantía.
Devoluciones.
Costos de Imagen.
Perdida de ventas.
Castigos y penalizaciones.
Demandas.
Juicios.
Pago de seguros.

Conclusión

Es claro que los costos de calidad son una de las áreas más complejas en el desarrollo del software, ya que es en esta etapa donde los costos de un proyecto se pueden “disparar”, mantenerse dentro del presupuesto o bien ya sea incluso que los costos sean menores, son algunas de las cuestiones que se tienen que tomar en cuenta. Personalmente creo que un buen control de calidad con un presupuesto aceptable, obtendremos como resultado un proyecto tanto de alta calidad y bajos costos. Lo que nos da como conclusión que el proyecto fue planificado de muy buena manera desde el inicio del mismo y hasta del fina, hay que tener en cuenta que entre más se avanza en el proyecto los costos van subiendo, es decir lo mejor que se debe hacer, es en las primeras etapas del proyecto detectar y solucionar la mayor cantidad de errores, para que en un futuro el costo no suba exponencialmente debido a que los problemas no se solucionaron y se dejaron para las etapas del proyecto. Por otro lado, están los costos relativos a la calidad, donde se presentan la clasificación, es aquí donde debemos de tener planificado de la mejor manera todas las etapas del control de calidad para no alterar lo que son los costos, es por eso que se mencionan anteriormente. Es muy importante tener presente todos estos conceptos, ya que si se trabaja siguiendo las reglas de aseguramiento de calidad y los controles de calidad la probabilidad de obtener como resultado un excelente proyecto es muy amplia en comparación a donde no se realicen las procesos correspondientes al QCs.

Referencias Bibliográficas

Fernandez, J. C. (04 de marzo de 2009). Slideshare. Obtenido de Costos de Calidad: https://es.slideshare.net/jcfdezmxcal/costos-de-calidad
Hernández, L. Y. (s.f.). Monografias. Obtenido de Los Costos de Calidad: http://www.monografias.com/trabajos90/costos-calidad/costos-calidad.shtml#antecedena
Mancilla, N. (s.f.). wordpress.com. Obtenido de Seguridad del Paciente: https://seguridaddelpaciente.wordpress.com/principios/principios-de-edward-deming/
NA. (s.f.). Obtenido de Costos de Calidad: http://tesis.uson.mx/digital/tesis/docs/7811/Capitulo6.pdf
NA. (s.f.). Obtenido de Costos de Calidad: http://unpan1.un.org/intradoc/groups/public/documents/icap/unpan033011.pdf
NA. (5 de diciembre de 2010). wordpress.com. Obtenido de ANALISIS DE LOS 14 PUNTOS DE DEMING: https://andicor.wordpress.com/2010/12/05/analisis-de-los-14-puntos-de-deming/
Saldaña, E. J. (11 de noviembre de 2012). Slideshare. Obtenido de Costos de Calidad : https://es.slideshare.net/edgarsjimenez/costos-de-calidad-15131275

Control de calidad, Defectos y Olores del Software

noreply@blogger.com (Anonymous) — Mon, 14 Aug 2017 03:35:00 +0000

Control de la calidad

Antes de iniciar con el tema de control de calidad y los otros temas, es necesario recordar lo que es el Aseguramiento de la Calidad también conocido como "Quality Assurance, que es el conjunto de actividades planificadas y sistemáticas aplicadas en un Sistema de Calidad para que los requisitos de calidad de un producto o servicio sean satisfechos. Entre estas actividades se encuentran la medición sistemática, la comparación con estándares, el seguimiento de los procesos, todas actividades asociadas con bucles de realimentación de información. Estas actividades contribuyen a la prevención de errores, lo cual se puede contrastar con el Control de Calidad, que se centra en las salidas del proceso.

Continuando con el tema de control de calidad, el problema principal para garantizar la calidad en el software está en la concepción de la gran mayoría de las personas cuando suponen que la garantía de calidad es algo que se impone bajo una medida que se obtiene al finalizar un proyecto de software. El control de calidad en el software se fundamenta en el principio de que la calidad se construye a través de un proceso continuo de desarrollo, verificación (revisión) y optimización en diferentes etapas. Es muy importante tener presente estas “actividades” que ayudan a la prevención de errores mediante inspecciones de software que surgen a partir de la necesidad de producir software de alta calidad. Algunos grupos de desarrollo creen que la calidad del software es algo en lo que deben preocuparse una vez que se ha generado el código, ¡Error!, la garantía de la calidad del software es una actividad de protección que se aplica a lo largo de todo el proceso de ingeniería de software.

Entonces, la calidad en el software, este está en relación directa con el cumplimiento de los requerimientos formulados por el usuario, de tal forma que si un programa no cumple con alguno de estos requerimientos es un software de baja calidad. Aunque el criterio de cumplimiento de los requerimientos es un factor importante, no es el único factor, ya que existen condiciones implícitas que el software debe cumplir como son eficiencia, seguridad, integridad, consistencia, etc.; por lo tanto, no podemos afirmar que un software es de alta calidad cuando cumple con los requerimientos del usuario. Además, en la calidad en el software existen ciertos factores que varían de acuerdo con el usuario y con los tipos de aplicación. Podemos resumir el concepto de la calidad en el software en los siguientes puntos:

Los requerimientos del usuario sobre un programa son los fundamentos desde los que se mide la calidad. La falta de concordancia con estos requerimientos es una falta de calidad.
Los estándares especificados definen un conjunto de criterios de desarrollo que guían la forma como se aplica la ingeniería de software; si no se siguen estos estándares, probablemente se obtendrá software de baja calidad.
Existe un conjunto de requerimientos implícitos que a menudo no se mencionan (eficiencia, facilidad de uso, facilidad de mantenimiento). Si el software falla en alcanzar los requerimientos implícitos, la calidad en el software queda en entredicho.

El control de calidad en el software, denominado SQA ("Software Quality Assurance"), se basa en las siguientes actividades:

Uso de métodos y herramientas de análisis, diseño, codificación y prueba.
Revisiones técnicas formales, que se aplican durante cada paso de la Ingeniería de software.
Estrategia de prueba multiescalada.
Control de la documentación del software y de los cambios realizados.
Procedimientos que aseguren un ajuste a los estándares de desarrollo.
Mecanismos de medida de la calidad ("métricas").

Comprobación de características de calidad

A continuación, se muestran las comprobaciones de características de la calidad respecto de la definición del modelo de calidad de software ISO 9126-1, el cual es presentar una visión general de la norma ISO 9126 y proporcionar una descripción detallada del modelo de calidad de software utilizado por esta norma, con una explicación de las principales características.

El modelo de calidad de software ISO 9126-1 identifica 6 características principales de calidad, a saber:

1. Funcionalidad: Un conjunto de atributos que dependen de la existencia de un conjunto de funciones y sus propiedades especificadas. Las funciones son aquellas que satisfacen necesidades declaradas o implícitas. (ISO 9126: 1991, 4.1).

Sub-características:

Aptitud: Esta es la característica esencial de la funcionalidad y se refiere a la adecuación (a la especificación) de las funciones del software.
Preciso: Esto se refiere a la corrección de las funciones.
Operabilidad: Un componente o sistema de software dado no suele funcionar de forma aislada. Esta sub-característica se refiere a la capacidad de un componente de software para interactuar con otros componentes o sistemas.
Conformidad: Cuando sea apropiado, se deben cumplir ciertas leyes y directrices de la industria. Esta sub-característica se refiere a la capacidad de software compatible.
Seguridad: Esta sub-característica se refiere al acceso no autorizado a las funciones de software.

2. Confiabilidad: Un conjunto de atributos que afectan a la capacidad del software para mantener su nivel de rendimiento bajo condiciones establecidas durante un período de tiempo establecido. (ISO 9126: 1991, 4.2).

Sub-características:

Madurez: Esta sub-característica se refiere a la frecuencia del fallo del software.
Tolerancia a fallos: La capacidad del software de soportar (y recuperarse) de un componente, o de un fallo ambiental.
Recuperabilidad: Capacidad para traer de vuelta un sistema fallido a la operación completa, incluyendo datos y conexiones de red.

3. Usabilidad: Un conjunto de atributos que dependen del esfuerzo necesario para su uso, y en la evaluación individual de tal uso, por un conjunto de usuarios declarado o implícito. (ISO 9126: 1991, 4.3).

Sub-características:

Comprensibilidad: Determina la facilidad con la que se pueden entender las funciones de los sistemas, se relaciona con los modelos mentales de los usuarios en los métodos de interacción de la computadora humana.
Aprendizaje: Esfuerzo de aprendizaje para diferentes usuarios, es decir, principiante, experto, casual, etc.
Operabilidad: Capacidad del software para ser fácilmente operado por un usuario dado en un entorno dado.

4. Eficiencia: Un conjunto de atributos que afectan a la relación entre el nivel de rendimiento del software y la cantidad de recursos utilizados, en las condiciones establecidas. (ISO 9126: 1991, 4.4).

Sub-características:

Comportamiento del tiempo: Caracteriza los tiempos de respuesta para un determinado paso, es decir, tasa de transacción.
Comportamiento del recurso: Caracteriza los recursos utilizados, es decir, la memoria, la CPU, el disco y el uso de la red.

5. Mantenibilidad: Un conjunto de atributos que dependen del esfuerzo necesario para realizar las modificaciones especificadas. (ISO 9126: 1991, 4.5).

Sub-características:

Analizabilidad: Caracteriza la capacidad de identificar la causa raíz de un fallo dentro del software.
Posibilidad de cambiar: Caracteriza la cantidad de esfuerzo para cambiar un sistema.
Estabilidad: Caracteriza la sensibilidad al cambio de un sistema dado que es el impacto negativo que puede ser causado por los cambios del sistema.
Testabilidad: Caracteriza el esfuerzo necesario para verificar (probar) un cambio del sistema.

6. Portabilidad: Conjunto de atributos que afectan a la capacidad del software para ser transferido de un entorno a otro. (ISO 9126: 1991, 4.6).

Sub-características:

Adaptabilidad: Caracteriza la capacidad del sistema para cambiar a nuevas especificaciones o entornos operativos.
Facilidad de instalación: Caracteriza el esfuerzo requerido para instalar el software.
Conformidad: Similar al cumplimiento de la funcionalidad, pero esta característica se refiere a la portabilidad. Un ejemplo sería la conformidad de Open SQL que se relaciona con la portabilidad de la base de datos utilizada.
Reemplazable: Caracteriza el aspecto plug and play de los componentes de software, que es lo fácil que es intercambiar un componente de software dado dentro de un entorno especificado.

Defectos del software y terminología asociada

Una de las limitaciones más importantes de las pruebas de software es que las pruebas pueden mostrar sólo la presencia de fallos, no su ausencia. Esta es una limitación fundamental y teórica; En general, el problema de encontrar todas las fallas en un programa es indecidible. Los asesores a menudo llaman a una prueba exitosa (o efectiva) una que encuentra un error. A continuación, se presentan algunas definiciones vistas en clase con él profesor.

Una de las distinciones más importantes a hacer es entre la validación y la verificación

1. Validación: El proceso de evaluación del software al final del desarrollo del software para garantizar el cumplimiento del uso previsto.

2. Verificación: El proceso de determinar si los productos de una fase dada del proceso de desarrollo de software cumplen con los requisitos establecidos durante la fase anterior.

3. Fallo de software: Un defecto estático en el software.

4. Error de software: Un estado interno incorrecto que es la manifestación de alguna falla.

5. Fracaso de software: Comportamiento externo, incorrecto con respecto a los requisitos u otra descripción del comportamiento esperado.

6. Pruebas: Evaluar el software observando su ejecución.

7. Fracaso de prueba: Ejecución que produce un error.

8. Depuración: El proceso de encontrar una falla dada una falla.

9. Resultados esperados: El resultado que se producirá al ejecutar la prueba si y sólo si el programa satisface su comportamiento previsto.

10. Observabilidad del software: Es fácil observar el comportamiento de un programa en términos de sus salidas, sus efectos en el entorno y otros componentes de hardware y software.

11. Control de software: Es fácil proporcionar un programa con los insumos necesarios, en términos de valores, operaciones y comportamientos.

12. Valores de prefijo: Cualquier entrada necesaria para poner el software en el estado apropiado para recibir los valores del caso de prueba.

13. Valores de postfijo: Cualquier entrada que necesite ser enviada al software después de enviar los valores del caso de prueba.

14. Valores de verificación: Valores necesarios para ver los resultados de los valores del caso de prueba.

15. Comandos de salida: Valores necesarios para finalizar el programa o devolverlo a un estado estable.

16. Caso de prueba: Un caso de prueba se compone de los valores de los casos de prueba, resultados esperados, valores de prefijo y valores de postfijo necesarios para una ejecución y evaluación completas del software bajo prueba.

17. Conjunto de pruebas: Un conjunto de pruebas es simplemente un conjunto de casos de prueba.

18. Script de prueba ejecutable: Un caso de prueba que se prepara en un formulario para ser ejecutado automáticamente en el software de prueba y producir un informe.

Clasificación de defectos

Con respecto a la clasificación de defectos la nace la pregunta: ¿Cómo se implementa la clasificación de incidentes? Esta es quizás una de las preguntas más comunes que surge cuando se intenta establecer la Gestión de Incidentes basada en la “Information Technology Infrastructure Library” (ITIL). Según ITIL, el objetivo de la clasificación de incidentes y el apoyo inicial es:

Especificar el servicio con el que se relaciona el incidente.
Asociar el incidente con un acuerdo de nivel de servicio (SLA).
Identificar la prioridad basada en el impacto del negocio.
Definir qué preguntas deben hacerse o información verificada.
Determinar una matriz de informes primaria para información de gestión.
Identificar una relación para coincidir con errores conocidos o soluciones.
Seleccionar y / o definir el mejor especialista o grupo para manejar el incidente.

Por lo tanto, la clasificación de incidentes existe principalmente para clasificar los incidentes con el fin de proporcionar apoyo inicial. El soporte inicial significa un análisis adecuado, evaluación y, si es necesario, enrutamiento.

1. Clasificación CTI (Categoría / Tipo / Artículo):

Muchas herramientas de administración de servicios de TI que ofrecen automatización de administración de incidentes usan una simple: categoría / tipo / artículo (CTI) para la clasificación. CTI es un enfoque de tres niveles de definición de "Categoría", un "Tipo" asociado con la "Categoría", y un "Artículo" asociado con el "Tipo". Un enfoque popular sugiere que Categoría y Tipo sean "sustantivos", y Artículo sea un "verbo". CTI funciona bien cuando se conoce el trabajo requerido.

Este tipo de esquema produce taxonomía de clasificación de la siguiente manera (usando taxonomía CTI):

category noun (Database) | type noun (Oracle) | item verb (Upgrade)

Así que básicamente el enfoque esta en identificar una categoría sobre términos generales, un sustantivo que me ayude a identificar que está siendo afectado y por último un verbo que es el que indique la acción que queremos hacer.

2. Clasificación ITIL (Information Technology Infrastructure Library):

El soporte inicial es determinar qué tipo de soporte necesita el cliente o usuario. La clasificación determina el soporte inicial que el cliente o usuario requiere y esto significa que la primera entrada en la clasificación taxonómica debe indicar el tipo de trabajo a realizar; Debe definir claramente cómo debe responder la organización de TI (no quién debe responder en la organización).

Por estas razones, ITIL proporciona un ejemplo de esto y etiqueta el primer elemento de su taxonomía de clasificación como "Tipo". La entrada Tipo describe la amplia participación funcional requerida para apoyar al cliente o usuario. Después de establecer el primer elemento, "Tipo", el siguiente elemento, "Categoría", cambia basado en el Tipo. Por ejemplo, considerando una Solicitud de Servicio para ayuda y orientación sobre una aplicación de software, una clasificación bien formada podría ser (usando la taxonomía de ITIL):

En este caso del ITIL lo resumimos en: que es lo que se solicita, el tipo de solicitud, que acción se ejecuta y sobre que lo estamos haciendo.

Service Request | Help User | Desktop Application

Olores del software

Cuando hablamos de calidad del software siempre hacemos mención a cosas como patrones de diseño, anti-patrones, métricas de calidad, etc; conceptos que tienen una aplicación concreta. En esta sección comentaremos sobre los olores de software. En la actualidad, la actividad de programación de aplicaciones de software exige que, quienes llevan a cabo la programación, tengan presente que temprano o tarde, su código será sujeto de mantenimiento producto de extensiones o cambios en los requerimientos del negocio.

¿Olor? Cuando desarrollamos un software, siempre lo hacemos de la mejor manera que sabemos. Pero ¿qué ocurre cuando ese desarrollo lleva un tiempo? Pues que ya sea por desmotivación, prisas, cambios de alcance, cambios de diseño, este software se oxida, se pudre… y, entonces, huele. Un olor, se puede definir, como situaciones donde ciertas características del código hacen que sea difícil o problemático su entendimiento, mantenimiento y pruebas. Los olores de software son indicadores que apuntan y presagian que, la falta de atención a problemas de diseño que puede causar dificultades en la evolución y mantenimiento del software.

La presencia de olores puede pasar una cara factura a las compañías que hacen uso de software para apalancar sus operaciones. Desde 1950 y hasta la fecha, las compañías han venido incrementando los porcentajes de personal dedicado a labores de mantenimiento de software (cerca de un 80%). Esta tendencia ejerce presión sobre las actividades de mantenimiento de software. Las dificultades encontradas, producto del mantenimiento, pueden convertirse en una situación problemática para las empresas que apuntan a responder, de forma oportuna, a las necesidades cambiantes de sus clientes y usuarios.

Existe una clasificación de 7 términos que nos puede indicar si nuestro software se está oxidando.

1. Rigidez: Un software es rígido cuando es difícil cambiarlo. Por ejemplo, si un cambio aparentemente sencillo supone más tiempo del esperado. Posibles razones serían: un simple cambio conlleva una cascada de cambios asociados, el código está tan enrevesado que no se sabe cómo se debería cambiar, etc

2. Fragilidad: Un software es frágil cuando un simple cambio provoca que se rompa en varios sitios con poca relación. Por ejemplo, se modifica una clase css para cambiar un color y se rompe una tabla que contiene un informe.

3. Inmovilidad: La inmovilidad hace referencia a la dificultad de volver a usar partes de código/módulos en otros sistemas. Tenemos un software que hace muchas cosas maravillosas pero está tan acoplado al proyecto al que pertenece que el esfuerzo que habría que realizar para usarlo de nuevo es demasiado grande.

4. Viscosidad: Por lo general, siempre hay maneras de modificar un software. Para este olor las vamos a englobar en 2: la manera en la que entra parte del diseño de la aplicación y los workarounds (o hacks). La viscosidad hace referencia a la facilidad que tiene un software de cambiar. Si es fácil realizar cambios que mantengan el diseño, un software es poco viscoso. Sin embargo, si es más fácil realizar workarounds significa que el software es viscoso.

5. Repeticiones innecesarias: Comúnmente llamado copy-paste. Cuando por dejadez o inexperiencia copiamos y pegamos el mismo trozo de código. Esto provoca que cuando que haya que realizar un cambio, éste se tenga que realizar en varios sitios con lo que multiplica el esfuerzo. Además, incrementa la posibilidad de que cuando corregimos un bug, no lo hagamos correctamente.

6. Opacidad: Este olor hace mención a lo complejo o difícil que puede ser leer o entender un código. Cuanto más difícil de entender, más opaco se considera.

7. Complejidad innecesaria: Por último, este olor hace referencia a cuando realizamos el código de manera demasiado compleja intentando anticiparnos a los futuros cambios. El software ha de ser mantenible, pero si aplicamos demasiadas abstracciones para prepararnos al futuro, puede ser que lo que consigamos sea hacerlo demasiado complejo y caer en los olores anteriores.

Conclusión

Es muy interesante notar como todo lo que se relaciona con el control de calidad, a decir verdad, a mi criterio este es indispensable para lo que es el desarrollo de un proyecto, ya que si no se tiene un control del software lo más probable es que nos de problemas en un futuro, además que esto se verá reflejado en gastos. Por otro lado, tenemos lo que es la comprobación de características de calidad, que pues gracias al ISO 9126-1, el cual nos da una idea de cuales características debe cumplir un proyecto para que puede considerarse dentro la norma, además es muy importante tener en cuenta todas las características de este y manejarlas de la mejor manera, lo que beneficia claro está, ya que poder tener un buen control de calidad ayuda mucho a los proyectos, además que es de obligación entregar un proyecto que cumpla con todos los requerimiento solicitados por el cliente, así como que este no presente errores cada día y pues también que sea lo más eficiente posible con el fin de entregar un producto que sea de la más alta calidad y no algo que más bien sea un desastre total. También comentamos otros temas como la clasificación de defectos en los cuales encontramos el CIT y el ITIL que ciertamente son temas muy interesantes y a su vez complejos a la hora de manejar lo que son los defectos y por ultimo mencionamos lo que son los olores de software algo que sinceramente es muy común en los programadores principiante, pero si estos olores se logran evitar, la posibilidad de desarrollar un software de calidad es muy alta y por ende al final del desarrollo tendremos como resultado un software de calidad que cumple con todas las expectativas del cliente y del programador.

Referencias Bibliográficas

Arroyo, F. (23 de mayo de 2016). Los 7 olores del software. Obtenido de https://www.beeva.com/beeva-view/desarrollo/los-7-olores-del-software/

Chavarria, L. J. (28 de noviembre de 2016). CAMTIC. Obtenido de http://www.camtic.org/hagamos-clic/presencia-de-olores-de-software-en-la-formacion-de-competencias-de-programacion/

Control de calidad del software. (s.f.). Obtenido de http://www.angelfire.com/my/jimena/ingsoft/calidad.htm

EcuRed. (s.f.). Obtenido de Sistema de control de calidad: https://www.ecured.cu/Sistema_de_control_de_calidad_de_software

ISO 9126 Software Quality Characteristics. (s.f.). Obtenido de http://www.sqa.net/iso9126.html

JGS, i. (2 de marzo de 2014). infoxicadoblog.wordpress.com. Obtenido de https://infoxicadoblog.wordpress.com/2014/03/02/aseguramiento-de-la-calidad-en-la-construccion/

L, J. H. (s.f.). Control de calidad en el software. Obtenido de https://repository.icesi.edu.co/biblioteca_digital/bitstream/item/4008/1/Control_calidad_software.pdf

Marquis, H. (23 de julio de 2010). Dity. Obtenido de http://www.itsmsolutions.com/newsletters/DITYvol6iss27.htm

Párraga, J. M. (s.f.). Control de calidad del software. Obtenido de https://jorgemontanoblog.files.wordpress.com/2011/10/control-de-calidad-de-software-final.pdf

Quality characteristics and subcharacteristics. (s.f.). Obtenido de http://www.issco.unige.ch/en/research/projects/ewg95/node55.html

Offutt, P. A. (2008). INTRODUCTION TO SOFTWARE TESTING. New York: CAMBRIDGE UNIVERSITY PRESS.

Fracasos del Software

noreply@blogger.com (Anonymous) — Mon, 07 Aug 2017 01:00:00 +0000

Es muy importante tener claro el motivo o las diferentes circunstancias que pueden ocurrir para ocasionar el fracaso de un software, porque razones fracasa el software y algo muy importante es cómo es posible evitarlo, o que acciones me permiten no llevar al software al fracaso, además se mencionan otros temas interesantes que tenemos de tener presente, así como algunos ejemplos de fracasos de software. Pues bien, la idea de esta “entrega número 1” es abarcar los temas de la primera presenta con del curso de Aseguramiento de la Calidad de Software de la mejor manera posible, dejando claro la materia que se investigara en fuentes externas y a su vez con la materia vista en clase con el profesor.

Es claro que existen varias características que son correspondientes a las causas más frecuentes por las cuales fracasan los proyectos de software, estas corresponden a la observación de aspectos claves en los procesos del desarrollo de un proyecto, como son la formulación, la comunicación, la planeación y la ejecución, los cuales se revisan a continuación:

Formulación

Standish luego de un estudio de 50.000 proyectos fallidos clasifica dentro de las principales causas por las cuales fracasan el 71% de los proyectos de desarrollo de software a: Requerimientos y especificaciones incompletas, Cambios frecuentes en los requerimientos y especificaciones, expectativas no realistas y a objetivos poco claros. Fonseca [1].

La formulación inicia cuando el departamento de ventas tiene el primer contacto con el cliente y es aquí donde se debe refinar la definición de sus necesidades con el propósito de tomar nota, analizar y retroalimentar sobre la información entregada con el fin de asegurar que lo que se entendió es lo que se requiere. Markus [3]. Es muy común en el desarrollo de proyectos de software que dadas las especificaciones del cliente no se realice un adecuado estudio de viabilidad técnico-financiera, lo que en últimas termina en el fracaso de los proyectos ya que se llevan a subestimar el costos y el tiempos y probablemente a sobreestimar los beneficios. Zabala [5].

Comunicación

La mayoría de los proyectos no fracasan por lo relacionado con el tema técnico, sino por el tema psicológico, particularmente en la comunicación. Gracia [6].

A criterio personal, la comunicación es sumamente necesaria para fomentar la interacción y vinculación entre los grupos de trabajo teniendo en cuenta que cada uno es experto en lo que hace y la idea está en que estos se complementen a través del intercambio de información. Además, creo que es recomendable escuchar a todos los miembros del grupo y hacerles saber que sus observaciones e ideas son importantes para el proyecto y que además son escuchadas, y que estas se incluirán dentro del proyecto, de esta manera se estará motivando la participación de los integrantes.

Una Implicación insuficiente de los usuarios en la definición, ejecución y control de actividades, según se observó en los resultados de una revisión de varios proyectos de desarrollo de software constituye una de las principales causas para que este tipo de proyectos no lleguen a la meta propuesta. Paredes [2].

Hacia finales del 2001 Piorum [4] realizó un estudio a cincuenta responsables de desarrollo de proyectos, aproximadamente, y encontró que los problemas de tipo humano como son la comunicación y los conflictos contribuyen en gran medida a que los proyectos de desarrollo de software fracasen.

Planeación

El fracaso de los proyectos se debe revisar desde las diferentes perspectivas, desde la técnica, ya que se contrata al personal que no tiene las capacidades requeridas, hasta una incorrecta visión de los negocios a nivel de la gerencia del proyecto. Romo [7].

Un enfoque incorrecto de la gerencia de los proyectos proporciona una gran probabilidad de terminar en proyectos fallidos, muy comúnmente, porque el plan de trabajo a seguir no fue adecuado. Humphrey [8].

Según el Dr. Daniel Tapia, Profesor Investigador del Centro de Investigación en Tecnologías de la Información (CITIS) de la Universidad Autónoma del Estado de Hidalgo menciona los siguientes errores como determinantes en el desarrollo de proyectos de desarrollo de software:

Se les da prioridad a los temas operativos y se descuida en gran medida la planificación, lo que conduce obviamente a una planeación muy deficiente.

También, se descuidan los objetivos de la organización y al no estar alineados con los de los proyectos no se les da la importancia que requieren.

Es decir, no se realiza una planeación estratégica que garantice el desarrollo eficaz del desarrollo de los proyectos.

Las personas en la planeación

Los proyectos que no lo logran su objetivo terminan generando costos adicionales tanto indirectos (por no disponer de los beneficios ofrecidos) como directos (al utilizar mayores recursos que los planeados), Aisemberg [9] y una de las causas es por disminuir costos en el recurso humano ocasionado que los proyectos vinculen menos personas que las requeridas o que vinculen personas que están en otros proyectos lo que hace que se atrasen porque contratan personas con baja capacidad técnica lo que redunda en la baja calidad de los entregables del proyecto.

Luego, los gerentes de proyecto a portan con su cuota al fracaso de los proyectos y lo hacen debido a que sus habilidades técnicas (duras) no son las requeridas para apoyar a sus equipo de trabajo o por la deficiencia en sus habilidades blandas como son las que tienen que ver con su interacción con su grupo de trabajo, sus principio, su carácter, sus valores, su empatía, su capacidad de liderazgo, de liderazgo, de resolución de problemas, de toma de decisiones, innovación, creatividad y delegación entre otras. Aramburo [10].

Tampoco hay de dejar de lado cambios en el personal clave del proyecto, quizá uno de los recursos más importantes, luego es importante planear y definir una buena matriz de funciones y responsabilidades ya que facilita una correcta selección del equipo de trabajo para luego comprometerlo y de esta forma garantizar su participación durante el tiempo estimado para llevar a cabo el proyecto. Figuerola [11].

Cuando no se planean y se definen correctamente los criterios de selección de las personas se puede conseguir una alta rotación del equipo de trabajo o contratar profesionales que por su incompetencia o inexperiencia ocasionen el fracaso del proyecto. Markus [3].

La estimación de tiempo y costos en la planeación

Motivo durante muchos años ha sido el crear una métrica confiable para realizar estimaciones del tiempo y costo a la hora de definir proyectos de desarrollo de software. Jones [12].

Personalmente este punto es muy interesante, ya que la estimación del tiempo y los costos son temas que son muy difíciles de manejar, y estos a su vez están sujetos a cambios en los cronogramas o problemas que puede ir surgiendo en el desarrollo del proyecto, aun así creo que las compañías serias y con gran experiencia han logrado cumplir de correcta y muy certera con sus predicciones en cuanto a costo y tiempo invertido, y pues esto es posible por la seriedad de trabajo y porque se han dado a la tarea de tomar nota de estos aspectos en la ejecución de sus proyectos a lo largo de su experiencia y que en el momento de definir nuevos proyectos lo usan como materia prima para una mejor estimación. Y pues bueno como bien sabemos es de aquí donde se desprende la importancia de documentar los proyectos, de tal manera que se pueden elaborar las lecciones aprendidas y de estas se parte de un excelente punto de partida en la estimación de proyectos futuros. Otro aspecto muy importante es la correcta administración de los riesgos (recordando todo lo visto en curos de Administración de proyecto), donde se detallan todas las posibles acciones que se tomaran en cuanto suceda una afectación en los costos y tiempos del proyecto.

Standish menciona como una de las principales causas para que los proyectos fallen o no lleguen a los objetivos propuestos, es por la imposición de cronogramas irreales. Fonseca [1]

Ejecución

Según Humphrey las causas que más contribuyen en el fracaso de los proyectos son de tipo administrativo: “Software projects rarely fail for technical reasons; invariably, the problem is poor management. Technical problems often exist, but they are rarely decisive”. Paredes [2].

Standish señala como resultado de su estudio de proyectos fallidos que en la ejecución de proyectos de software se cometen errores por falta de soporte ejecutivo entre otras causas porque la gerencia del proyecto no logra que los usuarios finales participen activamente o porque no implementan nuevas tecnologías, es decir, por su incompetencia tecnológica, Fonseca [1].

La inexistencia o el no uso de las metodologías adecuadas para desarrollar los proyectos es una causa que atenta contra la correcta ejecución de los proyectos. Piorum [4].

Cuando no se es consciente de la importancia de acordar metodologías para evaluar la calidad es fácil caer en un deficiente control de calidad al trabajo realizado. Humphrey [8].

A continuación, se comentará sobre temas como “El cono de la incertidumbre”, “The Chaos Report” y algunos otros factores, que ciertamente son muy interesantes y que con base investigaba sobre el tema de fracasos de software, también encontraba información sobre estos temas que se relacionada entre ellos. Para continuar comentare cada uno de ellos de manera muy breve, pero con la idea de entender un poco estos temas.

El Cono de la Incertidumbre

El Cono de la Incertidumbre de Barry Boehm representa el nivel de desconocimiento que se tiene de un proyecto en las distintas etapas del mismo y su impacto en las estimaciones. Como se puede ver en el gráfico en la etapa inicial la estimación puede variar ente 60% - 160%. Es interesante además notar que la estimación siempre tiene un error asociado, incluso en etapas avanzadas del proyecto. Sólo se puede saber cuánto duró el proyecto una vez terminado.

The Chaos Report

Por otra parte, The Standish Group ofrece un estudio estadístico (conocido como "The Chaos Report") con resultados reveladores en base a miles de proyectos relevados a lo largo de varios años. Los resultados son los siguientes:

Proyectos Exitosos: sólo el 16.2% de los proyectos son exitosos, es decir, completado dentro del tiempo y presupuesto estimados y con todas las funcionalidades especificadas implementadas.

Proyectos Problemáticos: el 52.7% del total de proyecto fue completado y es operacional, pero costó más de lo estimado, demoró más de lo estimado y ofrece menos funcionalidades de las inicialmente especificadas.

Proyectos Fracasados: el 31.1% del total de los proyectos fracasaron, es decir no llegaron a completarse por cancelarse en algún punto durante el ciclo de desarrollo.

Con cifras tan alarmantes resulta de interés profundizar en cada una, para lo cual podemos segmentar por tamaño de empresa:

Sólo 9% de los proyectos en grandes empresas son exitosos, 16.2% en el caso de medianas empresas y 28% para las pequeñas. Los proyectos problemáticos, en las grandes empresas es del 61.5%, en el caso de las medianas el 46.7% y para las pequeñas 50.4%. Los proyectos fracasados representan el 29.5% en las grandes empresas, 37.1% en las medianas y 21.6% en las pequeñas.

Si se analiza cada una de estas variables resulta afectada en los proyectos problemáticos y fracasados, vemos que en promedio los proyectos cuestan un 189% con respecto al presupuestado. La duración promedio es de 222% con respecto al estimado original y con respecto al alcance, los productos ofrecen, en promedio, sólo el 61% de las funcionalidades originalmente especificadas.

Factores determinantes

El estudio del Standish Group también se extiende a relevar qué factores son claves para determinar el éxito de los proyectos, el resultado es el siguiente:

Involucramiento del usuario (15.9%)
Soporte de la alta gerencia (13.9%)
Requerimientos claros (13%)
Planificación apropiada (9.6%)
Expectativas realistas (8.2%)
Hitos más pequeños (7.7%)
Personal competente (7.2%)

Ejemplos de fracasos de software

Correo electrónico de Facebook

El correo electrónico de Facebook, un producto que decía cambiar nuestras vidas y que realmente lo único que cambiaba era la ventana del navegador donde hacíamos lo mismo que en nuestro cliente de correo. Desde luego hubo mucha expectación, incluso se decía si servicios como Gmail o Hotmail se iban a resentir, pero a la larga ya hemos visto que ni el servicio era tan bueno, ni tan completo. Una integración con su servicio de mensajería y una dirección @facebook, todo para que no abandones la red social en ningún momento. En este caso ni el producto era tan bueno, ni entrar en una guerra entre clientes de correo electrónico tan fácil ni tan buena idea.

Ping

Y ya que hablamos de redes sociales, Apple también ha tenido su intento de crear una red social propia de algún modo. Y es en el tema musical, que tan bien domina y maneja con iTunes, que planteó esta red llamada Ping. Un concepto que no pareció demasiado atractivo a los usuarios de iTunes, que no le encontraron la gracia y se activaron cuentas muy por debajo de las expectativas de Apple. Quizá el concepto era demasiado novedoso, o quizá ya existía algo similar, o quizá el exceso de redes sociales temáticas tuvo la culpa. La cuestión es que Ping no acabó de despegar y Apple plantea darle carpetazo en breve. Una buena idea que por desgracia no tuvo su tiempo, y el hecho de no dejar de promocionarla con calzador (muchos emails y Ping por todas partes) no ayudaron a popularizarla.

Logitech Revue y Google TV

Un producto que se presentó en el anterior Google I/O y que nos hizo soñar con una televisión totalmente interactiva e integrada con internet de manera perfecta. Nada más lejos de la realidad, aunque el producto es bueno y realmente funciona bien los usuarios de Google TV se han quedado un poco desamparados. O al menos eso es lo que parece, ya que parece que Google no está dando un soporte tan pleno como cabría esperar del producto, y Logitech se ha retirado definiendo su relación con Google como “uno de los errores más grandes de Logitech”. Quizá una versión prematura de un software que podría destacar más de lo que lo hace, o el problema que tiene Google para saber vender sus productos pueden ser la causa. Veremos si con los televisores con Google TV integrado acaba de despegar o definitivamente es otro fracaso.

WebOS

WebOS es un sistema operativo especialmente diseñado para superficies táctiles que creó Palm en 2009. Un sistema multitarea que usa Java, HTML5 y CSS para funcionar y que causó un gran revuelo cuando se presentó al público. Pero, aunque hubo cierta esperanza de que acabara de despegar con la compra por parte de HP de Palm, finalmente parece ser que HP no tuvo la paciencia suficiente ni las ganas de seguir invirtiendo dinero en el sistema. Y es que crear un sistema operativo nuevo no es tan fácil, y hay muchísimos factores que hay que ir puliendo poco a poco.

Conclusión

Al revisar la información de los distintos autores se encontró que son distintas las causas por las cuales los proyectos de desarrollo de software fracasan y además es notable que se observa una alta coincidencia con respecto a los fracasos en el software y se puede afirmar que estas causas siguen siendo las mismas, lo que claramente indica que al momento de desarrollar los proyectos de software no se hace una revisión rigurosa al interior de cada una de las etapas de desarrollo, lo que al final causa las mismas equivocaciones. Personalmente es interesante como las principales causas de fracaso de desarrollo de proyectos son un tipo de “guía” para tener en cuenta a la hora de darle prioridad a las actividades que hacen parte de los proyectos. Finalmente tenemos que tener muy claro y saber cuáles son las principales causas por las cuales fracasan los proyectos, además saber porque se repiten, y así evitar inconvenientes en los proyectos futuros para que se eviten cometer los mismos errores.

Referencias bibliográficas

[1] Fonseca Orlando, (2008). http://http-peru.blogspot.com/2008/03/porqu-fallan-los-proyectos-informticos.html (octubre del 2014).

[2] Paredes Arlet, (2012). https://arlethparedes.wordpress.com/2012/08/26/porque-fallan-los-proyectos-de-software/ (octubre del 2014).

[3] Markus Marcel, (2000). http://asq.org/quality-progress/2000/11/emerging-sector/failed-software-projects-not-anymore.html (octubre del 2014)

[4] Piorum Daniel, (2003). http://www.degerencia.com/articulo/%20por_que_fracasan_los_proyectos (octubre del 2014)

[5] Zabala Jesús, (2004). http://www.youtube.com/watch?v=8fRBHQEVmLE (noviembre del 2014)

[6] Gracia Joaquín, (2004). Comunicación en Equipo de Software. En: http://www.ingenierosoftware.com/equipos/comunicacion.php (octubre del 2014).

[7] Romo Ascari, (2010). http://mundobyte-x.blogspot.com/2010/03/ultima-revision-17-de-marzo-2010.html (octubre del 2014)

[8] Humphrey Watts, (2002). Winning with software an executive strategy. Boston. Pearson Education Inc.,90 p.

[9] Aisemberg Daniel, (2011). http://www.redusers.com/noticias/%C2%BFpor-que-fracasan-los-proyectos-parte-i/ (octubre del 2014)

[10] Aramburo Jorge, (2005). http://acis.org.co/ porque fracasanlosgerentesdeproyecto.ppt (octubre del 2014).

[11] Figuerola Norberto, (2010). http://es.slideshare.net/NFiguerola/principales-causas-de-fracasos-en-proyectos-it?related=2 (noviembre del 2014)

[12] Jones Carpers, (2008). Estimación de costos y administración de proyectos de software. México. MCGraw Hill, 110 p.

[13]Buonamico, D. (22 de septiembre de 2013). Camino Ágil . Obtenido de http://www.caminoagil.com/2013/09/porque-fracasan-los-proyectos-de-software-no-agiles.html

[14]Callejas, I. (02 de junio de 2012). Omicrono. Obtenido de http://omicrono.elespanol.com/2012/06/los-mayores-fracasos-de-la-historia-de-la-tecnologia-software-y-servicios/