La evaluación de productos, procesos y recursos

 Infografía 

Aspectos claves de la Reingeniería

Modificación de documentación:

Para poder volver a reconstruir un sistema de software se debe de empezar por su diseño y si un sistema cuenta con una documentación mal estructurada o mal diseñada no se podrá realizar una correcta reingeniería del sistema.

Ingeniería inversa:

Para una mejor reingeniería se necesita de una ingeniería inversa que pueden tener nombres similares, pero no es lo mismo, la ingeniería inversa es un proceso que se encarga de tratar de entender que procesos tomaron para llevar acabo el diseño de un sistema, al aplicar una ingeniería inversa se puede mejorar y facilitar el proceso de reingeniería

Cambio o modificación de código:

Otro aspecto clave para la reingeniería de software es la modificación del código ya que aquí se puede tomar el código fuente que da el sistema y realizar un totalmente nuevo e incluso de en otro lenguaje de programación que beneficie la reingeniería.

Modificación de datos:

Si los datos del sistema al que se le aplicara Mantenieniento son demasiado débiles será difícil aplicar un mantenimiento, es por eso que la mejor forma de mejorar este problema es aplicando una ingeniería inversa y modificar los datos.

La economía:

En el mundo del software los programas que se diseñan tienen que tener una cierta rentabilidad, ya que la razón por la cual fueron creados fue para mejorar los aspectos de un trabajo y generar más ganancias, de no cumplirse esto el software debe ser cambiado y ahí es donde se aplica la reingeniería

 

 

 

 

El mantenimiento del sistema.

Mapa conceptual 

¿Por qué resulta necesario realizar mantenimiento del software? ¿Qué le pasa usualmente a un software que no se mantiene?

Es necesario el mantenimiento del software ya que sin un mantenimiento adecuado el software dejaría de funcionar correctamente, es esto se debe a que el software se deteriora con el tiempo y necesita una renovación por decirlo de una manera.

 

¿Cómo es posible clasificar los tipos de mantenimiento en función de sus objetivos?

Los tipos de mantenimiento se podrá catalogar como parte del proceso de desarrollo del sistema, esto se puede hacer posible de colocar junto a los objetivos ya que los mantenimientos en realidad se podrían tomar como mejoras hasta el punto de perfeccionar el sistema.

 

¿Qué problemas plantea el mantenimiento?

El mantenimiento del sistema plantea varios problemas entre ellos esta:

Desarrollado con tecnologías y técnicas “anticuadas”: es decir que se trabajó con tecnología muy vieja y ahora es muy difícil mejorar o actualizar el sistema

Ausencia de documentación adecuada (decisiones de diseño): esto quiere decir que la documentación del sistema no se realizó de manera correcta y por ende el diseño del sistema no quedo en óptimas condiciones.

Degradación calidad del producto: el producto o sistema está demasiado deteriorado y es difícil realizar el manteamiento 

 

¿Qué necesidades conflictivas aparecen durante el mantenimiento?

Durante el manteamiento surgen muchas necesidades, muchas de ellas conflictivas como:

Falta de información necesaria para la actualización

Falta de recurso tecnológico

Falta de tiempo para realizar el trabajo.

 

¿Qué hay que hacer para que los atributos de calidad del software no se degraden durante el mantenimiento?

Para que los atributos del software no se dañen o degraden demasiado rápido con el tiempo se debe de programar un mantenimiento preventivo con una frecuencia más alta, este tipo de mantenimiento es más fácil de hacer y mas económico.  

Entrega del Sitema

 ¿Cuándo corresponde comenzar la planificación de la liberación de un sistema? ¿Por qué?

La planificación de la liberación de debe realizar cuando el proyecto ya está terminado y se han realizado todas las pruebas necesarias para poder determinar un funcionamiento correcto.

Esto se hace debido a que la liberación del sistema es prácticamente la entrega de un producto final a un cliente y no se puede hacer una entrega de un producto a medias o con errores que pueden causar problemas en el funcionamiento del sistema.

¿Qué aspectos resulta necesario atender durante la liberación?

Los aspectos a tomar en cuenta en la liberación son:

Ayudar a los usuarios a entender y usar el sistema: para que los usuarios entiendan el sistema se debe realizar el siguiente proceso:

Entrenamiento: aquí se capacitan los usuarios para que puedan usar el sistema de forma adecuada y se le pueda obtener la máxima eficiencia

Documentación: se les entrega la documentación necesaria a los usuarios para poder tener un mejor entrenamiento y se le facilite la capacitación, la documentación puede ser, manual de usuario tanto de uso como para la solución de algún problema frecuente por mala práctica y por supuesto manual de configuración correcta.

Solución de Problemas: se hace por medio de guía de mensajes de error y con posibles soluciones, también con la habilitación de una guía rápida de solución o también con una asistencia en línea.

Conversión:  se cambia un sistema viejo e ineficiente por uno nuevo y más eficiente.

Instalación: se instala el software en los equipos de modo que siempre esté disponible y funcional para el uso del cliente o usuario

 

¿Qué relevancia tiene la documentación del software para su puesta en funcionamiento?

La documentación para la implementación de un sistema tiene mucha relevancia ya que la documentación es la que siempre tiene que estar disponible para el usuario o cliente final para poder resolver alguna duda que puede tener con respecto a la funciones o utilización de alguna herramienta que no quedo muy claro en el entrenamiento, pero la documentación puede solventar la duda.

¿Por qué resulta conveniente asignar recursos para la solución de problemas durante el período inicial de la implantación de un sistema?

Este recurso es importante y conviene mucho que se asigne en el presupuesto inicial y se tenga listo para esa etapa, ya que, si durante la implementación del sistema ocurre algún imprevisto, como por ejemplo fallas en compactibilidad de software con el equipo y se tiene que llevar a revisión, el recurso económico no se toma para la solución del problema no se toma de la parte de las ganancias y no genera pérdidas en el proyecto.

 

¿Qué problemas podríamos encontrar al momento de implementar un sistema?

Los problemas más comunes pueden ser los de compactibilidad de hardware, aunque es un punto a tomar durante el desarrollo, siempre hay diferencia entre los equipos que puede resultar en un problema, otro puede ser la deficiencia del personal o la mala disposición a la utilización de nuevo sistema,

 

¿Qué hacer si el problema es «resistencia al cambio tecnológico»?

Lo más recomendable es que el cliente ya haya previsto una resistencia por parte de los usuarios del uso de herramientas tecnológicas, y de alguna manera se hayan ido preparando para el cambio, pero si el problema se transfiere en la implementación lo idea es cambiar a los usuarios que de ninguna manera pusieron de su parte para poder hacer la transición de tecnología.

Pruebas de software

 

El software a evaluar se trata de un avance de aplicación web hibrida creada con el Ionic framework se ha implementado un login por medio de métodos, donde se probará lo siguiente .

Verificación de creación de la Página login y configuración

 Captura de datos y envío de credenciales

Verificación de usuario y contraseña

 

Pruebas de funciones

Creación de página login y configuración

Se evaluará

                Creación de página

                Configuración de inicio

                Tipos de datos permite ingresar

La página de login fue creada y agregara como página de inicio de la app

 

               

                

Al tratarse del logueo lo normal es que el usuario puede ingresar caracteres alfanuméricos y la contraseña se tapada, verificamos que se haga de esa manera.

 

 

Captura de datos y envío de credenciales

Se evaluará

Captura de datos y verificación de campos llenos

Envió de datos y verificación de credenciales

Sin el ingreso del Password no se activa el botón de login, pasa de la misma manera cuando no hay usuario, es una manera muy simple de evitar el envió de campos vacíos y evita trabajo innecesario al sistema

Cuando se realiza él envió de datos se verifica en la base y se aprueba o no el logueo, si es erróneo nos aparecerá este mensaje y nos pedirá que se vuelva a intentar.

una falla en esta parte es que podemos visualizar que la contraseña es visible al usuario.

Verificación de usuario y contraseña

Se evaluará

las credenciales correctas sean aceptadas

Para verificar las credenciales el sistema manda la información a la base y verifica las credenciales

En el caso de la aplicación el usuario es admin y la contraseña es admin, al tratarse de un avance son credenciales validas que se usan para las respectivas pruebas como es el caso.

Se modificará el código para que el usuario y contraseña puedan ser visibles, aunque se sabe que esto no es permitido en las pruebas de software

Línea modificada.

Se coloca las credenciales

Al presionar login automáticamente entramos a la aplicación.

Con estas pruebas, se puede verificar que el sistema de login funciona de manera adecuada. 

 

 

Ejemplo de Prueba de los Programas

Qué tipo de pruebas a desarrollado a los sistemas que han desarrollado (Ya sea en su lugar de trabajo o a los que han desarrollado durante el desarrollo de sus carreras)

 

Prueba Unitaria

La prueba unitaria es la que más he utilizado para examinación y verificación del correcto funcionamiento es la prueba unitaria, ya que los programas o software que he desarrollado no representan una gran cantidad de información a examinar y no siento que allá resultado difícil realizar la inspección del código y de igual manera para el equipo de trabajo, se mantuvieron todos de acuerdo en usar este tipo de prueba unitaria.

En la mayoría de ocasiones se lograron obtener resultados favorables, casi siempre se encontraban fallas en la sintaxis del código, pero eran más comunes errores de lógica y ordenamiento.

Partiendo de los tipos de pruebas presentados seleccione una, que usted no ha aplicado, y explique por qué la ha seleccionado   

  

   

Prueba de Integración Big - Bang

Esta prueba me parece muy curiosa y la he seleccionado por que es una prueba que evalúa prácticamente todo el sistema completo, esto se escucha muy prometedor para el que está realizando pruebas unitarias, ya que al evaluar todo el sistema sería más fácil, pero esto tiene complicaciones como su nombre lo dice  Big - Bang, estamos hablando de una explosión de pruebas que quizá resulte muy complicado de realizar para proyectos grandes, y es más recomendado para proyectos pequeños, por esa razón llama mucho mi atención, ya que como desarrollador pequeño o independiente, poder realizar pruebas a un sistema en conjunto sería una herramienta muy útil y podría ayudar a mejorar la calidad de los productos. 

Prueba de los programa

Es importante considerar, que la etapa de prueba no es la primera instancia en que se localizan defectos también las revisiones de requerimientos y diseño contribuyen a descubrir los problemas en instancias tempranas del desarrollo.

Existen muchos tipos de pruebas: 

• prueba unitaria: es una forma de comprobar el correcto funcionamiento de una unidad de código. Por ejemplo, en diseño estructurado o en diseño funcional una función o un procedimiento, en diseño orientado a objetos una clase

• prueba de integración: Pruebas integrales o pruebas de integración son aquellas que se realizan en el ámbito del desarrollo de software una vez que se han aprobado las pruebas unitarias y lo que prueban es que todos los elementos unitarios que componen el software, funcionan juntos correctamente probándolos en grupo.

• prueba de función: es una prueba de tipo caja negra basada en la ejecución, revisión y retroalimentación de las funcionalidades previamente diseñadas para el software.

• prueba de desempeño: son las pruebas que se realizan, desde una perspectiva, para determinar lo rápido que realiza una tarea un sistema en condiciones particulares de trabajo

• prueba de aceptación: las pruebas de aceptación pertenecen a las últimas etapas previas a la liberación en firme de versiones nuevas a fin de determinar si cumplen con las necesidades y/o requerimientos de las empresas y sus usuarios.

• prueba de instalación: pueden buscar errores que se produzcan en el proceso de instalación y que afecten la percepción y la capacidad del usuario para utilizar el software instalado

Defectos y Fallas del software

Por lo general se interpreta que el software no hace lo que especifican los requerimientos. La falla puede ser el resultado de alguna de varias razones:

• La especificación puede ser errónea o puede haberse omitido algún requerimiento. 
• La especificación puede contener un requerimiento que es imposible de implementar con el software y el hardware prescrito. 
• El diseño del sistema puede contener un defecto. 
• El diseño del programa puede contener un defecto. 
• El código del programa puede estar errado. 

Una falla es el resultado de uno o más defectos en algunos aspectos del sistema.

• Muchos programadores consideran que la prueba es una comprobación de que sus programas operan correctamente. 
• La idea de demostración de exactitud es realmente lo inverso de lo que entraña la prueba. 
• Se prueba un programa para demostrar la existencia de un defecto

Tipos de Defectos 

Defectos Algorítmicos: Se produce cuando el algoritmo o la lógica de un componente no producen la salida apropiada para una entrada dada, debido a que algo esta mal en los pasos del procesamiento.

Defectos de Sintaxis: Se realiza mientras se buscan defectos algorítmicos. En este caso, se desea asegurar que se han utilizado apropiadamente las estructuras del lenguaje de programación.

Defectos de computación y de precisión: Ocurre cuando la implementación de una fórmula es errónea o no calcula el resultado con el grado requerido de exactitud. Ej.: Mezcla de flotantes y enteros resultado inesperado.

Defectos de Documentación: Es cuando la documentación no corresponde con lo que el programa realmente hace. Se tiende a confiar en la documentación al pasar de una etapa a otra y al modificar.

Defectos de sincronización o de coordinación: Al desarrollar sistemas de tiempo real, una consideración critica es la coordinación de los varios procesos que se ejecutan simultáneamente o una secuencia rigurosa definida. El defecto se produce cuando el código que coordina dichos eventos es inadecuado.

Aspecto de la prueba

¿Quién realiza las pruebas? 

Muchas veces se manifiestan dificultades para separar los sentimientos personales del proceso de prueba. Por lo tanto, a menudo se utiliza un equipo de prueba independiente. 

Es claro que nadie entrega su código para la prueba sino piensa que el código a sido realizado de acuerdo con la especificación, pero se puede estar demasiado apegado al código como para ser realmente objetivos y reconocer algunos de los defectos más sutiles. 

La visión de los objetos de prueba 

Al probar un componente, un grupo de componentes, un subsistema o un sistema, la propia visión del objeto de prueba puede afectar la forma que se lleva acabo la prueba. Si el objeto de prueba se ve desde afuera, como una “caja negra” o “caja cerrada” , cuyo contenido se desconoce, las pruebas consisten en alimentar la caja negra con entradas y anotar cuales son las salidas que se producen.

La desventaja de utilizar la prueba de caja negra en un componente, es que no se pueden seleccionar los casos de prueba más significativos porque no se tiene un conocimiento acabado del procesamiento. 

Para superar este problema el objeto de prueba puede verse como una “caja abierta”, “caja de cristal”, “caja blanca” o “caja transparente”, luego; se puede utilizar la estructura interna del objeto de prueba, para probar las diferentes maneras.

Prueba Unitaria

El proceso es similar al que se utiliza, cuando se prueba un programa asignado como tarea en la universidad: 

1. Se examina el código, leyendo minuciosamente, tratando de localizar defectos en los algoritmos, los     datos y la sintaxis. 

2. Comparar el código con las especificaciones y con el diseño hasta tener la certeza de considerar             todos los casos relevantes. 

3. Finalmente se desarrollan los casos de prueba para demostrar que las entradas se convierten                      realmente en las salidas esperadas.

El examen del código: El proceso de revisión del código es similar al de la revisión de requerimientos y diseño. Se conforma un equipo, integrado por el mismo programador y tres o cuatro expertos técnicos.

Recorridos de código: Se presenta el código y la documentación correspondiente al equipo de revisión y el equipo comenta sobre su exactitud.

Inspección de código: Este método fue presentado por Fagan (1976) en IBM. Es similar a una recorrida pero más formal. El equipo revisa el código y la documentación contra una lista de puntos de interés preparados.

Éxito de las revisiones de código: Puede sentirse incomodidad al tener a un grupo revisando el código propio

test case (Casos de Prueba): 

• Un buen test case es aquel que tiene una alta probabilidad de encontrar un defecto no descubierto, no aquel en que el programa funciona correctamente. 
• Un buen test case no es redundante, ni muy simple, ni muy complejo idealmente, el mejor de su clase. 
• Un exitoso test case es aquel que descubre un defecto no descubierto. 
• El diseño de test cases es muy difícil. 
• El Testing no puede mostrar la ausencia de defectos, sólo puede mostrar que los defectos están presentes.

Prueba de Integración

Cuando se llega a un convencimiento de los componentes individuales están trabajando correctamente y se satisfacen los objetivos, se los combina en un sistema activo. Esta integración se planea y coordina para que al producirse una falla, se pueda tener alguna idea de lo que le ha dado origen. 

Integración Ascendente (bottom – up): Cuando se usa este método, se prueba primero en forma individual cada componente al nivel más bajo de la jerarquía del sistema. Luego los próximos componentes que se prueban son lo que llaman a los ya probados.

Integración Descendente (Top – Down):  El componente principal se prueba aisladamente, después todos los componentes llamados por el componente se combinan y se prueban como una unidad mayor. Este enfoque se vuelve a aplicar hasta que todos los componentes estén incorporados. En la prueba descendente no se necesitan programas controladores. Por otro lado la escritura de los talones puede ser difícil, porque estos deben permitir probar todas las posibles condiciones.

Integración Big - Bang: Cuando todos los componentes se prueban por separado, existe la tentación de mezclarlos juntos como un sistema final y ver si funciona la primera vez.  Muchos programadores usan este enfoque para sistemas pequeños, pero no es práctico para los grandes.

Integración Intercalada:  El sistema de se como tres capas, al igual que un sandwich: en el medio la capa objetivo, los niveles por encima del objetivo y los niveles por debajo del objetivo.  Este enfoque permite utilizar el enfoque bottom - up para verificar lo correcto de los utilitarios al principio de la prueba. Por lo tanto no se necesita escribir talones para los utilitarios porque están disponibles.