Calidad del Software

La calidad del software es una mezcla compleja de factores que varían a través de las diferentes aplicaciones y según los clientes que las pidan.

Reingeniería de Sistemas

Arreglar el sistema antes de que falle es uno de los objetivos de la reingeniería de sistemas.

La reingeniería de sistemas es el mantenimiento de un sistema de información asociado a los cambios tecnológicos.

Auditoría de Sistemas

Auditoría de Seguridad Lógica

Se divide en auditoría de penetración externa e interna.

Auditoría de Seguridad Física

Se refiere a la protección del hardware y los soportes de datos, así como la seguridad de los edificios e instalaciones que los albergan.

Integridad de Datos

Es un objetivo fundamental de la auditoría.

Conversión de Sistemas

Paso final de la implantación.

Definición de Auditoría de Sistemas

La auditoría de sistemas es la verificación de controles en el procesamiento de la información, desarrollo de sistemas e instalación.

Mantenimiento de Sistemas

Conocer la aplicación y sus programas es una tarea del mantenimiento de sistemas.

Soporte de Sistemas: es el mantenimiento continuado de un SI después que haya sido puesto en funcionamiento.

Factores de Calidad del Software

• Portabilidad/ Reusabilidad/ Interoperatividad: factor de calidad del software asociado a la transición del producto.
• Eficiencia/ Usabilidad/ Integridad/ Corrección/ Fiabilidad: factor de calidad asociado a la operación del producto.
• Facilidad de mantenimiento/ Flexibilidad/ Facilidad de prueba: factor de calidad asociado a la revisión del producto.

Pruebas de Regresión

Cualquier tipo de pruebas de software que intentan descubrir las causas de nuevos errores.

Planificación Estratégica de TI

Definición de un plan Estratégico: lograr un balance óptimo entre las oportunidades de tecnología de información y los requerimientos de TI de negocio, para asegurar sus logros futuros.

Normas y Estándares

ISO 17799

Norma que ofrece recomendaciones para realizar la gestión de la seguridad de la información.

Normas COBIT

Las Normas COBIT establecen 5 objetivos TI, los siguientes son 3 ejemplos: Datos, Aplicaciones e Instalaciones.

COBIT es en realidad un acrónimo formado por las siglas derivadas de objetivos de control para tecnología de información y tecnologías relacionadas. COBIT, lanzado en 1996, es una herramienta de gobierno de TI que ha cambiado la forma en que trabajan los profesionales de TI. Vinculando tecnología informática y prácticas de control, COBIT consolida y armoniza estándares de fuentes globales prominentes en un recurso crítico para la gerencia, los profesionales de control y los auditores. El concepto del marco COBIT se basa en que el control en TI se logra obteniendo la información necesaria para apoyar los requerimientos u objetivos del negocio, y visualizando la información como resultado de la aplicación combinada de recursos de TI que necesitan ser administrados por procesos de TI.

Estructura de COBIT

• Criterios de Información: Calidad, Fiduciarios, Seguridad.
• Procesos de TI: Dominios, Procesos, Actividades.
• Recursos de TI: Gente, Sistemas, Tecnología, Instalaciones y datos.

Estructuras de Niveles COBIT

• Dominios: Agrupación natural de procesos, normalmente corresponden a un dominio o una responsabilidad organizacional.
• Procesos: Conjuntos o series de actividades unidas con delimitación o cortes de control.
• Actividades: Acciones requeridas para lograr un resultado medible.

Se definen 34 objetivos de control generales, uno para cada uno de los procesos de las TI. Estos procesos están agrupados en cuatro grandes dominios que se detallan a continuación junto con sus procesos y una descripción general de las actividades de cada uno:

1. Planificación y Organización

La Planificación y el dominio de Organización cubren el empleo de tecnología y como mejor esto puede ser usado en una empresa ayudar alcanzar los objetivos de la empresa y objetivos. Esto también destaca la forma de organización e infraestructural TI debe tomar para alcanzar los resultados óptimos y generar la mayor parte de ventajas del empleo de TI. La mesa siguiente cataloga los objetivos de control nivel altos para el dominio de Organización y la Planificación.

OBJETIVOS – Planificación y Organización

2. Adquisición e Implementación

Identificación de sus exigencias TI, adquiriendo la tecnología, y poniéndolo en práctica (realización) dentro de los procesos de negocio corrientes de la empresa. Este dominio también dirige el desarrollo de un plan de mantenimiento que una empresa debería adoptar para prolongar la vida de un sistema TI y sus componentes. La mesa siguiente cataloga los objetivos de control nivel altos para el dominio de Puesta en práctica y la Adquisición.

OBJETIVOS – Adquisición e Implementación

3. Entrega y Soporte

La Entrega y el dominio de Apoyo enfocan en los aspectos de entrega de la tecnología de información. Esto cubre áreas como la ejecución de los usos dentro del sistema TI y sus resultados, así como, los procesos de apoyo que permiten la ejecución eficaz y eficiente de estos sistemas TI. Estos procesos de apoyo incluyen cuestiones de seguridad y educación (entrenamiento). La mesa siguiente cataloga los objetivos de control nivel altos para el dominio de Apoyo y la Entrega.

OBJETIVOS – Entrega y Soporte

4. Supervisión y Evaluación

La Supervisión y el dominio de Evaluación tratan con la estrategia de una empresa en la evaluación de las necesidades de la empresa y si realmente la corriente TI el sistema todavía encuentra los objetivos para los cuales fue diseñado y los mandos necesarios de cumplir con exigencias reguladoras. La supervisión también cubre la cuestión de una evaluación independiente de la eficacia de sistema TI en su capacidad de encontrar objetivos de negocio y los procesos de control de la empresa por interventores internos y externos. La mesa siguiente cataloga los objetivos de control nivel altos para la Supervisión del dominio.

OBJETIVOS – Supervisión y Evaluación

Métricas de Software

Métrica Basada en la Función

Puede emplearse para desarrollar una indicación del tamaño del software a implantar.

Nivel de Componentes

Es un ejemplo de métricas de diseño.

Administrar Cambios

Es un proceso del dominio «Adquisición e Implementación».

Tipos de Amenazas Informáticas que el Auditor Debe Saber

• Suplantación
• Alteración
• Divulgar Información
• Elevación de Privilegios

En qué Consiste la Auditoría de Sistemas de Información

En verificar los controles en el procesamiento de la información, desarrollo de sistemas e instalación con el objetivo de evaluar su efectividad y presentar recomendaciones a la Gerencia.

Métricas del Modelo de Diseño

• Arquitectónico: se concentran en las características de la arquitectura del programa y la eficiencia de los módulos.
• A Nivel de Componentes: se concentran en las características internas de los componentes del software.
• De Interfaz: se concentra en la representación gráfica del usuario (iconos, campos de edición, menús y ventanas).

Métricas del Código Fuente

Consisten en calcular el volumen del programa basándose en el código fuente. Las líneas de código representan la medida más simple e inmediata para el código fuente.

Proceso de las Normas COBIT para Asegurar el Mejor Enfoque para Cumplir con los Requerimientos del Usuario

Identificación de Soluciones Automatizadas (4. Dominio: Adquisición e implementación).

Evaluación de la Implantación

• Prueba de Verificación
• Prueba de Validación
• Prueba de Auditoría

Actividades del Soporte de Sistemas

• Corregir Errores
• Recuperar el Sistema
• Asistir a los usuarios del SI
• Adaptar el SI a las nuevas necesidades

Objetivos Fundamentales del Mantenimiento de Sistemas

• Hacer cambios predecibles en los programas existentes para corregir errores que se cometieron durante el diseño y la implantación del sistema.
• Preservar aquellos aspectos de los programas que fueron ya corregidos.

Tareas Principales del Mantenimiento de Sistemas

1. Definir y validar los problemas: Generalmente la definición del problema es proporcionada por el usuario del sistema. El analista y programador tratan de reproducir el error para determinar si en realidad es un error del programa (aplicación) o es un error de operación del usuario. Si el problema es válido entonces se procede a definir las expectativas de solución, de lo contrario se encuentra la causa y se da la solución.
2. Aplicar un juego de datos de prueba a los programas: Un cambio en la aplicación influirá en el funcionamiento global de todo el sistema, por tal razón es recomendable y necesario que antes de realizar un cambio en la aplicación se realicen pruebas para definir una línea de acción con respecto a que se ha de comparar el sistema. Utilizar datos de prueba antiguos (diccionario de proyectos). Utilizar una herramienta de pruebas para capturarlos automáticamente. Workstation Interactive Test Tool registra pulsaciones del teclado, movimientos del ratón e instrucciones así como respuestas del sistema, mientras un usuario utiliza el sistema en prueba.
3. Conocer la aplicación y sus programas: Para poder llevar a cabo esta tarea debe de estudiarse los diagramas de flujo, los diccionarios de datos, los árboles de decisión, las tablas de decisión, los DER, los DFD’s y el manual del analista.
4. Editar y probar programas: Luego de conocer el problema y conocer el programa el analista puede encaminarse en la tarea de editar y probar los programas nuevamente.
5. Actualizar la documentación: Es imprescindible realizar los cambios necesarios en la documentación del sistema luego de haber editado y probado los errores corregidos. Es necesario reconocer que en este caso se hace cambios en por lo menos dos tipos de documentación una es la documentación del sistema y la otra es la documentación del programa (aplicación).

Pruebas Esenciales en el Mantenimiento de Sistemas

• Pruebas de unidades
• Pruebas de sistemas
• Pruebas de regresión: Pruebas de software que intentan descubrir las causas de nuevos errores (bugs), carencias de funcionalidad, o divergencias funcionales con respecto al comportamiento esperado del software, inducidos por cambios recientemente realizados en partes de la aplicación que anteriormente al citado cambio no eran propensas a este tipo de error. Esto implica que el error tratado se reproduce como consecuencia inesperada del citado cambio en el programa.

Recuperación del Sistema

Esta es una actividad que a los especialistas de informática no les gustaría realizar o por lo menos no debería de ocurrir con frecuencia, sin embargo ocurre y es necesario llevarla a cabo. Esta actividad se da cuando por alguna razón ocurre un error que deja inoperable al sistema, por lo tanto el analista o programador es informado y este se encarga de corregir. El problema puede ser de hardware o de software, sin embargo en cualquiera de los dos casos se debe a una falta de pruebas exhaustivas tanto del hardware como del software. Dependiendo del tipo de problema será necesario por ejemplo recuperar las bases de datos dañadas, recuperar la información pérdida, etc. Por tal razón los sistemas deben de incluir un modulo de respaldo diario automático de la información para estar preparados para enfrentar este problema.

Asistencia a los Usuarios del Sistema

Un sistema de información puede no operar bien, ya sea porque el usuario no ha entendido el procedimiento para realizar una tarea, porque la documentación no es muy clara o talvez porque es un usuario nuevo y por lo tanto no recibió la formación a la hora de implantar el sistema.

¿Qué hacen los usuarios en esta actividad (SOPORTE)?

Informan sobre el problema encontrado al analista y él puede responder de varias formas: Cambios en los procedimientos de operación y documentación, proposición de mejoras. formación adicional y otros medio de soporte.

Factores de Calidad

Factores de Calidad de HP – (FURPS)

• La funcionalidad
• La facilidad de uso se valora considerando factores humanos.
• La fiabilidad se evalúa midiendo la frecuencia y gravedad de los fallos, la exactitud de las salidas (resultados), el tiempo de medio de fallos (TMDF), la capacidad de recuperación de un fallo y la capacidad de predicción del programa.
• El rendimiento se mide por la velocidad de procesamiento, el tiempo de respuesta,consumo de recursos, rendimiento efectivo total y eficacia.
• La capacidad de soporte combina la capacidad de ampliar el programa (extensibilidad), adaptabilidad y servicios (mantenimiento).

Factores de Calidad ISO 9126

• Funcionalidad
• Confiabilidad
• Usabilidad
• Eficiencia
• Facilidad de mantenimiento
• Portabilidad

Principios de Medición

• Ayuden a la evaluación de los modelos de análisis y diseño.
• Proporcionen una indicación de la complejidad de los diseños procedimentales y del código fuente.
• Ayuden en el diseño de pruebas más efectivas, es importante entender los principios básicos de la medición.

El Proceso de la Medición

Se puede caracterizar por las siguiente actividades:

• Formulación: la obtención de medidas y métricas del software apropiadas para la representación del software en cuestión.
• Colección: el mecanismo empleado para acumular datos necesarios para obtener las métricas formuladas.
• Análisis: el cálculo de las métricas y la aplicación de herramientas matemáticas.
• Interpretación: la evaluación de los resultados de las métricas en un esfuerzo por conseguir una visión interna de la calidad de la representación.
• Realimentación (feedback): recomendaciones obtenidas de la interpretación de métricas técnicas transmitidas al equipo que construye el software.

Características Fundamentales de las Métricas de Software

• Simples y fáciles de calcular. Debería ser relativamente fácil aprender a obtener la métrica y su cálculo no debería demandar un esfuerzo o cantidad de tiempo inusuales.
• Empírica e intuitivamente persuasivas. La métrica debería satisfacer las nociones intuitivas del ingeniero sobre el atributo del producto en cuestión (por ejemplo, una métrica que mide la cohesión de un módulo debería aumentar su valor a medida que crece el nivel de cohesión).
• Consistentes y Objetivas. La métrica debería siempre producir resultados sin ambigüedad. Un tercer equipo debería ser capaz de obtener el mismo valor de métrica usando la misma información del Software.
• Consistentes en el empleo de unidades y tamaños. El cálculo matemático de la métrica debería emplear medidas que no conduzcan a extrañas combinaciones de unidades. Por ejemplo, multiplicando el número de personas de un equipo por las variables del lenguaje de programación en el programa resulta una sospechosa mezcla de unidades que no son intuitivamente persuasivas.
• Independientes del lenguaje de programación. Las métricas deberían basarse en el modelo de análisis, modelo de diseño o en la propia estructura del programa.
• Un eficaz mecanismo para la realimentación de calidad. La métrica debería proporcionar, al desarrollador de software, información que le lleve a un producto final de mayor calidad.

Métricas del Modelo de Análisis

Métricas Basadas en la Función

La métrica de punto de función (PF) se puede usar como medio para predecir el tamaño de un sistema que se va a obtener de un modelo de análisis.

Parámetros para las Métricas de Función

La Métrica Bang

Estas ayudan a evaluar el análisis y diseño, proporcionan medidas de la complejidad, y ayudan a diseñar pruebas más efectivas. Estas métricas se dividen en : Medidas del análisis, medidas de especificación, medidas de diseño.

Para calcular la métrica bang, el desarrollador de software debe evaluar primero un conjunto de primitivas (elementos del modelo de análisis que no se subdividen más en el nivel de análisis). Las primitivas se determinan evaluando el modelo de análisis y desarrollando cuentas para los siguientes elementos:

• Primitivas funcionales (PFu). Transformaciones (burbujas) que aparecen en el nivel inferior de un diagrama de flujo de datos.
• Elementos de datos (ED). Los atributos de un objeto de datos, los elementos de datos son datos no compuestos y aparecen en el diccionario de datos.
• Objetos (OB). Objetos de datos.
• Relaciones (RE). Las conexiones entre objetos de datos.
• Estados (ES). El número de estados observables por el usuario en el diagrama de transición de estados.
• Transiciones (TR). El número de transiciones de estado en el diagrama de transición de estados.

Además, se determinan las cuentas adicionales para:

• Primitivas modificadas de función manual (PMFu). Funciones que caen fuera del límite del sistema y que deben modificarse para acomodarse al nuevo sistema.
• Elementos de datos de entrada (EDE). Aquellos elementos de datos que se introducen en el sistema.
• Elementos de datos de salida (EDS). Aquellos elementos de datos que se sacan del sistema.
• Elementos de datos retenidos (EDR). Aquellos elementos de datos que son retenidos (almacenados) por el sistema.
• Muestras (tokens) de datos (TCi). Las muestras de datos que existen en el límite de la i-ésima primitiva funcional (evaluada para cada primitiva).
• Conexiones de relación (REi). Las relaciones que conectan el i-ésimo objeto en el modelo de datos con otros objetos.

Métricas de la Calidad de la Especificación

Lista de características que pueden emplearse para valorar la calidad del modelo de análisis y la correspondiente especificación de requisitos: especificidad (ausencia de ambigüedad), compleción, corrección, comprensión, capacidad de verificación, consistencia interna y externa, capacidad de logro, concisión, trazabilidad, capacidad de modificación, exactitud y capacidad de reutilización.

Reingeniería de SI

Recupera información sobre el diseño de un programa existente y utiliza esta información para reestructurar o reconstruir el programa existente, con vistas a adaptarlo a un cambio, a ampliarlo o mejorar su calidad general, con el objetivo de conseguir una mayor facilidad de mantenimiento en el futuro (esto es lo que se denomina mantenimiento preventivo).

Objetivos de la Reingeniería

• Adaptar el sistema ante un cambio tecnológico importante.
• Arreglar el Sistema antes de que falle.
• Hacer el sistema más sencillo de manejar.

Categorías de los Factores de Calidad

1. Factores que se pueden medir directamente (por ejemplo, defectos por punto de función).
2. Factores que se pueden medir sólo indirectamente (por ejemplo, facilidad de uso o de mantenimiento).

Operación del Producto

Corrección. Hasta dónde satisface un programa su especificación y logra los objetivos propuestos por el cliente.

Fiabilidad. Hasta dónde se puede esperar que un programa lleve a cabo su función con la exactitud requerida. Hay que hacer notar que se han propuesto otras definiciones de fiabilidad más completas.

Eficiencia. La cantidad de recursos informáticos y de código necesarios para que un programa realice su función.

Integridad. Hasta dónde se puede controlar el acceso al software o a los datos por personas no autorizadas.

Usabilidad (facilidad de manejo). El esfuerzo necesario para aprender a operar con el sistema, preparar los datos de entrada e interpretar las salidas (resultados) de un programa.

Revisión del Producto

Facilidad de mantenimiento. El esfuerzo necesario para localizar y arreglar un error en un programa. (Esta es una definición muy limitada).

Flexibilidad. El esfuerzo necesario para modificar un programa que ya está en funcionamiento.

Facilidad de prueba. El esfuerzo necesario para probar un programa y asegurarse de que realiza correctamente su función.

Transición del Producto

Portabilidad. El esfuerzo necesario para transferir el programa de un entorno hardware/software a otro en entorno diferente.

Reusabilidad (capacidad de reutilización). Hasta dónde se puede volver a emplear un programa (o partes de un programa) en otras aplicaciones, en relación al empaquetamiento y alcance de las funciones que realiza el programa.

Interoperatividad. El esfuerzo necesario para acoplar un sistema con otro.

Etiquetas: Auditoría de Sistemas, Calidad del Software, COBIT, ISO 17799, Mantenimiento de Sistemas, métricas de software, Reingeniería de Sistemas, seguridad informática