Plan de soporte

Descarga: Plan de soporte

Gestión del cambio

Introducción

Al desarrollar software, el cambio es inevitable y puede aumentar en grado de confusión entre los ingenieros de software que trabajan en un proyecto cuando los cambios:

• No son analizados antes de que se comiencen.
• No se registran antes de implementarlos.
• No se controlan, de forma que mejorará la calidad y reducirá el error.
• No son reportados.

Es por ello, que nace “la gestión de cambio”, mejor conocida como gestión de configuración de software, una actividad protectora que se aplica  a lo largo de todo el proceso de software.

Los objetivos de la gestión de configuración de software son:

• Identificar el cambio.
• Controlar el cambio.
• Garantizar la implementación del cambio.
• Informar el cambio.

La gestión de configuración es un conjunto de actividades de seguimiento y de control que se inician cuando comienza un proyecto de ingeniería de software y termina cuando este se retira de operación.

Configuración del software

La configuración de software es la salida de información del proceso de software en tres categorías:

• Programas de computadora.
• Productos de trabajo, que describen los programas de computadora.
• Datos internos y externos al programa.

Toda esta información conjunta constituya a la configuración del software.

Cuatro fuentes fundamentales del cambio

• Nuevas condiciones: el negocio o el mercado dictan cambios en los requisitos.
• Nuevas necesidades del cliente: modificación de los datos que producen los sistemas de información.
• La reorganización o el crecimiento o reducción del negocio.
• Restricciones presupuestales o de calendarización.

                                             

Escenario de gestión de configuración de software

Un escenario involucra a:

• Gestor de proyecto: A cargo del grupo de software, garantiza que el producto se entregue dentro de cierto periodo supervisa el progreso de desarrollo y reacciona ante los problemas.
• Gestor de configuración: a cargo de los procedimientos y políticas para crear, cambiar y poner a prueba el código.
• Ingeniero de software: responsable del desarrollo y mantenimiento del producto de software.
• Cliente: quien emplea el producto.

Elementos de un sistema de gestión de configuración:

• Elementos de componentes.
• Elementos de proceso.
• Elementos de construcción.
• Elementos humanos.

Línea base

Es un concepto de gestión de configuración del software que ayuda a controlar el cambio sin impedir seriamente el cambio justificable.

Según la IEEE es una especificación que se ha revisado formalmente y se está de acuerdo con los resultados, y que a partir de ahí sirve como la base para el desarrollo posterior y que puede cambiarse solo por medios formales de control de cambio.

Elementos de configuración del software

Un elemento de configuración de software es información que se crea del proceso de ingeniería de software, después este ECS se revisa y se aprueba colocándose en una base de datos del proyecto, conocida también como depósito del software. Después de ello, cuando un miembro de un quipo quiere modificar u n ECS que se ha convertido ya en una línea base, se copia de la base de datos del proyecto en el espacio de trabajo privado del ingeniero.

El papel del depósito 

El depósito es un conjunto de mecanismos y estructuras de datos que permiten que un equipo de software maneje el cambio de una manera eficaz, para:

• La integridad de los datos
• El compartir información
• La integración de las herramientas
• La integración de los datos
• El fortalecimiento de la metodología
• Estandarización de los documentos

El depósito se define en función de un meta-modelo.

El proceso de gestión de configuración del software

• Identificar todos los elementos que colectivamente definen la configuración del software.
• Gestionar los cambios a uno o más de dichos elementos.
• Facilitar la construcción de diferentes versiones de una ampliación.
• Garantizar que la calidad del software se conserva conforme la configuración. 

Ingeniería inversa

Introducción

La ingeniería inversa invoca una imagen de «ranura mágica». En la ranura se inserta una lista fuente sin documentar y diseñado casualmente, y del otro extremo sale una descripción completa del diseño para el programa de computadora. Desdichadamente, la ranura mágica no existe.

El grado de abstracción de un proceso de ingeniería inversa y las herramientas utilizadas para efectuarlo se refieren a la sofisticación de la información de diseño de procedimiento (grado de abstracción bajo), información de estructura de programa y datos (grado de abstracción un poco más elevado), modelos de objeto, modelos de flujo de datos o control (grado de abstracción relativamente alto) y clases UML, diagramas de estado y despliegue (grado alto de abstracción).  Conforme el grado de abstracción aumenta, el ingeniero de software obtiene información que le permitirá comprender con más facilidad el programa.

La completud de un proceso de ingeniería inversa se refiere al grado de detalle que se ofrece en un grado de abstracción. La integridad disminuye conforme el grado de abstracción aumenta, por ejemplo, dada una lista del código fuente, es relativamente sencillo desarrollar una representación completa del diseño del procedimiento, pero es mucho más difícil desarrollar un conjunto completo de diagramas o modelos UML.

Si la direccionalidad del proceso de ingeniería inversa es unidireccional, toda la información extraída del código fuente se ofrece al ingeniero de software que entonces puede usarla durante cualquier actividad de mantenimiento.

Ingeniería inversa para comprender los datos

Al nivel de programa, las estructuras de datos internos del programa usualmente deben someterse a reingeniería inversa como parte de una reingeniería. La ingeniería inversa de las actuales estructuras globales de datos establece el escenario para introducción de una nueva base de datos que abarque todo el sistema.

Ingeniería inversa para comprender el procesamiento

Comienza con un intento por comprender y luego extraer abstracciones de procedimientos representadas por el código fuente. La funcionalidad global de todo un sistema de aplicación se debe comprender antes de que ocurra un trabajo de ingeniería inversa más detallado.

En sistemas grandes la ingeniería inversa, por lo general, se logra utilizando un enfoque semi automatizado. Las herramientas automatizadas ayudan al ingeniero de software a comprender la semántica del código existente.

Ingeniería inversa de interfaces de usuario

Desarrollar de nuevo las interfaces de usuario se ha vuelto uno de los tipos más comunes de actividad de reingeniería. Pero antes de que una interfaz de usuario se pueda reconstruir deberá realizarse una actividad de ingeniería inversa.

Se sugieren tres preguntas básicas que deben responder conforme comienza la ingeniería inversa de la interfaz de usuario:

• ¿Cuáles son las acciones básicas (presiones de tecla o clics de ratón, por ejemplo) que debe procesar el sistema?
• ¿Cuál es la descripción compacta de las respuestas de comportamiento del sistema a estas acciones?
• ¿Qué se entiende por «reemplazo» o, más exactamente, qué concepto de equivalencia de interfaces es relevante en este caso? 

Reingeniería

Reingeniería de procesos de negocio

La reingeniería de procesos de negocio rebasa el ámbito de las tecnologías de la información y de la ingeniería de software. La definición que más destaca es la siguiente: «La búsqueda e implementación de un cambio radical en el proceso de negocios para lograr resultados de vanguardia». 

Proceso de negocio

Un proceso de negocio es un «conjunto de tareas lógicamente relacionadas que se ejecutan para lograr un resultado de negocios específico». Los ejemplos de procesos de negocios incluyen el diseño de un nuevo producto, la compra de servicios  y suministros, la contratación de un nuevo empleado y el pago a proveedores.

La reingeniería de procesos de negocio es iterativa. Las metas del negocio y los procesos que se logran se deben adaptar a un entorno cambiante. El modelo define seis actividades:

• Definición del negocio: las metas del negocio se identifican en el contexto de cuatro controladores clave, reducción de costo, reducción de tiempos, mejora de la calidad y desarrollo y fortalecimiento del personal.
• Identificación del proceso: se identifican los procesos cruciales para lograr las metas precisadas en la definición del negocio.
• Evaluación del proceso: el proceso existente se analiza y mide exhaustivamente.
• Especificación y diseño del proceso: con base en la retroalimentación obtenida durante las primeras tres actividades se preparan los casos de uso para cada proceso que será rediseñado.
• Elaboración de prototipos: un proceso de negocio rediseñado debe convertirse en prototipo antes de que sea integrado por completo.
• Refinamiento y particularización: con base en la retroalimentación del prototipo, el proceso de negocio se refina y luego se particulariza.

Reingeniería de software

La reingeniería requiere tiempo, cuesta cantidades significativas de dinero y absorbe recursos que de otro modo se ocuparían en problemas inmediatos. La reingeniería es una actividad de reconstrucción y se comprende mejor si se considera una actividad análoga.

Las etapas del modelo de reingeniería de software es la siguiente:

• Análisis de inventarios: saber con qué se cuenta. Las empresas lo hacen para determinar que software es candidato a reingeniería.
• Restructuración de documentos: si el software no cuenta con ningún tipo de documentación, y ésta se requiere, debe realizarse. Aun así, se debe procurar realizar sólo lo necesario: no tiene caso volver a documentar todo un software si este funciona bien.
• Ingeniería inversa: va de «atrás hacia adelante». A través del código se pueden obtener especificaciones de diseño y del proceso que realiza el software para entenderlo.
• Reestructuración de código: adapta el código a los estándares para que sea fácil de entender y se le pueda dar mantenimiento.
• Reestructuración de datos: analiza la estructura de datos del sistema y si ésta es o no viable. Se considera como ingeniería avanzada.
• Ingeniería directa: es también llamada renovación o reclamación. Adapta el software a otros lenguajes, otras plataformas, etcétera. 

Soporte y mantenimiento

Soporte de software

Es el diseño de la asistencia que se le va a brindar a un usuario, de un servicio que tenga problemas, errores, o dificultades de operación, localizados en el software de cierto dispositivo electrónico o PC.

El soporte de software se da después de del ciclo de vida del desarrollo de software, es decir se da después de la “Entrega” del sistema.

Ciclo de desarrollo del software:

• Análisis
• Diseño
• Desarrollo
• Pruebas
• Mantenimiento
• Entrega

Esta asistencia siempre es brindada al usuario.

Mantenimiento de software

El servicio de mantenimiento de software es una de las actividades en la Ingeniería de Software y es el proceso de mejorar y optimizar el software desplegado, así como remediar los defectos.

La fase de mantenimiento de software involucra cambios al software en orden de corregir defectos y dependencias encontradas durante su uso tanto como la adición de nueva funcionalidad para mejorar la usabilidad y aplicabilidad del software

El mantenimiento de software se puede dar antes o después de terminación del software.

Algunas definiciones de mantenimiento software:

Estándar IEEE 1219

La modificación de un producto software después de su entrega al cliente o usuario para corregir defectos, para mejorar el rendimiento u otras propiedades deseables, o para adaptarlo a un cambio de entorno.

Estándar ISO/IEC 14764   

                   

Conjunto de actividades destinadas a proporcionar soporte económicamente rentable para un determinado producto software. Estas actividades se realizan tanto antes de la entrega del producto como después de la entrega del mismo.

Las actividades previas a la entrega incluyen las actividades destinadas a planificar, anticipar y preparar actividades de mantenimiento posteriores. Las actividades posteriores a la entrega incluyen modificaciones del producto software, formación y asistencia al usuario.

Costes del mantenimiento de software

Múltiples estudios señalan que el mantenimiento es la parte más costosa del ciclo de vida del software. Estadísticamente está comprobado que el coste de mantenimiento de un producto software a lo largo de toda su vida útil supone más del doble que los costes de su desarrollo.

[Pressman, 1993] años 70 35%-40%    Años 90  90%

• Estos programas han sufrido una o varias migraciones a nuevas plataformas o sistemas operativos.
• Y han experimentado múltiples modificaciones para mejorarlos y adaptarlos a las nuevas necesidades de los usuarios.

Tipos de acciones de mantenimiento software

• Correctivo: localiza y corrige defectos en un programa tras su entrega (ej. IVA al 15 %, agujeros de seguridad). Puede ser urgente o no urgente.
• Adaptativo: Modificación para adaptarse a un cambio en el entorno (ej. Euro, pantallas táctiles).
• Perfectivo: Modificación para detectar y corregir fallos latentes antes de que se conviertan en carencias. Añadir nuevas funcionalidades. (Ej. Firma digital en banca online).
• Preventivo: Modificación para corregir fallos antes de que se conviertan en fallos operacionales. Mejorar las propiedades del software. (Ej. Recodificar para aplicar patrones de diseño).

Referencias

• ESCUELA SUPERIOR DE INFORMÁTICA, UNIVERSIDAD DE CASTILLA-LA MANCHA URL: http://alarcos.inf-cr.uclm.es/doc/mso/
• Universidad de Cantabria URL: http://ocw.unican.es/ensenanzas-tecnicas/ingenieria-del-software-ii/materiales/tema8-mantenimientoSistemasSoftware.pdf
• IEEE (The Institute of Electrical and Electronics Engineers). Standard for software maintenance.

Calidad

Introducción

La palabra calidad designa el conjunto de atributos o propiedades que nos permiten emitir un juicio de valor acerca de él. Se utilizada la palabra «calidad» para decir que algo «está bien hecho» o que «tiene las características necesarias para funcionar», etcétera.

El término «calidad» se aplica cada vez con mayor frecuencia a los productos que son el resultado de la actividad de manufactura, debido a la importancia que esta actividad comenzó a tener desde la transformación industrial.

En el proceso de evolución de la calidad se distinguen cuatro diferentes etapas:

1950 – 1960: se cuida la calidad de los productos mediante un trabajo de inspección.

1950 – 1970: se cae en la cuenta de que la atención a la calidad exige observación del proceso.

1960 – 1970: se percibe la necesidad de asegurar el mejoramiento.

1980 – 1990: la administración misma redefine su papel con el propósito de que la calidad del producto sea la estrategia a emplear para tener éxito frente a los competidores.

Primera etapa: el control de la calidad mediante la inspección

Coincide con el periodo en el que comienza a tener mucha importancia la producción de artículos en serie, pues era necesario ver si el artículo, al final de la línea de producción, resultaba apto para el uso para el que estaba destinado. Por ello se introdujo un departamento especial en la industria a cuyo cargo estuviera la tarea de inspección. A este nuevo organismo se le denominó «departamento de control de calidad».

G. S. Radford, en su libro The Control of Quality in Manufacturing, afirma que la inspección tiene como propósito examinar de cerca y en forma crítica el trabajo para comprobar su calidad. Lo importante es que el producto cumpla con los estándares establecidos.

Otros aspectos relacionados con la calidad son las necesidades de que los diseñadores se involucren en las actividades de calidad, la necesidad de que exista coordinación entre los diferentes departamentos y la relación que debe existir entre el mejoramiento de la calidad y la baja de los costos.

Segunda etapa: el control estadístico de la calidad

W. A. Shewhart publicó el libro Economic Control of Quality of Manufactured Product, que proporciona una definición precisa del control a efectuarse en el proceso de manufactura. Desarrolla técnicas para monitorear y evaluar la producción al mismo tiempo que propone diversas formas para mejorar la calidad.

Shewhart observó que no pueden producirse dos partes con las mismas especificaciones, lo cual se debe, entre otras cosas, a las diferencias que se dan en la materia prima, a las habilidades de los operadores y a las condiciones en que se encuentra el equipo. No se trata de suprimir la variación, sino de ver qué rango de variación es aceptable sin que se originen problemas.

Harold Dodge y Harry Roming avanzaron en la forma de llevar a cabo la práctica del muestreo, que es el segundo elemento importante del control estadístico del proceso. Las técnicas de muestreo parten del hecho de que en una producción masiva es imposible inspeccionar todos los productos. De ahí la necesidad de verificar un cierto número de artículos entresacados de un mismo lote de producción para decidir sobre esta base si el lote entero es aceptable o no.

Tercera etapa: el aseguramiento de la calidad

Antes de la década de los cincuenta, la atención se había centrado en el control estadístico del proceso, ya que en esta forma era posible tomar medidas adecuadas para prevenir los defectos.

Sin embargo, era necesario que quedara asegurado el mejoramiento de calidad logrado, lo cual significaba que había que desarrollar profesionales dedicados al aseguramiento de la calidad y que había que involucrar a todos en el logro de la calidad. Todo requería un compromiso mayor por parte de la administración.

El planteamiento de W. Edwards Deming es el siguiente: si se mejora la calidad, disminuyen los costos. La reducción de costos juntamente con el mejoramiento de la calidad se traduce en mayor productividad. La empresa con mayor productividad es capaz de capturar un mercado cada vez mayor.

Joseph Juran, en su libro Quality Control Handbook, trató el tema de los costos. Algunos costos de producción son inevitables, como los relacionados con el control de calidad; se pueden suprimir los que se relacionan con los productos defectuosos, como son el material de desecho, las horas invertidas en reparaciones, en re trabajo y en atender reclamaciones.

Armand Feigenbaum propone por primera vez el concepto «control total de calidad». Para que el control de calidad sea efectivo este debe iniciarse con el diseño mismo del producto y terminar sólo cuando el artículo esté en manos de un consumidos satisfecho. La calidad es trabajo de todos y de cada uno de los que intervienen en cada etapa del proceso.

Cuarta etapa: la calidad como estrategia competitiva

La calidad no pasa a ser estrategia competitiva sólo porque se apliquen métodos estadísticos para controlar el proceso; como tampoco lo es por el hecho de que todos se comprometan a elaborar productos sin ningún defecto, pues esto de nada serviría si no hay mercado para ellos. La calidad pasa a ser estrategia de competitividad en el momento en que se toma como punto de partida para la planeación estratégica de los requerimientos del consumidor y la calidad de los productos de los competidores.