QUE ES EL PPT COMUNIDAD ONLINE

Primera guía taller pruebas y mantención primera unidad

Calidad del software

En el desarrollo de software y la ingeniería de sistemas se busca la calidad.  Calidad es el cumplimiento de las expectativas puestas (por el usuario o cliente) en un servicio o producto.  Para nuestro caso el software que desarrollamos.

No es posible ver la calidad del software como un todo, pues claramente cuando valoramos un software podemos realizarlo en dos perspectivas diferentes:

• Factores externos: son propiedades que pueden ser percibidos por los usuarios del sistema, como por ejemplo la velocidad o la facilidad de uso.  
• Factores internos: son características solo percibidas por ingenieros de software que tienen acceso al proyecto (código fuente, documentación).

Corrección

Es la capacidad de los productos software para realizar con exactitud sus tareas, tal y como se definen en las especificaciones (requerimientos).

Es la más importante de todos los factores externos, pues de nada sirve un software que no hace lo que se supone debe hacer.

Robustez

Es la capacidad de los sistemas software de reaccionar apropiadamente ante condiciones excepcionales

Por lo tanto la robustez es el complemento de la corrección, pues mientras que la corrección tiene que ver con el comportamiento previsto del sistema, la robustez es con el imprevisto.

Extensibilidad

Es la facilidad de adaptar los productos de software a los cambios de especificación.  Ciertamente un software (soft = blando) debiera ser fácil de amoldar a los cambiantes requerimientos, sin embargo no basta con solo tener los códigos fuentes, sino que se debe desarrollar con expectativas a la extensibilidad.   El paradigma de la orientación a objetos es valioso para lograr este factor.

Reutilización

Es la posibilidad de los elementos de software de servir para la construcción de muchas aplicaciones diferentes.

Reutilizar es minimizar costos y esfuerzo en construir software de calidad, ya que código certificado (validado y verificado) utilizado en otras aplicaciones, nos ayudará a obtener un porcentaje de código nuevo ya con una cuota de certificación.

Compatibilidad

Es la facilidad de combinar unos elementos software con otros.  Hoy en día se hace necesario la utilización de servicios externos para la obtención de datos desde un proveedor de datos, ya sean legales, tributarios, económicos u otros. Lograr software compatible es un factor de calidad a considerar si deseamos que nuestro software no actúe como una isla independiente en un mar de tecnologías globalizadas.  Los estándares son imprescindibles. 

Eficiencia

Es la capacidad de un sistema software para exigir la menor  cantidad posible de recursos hardware, tales como tiempo de procesador, espacio ocupado de memoria interna y externa o ancho de banda utilizado en los dispositivos de comunicación.

La clave para lograr eficiencia es buscar un punto de equilibrio entre la importancia de optimizar el código y lograr el objetivo deseado dentro de los márgenes de tiempo y costo. (la eficiencia puede no tener límites en su cometido)

Portabilidad

Es la facilidad de transferir los productos software a diferentes entornos hardware y software.  ¿A quién no le gustaría que el software adquirido funcione en el PC, un TabletPC y un Smartphone?, la portabilidad agrega un atractivo al software, sin embargo los costos de producirlos pueden ser fuertemente afectados.

Facilidad de uso

Es la facilidad con la cual personas con diferentes formaciones y aptitudes pueden aprender a usar los productos software y aplicarlos a la resolución de problemas.  También cubre la facilidad de instalación, de operación y supervisión.  El diseño de interfaces hombre/máquina (HMI), debe ser un factor a considerar para la toma de requerimientos.  No suponga que conoce al usuario, realmente no lo conoce.

Funcionalidad

Es el conjunto de posibilidades que proporciona un sistema.

El problema más difícil de resolver para un jefe de proyectos es determinar: ¿Cuánta funcionalidad es suficiente?  Delimitar los requerimientos y equilibrar  costos, tiempos, posibilidades y necesidades es la clave

Oportunidad

Un sistema de software debe ser lanzado cuando los usuarios lo desean,  o antes. Siempre la queja general de los usuarios con respecto a los sistemas es: ¿Cuándo estará completamente listo? El análisis y la planificación responsable hacen posible cumplir las expectativas de tiempo.

Integridad

Son los mecanismos de los sistemas (software) necesarios para proteger sus diversos componentes (programas, datos, etc.) contra modificaciones y accesos no autorizados.

Reparación

Es el mecanismo que permite la reparación de los defectos.  Muchos sistemas de instalación actuales son capaces de reparar posibles archivos corruptos (ya que resguardan copias originales de estos).  También es fundamental incluir funcionalidades de reparación de datos en el caso de aplicaciones que operan con bases de datos.

Economía

Es la capacidad que un sistema tiene de complementarse con el presupuesto asignado o por debajo del mismo.  Principal factor para empezar a producir el software requerido.  Nadie se hará cargo de un presupuesto exagerado y generará desconfianza un presupuesto demasiado desvalorizado.

Validación y Verificación

En el desarrollo de todo sistema computacional, es importante ser capaz de asegurar que el sistema cumple con todas las especificaciones iniciales y si sus resultados son los correctos.

Es por ello que la validación y verificación deben ser procesos importantes desde los inicios tempranos del desarrollo del software (post análisis).

Formalmente Validar es la comprobación que el sistema software cumple con los requerimientos específicos de este, de forma de obtener el software correcto. De forma paralela verificar es la comprobación que el software responde adecuadamente en su ejecución.

De esta forma tenemos dos preguntas que responden a la validación y la verificación:

Validación : ¿Hicimos el software correcto?

Verificación: ¿Hicimos bien el software?

Si bien parecen similares, la validación corresponde al rol, las expectativas, la corrección y la utilidad que la solución presenta.  Mientras que verificación se refiere a la forma en que esta solución se construyó , el cual deberá responder a la altura de las expectativas.

Por consiguiente, validamos cuando comprobamos que estamos realizando el software correcto, verificamos cuando comprobamos que estamos realizando un buen software.

Para ambos casos (validar y verificar), existen técnicas de testing que nos permitirá encontrar fallas/defectos/errores en la solución.

Testing

Se entiende por testing al proceso por el cual se pretenden encontrar defectos en el software mediante diversas técnicas acordes a la naturaleza de la solución.  Una premisa del testing es que “permite encontrar defectos, más no la ausencia de estos”.

Para precisar qué es el “defecto” que se busca en el testing, podemos definir con más precisión los conceptos atribuibles a estas situaciones:

• Excepción: Situación no esperada.  Que se sale de la regla común.
• Error: es la manifestación de una excepción durante el tiempo de ejecución de la aplicación, son excepciones producto de una decisión equivocada.
• Falla: Es una propiedad de un sistema software que puede causar que el sistema se aparte del comportamiento previsto.
• Defecto: Es un error que manifiesta una falta del cumplimiento de una especificación.

En el lenguaje común, estos cuatro conceptos son intercambiables.  Sin embargo, conviene tener presente sus definiciones, para utilizar un lenguaje más preciso cuando sea necesario.

Testing de verificación

Se separan en dos tipos:

• Dinámicas.
• Estáticas.

Pruebas dinámicas

Las pruebas dinámicas se realizan sobre la marcha del sistema (etapa de interpretación, compilación o ejecución).

A su vez se distinguen tres tipos de pruebas dinámicas:

• Funcionales.
• Estructurales.
• Aleatorias

Prueba funcional: Se realiza en base a la observación de los resultados arrojados por las funciones, métodos o componentes del sistema, en base a las entradas.  Por lo tanto solo nos basamos en lo que supuestamente debería realizar cierto componente, sin interesarnos como lo realiza.

...