Desarrollo del Software II

UNIDAD I

Reconocimiento del Problema

 - Contexto, Características y Consecuencias.
 - Unidades Involucradas y Procesos
 - Manuales de Usuario

Tareas del Análisis (CONTEXTO)

El análisis de requerimientos puede dividirse en cuatro áreas:

1.- Reconocimiento del problema

2.- Evaluación y síntesis

3.- Especificación

4.- Revisión.

Inicialmente, el analista estudia la especificación del sistema (si existe) y el plan de proyecto. Es importante comprender el contexto del sistema y revisar el ámbito de los programas que se usó para generar las estimaciones de la planificación. A continuación, debe establecerse la comunicación necesaria para el análisis, de forma que se asegure el reconocimiento del problema.
Las formas de comunicación requeridas para el análisis se ilustran en la Imagen. El analista debe establecer contacto con el equipo técnico y de gestión del usuario/cliente y con la empresa que vaya a desarrollar el software. El gestor del programa puede servir como coordinador para facilitar el establecimiento de los caminos de comunicación. El objetivo del analista es reconocer los elementos básicos del programa tal como lo percibe el usuario/cliente.

CARACTERÍSTICAS

La evaluación del problema y la síntesis de la solución es la siguiente área principal de trabajo del análisis. El analista debe evaluar el flujo y estructura de la información, refinar en detalle todas las funciones del programa, establecer las características de la interface del sistema y descubrir las ligaduras del diseño, Cada una de las tareas sirven para descubrir el problema de forma que pueda sintetizarse un enfoque o solución global.

CONSECUENCIAS

No hay duda de que la forma de especificar tiene mucho que ver con la calidad de la solución. Los ingenieros de software que se han esforzado en trabajar con especificaciones incompletas, inconsistentes o mal establecidas han experimentado la frustración y confusión que invariablemente se produce. Las consecuencias se padecen en la calidad, oportunidad y completitud del software resultante.

Hemos visto que los requerimientos de software pueden ser analizados de varias formas diferentes. Las técnicas de análisis pueden conducir a una especificación en papel que contenga las descripciones gráficas y el lenguaje natural de los requerimientos del software. La construcción de prototipos conduce a una especificación ejecutable, esto es, el prototipo sirve como una representación de los requerimientos. Los lenguajes de especificación formal conducen a representaciones formales de los requerimientos que pueden ser verificados o analizados.

UNIDADES INVOLUCRADAS Y PROCESOS

Ingeniería de Software

Es una disciplina o área de las ciencias de la computación que ofrece métodos y técnicas para desarrollar y mantener software e calidad que resuelve problemas de todo tipo.

Ingeniería de Software no es una disciplina que solo debe seguirse para proyectos de software que se encuentra pensados dentro de ciertas áreas, por el contrario, trata con áreas muy diversas de las ciencias de la computación, tales como construcción de compiladores, sistemas operativos, o desarrollos en Internet como es un cercanamente el caso de la aplicación de software de esta propuesta. La Ingeniería de Software abarca todas las fases del ciclo de la vida del desarrollo de cualquier tipo de sistemas de información aplicables a áreas tales como los negocios, investigación científica, medicina, producción, logística, banca, y realidad virtual.

Un aspecto muy importante de Ingeniería de Software es que proporciona parámetros formales para lo que se conoce como Gestión (o Administración) de Proyectos de Software. Esto se refiere a que Ingeniería de Software proporciona diversas métricas y metodologías que puede usarse como especificaciones para todo lo referente a la administración del personal involucrado en proyectos de software, ciclos de vida de un proyecto de software, costos de un proyecto, y en si todo el aspecto administrativo que implica el desarrollar software.

De acuerdo con Pressman, Ingeniería en general es el análisis, diseño, construcción, verificación y gestión de entidades técnicas. En general, todo proceso de la ingeniería debe comenzar por contestar las siguientes preguntas: ¿Cuál es el problema a resolver?, ¿Cuáles son las características de la entidad que se utiliza para resolver el problema?, ¿Cómo se realizará la entidad (y la solución) ?, ¿Cómo se construirá la entidad?, ¿Cómo va a probarse la entidad?, y ¿Cómo se apoyará la entidad cuando los usuarios finales soliciten correcciones y adaptaciones a la entidad?

Requisitos del Software

Es la descripción de los servicios y restricciones de un sistema de software, es decir, lo que el software debe hacer y bajo qué circunstancias debe hacerlo.

Ingeniería de Requisitos del Software

“Es el proceso de descubrir, analizar, documentar y verificar los requisitos del software.”

Stakeholders (Las partes interesadas)

Este término se utiliza para referirse a cualquier persona que tiene influencia directa o indirecta sobre los requisitos del sistema. Entre los stakeholders se encuentran los usuarios finales que interactúan con el sistema y todos aquellos en la organización que se verán afectados por dicho sistema.  Los stakeholders también son los ingenieros que desarrollan o dan mantenimiento a otros sistemas relacionados, los administradores del negocio, los expertos en el dominio del sistema, los representantes de los trabajadores, etc.

Las actividades del proceso son:

1.      Comprensión del dominio

2.      Recolección de requisitos

3.      Clasificación

4.      Resolución de conflictos

5.      Priorización

6.      Verificación de requisitos

7.      Análisis

Actividades de la Ingeniería de Requisitos. [SOMMERVILLE, 2002]

La ingeniería de requisitos incluye dos actividades principales: la obtención de requisitos, que da como resultado una especificación del sistema que el cliente comprende, y el análisis, que da comoresultado un modelo de análisis que los desarrolladores pueden interpretar sin ambigüedad. [BRUEGGE, 2002]

La obtención de requisitos se enfoca en la descripción del propósito del sistema y es la que implica el reto mayor. El cliente, los desarrolladores y los usuarios identifican un área problema y definen un sistema que resuelve el problema. A tal definición se le llama especificación de los requisitos del software (SRS) y sirve como contrato entre el cliente y los desarrolladores. La SRS se estructura y formaliza durante el análisis para producir un modelo de análisis. Tanto la SRS como el modelo de análisis representan la misma información. Difieren sólo en el lenguaje y notación que usan. La SRS está escrita en lenguaje natural, mientras que el modelo de análisis se expresa, por lo general, en una notación formal o semiformal. La especificación del sistema es la base de la comunicación con los stakeholders.  El modelo de análisis es la base de la comunicación entre los desarrolladores.

La obtención de requisitos y el análisis se enfocan sólo en la visión del sistema que tiene el usuario.

Tipos de requisitos

Requisitos funcionales: Describen las interacciones entre el sistema y su ambiente, en forma independiente a su implementación. El ambiente incluye al usuario y cualquier otro sistema externo con el cual interactúe el sistema.

Requisitos no funcionales: Describen atributos sólo del sistema o del ambiente del sistema que no están relacionados directamente con los requisitos funcionales. Los requisitos no funcionales incluyen restricciones cuantitativas, como el tiempo de respuesta o precisión, tipo de plataforma (lenguajes de programación y/o sistemas operativos, etc.)

Características de una buena SRS:

1. Correcta: Una SRS es correcta, sí y solo sí, cada requisito especificado es un requisito que el software debe cumplir.
2. No ambigua: Una SRS no es ambigua sí y solo sí cada requisito especificado tiene sólo una interpretación.
3. Completa:Una SRS es completa, sí y solo sí, incluye los siguientes elementos:

• Todos los requisitos significativos, ya sea que se relacionen a funcionalidad, desempeño, restricciones de diseño, atributos o interfaces externas. En particular cualquier requisito externo impuesto por una especificación del sistema debe ser reconocido y tratado.
• Definición de las respuestas del software a todos los tipos posibles de clases de datos de entrada en todos los tipos posibles de clases de situaciones. Notar que es importante especificar las respuestas tanto para valores de entrada válidos como inválidos.
• Etiquetas y referencias completas a todas las figuras, tablas y diagramas en la SRS así como la definición de todos los términos y unidades de medida.

4. Consistente:Una SRS es consistente, sí y solo sí, no se contradice a sí misma, es decir, si ningún subconjunto de requisitos ahí descritos se contradice o entran en conflicto.

5. Jerarquizada de acuerdo a la importancia y/o estabilidad:Una SRS está calificada de acuerdo a la importancia y/o estabilidad si cada requisito tiene un identificador que indique la importancia o estabilidad del requisito.

6. Verificable:Una SRS es verificable, sí y solo sí, cada requisito especificado es verificable. Un requisito es verificable sí y solo sí existe un proceso finito de costo-efectivo con el cual una persona o una máquina puede verificar que el producto de software cumple el requisito. En general cualquier requisito ambiguo no es verificable.

7. Modificable:Una SRS es modificable, sí y solo sí, su estructura y estilo son tales que, cualquier cambio a los requisitos pueden ser hechos fácil, completa y consistentemente sin perder la estructura y el estilo. La modificabilidad generalmente requiere que una SRS:
   
   a)       Tenga una organización coherente y fácil de usar con una tabla de contenido, un índice y referencias cruzadas explícitas.b)       No sea redundante (esto es, el mismo requisito no debe aparecer en más de una parte en la SRS).c)       Expresa cada requisito de manera separada, en vez de hacerlo mezclado con otros requisitos.

8. Rastreable:Una SRS es rastreable si el origen de cada uno de sus requisitos es claro y si facilita la referencia de cada requisito en el desarrollo futuro o mejora de la documentación. Se recomiendan los siguientes dos tipos de rastreabilidad:
   
   a)       Rastreabilidad hacia atrás (esto es, a estados previos del desarrollo). El requisito tiene referencias explícitas a sus fuentes en documentos anteriores.b)       Rastreabilidad hacia enfrente (esto es, a todos los documentos derivados del SRS). Depende de que cada requisito en la SRS tenga un nombre único o número de referencia. Es particularmente importante cuando el software entra en operación y mantenimiento. Cuando el código y los documentos de diseño son modificados, es esencial contar con la capacidad para conocer el conjunto completo de requisitos que pueden ser afectados por esas modificaciones.

MANUALES

Las tareas asociadas con el análisis y especificación existen para dar una representación del programa que pueda ser revisada y aprobada por el cliente. En un mundo ideal el cliente desarrolla una especificación de requerimientos del software completamente por sí mismo. Esto se presenta raramente en el mundo real. En el mejor de los casos, la especificación se desarrolla conjuntamente entre el cliente y el técnico.

Una vez que se hayan descrito las funcionalidades básicas, comportamiento, interface e información, se especifican los criterios de validación para demostrar una comprensión de una correcta implementación de los programas. Estos criterios sirven como base para hacer una prueba durante el desarrollo de los programas. Para definir las características y atributos del software se escribe una especificación de requerimientos formal. Además, para los casos en los que se desarrolle un prototipo se realiza un manual de usuario preliminar.

Puede parecer innecesario realizar un manual de usuario en una etapa tan temprana del proceso de desarrollo. Pero, de hecho, este borrador del manual de usuario fuerza al analista a tomar el punto de vista del usuario del software. El manual permite al usuario / cliente revisar el software desde una perspectiva de ingeniería humana y frecuentemente produce el comentario: "La idea es correcta, pero esta no es la forma en que pensé que se podría hacer esto". Es mejor descubrir tales comentarios lo más tempranamente posible en el proceso.

Los documentos del análisis de requerimiento (especificación y manual de usuario) sirven como base para una revisión conducida por el cliente y el técnico. La revisión de los requerimientos casi siempre produce modificaciones en la función, comportamiento, representación de la información, ligaduras o criterios de validación. Además, se realiza una nueva apreciación del plan del proyecto de software para determinar si las primeras estimaciones siguen siendo válidas después del conocimiento adicional obtenido durante el análisis.

UNIDAD 2. 

Gestión del proyecto. 

La Gestión de Proyectos no es más que la capacidad de reconocer los desafíos que te proporciona el cliente o la Empresa, para a través de ellos encontrar, revisar y evaluar las múltiples soluciones, seleccionando la que más responda a las definiciones de eficiencia y calidad, para después ponerla en práctica, acorde a los objetivos y planificación establecidos.La gestión de proyectos simplemente en conducir un proyecto desde el comienzo hasta un final satisfactorio, haciendo uso conjunto de procesos, conocimientos, habilidades, herramientas y técnicas que orienten y motiven al personal a realizar satisfactoriamente su trabajo dentro del proyecto.

Planificación del proyecto.

El objetivo de planificación del proyecto de Software es proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos, costo y planificación temporal. Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de un proyecto de Software, y deberían actualizarse a medida que progresa el proyecto. Además, las estimaciones deberían definir los escenarios del " mejor caso " y " peor caso " de forma que los resultados del proyecto puedan limitarse. El objetivo de la planificación se logra mediante un proceso de descubrimiento de la información que lleve a estimaciones razonables.

          

Análisis de las herramientas para el desarrollo del software propuesto.En todo desarrollo de sistemas de software es de suma importancia el seguir alguna especificación que permita a los desarrolladores el tener una disciplina que haga que todas las etapas del desarrollo del sistema, desde la pesquisa inicial de requerimientos hasta las pruebas finales del sistema, sean no solo más coherentes sino también más formales.

Organización de grupos de trabajoEl desarrollo de software y, por extensión, el de aplicaciones web es una actividad que requiere del cumplimiento de diversas facetas y del conocimiento de distintas tareas tanto relacionadas con la informática como no. Para la consecución de un proyecto de desarrollo de software deben conjugarse aspectos que abarcan la gestión, la dirección, la comunicación, la creatividad, así como aspectos comerciales además de los puramente relacionados con el software como la programación o el diseño de aplicaciones. Todo ello sumado, por regla general, a una cantidad significativa de horas de trabajo, por lo que, ante esta exigencia, en la mayoría de casos se hace casi imprescindible para la consecución de objetivos realizar el trabajo de desarrollo de software en equipo.

          En las labores de investigación y desarrollo se han definido teóricamente cuatro modelos de organización de grupos o equipos de trabajo: modelo jerárquico, modelo adaptativo, modelo libre y modelo sincrónico. Y como resultado de su combinación puede considerarse un quinto modelo, el abierto.

Control del Proyecto

          El control de proyecto tiene como objetivo principal el mantener el proyecto alineado con sus objetivos. Todas las dimensiones del proyecto han de ser gestionadas de manera concurrente, integrando costes, plazo, alcance y calidad en el método de control utilizado. De poco serviría un producto que cumpliera con los objetivos de costes, plazos y alcance, pero que no tuviese la calidad especificada, o un producto con la calidad adecuada, pero con un coste o un retraso que le hagan no ser competitivo.

Un control de proyecto efectivo nos va a permitir, a partir de la comparación entre valores planificados e incurridos:

          Evaluar la actuación o ejecución pasada en cualquier instante de la vida del proyecto.

          Analizar tendencias futuras que permitan estimar los costes y plazos de finalización del proyecto (método del valor ganado).

Documentación de la aplicación

          Documentación externa:

Es aquella que se escribe en cuadernos o libros, totalmente ajena a la aplicación en sí. Dentro de esta categoría también se encuentra la ayuda electrónica.

       +Documentación del usuario.

       + Documentación del sistema

          Documentación interna: 
Es aquella que se crea en el mismo código, ya puede ser en forma de comentarios o de archivos de información dentro de la aplicación.

UNIDAD 3.

Procesos de apoyo al desarrollo de software.
El proceso de apoyo es el cual da soporte a otro soporte con un propósito bien definido el cual se emplea y se ejecuta por otro proceso según sus necesidades. Este tiene 8 procesos del ciclo de vida:

o   Proceso de documentación.

o   Proceso de gestión de la configuración.

o   Proceso de aseguramiento de la calidad.

o   Proceso de verificación

o   Proceso de validación

o   Procesos de revisión conjunta.

o   Proceso de auditoría.

o   Proceso de solución de problemas.

Codificación del software.

Una vez que los algoritmos de una aplicación han sido diseñados, ya se puede iniciar la fase de codificación. En esta etapa se tienen que traducir dichos algoritmos a un lenguaje de programación específico; es decir, las acciones definidas en los algoritmos hay que convertirlas a instrucciones.

Para codificar un algoritmo hay que conocer la sintaxis del lenguaje al que se va a traducir. Sin embargo, independientemente del lenguaje de programación en que esté escrito un programa, será su algoritmo el que determine su lógica.
La lógica de un programa establece cuáles son sus acciones y en qué orden se deben ejecutar. Por tanto, es conveniente que todo programador aprenda a diseñar algoritmos antes de pasar a la fase de codificación.

Procesamiento de errores (pruebas de software).

Las pruebas de software (en inglés software testing) son las investigaciones empíricas y técnicas cuyo objetivo es proporcionar información objetiva e independiente sobre la calidad del producto a la parte interesada o stakeholder. Es una actividad más en el proceso de control de calidad.Las pruebas son básicamente un conjunto de actividades dentro del desarrollo de software. Dependiendo del tipo de pruebas, estas actividades podrán ser implementadas en cualquier momento de dicho proceso de desarrollo. Existen distintos modelos de desarrollo de software, así como modelos de pruebas. A cada uno corresponde un nivel distinto de involucramiento en las actividades de desarrollo.

Procesos de validación.

Evidencia documentada la cual proporciona un alto grado de seguridad que un proceso específico resultará consistentemente en un producto que reúne sus especificaciones pre-determinadas y sus características de calidad.

o   Tipos de validación:

§  Validación prospectiva.

§  Validación concurrente.

§  Validación retrospectiva.

Documentación del software.

La documentación en un proyecto de software es importante porque permite conservar la historia, facilita la utilización por parte del usuario, garantiza la permanencia y disminuye los costos de operación y de ejecución del proyecto como tal.

En la ejecución de un proyecto informático o un programa software se deben de seguir una serie de pasos desde que se plantea el problema hasta que se dispone del programa o del a aplicación funcionando en el ordenador.

o   Los pasos son los siguientes:

§  Análisis de factibilidad

§  Análisis de requerimientos

§  Diseño del sistema

§  Implementación

§  Validación y pruebas

§  Explotación

§  Mantenimiento

Cada uno de estos pasos debe de llevar asociado un documento. Estos documentos son muy importantes ya que van a regir las fases del ciclo de vida del software y se recogen los pasos seguidos en cada fase para su ejecución.

Implantar la versión beta del software.

Una beta representa generalmente la primera versión completa del programa informático o de otro producto, que es posible que sea inestable pero útil para que las de inspección previa (preview) o como una inspección previa técnica (technical preview [TP]). Esta etapa comienza a menudo cuando los desarrolladores anuncian una congelación de las características del producto, indicando que no serán agregadas más características a esta versión y que solamente se harán pequeñas ediciones o se corregirán errores.
Las versiones beta están en un paso intermedio en el ciclo de desarrollo completo. Los desarrolladores las lanzan a un grupo de probadores beta o betatesters (a veces el público en general) para una prueba de usuario. Los probadores divulgan cualquier error que encuentran y características, a veces de menor importancia, que quisieran ver en la versión final.

Plan de mantenimiento.

Este proceso busca la coherencia y sostenibilidad de los servicios de software, para superar las pruebas operacionales o necesidades del cliente.

La estrategia de mantenimiento de software consiste de las siguientes actividades:

o Concepto de mantenimiento

o   Plan de mantenimiento

o   Análisis de recursos

Tipos de Mantenimiento

o   Mantenimiento correctivo: Es aquel que se ocupa de la reparación una vez se ha producido el fallo y el paro súbito de la máquina o instalación.

o   Mantenimiento Preventivo: Este tipo de mantenimiento surge de la necesidad de rebajar el correctivo y todo lo que representa. Pretende reducir la reparación mediante una rutina de inspecciones periódicas y la renovación de los elementos dañados.

UNIDAD 4.

Mantenimiento del Software. 
En ingeniería del software, el mantenimiento de software es la modificación de un producto de software después de la entrega, para corregir errores, mejorar el rendimiento, u otros atributos. El mantenimiento del software es una de las actividades más comunes en la ingeniería de software.
El mantenimiento de software es también una de las fases en el ciclo de vida de desarrollo de sistemas (SDLC, sigla en inglés de system development life cycle), que se aplica al desarrollo de software. La fase de mantenimiento es la fase que viene después del despliegue (implementación) del software en el campo.
Una percepción común del mantenimiento es que se trata meramente de la corrección de defectos.

Razones para el mantenimiento.

El mantenimiento debe ser realizado para reparar los fallos existentes del software. Esto puede incluir depuración de errores debido a un mal código o una reparación mayor del sistema si el problema es avanzado.

Los patrones de funcionamiento, la plataforma de software, la conversión de datos, la actualización de hardware, entre otros, todos afectan el funcionamiento del software.

El mantenimiento de software también puede ser necesario para ajustar la habilidad de rendimiento, funcionalidad y usabilidad del software. Puede oscilar entre simplemente cambiar la interfaz gráfica de usuario del software para hacerla más atractiva y amigable con el usuario hasta hacer cambios drásticos en el código central para mejorar el tiempo de ejecución y el rendimiento.

Problemas asociados.

El mantenimiento de software incluye hacer pruebas para detectar un problema y hacer la depuración sin perturbar el resto del sistema. Los problemas claves de mantenimiento de software son administrativos y técnicos.

Problemas clave de administración son: alineación con las prioridades del cliente, dotación de personal, cuál organización hace mantenimiento, estimación de costos. Son cuestiones técnicas claves: limitado entendimiento, análisis de impacto, pruebas (testing), medición de mantenibilidad.

Ventajas y desventajas del mantenimiento.

Los conceptos fundamentales de los distintos tipos de mantenimiento se resumen en la siguiente tabla.

Mantenimiento	Concepto	Ventajas	Desventajas	Aplicación
Correctivo	Se ejecuta en caso de falla notable en el rendimiento operativo del equipo o inactividad total.	Genera costo ante falla existente.	Incertidumbre sobre cuándo se producirá la falla, que puede ser en el momento más inconveniente e involucrar un alto costo.	En todos los casos.
Preventivo	Considera el historial de fallas en máquinas iguales para la programación de paradas y verificación.	El mantenimiento es programado para el momento productivo oportuno.	El mantenimiento puede ser innecesario.	Generalizada. No aplicable cuando las posible averías no generan grandes gastos comparados con los de mantenimiento.
Predictivo	Monitoreo programable de variables indicativas del funcionamiento. Se ejecuta el mantenimiento cuando alguna/s  de ellas se aleja/n de su/s valores promedio.	Se evitan desarmes innecesarios y se conoce el estado de la máquina.	Un monitoreo mal implementado o llevado someramente puede permitir que la maquinaria falle.	Cuando el costo de paradas (para una reparación más profunda en el caso de mantenimiento Correctivo, o de paradas innecesarias en el caso de mantenimiento Preventivo) justifica la implementación de este tipo.

Costos del mantenimiento.

Hay unos costos que son fácilmente visibles en el mantenimiento y otros que parecen no notarse hasta que ocurre. Los primeros, que hacen se tienda a minimizar el mantenimiento, son:

o   Costos Exteriorizados                                                  

§  Materiales                                       

§  Mano de obra                                                 

§  Servicios de terceros         
                          

Los otros deben ser previstos, para poder evaluar la necesidad de utilizar algún tipo de mantenimiento:                            

o   Costos Ocultos                                

§  Lucro cesante por paradas.       

§  Accidentes por falla de equipo de seguridad.

§  Deterioro del ritmo de producción.

§  Baja de la calidad de producto.

§  Acortamiento de vida útil de equipo.

§  Inmovilización de inventarios.

Tipos de mantenimiento.

A lo largo de su vida útil, la aplicación puede necesitar modificaciones por distintas razones, que determinan diferentes tipos de mantenimiento:

·         Mantenimiento preventivo. Consiste en la revisión constante del software para detectar posibles focos de problemas que puedan surgir en el futuro.

·         Mantenimiento predictivo.
Evalúa el flujo de ejecución del programa para predecir con certeza el momento en el que se producirá la falla, y así determinar cuándo es adecuado realizar los ajustes correspondientes.

·         Mantenimiento correctivo.
Corrige los defectos encontrados en el software, y que originan un comportamiento distinto al deseado. Estas fallas pueden ser de procesamiento, rendimiento (por ejemplo, uso ineficiente de los recursos de hardware), programación (inconsistencias en la ejecución), seguridad o estabilidad, entre otras.

·         Mantenimiento adaptativo. Si se requiere cambiar el entorno de uso de la aplicación (que incluye al sistema operativo, a la plataforma de hardware o, en el caso de las aplicaciones web, al navegador), puede ser indispensable modificarla para mantener su plena funcionalidad en estas nuevas condiciones.

·         Mantenimiento evolutivo.
Es un caso especial donde la adaptación resulta prácticamente obligatoria, ya que de lo contrario el programa quedaría obsoleto con el paso del tiempo. Por ejemplo, el cambio de versión en un navegador (muchas veces impuesto sin el consentimiento del usuario) suele obligar a realizar ajustes en plugins y aplicaciones web.

·         Mantenimiento perfectivo.
Por distintas razones, el usuario puede solicitar el agregado de nuevas funcionalidades o características no contempladas al momento de la implementación del software. El mantenimiento perfectivo adapta la aplicación a este requerimiento.

Soporte a usuarios.

El contrato de soporte de software es una parte integral y esencial de la inversión en software de calibración. De hecho, uno ni siquiera debería considerar la posibilidad de comprar software de calibración sin tener en cuenta los aspectos del mantenimiento y soporte del software. Cuanto mayor es la inversión en calibración y/o mayor es el tiempo que el cliente prevé tener operativo y en uso el sistema de calibración, más importante es evaluar la posibilidad de invertir en un contrato de mantenimiento.

Un contrato de soporte de software suele ser un contrato de servicio de duración fija o renovación automática por el cual el cliente tiene derecho a recibir determinados servicios relativos a un software concreto durante la vigencia del contrato a cambio de una cuota fija; estos servicios suelen incluir actualizaciones de software y soporte técnico.