INGENIERIA DEL SOFTWARE
1. Determinar qué es la calidad del software
“La calidad del software es el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y las necesidades o expectativas del cliente o usuario”. (IEEE, Std. 610-1990).
“Concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentados, y con las características implícitas que se espera de todo software desarrollado profesionalmente” (Pressman, 2002)
2. Identificar los aspectos de gestión y las actividades específicas del proceso de calidad del software.
La garantía de calidad del software (SQA, Software Quality Assurance GCS, Gestión de calidad del software) es una actividad de protección que se aplica a lo largo de todo el proceso del software.
Antes del siglo veinte, la garantía de calidad era responsabilidad única de la persona que construía el producto. La primera función de control y de garantía de calidad formal fue introducida por los laboratorios Bell en 1916 y se extendió rápidamente por todo el mundo de las manufacturas. Hoy en día, cada compañía tiene un mecanismo que asegura la calidad de sus productos de hecho, durante la pasada década, se han usado ampliamente como tácticas de mercado la declaración explícita de mensajes que ponían de manifiesto la calidad ofrecida por las compañías.
La historia de la garantía de calidad en el desarrollo de software ha sido paralela a la historia en la fabricación de hardware. Durante los primeros años de información (los 50 y los 60), la calidad era responsabilidad únicamente del programador.
Durante los años 70 se introdujeron estándares de garantía de calidad para el software en los contratos militares de desarrollo de software y sean extendidos rápidamente en los desarrollos de software del mundo comercial.
La SQA forma parte de una función más amplia de garantía de calidad y engloba las siguientes actividades:
1. Un enfoque de gestión de la calidad.
2. Métodos y Herramientas.
3. Revisiones técnicas formales.
4. Documentación.
3. Establecer la importancia de la garantía de calidad del software y definir las estrategias para los planes de garantía de calidad del software.
La garantía de calidad del software (SQA), comprende un conjunto de tareas y acciones sistemáticas y planificadas que permiten asegurar la calidad del software.
A este conjunto de tareas y acciones se le denomina Actividades de SQA y comprende:
|
Actividad |
Características |
|
Plan SQA para el proyecto |
El plan debe involucrar: Evaluaciones, Auditorias, revisiones, estándares que se pueden aplicar al proyecto. Procedimientos para información, seguimiento de errores y realimentación. El grupo SQA debe además documentar la información necesaria. |
|
Actividad |
Características |
|
Proceso de software del proyecto |
Se determina el proceso y se realiza la revisión de la descripción del proceso para poder establecer los ajustes de acuerdo a las políticas de la organización. |
|
Ajustes al proceso del software |
El grupo SQA se encarga de revisar, documentar y verificar que se han hecho los ajustes al proceso. |
|
Auditoria de los productos de software |
El grupo SQA está en constante revisión del proceso software e informa periódicamente los resultados al gestor del proyecto. |
|
Documentación de productos software |
Se debe documentar todas las desviaciones encontradas a nivel: De procesos De estándares y Técnicos |
|
Registro de ajustes a requisitos e informes |
Se realiza seguimiento a los requisitos que no se ajustan y se elaboran los informes respectivos. |
El grupo SQA, además de tener a cargo el plan SQA, también debe coordinar, control y gestionar los cambios, recopilar y analizar las métricas del software.
4. Definir los fundamentos de las pruebas del software.
Las pruebas de software tienen los siguientes objetivos:
1. Descubrir un error
2. Mostrar un error no descubierto hasta ese momento
3. Descubrir un error no detectado hasta ese momento
4. Las pruebas tienen los siguientes principios:
5. Las pruebas deben tener un seguimiento hasta los requisitos del cliente.
6. Las pruebas deben planificarse antes de que empiecen.
7. Es aplicable el principio de Pareto a la prueba del software.
8. No es posible las pruebas exhaustivas
9. Las pruebas deben ser realizadas por un equipo independiente
5. Determinar que son las pruebas de caja negra, blanca, de camino básico y de estructura de control.
Prueba de caja blanca
Esta prueba se centra en la estructura interna del programa. En este caso la prueba consiste en probar todos los posibles caminos de ejecución a través de las instrucciones del código, que puedan trazarse.
Entrada Salida
Prueba del camino básico
Esta prueba permite obtener una medida de la complejidad de la lógica de un diseño procedimental y usar ésa medida como guía para la definición de un conjunto básico de camino de ejecución. Esta prueba permite que se ejecute por lo menos una vez cada sentencia del programa.
Complejidad ciclomática
Es una métrica que proporciona una medición cuantitativa de la complejidad lógica de un programa.
La complejidad ciclomática está basada en la teoría de grafos por lo que es importante recordar:
1
Nodos
Aristas
23
6 R2 4.5
Región
7 R3 8 R1
9
10 113
11
Prueba de caja negra
Consiste en estudiar la especificación de las funciones, la entrada y la salida para derivar los casos. Aquí, la prueba ideal del software consiste en probar todas las posibles entradas y salidas del programa.
|
Funciones |
Entrada Salida
Prueba de la estructura de control
Comprende las siguientes pruebas:
1. Prueba de condición
Se centra en la prueba de cada una de las condiciones del programa y tiene como propósito detectar los errores en las condiciones de un programa y los errores del programa.
2. Prueba del flujo de datos
Se centra en la selección de caminos de prueba de un programa de acuerdo con la ubicación de las definiciones y los usos de las variables del programa.
Esta prueba es útil para seleccionar caminos de prueba de un programa que contenga sentencias if o bucles anidados.
6. Identificar las pruebas de unidad, integración, validación y del sistema.
Prueba de unidad
El proceso de verificación, se centra en la menor unidad del diseño del software: el módulo.
Está orientada a caja blanca y este paso se puede llevar a cabo en paralelo para múltiples módulos. Las pruebas que se dan como parte de la prueba de unidad son:
Modulo
~~~~
Interfaz
Estructuras de datos locales
Condiciones límite
Caminos independientes
Caminos de manejo de errores
Prueba de integración del sistema
La prueba de integración es una técnica para construir la estructura del programa mientras que, al mismo tiempo, se llevan a cabo pruebas para detectar errores asociados con la interacción.
Integración descendente
Se integran los módulos moviéndose hacia abajo por la jerarquía de control, comenzando por el módulo de control principal (programa principal).
M1
M2 M3 M4
M5 M6 M7
M8
Prueba de validación
La validación se consigue cuando el software funciona de acuerdo con las expectativas razonables del cliente.
Se llevan a cabo dos pruebas:
|
Prueba Alfa |
Prueba Beta |
|
Se lleva a cabo, por un cliente, en el lugar de desarrollo. Se usa el software de forma natural con el desarrollador como observador del usuario y registrando los errores y los problemas de uso. Las pruebas Alfa se llevan a cabo en un entorno controlado. |
Se lleva a cabo por los usuarios finales del software en los lugares de trabajo de los clientes. El desarrollador no está presente en esta prueba. La prueba beta es una aplicación en vivo del software en un entorno que no puede ser controlado por el desarrollador. |
Prueba del sistema
Su propósito primordial es ejercitar profundamente el sistema, verificando que se hayan integrado adecuadamente todos los elementos del sistema y que realizan las funciones apropiadas.
· Prueba de recuperación
· Prueba de seguridad
· Prueba de resistencia (stress)
· Prueba de rendimiento
7. Identificar las métricas del modelo de análisis, del modelo de diseño, del código fuente, para pruebas y del mantenimiento.
Métricas del modelo de análisis
En esta fase, las métricas técnicas proporcionan una visión interna a la calidad del modelo de análisis. Estas métricas examinan el modelo de análisis con la intención de predecir el "tamaño" del sistema resultante; es probable que el tamaño y la complejidad del diseño estén directamente relacionados.
Dentro de las métricas del modelo de análisis tenemos:
· Métricas basadas en la Función
· Métrica Bang
Métricas del modelo de diseño
Se concentran en las características de la arquitectura del programa, con énfasis en la estructura arquitectónica y en la eficiencia de los módulos.
Estas métricas son de caja negra en el sentido que no requieren ningún conocimiento del trabajo interno de un módulo en particular del sistema.
Métricas del código fuente
Utiliza un conjunto de medidas primitivas que pueden obtenerse una vez que se han generado o estimado el código después de completar el diseño.
Estas medidas son:
n1: número de operadores diferentes que aparecen en el programa.
n2: número de operadores diferentes que aparecen en el programa.
N1: número total de veces que aparece el operador.
N2: número total de veces que aparecen el operando.
Métricas para pruebas
Las métricas para pruebas se concentran en el proceso de prueba, no en las características técnicas de las pruebas mismas. En general, los responsables de las pruebas deben fiarse en las métricas de análisis, diseño y código para que sirvan de guía en el diseño y ejecución de los casos de prueba.
A medida que se van haciendo las pruebas, tres medidas diferentes proporcionan una indicación de la compleción de las pruebas:
|
Medida de amplitud de las pruebas. |
Proporciona una indicación de cuantos requisitos se han probado del número total de ellos. Indica la compleción del plan de pruebas. |
|
Profundidad de las pruebas |
Medida del porcentaje de los caminos básicos independientes probados con relación al número total de estos caminos en el programa. Se puede calcular una estimación razonablemente exacta del número de caminos básicos sumando la complejidad ciclomática de todos los módulos del programa. |
|
Perfiles de fallos |
Se emplean para dar prioridad y categorizar los errores. La prioridad indica la severidad del problema. Las categorías de los fallos proporcionan una descripción de un error, de manera que se puedan llevar a cabo análisis estadístico de errores. |
Métricas del mantenimiento
Todas las métricas descritas pueden utilizarse para el desarrollo de nuevo software y para el mantenimiento del existente.
El estándar IEEE 982.1-1988 sugiere el índice de madurez del software (IMS) que proporciona una indicación de la estabilidad de un producto software basada en los cambios que ocurren con cada versión del producto. Con el IMS se determina la siguiente información:
El índice de madurez del software se calcula de la siguiente manera:
MT= Número de módulos en la versión
actualFc = Número de módulos en la versión actual que se han cambiado
Fa= Número de módulos en la versión actual que se han añadido
Fe= Número de módulos en la versión actual que se han eliminado
8. Definir los fundamentos de la reutilización del software.
La reutilización del software es una de las soluciones más importantes para el desafío de construir sistemas complejos.
Una reutilización efectiva requiere:
Repositorios de fácil acceso a componentes de alta calidad
Estándares en tecnología, documentación y procesos de software
Herramientas para encontrar, entender, evaluar, adaptar e integrar los componentes reutilizables
Apoyo efectivo de la comunidad de desarrolladores que está reutilizando cada biblioteca o librería
Esta categoría en tigris.org alberga proyectos de código abierto que están produciendo componentes de software reutilizables.
Dentro de esta categoría se pueden mencionar las siguientes herramientas:
Herramienta Uso Disponible en:
gef Framework para edición gráfica en Java https://gef.tigris.org/
axion Base de datos JAVA https://axion.tigris.org/
style CSS para aplicaciones web https://style.tigris.org/
SSTree Arbol Super Simple Java Script https://sstree.tigris.org/
9. Determinar las dificultades para la reutilización
10. Determinar algunas sugerencias para establecer un enfoque de la reutilización.
INGENIERIA DEL SOFTWARE
Taller 3
Definir y contestar los siguientes ítems haciendo uso de las distintas herramientas informáticas en el desarrollo de Mapas conceptuales, o mentefatos.
Nota:
En el módulo encontrara toda la información puede consultar en internet, para el día 8 de noviembre plazo máximo para entrega de primer avance del blog como mínimo deben tener 3 actividades completas con esta. Las personas que no asistieron a la actividad del día 03 serán valoradas en este último taller sobre 4.0
1. Determinar qué es la calidad del software
“La calidad del software es el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y las necesidades o expectativas del cliente o usuario”. (IEEE, Std. 610-1990).
“Concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentados, y con las características implícitas que se espera de todo software desarrollado profesionalmente” (Pressman, 2002)
2. Identificar los aspectos de gestión y las actividades específicas del proceso de calidad del software.
La garantía de calidad del software (SQA, Software Quality Assurance GCS, Gestión de calidad del software) es una actividad de protección que se aplica a lo largo de todo el proceso del software.
Antes del siglo veinte, la garantía de calidad era responsabilidad única de la persona que construía el producto. La primera función de control y de garantía de calidad formal fue introducida por los laboratorios Bell en 1916 y se extendió rápidamente por todo el mundo de las manufacturas. Hoy en día, cada compañía tiene un mecanismo que asegura la calidad de sus productos de hecho, durante la pasada década, se han usado ampliamente como tácticas de mercado la declaración explícita de mensajes que ponían de manifiesto la calidad ofrecida por las compañías.
La historia de la garantía de calidad en el desarrollo de software ha sido paralela a la historia en la fabricación de hardware. Durante los primeros años de información (los 50 y los 60), la calidad era responsabilidad únicamente del programador.
Durante los años 70 se introdujeron estándares de garantía de calidad para el software en los contratos militares de desarrollo de software y sean extendidos rápidamente en los desarrollos de software del mundo comercial.
La SQA forma parte de una función más amplia de garantía de calidad y engloba las siguientes actividades:
1. Un enfoque de gestión de la calidad.
2. Métodos y Herramientas.
3. Revisiones técnicas formales.
4. Documentación.
3. Establecer la importancia de la garantía de calidad del software y definir las estrategias para los planes de garantía de calidad del software.
La garantía de calidad del software (SQA), comprende un conjunto de tareas y acciones sistemáticas y planificadas que permiten asegurar la calidad del software.
A este conjunto de tareas y acciones se le denomina Actividades de SQA y comprende:
|
Actividad |
Características |
|
Plan SQA para el proyecto |
El plan debe involucrar: Evaluaciones, Auditorias, revisiones, estándares que se pueden aplicar al proyecto. Procedimientos para información, seguimiento de errores y realimentación. El grupo SQA debe además documentar la información necesaria. |
|
Actividad |
Características |
|
Proceso de software del proyecto |
Se determina el proceso y se realiza la revisión de la descripción del proceso para poder establecer los ajustes de acuerdo a las políticas de la organización. |
|
Ajustes al proceso del software |
El grupo SQA se encarga de revisar, documentar y verificar que se han hecho los ajustes al proceso. |
|
Auditoria de los productos de software |
El grupo SQA está en constante revisión del proceso software e informa periódicamente los resultados al gestor del proyecto. |
|
Documentación de productos software |
Se debe documentar todas las desviaciones encontradas a nivel: De procesos De estándares y Técnicos |
|
Registro de ajustes a requisitos e informes |
Se realiza seguimiento a los requisitos que no se ajustan y se elaboran los informes respectivos. |
El grupo SQA, además de tener a cargo el plan SQA, también debe coordinar, control y gestionar los cambios, recopilar y analizar las métricas del software.
4. Definir los fundamentos de las pruebas del software.
Las pruebas de software tienen los siguientes objetivos:
1. Descubrir un error
2. Mostrar un error no descubierto hasta ese momento
3. Descubrir un error no detectado hasta ese momento
4. Las pruebas tienen los siguientes principios:
5. Las pruebas deben tener un seguimiento hasta los requisitos del cliente.
6. Las pruebas deben planificarse antes de que empiecen.
7. Es aplicable el principio de Pareto a la prueba del software.
8. No es posible las pruebas exhaustivas
9. Las pruebas deben ser realizadas por un equipo independiente
5. Determinar que son las pruebas de caja negra, blanca, de camino básico y de estructura de control.
Prueba de caja blanca
Esta prueba se centra en la estructura interna del programa. En este caso la prueba consiste en probar todos los posibles caminos de ejecución a través de las instrucciones del código, que puedan trazarse.
Entrada Salida
Prueba del camino básico
Esta prueba permite obtener una medida de la complejidad de la lógica de un diseño procedimental y usar ésa medida como guía para la definición de un conjunto básico de camino de ejecución. Esta prueba permite que se ejecute por lo menos una vez cada sentencia del programa.
Complejidad ciclomática
Es una métrica que proporciona una medición cuantitativa de la complejidad lógica de un programa.
La complejidad ciclomática está basada en la teoría de grafos por lo que es importante recordar:
1
Nodos
Aristas
23
6 R2 4.5
Región
7 R3 8 R1
9
10 113
11
Prueba de caja negra
Consiste en estudiar la especificación de las funciones, la entrada y la salida para derivar los casos. Aquí, la prueba ideal del software consiste en probar todas las posibles entradas y salidas del programa.
|
Funciones |
Entrada Salida
Prueba de la estructura de control
Comprende las siguientes pruebas:
1. Prueba de condición
Se centra en la prueba de cada una de las condiciones del programa y tiene como propósito detectar los errores en las condiciones de un programa y los errores del programa.
2. Prueba del flujo de datos
Se centra en la selección de caminos de prueba de un programa de acuerdo con la ubicación de las definiciones y los usos de las variables del programa.
Esta prueba es útil para seleccionar caminos de prueba de un programa que contenga sentencias if o bucles anidados.
6. Identificar las pruebas de unidad, integración, validación y del sistema.
Prueba de unidad
El proceso de verificación, se centra en la menor unidad del diseño del software: el módulo.
Está orientada a caja blanca y este paso se puede llevar a cabo en paralelo para múltiples módulos. Las pruebas que se dan como parte de la prueba de unidad son:
Modulo
~~~~
Interfaz
Estructuras de datos locales
Condiciones límite
Caminos independientes
Caminos de manejo de errores
Prueba de integración del sistema
La prueba de integración es una técnica para construir la estructura del programa mientras que, al mismo tiempo, se llevan a cabo pruebas para detectar errores asociados con la interacción.
Integración descendente
Se integran los módulos moviéndose hacia abajo por la jerarquía de control, comenzando por el módulo de control principal (programa principal).
M1
M2 M3 M4
M5 M6 M7
M8
Prueba de validación
La validación se consigue cuando el software funciona de acuerdo con las expectativas razonables del cliente.
Se llevan a cabo dos pruebas:
|
Prueba Alfa |
Prueba Beta |
|
Se lleva a cabo, por un cliente, en el lugar de desarrollo. Se usa el software de forma natural con el desarrollador como observador del usuario y registrando los errores y los problemas de uso. Las pruebas Alfa se llevan a cabo en un entorno controlado. |
Se lleva a cabo por los usuarios finales del software en los lugares de trabajo de los clientes. El desarrollador no está presente en esta prueba. La prueba beta es una aplicación en vivo del software en un entorno que no puede ser controlado por el desarrollador. |
Prueba del sistema
Su propósito primordial es ejercitar profundamente el sistema, verificando que se hayan integrado adecuadamente todos los elementos del sistema y que realizan las funciones apropiadas.
· Prueba de recuperación
· Prueba de seguridad
· Prueba de resistencia (stress)
· Prueba de rendimiento
7. Identificar las métricas del modelo de análisis, del modelo de diseño, del código fuente, para pruebas y del mantenimiento.
Métricas del modelo de análisis
En esta fase, las métricas técnicas proporcionan una visión interna a la calidad del modelo de análisis. Estas métricas examinan el modelo de análisis con la intención de predecir el "tamaño" del sistema resultante; es probable que el tamaño y la complejidad del diseño estén directamente relacionados.
Dentro de las métricas del modelo de análisis tenemos:
· Métricas basadas en la Función
· Métrica Bang
Métricas del modelo de diseño
Se concentran en las características de la arquitectura del programa, con énfasis en la estructura arquitectónica y en la eficiencia de los módulos.
Estas métricas son de caja negra en el sentido que no requieren ningún conocimiento del trabajo interno de un módulo en particular del sistema.
Métricas del código fuente
Utiliza un conjunto de medidas primitivas que pueden obtenerse una vez que se han generado o estimado el código después de completar el diseño.
Estas medidas son:
n1: número de operadores diferentes que aparecen en el programa.
n2: número de operadores diferentes que aparecen en el programa.
N1: número total de veces que aparece el operador.
N2: número total de veces que aparecen el operando.
Métricas para pruebas
Las métricas para pruebas se concentran en el proceso de prueba, no en las características técnicas de las pruebas mismas. En general, los responsables de las pruebas deben fiarse en las métricas de análisis, diseño y código para que sirvan de guía en el diseño y ejecución de los casos de prueba.
A medida que se van haciendo las pruebas, tres medidas diferentes proporcionan una indicación de la compleción de las pruebas:
|
Medida de amplitud de las pruebas. |
Proporciona una indicación de cuantos requisitos se han probado del número total de ellos. Indica la compleción del plan de pruebas. |
|
Profundidad de las pruebas |
Medida del porcentaje de los caminos básicos independientes probados con relación al número total de estos caminos en el programa. Se puede calcular una estimación razonablemente exacta del número de caminos básicos sumando la complejidad ciclomática de todos los módulos del programa. |
|
Perfiles de fallos |
Se emplean para dar prioridad y categorizar los errores. La prioridad indica la severidad del problema. Las categorías de los fallos proporcionan una descripción de un error, de manera que se puedan llevar a cabo análisis estadístico de errores. |
Métricas del mantenimiento
Todas las métricas descritas pueden utilizarse para el desarrollo de nuevo software y para el mantenimiento del existente.
El estándar IEEE 982.1-1988 sugiere el índice de madurez del software (IMS) que proporciona una indicación de la estabilidad de un producto software basada en los cambios que ocurren con cada versión del producto. Con el IMS se determina la siguiente información:
El índice de madurez del software se calcula de la siguiente manera:
MT= Número de módulos en la versión
actualFc = Número de módulos en la versión actual que se han cambiado
Fa= Número de módulos en la versión actual que se han añadido
Fe= Número de módulos en la versión actual que se han eliminado
8. Definir los fundamentos de la reutilización del software.
La reutilización del software es una de las soluciones más importantes para el desafío de construir sistemas complejos.
Una reutilización efectiva requiere:
Repositorios de fácil acceso a componentes de alta calidad
Estándares en tecnología, documentación y procesos de software
Herramientas para encontrar, entender, evaluar, adaptar e integrar los componentes reutilizables
Apoyo efectivo de la comunidad de desarrolladores que está reutilizando cada biblioteca o librería
Esta categoría en tigris.org alberga proyectos de código abierto que están produciendo componentes de software reutilizables.
Dentro de esta categoría se pueden mencionar las siguientes herramientas:
Herramienta Uso Disponible en:
gef Framework para edición gráfica en Java https://gef.tigris.org/
axion Base de datos JAVA https://axion.tigris.org/
style CSS para aplicaciones web https://style.tigris.org/
SSTree Arbol Super Simple Java Script https://sstree.tigris.org/
9. Determinar las dificultades para la reutilización
10. Determinar algunas sugerencias para establecer un enfoque de la reutilización.
INGENIERIA DEL SOFTWARE
Taller 3
Definir y contestar los siguientes ítems haciendo uso de las distintas herramientas informáticas en el desarrollo de Mapas conceptuales, o mentefatos.
Nota:
En el módulo encontrara toda la información puede consultar en internet, para el día 8 de noviembre plazo máximo para entrega de primer avance del blog como mínimo deben tener 3 actividades completas con esta. Las personas que no asistieron a la actividad del día 03 serán valoradas en este último taller sobre 4.0
1. Determinar qué es la calidad del software
“La calidad del software es el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y las necesidades o expectativas del cliente o usuario”. (IEEE, Std. 610-1990).
“Concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentados, y con las características implícitas que se espera de todo software desarrollado profesionalmente” (Pressman, 2002)
2. Identificar los aspectos de gestión y las actividades específicas del proceso de calidad del software.
La garantía de calidad del software (SQA, Software Quality Assurance GCS, Gestión de calidad del software) es una actividad de protección que se aplica a lo largo de todo el proceso del software.
Antes del siglo veinte, la garantía de calidad era responsabilidad única de la persona que construía el producto. La primera función de control y de garantía de calidad formal fue introducida por los laboratorios Bell en 1916 y se extendió rápidamente por todo el mundo de las manufacturas. Hoy en día, cada compañía tiene un mecanismo que asegura la calidad de sus productos de hecho, durante la pasada década, se han usado ampliamente como tácticas de mercado la declaración explícita de mensajes que ponían de manifiesto la calidad ofrecida por las compañías.
La historia de la garantía de calidad en el desarrollo de software ha sido paralela a la historia en la fabricación de hardware. Durante los primeros años de información (los 50 y los 60), la calidad era responsabilidad únicamente del programador.
Durante los años 70 se introdujeron estándares de garantía de calidad para el software en los contratos militares de desarrollo de software y sean extendidos rápidamente en los desarrollos de software del mundo comercial.
La SQA forma parte de una función más amplia de garantía de calidad y engloba las siguientes actividades:
1. Un enfoque de gestión de la calidad.
2. Métodos y Herramientas.
3. Revisiones técnicas formales.
4. Documentación.
3. Establecer la importancia de la garantía de calidad del software y definir las estrategias para los planes de garantía de calidad del software.
La garantía de calidad del software (SQA), comprende un conjunto de tareas y acciones sistemáticas y planificadas que permiten asegurar la calidad del software.
A este conjunto de tareas y acciones se le denomina Actividades de SQA y comprende:
|
Actividad |
Características |
|
Plan SQA para el proyecto |
El plan debe involucrar: Evaluaciones, Auditorias, revisiones, estándares que se pueden aplicar al proyecto. Procedimientos para información, seguimiento de errores y realimentación. El grupo SQA debe además documentar la información necesaria. |
|
Actividad |
Características |
|
Proceso de software del proyecto |
Se determina el proceso y se realiza la revisión de la descripción del proceso para poder establecer los ajustes de acuerdo a las políticas de la organización. |
|
Ajustes al proceso del software |
El grupo SQA se encarga de revisar, documentar y verificar que se han hecho los ajustes al proceso. |
|
Auditoria de los productos de software |
El grupo SQA está en constante revisión del proceso software e informa periódicamente los resultados al gestor del proyecto. |
|
Documentación de productos software |
Se debe documentar todas las desviaciones encontradas a nivel: De procesos De estándares y Técnicos |
|
Registro de ajustes a requisitos e informes |
Se realiza seguimiento a los requisitos que no se ajustan y se elaboran los informes respectivos. |
El grupo SQA, además de tener a cargo el plan SQA, también debe coordinar, control y gestionar los cambios, recopilar y analizar las métricas del software.
4. Definir los fundamentos de las pruebas del software.
Las pruebas de software tienen los siguientes objetivos:
1. Descubrir un error
2. Mostrar un error no descubierto hasta ese momento
3. Descubrir un error no detectado hasta ese momento
4. Las pruebas tienen los siguientes principios:
5. Las pruebas deben tener un seguimiento hasta los requisitos del cliente.
6. Las pruebas deben planificarse antes de que empiecen.
7. Es aplicable el principio de Pareto a la prueba del software.
8. No es posible las pruebas exhaustivas
9. Las pruebas deben ser realizadas por un equipo independiente
5. Determinar que son las pruebas de caja negra, blanca, de camino básico y de estructura de control.
Prueba de caja blanca
Esta prueba se centra en la estructura interna del programa. En este caso la prueba consiste en probar todos los posibles caminos de ejecución a través de las instrucciones del código, que puedan trazarse.
Entrada Salida
Prueba del camino básico
Esta prueba permite obtener una medida de la complejidad de la lógica de un diseño procedimental y usar ésa medida como guía para la definición de un conjunto básico de camino de ejecución. Esta prueba permite que se ejecute por lo menos una vez cada sentencia del programa.
Complejidad ciclomática
Es una métrica que proporciona una medición cuantitativa de la complejidad lógica de un programa.
La complejidad ciclomática está basada en la teoría de grafos por lo que es importante recordar:
1
Nodos
Aristas
23
6 R2 4.5
Región
7 R3 8 R1
9
10 113
11
Prueba de caja negra
Consiste en estudiar la especificación de las funciones, la entrada y la salida para derivar los casos. Aquí, la prueba ideal del software consiste en probar todas las posibles entradas y salidas del programa.
|
Funciones |
Entrada Salida
Prueba de la estructura de control
Comprende las siguientes pruebas:
1. Prueba de condición
Se centra en la prueba de cada una de las condiciones del programa y tiene como propósito detectar los errores en las condiciones de un programa y los errores del programa.
2. Prueba del flujo de datos
Se centra en la selección de caminos de prueba de un programa de acuerdo con la ubicación de las definiciones y los usos de las variables del programa.
Esta prueba es útil para seleccionar caminos de prueba de un programa que contenga sentencias if o bucles anidados.
6. Identificar las pruebas de unidad, integración, validación y del sistema.
Prueba de unidad
El proceso de verificación, se centra en la menor unidad del diseño del software: el módulo.
Está orientada a caja blanca y este paso se puede llevar a cabo en paralelo para múltiples módulos. Las pruebas que se dan como parte de la prueba de unidad son:
Modulo
~~~~
Interfaz
Estructuras de datos locales
Condiciones límite
Caminos independientes
Caminos de manejo de errores
Prueba de integración del sistema
La prueba de integración es una técnica para construir la estructura del programa mientras que, al mismo tiempo, se llevan a cabo pruebas para detectar errores asociados con la interacción.
Integración descendente
Se integran los módulos moviéndose hacia abajo por la jerarquía de control, comenzando por el módulo de control principal (programa principal).
M1
M2 M3 M4
M5 M6 M7
M8
Prueba de validación
La validación se consigue cuando el software funciona de acuerdo con las expectativas razonables del cliente.
Se llevan a cabo dos pruebas:
|
Prueba Alfa |
Prueba Beta |
|
Se lleva a cabo, por un cliente, en el lugar de desarrollo. Se usa el software de forma natural con el desarrollador como observador del usuario y registrando los errores y los problemas de uso. Las pruebas Alfa se llevan a cabo en un entorno controlado. |
Se lleva a cabo por los usuarios finales del software en los lugares de trabajo de los clientes. El desarrollador no está presente en esta prueba. La prueba beta es una aplicación en vivo del software en un entorno que no puede ser controlado por el desarrollador. |
Prueba del sistema
Su propósito primordial es ejercitar profundamente el sistema, verificando que se hayan integrado adecuadamente todos los elementos del sistema y que realizan las funciones apropiadas.
· Prueba de recuperación
· Prueba de seguridad
· Prueba de resistencia (stress)
· Prueba de rendimiento
7. Identificar las métricas del modelo de análisis, del modelo de diseño, del código fuente, para pruebas y del mantenimiento.
Métricas del modelo de análisis
En esta fase, las métricas técnicas proporcionan una visión interna a la calidad del modelo de análisis. Estas métricas examinan el modelo de análisis con la intención de predecir el "tamaño" del sistema resultante; es probable que el tamaño y la complejidad del diseño estén directamente relacionados.
Dentro de las métricas del modelo de análisis tenemos:
· Métricas basadas en la Función
· Métrica Bang
Métricas del modelo de diseño
Se concentran en las características de la arquitectura del programa, con énfasis en la estructura arquitectónica y en la eficiencia de los módulos.
Estas métricas son de caja negra en el sentido que no requieren ningún conocimiento del trabajo interno de un módulo en particular del sistema.
Métricas del código fuente
Utiliza un conjunto de medidas primitivas que pueden obtenerse una vez que se han generado o estimado el código después de completar el diseño.
Estas medidas son:
n1: número de operadores diferentes que aparecen en el programa.
n2: número de operadores diferentes que aparecen en el programa.
N1: número total de veces que aparece el operador.
N2: número total de veces que aparecen el operando.
Métricas para pruebas
Las métricas para pruebas se concentran en el proceso de prueba, no en las características técnicas de las pruebas mismas. En general, los responsables de las pruebas deben fiarse en las métricas de análisis, diseño y código para que sirvan de guía en el diseño y ejecución de los casos de prueba.
A medida que se van haciendo las pruebas, tres medidas diferentes proporcionan una indicación de la compleción de las pruebas:
|
Medida de amplitud de las pruebas. |
Proporciona una indicación de cuantos requisitos se han probado del número total de ellos. Indica la compleción del plan de pruebas. |
|
Profundidad de las pruebas |
Medida del porcentaje de los caminos básicos independientes probados con relación al número total de estos caminos en el programa. Se puede calcular una estimación razonablemente exacta del número de caminos básicos sumando la complejidad ciclomática de todos los módulos del programa. |
|
Perfiles de fallos |
Se emplean para dar prioridad y categorizar los errores. La prioridad indica la severidad del problema. Las categorías de los fallos proporcionan una descripción de un error, de manera que se puedan llevar a cabo análisis estadístico de errores. |
Métricas del mantenimiento
Todas las métricas descritas pueden utilizarse para el desarrollo de nuevo software y para el mantenimiento del existente.
El estándar IEEE 982.1-1988 sugiere el índice de madurez del software (IMS) que proporciona una indicación de la estabilidad de un producto software basada en los cambios que ocurren con cada versión del producto. Con el IMS se determina la siguiente información:
El índice de madurez del software se calcula de la siguiente manera:
MT= Número de módulos en la versión
actualFc = Número de módulos en la versión actual que se han cambiado
Fa= Número de módulos en la versión actual que se han añadido
Fe= Número de módulos en la versión actual que se han eliminado
8. Definir los fundamentos de la reutilización del software.
La reutilización del software es una de las soluciones más importantes para el desafío de construir sistemas complejos.
Una reutilización efectiva requiere:
Repositorios de fácil acceso a componentes de alta calidad
Estándares en tecnología, documentación y procesos de software
Herramientas para encontrar, entender, evaluar, adaptar e integrar los componentes reutilizables
Apoyo efectivo de la comunidad de desarrolladores que está reutilizando cada biblioteca o librería
Esta categoría en tigris.org alberga proyectos de código abierto que están produciendo componentes de software reutilizables.
Dentro de esta categoría se pueden mencionar las siguientes herramientas:
Herramienta Uso Disponible en:
gef Framework para edición gráfica en Java https://gef.tigris.org/
axion Base de datos JAVA https://axion.tigris.org/
style CSS para aplicaciones web https://style.tigris.org/
SSTree Arbol Super Simple Java Script https://sstree.tigris.org/
9. Determinar las dificultades para la reutilización
10. Determinar algunas sugerencias para establecer un enfoque de la reutilización.
INGENIERIA DEL SOFTWARE
Taller 3
Definir y contestar los siguientes ítems haciendo uso de las distintas herramientas informáticas en el desarrollo de Mapas conceptuales, o mentefatos.
Nota:
En el módulo encontrara toda la información puede consultar en internet, para el día 8 de noviembre plazo máximo para entrega de primer avance del blog como mínimo deben tener 3 actividades completas con esta. Las personas que no asistieron a la actividad del día 03 serán valoradas en este último taller sobre 4.0
1. Determinar qué es la calidad del software
“La calidad del software es el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y las necesidades o expectativas del cliente o usuario”. (IEEE, Std. 610-1990).
“Concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentados, y con las características implícitas que se espera de todo software desarrollado profesionalmente” (Pressman, 2002)
2. Identificar los aspectos de gestión y las actividades específicas del proceso de calidad del software.
La garantía de calidad del software (SQA, Software Quality Assurance GCS, Gestión de calidad del software) es una actividad de protección que se aplica a lo largo de todo el proceso del software.
Antes del siglo veinte, la garantía de calidad era responsabilidad única de la persona que construía el producto. La primera función de control y de garantía de calidad formal fue introducida por los laboratorios Bell en 1916 y se extendió rápidamente por todo el mundo de las manufacturas. Hoy en día, cada compañía tiene un mecanismo que asegura la calidad de sus productos de hecho, durante la pasada década, se han usado ampliamente como tácticas de mercado la declaración explícita de mensajes que ponían de manifiesto la calidad ofrecida por las compañías.
La historia de la garantía de calidad en el desarrollo de software ha sido paralela a la historia en la fabricación de hardware. Durante los primeros años de información (los 50 y los 60), la calidad era responsabilidad únicamente del programador.
Durante los años 70 se introdujeron estándares de garantía de calidad para el software en los contratos militares de desarrollo de software y sean extendidos rápidamente en los desarrollos de software del mundo comercial.
La SQA forma parte de una función más amplia de garantía de calidad y engloba las siguientes actividades:
1. Un enfoque de gestión de la calidad.
2. Métodos y Herramientas.
3. Revisiones técnicas formales.
4. Documentación.
3. Establecer la importancia de la garantía de calidad del software y definir las estrategias para los planes de garantía de calidad del software.
La garantía de calidad del software (SQA), comprende un conjunto de tareas y acciones sistemáticas y planificadas que permiten asegurar la calidad del software.
A este conjunto de tareas y acciones se le denomina Actividades de SQA y comprende:
|
Actividad |
Características |
|
Plan SQA para el proyecto |
El plan debe involucrar: Evaluaciones, Auditorias, revisiones, estándares que se pueden aplicar al proyecto. Procedimientos para información, seguimiento de errores y realimentación. El grupo SQA debe además documentar la información necesaria. |
|
Actividad |
Características |
|
Proceso de software del proyecto |
Se determina el proceso y se realiza la revisión de la descripción del proceso para poder establecer los ajustes de acuerdo a las políticas de la organización. |
|
Ajustes al proceso del software |
El grupo SQA se encarga de revisar, documentar y verificar que se han hecho los ajustes al proceso. |
|
Auditoria de los productos de software |
El grupo SQA está en constante revisión del proceso software e informa periódicamente los resultados al gestor del proyecto. |
|
Documentación de productos software |
Se debe documentar todas las desviaciones encontradas a nivel: De procesos De estándares y Técnicos |
|
Registro de ajustes a requisitos e informes |
Se realiza seguimiento a los requisitos que no se ajustan y se elaboran los informes respectivos. |
El grupo SQA, además de tener a cargo el plan SQA, también debe coordinar, control y gestionar los cambios, recopilar y analizar las métricas del software.
4. Definir los fundamentos de las pruebas del software.
Las pruebas de software tienen los siguientes objetivos:
1. Descubrir un error
2. Mostrar un error no descubierto hasta ese momento
3. Descubrir un error no detectado hasta ese momento
4. Las pruebas tienen los siguientes principios:
5. Las pruebas deben tener un seguimiento hasta los requisitos del cliente.
6. Las pruebas deben planificarse antes de que empiecen.
7. Es aplicable el principio de Pareto a la prueba del software.
8. No es posible las pruebas exhaustivas
9. Las pruebas deben ser realizadas por un equipo independiente
5. Determinar que son las pruebas de caja negra, blanca, de camino básico y de estructura de control.
Prueba de caja blanca
Esta prueba se centra en la estructura interna del programa. En este caso la prueba consiste en probar todos los posibles caminos de ejecución a través de las instrucciones del código, que puedan trazarse.
Entrada Salida
Prueba del camino básico
Esta prueba permite obtener una medida de la complejidad de la lógica de un diseño procedimental y usar ésa medida como guía para la definición de un conjunto básico de camino de ejecución. Esta prueba permite que se ejecute por lo menos una vez cada sentencia del programa.
Complejidad ciclomática
Es una métrica que proporciona una medición cuantitativa de la complejidad lógica de un programa.
La complejidad ciclomática está basada en la teoría de grafos por lo que es importante recordar:
1
Nodos
Aristas
23
6 R2 4.5
Región
7 R3 8 R1
9
10 113
11
Prueba de caja negra
Consiste en estudiar la especificación de las funciones, la entrada y la salida para derivar los casos. Aquí, la prueba ideal del software consiste en probar todas las posibles entradas y salidas del programa.
|
Funciones |
Entrada Salida
Prueba de la estructura de control
Comprende las siguientes pruebas:
1. Prueba de condición
Se centra en la prueba de cada una de las condiciones del programa y tiene como propósito detectar los errores en las condiciones de un programa y los errores del programa.
2. Prueba del flujo de datos
Se centra en la selección de caminos de prueba de un programa de acuerdo con la ubicación de las definiciones y los usos de las variables del programa.
Esta prueba es útil para seleccionar caminos de prueba de un programa que contenga sentencias if o bucles anidados.
6. Identificar las pruebas de unidad, integración, validación y del sistema.
Prueba de unidad
El proceso de verificación, se centra en la menor unidad del diseño del software: el módulo.
Está orientada a caja blanca y este paso se puede llevar a cabo en paralelo para múltiples módulos. Las pruebas que se dan como parte de la prueba de unidad son:
Modulo
~~~~
Interfaz
Estructuras de datos locales
Condiciones límite
Caminos independientes
Caminos de manejo de errores
Prueba de integración del sistema
La prueba de integración es una técnica para construir la estructura del programa mientras que, al mismo tiempo, se llevan a cabo pruebas para detectar errores asociados con la interacción.
Integración descendente
Se integran los módulos moviéndose hacia abajo por la jerarquía de control, comenzando por el módulo de control principal (programa principal).
M1
M2 M3 M4
M5 M6 M7
M8
Prueba de validación
La validación se consigue cuando el software funciona de acuerdo con las expectativas razonables del cliente.
Se llevan a cabo dos pruebas:
|
Prueba Alfa |
Prueba Beta |
|
Se lleva a cabo, por un cliente, en el lugar de desarrollo. Se usa el software de forma natural con el desarrollador como observador del usuario y registrando los errores y los problemas de uso. Las pruebas Alfa se llevan a cabo en un entorno controlado. |
Se lleva a cabo por los usuarios finales del software en los lugares de trabajo de los clientes. El desarrollador no está presente en esta prueba. La prueba beta es una aplicación en vivo del software en un entorno que no puede ser controlado por el desarrollador. |
Prueba del sistema
Su propósito primordial es ejercitar profundamente el sistema, verificando que se hayan integrado adecuadamente todos los elementos del sistema y que realizan las funciones apropiadas.
· Prueba de recuperación
· Prueba de seguridad
· Prueba de resistencia (stress)
· Prueba de rendimiento
7. Identificar las métricas del modelo de análisis, del modelo de diseño, del código fuente, para pruebas y del mantenimiento.
Métricas del modelo de análisis
En esta fase, las métricas técnicas proporcionan una visión interna a la calidad del modelo de análisis. Estas métricas examinan el modelo de análisis con la intención de predecir el "tamaño" del sistema resultante; es probable que el tamaño y la complejidad del diseño estén directamente relacionados.
Dentro de las métricas del modelo de análisis tenemos:
· Métricas basadas en la Función
· Métrica Bang
Métricas del modelo de diseño
Se concentran en las características de la arquitectura del programa, con énfasis en la estructura arquitectónica y en la eficiencia de los módulos.
Estas métricas son de caja negra en el sentido que no requieren ningún conocimiento del trabajo interno de un módulo en particular del sistema.
Métricas del código fuente
Utiliza un conjunto de medidas primitivas que pueden obtenerse una vez que se han generado o estimado el código después de completar el diseño.
Estas medidas son:
n1: número de operadores diferentes que aparecen en el programa.
n2: número de operadores diferentes que aparecen en el programa.
N1: número total de veces que aparece el operador.
N2: número total de veces que aparecen el operando.
Métricas para pruebas
Las métricas para pruebas se concentran en el proceso de prueba, no en las características técnicas de las pruebas mismas. En general, los responsables de las pruebas deben fiarse en las métricas de análisis, diseño y código para que sirvan de guía en el diseño y ejecución de los casos de prueba.
A medida que se van haciendo las pruebas, tres medidas diferentes proporcionan una indicación de la compleción de las pruebas:
|
Medida de amplitud de las pruebas. |
Proporciona una indicación de cuantos requisitos se han probado del número total de ellos. Indica la compleción del plan de pruebas. |
|
Profundidad de las pruebas |
Medida del porcentaje de los caminos básicos independientes probados con relación al número total de estos caminos en el programa. Se puede calcular una estimación razonablemente exacta del número de caminos básicos sumando la complejidad ciclomática de todos los módulos del programa. |
|
Perfiles de fallos |
Se emplean para dar prioridad y categorizar los errores. La prioridad indica la severidad del problema. Las categorías de los fallos proporcionan una descripción de un error, de manera que se puedan llevar a cabo análisis estadístico de errores. |
Métricas del mantenimiento
Todas las métricas descritas pueden utilizarse para el desarrollo de nuevo software y para el mantenimiento del existente.
El estándar IEEE 982.1-1988 sugiere el índice de madurez del software (IMS) que proporciona una indicación de la estabilidad de un producto software basada en los cambios que ocurren con cada versión del producto. Con el IMS se determina la siguiente información:
El índice de madurez del software se calcula de la siguiente manera:
MT= Número de módulos en la versión
actualFc = Número de módulos en la versión actual que se han cambiado
Fa= Número de módulos en la versión actual que se han añadido
Fe= Número de módulos en la versión actual que se han eliminado
8. Definir los fundamentos de la reutilización del software.
La reutilización del software es una de las soluciones más importantes para el desafío de construir sistemas complejos.
Una reutilización efectiva requiere:
Repositorios de fácil acceso a componentes de alta calidad
Estándares en tecnología, documentación y procesos de software
Herramientas para encontrar, entender, evaluar, adaptar e integrar los componentes reutilizables
Apoyo efectivo de la comunidad de desarrolladores que está reutilizando cada biblioteca o librería
Esta categoría en tigris.org alberga proyectos de código abierto que están produciendo componentes de software reutilizables.
Dentro de esta categoría se pueden mencionar las siguientes herramientas:
Herramienta Uso Disponible en:
gef Framework para edición gráfica en Java https://gef.tigris.org/
axion Base de datos JAVA https://axion.tigris.org/
style CSS para aplicaciones web https://style.tigris.org/
SSTree Arbol Super Simple Java Script https://sstree.tigris.org/
9. Determinar las dificultades para la reutilización
10. Determinar algunas sugerencias para establecer un enfoque de la reutilización.