domingo, 23 de julio de 2017

4.7 TENDENCIAS ACTUALES APLICADAS A LA CALIDAD EN LOS SISTEMAS DE INFORMACIÓN

TENDENCIAS ACTUALES APLICADAS A LA CALIDAD EN LOS SISTEMAS DE INFORMACIÓN

Tendencia:

Cualquier idea religiosa, económica, política, artística, etc. Que se orienta en
determinada dirección.

Innovando el futuro.
Existen tres principales puntos de las nuevas tendencias.
  • Menos riesgo: APP más accesibles y menos costosas.
  • Utilización de las redes sociales dentro de las compañías: Redes sociales.
  • Llega el Internet de los objetos: Vamos a un mundo de sensores
Aceleración de la adquisición de teléfonos inteligentes:
  •    Smartphones.
Computación de software alojado y nube:
  •  Google's Docs
  • Mega.
  • Dropbox, etc.
Redes inalámbricas y celulares: 
  • Wi-Fi.
En el siguiente video se explica con mas detalle este tema:



4.6 CMMI

CMMI – Capability Maturity Model Integration

Integración de Modelos de Madurez de las Capacidades., es un modelo de evaluación de los procesos de una organización. Fue desarrollado inicialmente para los procesos relativos al software por la Universidad Carnegie-Mellon para el SEI (Software Engineering Institute).

Este modelo establece un conjunto de prácticas o procesos clave agrupados en Áreas Clave de Proceso (KPA – Key Process Area). Para cada área de proceso define un conjunto de buenas prácticas que habrán de ser:
  • Definidas en un procedimiento documentado
  • Provistas (la organización) de los medios y formación necesarios
  •   Ejecutadas de un modo sistemático, universal y uniforme (institucionalizadas)
  •  Medidas
  • Verificadas
A su vez estas Áreas de Proceso se agrupan en cinco “niveles de madurez”, de modo que una organización que tenga institucionalizadas todas las prácticas incluidas en un nivel y sus inferiores, se considera que ha alcanzado ese nivel de madurez.
Los niveles son:
1 – Inicial. Las organizaciones en este nivel no disponen de un ambiente estable para el desarrollo y mantenimiento de software. Aunque se utilicen técnicas correctas de ingeniería, los esfuerzos se ven minados por falta de planificación. El éxito de los proyectos se basa la mayoría de las veces en el esfuerzo personal, aunque a menudo se producen fracasos y casi siempre retrasos y sobrecostes. El resultado de los proyectos es impredecible.
2 – Repetible. En este nivel las organizaciones disponen de unas prácticas institucionalizadas de gestión de proyectos, existen unas métricas básicas y un razonable seguimiento de la calidad. La relación con subcontratistas y clientes está gestionada sistemáticamente.
3 – Definido. Además de una buena gestión de proyectos, a este nivel las organizaciones disponen de correctos procedimientos de coordinación entre grupos, formación del personal, técnicas de ingeniería más detallada y un nivel más avanzado de métricas en los procesos. Se implementan técnicas de revisión por pares (peer reviews).
4 – Gestionado. Se caracteriza porque las organizaciones disponen de un conjunto de métricas significativas de calidad y productividad, que se usan de modo sistemático para la toma de decisiones y la gestión de riesgos. El software resultante es de alta calidad.
5 – Optimizado. La organización completa está volcada en la mejora continua de los procesos. Se hace uso intensivo de las métricas y se gestiona el proceso de innovación.
Las prácticas que deben ser realizadas por cada Area Clave de Proceso están  organizadas en 5 Características Comunes, las cuales constituyen propiedades que  indican si la implementación y la institucionalización de un proceso clave es efectivo,  repetible y duradero.
Estas 5 características son:

  • Compromiso de la realización       
  •  La capacidad de realización
  •  Las actividades realizada
  • Las mediciones y el análisis
  • La  verificación de la implementación



4.5 PSP/TSP

PSP/TSP

PSP (Personal Software Process), es un conjunto de prácticas disciplinadas para la gestión del tiempo y mejora de la productividad personal de los programadores o ingenieros de software, en tareas de desarrollo y mantenimiento de sistemas. Está alineado y diseñado para emplearse en organizaciones con modelos de procesos CMMI o ISO 15504. Fue propuesto por Watts Humphrey en 1995 y estaba dirigido a estudiantes. A partir de 1997 con el lanzamiento del libro "An introduction to the Personal Software Process" se dirige ahora a ingenieros juniors.
Se puede considerar como la guía de trabajo personal para ingenieros de software en organizaciones que emplean un modelo CMMI con nivel de madurez o de capacidad de procesos que implica la medición cualitativa y mejora de procesos.
Uno de los mayores problemas que tiene es la gran cantidad de datos que hay que tomar. El PSP tiene obsesión por la toma de datos y elaboración de tablas. El PSP se orienta el conjunto de áreas clave del proceso que debe manejar un desarrollador cuando trabaja de forma individual.
PSP, es uno de los 3 vértices donde descansa un proceso de mejora que trabaja sobre 3 niveles de la organización, los otros 2 son CMM y TSP.
El PSP amplía el proceso de mejora a la gente que realiza el trabajo de desarrollo de software, concentrándose en las prácticas de trabajo de los ingenieros en una forma individual, enseñando como manejar la calidad desde el principio de un producto. PSP son nuestras propias métricas, que permiten estructurar y ordenar nuestro trabajo del día a día. El resultado de nuestro trabajo, además puede ser llevado a un trabajo en equipo TSP (Team Process Software), el cual es “comandado” por un sistema de gestión de la configuración y por supuesto, un Jefe de Proyecto quien evalúa los resultados y avances de los miembros del equipo.

En PSP todas las tareas y actividades que el ingeniero de software debe realizar durante el proceso de desarrollo de un producto de software, están puntualmente definidas en un conjunto de documentos conocidos como scripts. Los scripts son el punto medular de PSP, por lo que se hace mucho énfasis en que deben ser seguidos en forma disciplinada, ya que de ello dependerá el éxito de la mejora que se busca. Gran parte de las tareas y actividades definidas en los scripts generará en su realización un conjunto de datos, fundamentalmente de carácter estadístico. La aplicación de PSP en varios procesos de desarrollo, y el análisis de la información estadística generada en cada uno de éstos, permitirán al ingeniero de software identificar, tanto sus fortalezas como sus debilidades, y crecer a través de un proceso de auto aprendizaje y auto mejora. La calidad en PSP, es un aspecto fuertemente relacionado con la cantidad de defectos que el producto de software contiene.

Características:

  •  Los pasos de registro de información a detalle en el nivel de medición pueden resultar frustrantes cuando se tiene presión de tiempo.
  •  En los scripts de PSP no se incluyen tareas y actividades para la etapa de análisis de requerimientos.
  •  Siempre se parte de una definición de requerimientos que no va a cambiar. Aún no existe una herramienta automatizada que facilite el registro y análisis de datos generados por la aplicación de PSP.
Objetivos:
PSP pretende formar ingenieros de software con métodos disciplinados para mejorar su desarrollo personal de software. PSP le ayuda a los desarrolladores a:
  •  Mejorar sus habilidades de estimación y planeación.
  • Hacer compromisos que se puedan cumplir.
  • Administrar la calidad de sus procesos.
  •  Reducir la cantidad de defectos en sus producto
TSP (Team Software Process), es un método de establecimiento y mejora del trabajo en equipo para procesos software.
TSP proporciona directrices para ayudar a un equipo a establecer sus objetivos, a planificar sus procesos y a revisar su trabajo con el fin de que la organización pueda establecer prácticas de ingeniería avanzadas y así obtener productos eficientes, fiables y de calidad. Está formado por dos componentes primarios que abarcan distintos aspectos del trabajo en equipo:

  •   Formación del equipo de trabajo.
  •  Gestión del equipo de trabajo.
Existen diferentes metodologías para la mejora de procesos, la mayoría de ellas se basa en la mejora de los procesos que dan como resultado un servicio o producto. El TSP busca integrar un equipo que tenga como punto de partida la unificación del mismo, para poder llevar a cabo todos aquellos procedimientos que puedan realizar mejora a los procesos que desarrollan.
El Team Software Process (TSP) es un proceso de desarrollo para equipos de ingenieros basado en CMMI, ayuda a conformar equipos para el desarrollo de software de calidad. TSP proporciona directrices para ayudar a un equipo a establecer sus objetivos, a planificar sus procesos y a revisar su trabajo con el fin de que la organización pueda establecer prácticas de ingeniería avanzadas y así obtener productos eficientes, fiables y de calidad. TSP es una solución basada en procesos para resolver problemas de negocio, tales como:

  •  Predictibilidad de costo y tiempo
  • Mejora de productividad
  •  Ciclos de desarrollo y mejora de calidad de productos.                                           
 Características de los grupos eficaces:

  • Miembros expertos en papeles de liderazgo y pertenencia.
  • Relaciones tranquilas y establecidas entre los miembros.
  •   Los miembros se sienten atraídos por el grupo y son fieles.
  • Los valores y metas del grupo son los de sus integrantes.
  • Los miembros están motivados por hacer lo que puedan por el grupo.
  • La interacción y toma de decisiones tiene lugar en el ambiente adecuado.
  •  El grupo desea ayudar a cada miembro a adquirir su pleno El grupo desea ayudar a cada miembro a adquirir su pleno potencial.
  • Cada miembro acepta con gusto y sin resentimiento las metas y normas establecidas.
  • Los miembros se prestan ayuda mutua cuando es necesaria o recomendable.
  •  Existe una atmósfera de creatividad.
  •   El grupo conoce el “conformismo constructivo” y se sirve de él.
  •  Existe gran motivación para iniciar y recibir las comunicaciones.
  •  Los miembros son flexibles y adaptables en sus metas y actitudes.
  •  Los miembros se sienten seguros al tomar decisiones que les Los miembros se sienten seguros al tomar decisiones que les parecen apropiadas al entender la filosofía de la operación.
Sus orígenes se deben a las limitaciones que el PSP (Personal Software Process, su antecesor) tenía en el ámbito industrial. PSP resultó muy efectivo para que los ingenieros pudiesen tener el control de su proceso personal mediante la mejora de sus habilidades de estimación y la reducción de los defectos introducidos en los productos sin afectar a su productividad, pero PSP sólo se enfocaba en las fases de desarrollo de software (diseño y pruebas unitarias); la aplicación que lo ingenieros hicieron del PSP dentro de las empresas resulto en prácticas no satisfactorias.
Por tal motivo, Watts Humphrey desarrolló el TSP, el cual consideraba como parte importante, además de lo previsto por el PSP, los requisitos, las pruebas de integración, la documentación y otras actividades típicas en todo proyecto de desarrollo, de igual manera incluía actividades como los roles de equipo, interrelaciones dentro de la organización y la definición de un proceso de equipo para ser utilizado dentro de los procesos existentes en la organización.

Los Roles (responsabilidades) en los equipos en STP son: 
  • Líder del Equipo: Dirige al equipo, se asegura que todos reporten sus datos de los procesos y completen su trabajo tal y como se planeó. Realiza los reportes semanales del avance del equipo.
  • Gestor de desarrollo: Guía al equipo en el diseño y desarrollo del producto.
  • Gestor de Planificación: Apoya y guía al equipo en la planificación y seguimiento del trabajo.
  • Gestor de Calidad/Proceso: Apoya al equipo en definir sus necesidades acerca del proceso y a establecer y administrar el plan de calidad. 
  • Genera estándares para obtener un trabajo uniforme. Modera las inspecciones y revisa cada artefacto generado.
  • Administrador de Requerimientos/Soporte: Dirige al equipo en el desarrollo de requerimientos de software y ayuda a dar a conocer la tecnología y en las necesidades de apoyo administrativo.
  • Administra el plan de configuración.

Es necesario que los ingenieros que usan TSP estén formados en PSP. Con TSP, los equipos encuentran y reparan defectos en etapas tempranas del proceso de desarrollo, esto reduce de manera importante el tiempo de pruebas. Esto reduce de manera importante el tiempo de pruebas. Con un testing más corto, el ciclo completo se reduce.
A diferencia de otros métodos, TSP mejora el desempeño tanto de equipos como individuos, es disciplinado y ágil, provee beneficios inmediatos y medibles y acelera las iniciativas de mejora de procesos organizacionales.

En las fases del Ciclo TSP se planea el número de ciclos. Dentro de cada ciclo se realiza:

  •  Lanzamiento
  •  Estrategia
  •   Plan
  •      Requisitos
  •   Diseño
  •  Implementación
  •     Pruebas
  •  Postmortem
     Los objetivos que tiene el TSP son:

  • Maximizar calidad software, minimizar costos.
  • Integrar equipos independientes de alto rendimiento que planeen su trabajo, establezcan metas y san sueños de sus procesos y planes.
  • Mostrar a los gerentes como monitorear y motivar a sus equipos de trabajo y como ayudarlos a alcanzar su máxima productividad
Sus entornos son:
  • CMM- Administración.
  •  TSP- Equipo Ingenieros.
  • PSP-Ingeniero.




4.4 SPICE

SPICE

El ISO/IEC 15504, también conocido como Software Process Improvement Capability Determination, abreviado SPICE, en español, Determinación de la Capacidad de Mejora del Proceso de Software,es un modelo para la mejora, evaluación de los procesos de desarrollo, mantenimiento de sistemas de información y productos de software.
En 1991, dado el número creciente dre). Por tanto, el proyecto SPICE fue creado bajo los auspicios del Comité Internacional de estándares de Ingeniería de Software y Sistemas a través de su Grupo de Trabajo sobre Evaluación de proceso (WG10).
En 1992, el informe del grupo de estudio dijo que: “...la comunidad internacional debería poner recursos para desarrollar un estándar para la evaluación de procesos software, incorporando lo mejor de los métodos de evaluación de procesos existentes.”
ISO decidió entonces se hiciera el desarrollo por pasos de un estándar para la evaluación de procesos. Los pasos fueron los siguientes:
  • Publicación inicial como Informe Técnico ‘Technical Report’ (“borrador de estándar”) 
  • Revisión y publicación como estándar internacional IS ISO/IEC 15504 
  • Tecnologías de la Información 
  •  Evaluación de Procesos (‘ISO/IEC 15504 Information Technology – Process Assessment’).
El proyecto SPICE tenía tres objetivos principales:
  • Desarrollar un borrador de trabajo para un estándar de evaluación de procesos de software.
  • Llevar a cabo los ensayos de la industria de la norma emergente.
  • Promover la transferencia de tecnología de la evaluación de procesos de software a la industria del software a nivel mundial.
El primer objetivo del proyecto se logró en junio de 1995, con la entrega del borrador de trabajo de la norma para la evaluación de procesos de software al WG10 para su votación entre la comunidad de estandarización internacional. El Borrador de Trabajo se denominaba comúnmente como el conjunto de documentos SPICE (o SPICE Versión 1).

Los ensayos de estos primeros documentos SPICE han sido el foco del proyecto SPICE durante el período 1994 a 1998. Fue entonces, en 1998 cuando se publicó la primera familia de estándares ISO TR 15504. En aquel momento se comenzó a trabajar en la versión "Internacional Standard" de la norma, y desde 2006 está completamente publicado, exceptuadas las partes nuevas que se estén produciendo.
En marzo de 2003, el proyecto SPICE se cerró oficialmente. La Red SPICE se estableció posteriormente con el encargo de seguir coordinando las actividades de la comunidad SPICE. La Red de SPICE está formalmente organizada por el ‘The Spice User Grupo’ (www.spiceusergroup.org).
En este momento se efectúan actividades promocionales que se realizan a través de la Conferencia Internacional Anual SPICE y la publicación de artículos y libros.
Con el fin de apoyar la excelencia y la coherencia de la formación de los evaluadores, el proyecto SPICE también desarrolló y lanzó un Plan de Estudios de formación de los evaluadores SPICE que es utilizado actualmente por el Esquema de Registro Internacional de Evaluadores (IntRSA).


4.3 MOPROSOFT

MOPROSOFT

Es el Modelo de Procesos para la Industria del Software. Un modelo para la mejora y evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software. Desarrollado por la Asociación Mexicana para la Calidad en Ingeniería de Software a través de la Facultad de Ciencias de la Universidad Nacional Autónoma de México (UNAM) y a solicitud de la Secretaría de Economía para obtener una norma mexicana que resulte apropiada a las características de tamaño de la gran mayoría de empresas mexicanas de desarrollo y mantenimiento de software.

El Programa para el Desarrollo de la Industria del Software (PROSOFT), es un plan de la Secretaría de Economía de México que forma parte del Plan Nacional de Desarrollo 2001-2006. Y está vigente a la fecha.
PROSOFT tiene siete líneas estratégicas, siendo la sexta la que ha dado origen a MoProSoft: "Alcanzar niveles internacionales en capacidad de procesos". Al comenzar el desarrollo de esta línea estratégica se evaluó la adopción de los modelos: ISO 9000, ISO 15504, SW-CMM. El resultado de la evaluación fue: "Ninguno de los estándares o modelos cumple con los requisitos expresados por la industria nacional", y se decidió la elaboración de un modelo adecuado para las características de las empresas mexicanas, que se basaría en los modelos evaluados.

Procesos que maneja Moprosoft:
Categoría alta dirección (DIR): La alta dirección tiene un papel importante a través de la planificación estratégica. Debe actuar como promotor del buen funcionamiento de la organización a través de su implicación en la revisión y mejora continua del modelo.

Gestión de Negocio


Categoría Gerencia (GER): El modelo considera a la gestión como proveedora de recursos, procesos y proyectos; así como responsable de la vigilancia del cumplimiento de los objetivos estratégicos de la organización:
  • Gestión de Proceso.
  • Gestión de Proyectos.
  • Gestión de Recursos Humanos y Ambiente de Trabajo o Bienes Servicios e Infraestructura o Conocimiento de la Organización.
Categoría Operación (OPE): El modelo considera a la operación como ejecutora de los proyectos de desarrollo y mantenimiento de software.
  • Administración de Proyectos Específicos
  • Desarrollo y Mantenimiento de Software. 
  •  El Programa para el Desarrollo de la Industria de Software (PROSOFT) fue implementado en octubre de 2002.
  • Recursos finales.
En cada categoría se establecen roles y actividades a desarrollar, así como un responsable, una empresa o persona se puede certificar en MOPROSOFT para poder aplicar el modelo a sus desarrollos de software.

4.2 NORMA DE EVALUACIÓN ISO/IEC 9126

NORMA DE EVALUACIÓN ISO/IEC 9126

Esta norma Internacional fue publicada en 1992, la cual es usada para la evaluación de la calidad de software, llamado “Information technology-Software product evaluation-Quality characteristics and guidelines for their use”; o también conocido como ISO 9126 (o ISO/IEC 9126). Este estándar describe 6 características generales: Funcionalidad, Confiabilidad, Usabilidad, Eficiencia, Mantenibilidad, y Portabilidad.

 La norma ISO/IEC 9126 permite especificar y evaluar la calidad del software desde diferentes criterios asociados con adquisición, requerimientos, desarrollo, uso, evaluación, soporte, mantenimiento, aseguramiento de la calidad y auditoria de software. Los modelos de calidad para el software se describen así:

Calidad interna y externa: Especifica 6 características para calidad interna y externa, las cuales, están subdivididas. Estas divisiones se manifiestan externamente cuando el software es usado como parte de un sistema Informático, y son el resultado de atributos internos de software.

Calidad en uso: Calidad en uso es el efecto combinado para el usuario final de las 6 características de la calidad interna y externa del software. Especifica 4 características para la calidad en uso.

Al unir la calidad interna y externa con la calidad en uso se define un modelo de evaluación más completo, se puede pensar que la usabilidad del modelo de calidad externa e interna pueda ser igual al modelo de calidad en uso, pero no, la usabilidad es la forma como los profesionales interpretan o asimilan la funcionabilidad del software y la calidad en uso se puede asumir como la forma que lo asimila o maneja el usuario final. Si se unen los dos modelos, se puede definir que los seis indicadores del primer modelo tienen sus atributos y el modelo de calidad en uso sus 4 indicadores pasarían hacer sus atributos, mirándolo gráficamente quedaría así:

Se establecen categorías para las cualidades de la calidad externa e interna y calidad en uso del software, teniendo en cuenta estos 7 indicadores (funcionalidad, confiabilidad, utilidad, eficiencia, capacidad de mantenimiento, portabilidad y calidad en uso), que se subdividen a su vez en  varios indicadores; estas se pueden medir por métrica interna o externa.

Las definiciones se dan para cada característica y subcaracterística de calidad del software que influye en la calidad. Para cada característica y subcaracterística, la capacidad del software es determinada por un conjunto de atributos internos que pueden ser medidos. Las características y subcaracterísticas se pueden medir externamente por la capacidad del sistema que contiene el software.


FUNCIONALIDAD

Funcionalidad es la capacidad del software de cumplir y proveer las funciones para satisfacer las necesidades explícitas e implícitas cuando es utilizado en condiciones específicas. A continuación se muestra la característica de Funcionalidad y las subcaracterísticas que cubre:

La funcionalidad se divide en 5 criterios:
Adecuación: La capacidad del software para proveer un adecuado conjunto de funciones que cumplan las tareas y objetivos especificados por el usuario.

 Exactitud: La capacidad del software para hacer procesos y entregar los resultados solicitados con precisión o de forma esperada.

Interoperabilidad: La capacidad del software de interactuar con uno o más sistemas específicos.

Seguridad: La capacidad del software para proteger la información y los datos de manera que los usuarios o los sistemas no autorizados no puedan acceder a ellos para realizar operaciones, y la capacidad de aceptar el acceso a los datos de los usuarios o sistemas autorizados

Conformidad de la funcionalidad: La capacidad del software de cumplir los estándares referentes a la funcionalidad.

CONFIABILIDAD

La confiabilidad es la capacidad del software para asegurar un nivel de funcionamiento adecuado cuando es utilizando en condiciones específicas. En este caso a la confiabilidad se amplía sostener un nivel especificado de funcionamiento y no una función requerida.

 La confiabilidad se divide en 4 criterios:

Madurez: La capacidad que tiene el software para evitar fallas cuando encuentra errores. Ejemplo, la forma como el software advierte al usuario cuando realiza operaciones en la unidad de diskett vacía, o cuando no encuentra espacio suficiente el disco duro donde esta almacenando los datos.

Tolerancia a errores: La capacidad que tiene el software para mantener un nivel de funcionamiento en caso de errores.

Recuperabilidad: La capacidad que tiene el software para restablecer su funcionamiento adecuado y recuperar los datos afectados en el caso de una falla.

Conformidad de la fiabilidad: La capacidad del software de cumplir a los estándares o normas relacionadas a la fiabilidad.

USABILIDAD

La usabilidad es la capacidad del software de ser entendido, aprendido, y usado en forma fácil y atractiva. Algunos criterios de funcionalidad, fiabilidad y eficiencia afectan la usabilidad, pero para los propósitos de la ISO/IEC 9126 ellos no clasifican como usabilidad. La usabilidad está determinada por los usuarios finales y los usuarios indirectos del software, dirigidos a todos los ambientes, a la preparación del uso y el resultado obtenido.

 La usabilidad se divide en 5 criterios:

Entendimiento: La capacidad que tiene el software para permitir al usuario entender si es adecuado, y de una manera fácil como ser utilizado para las tareas y las condiciones particulares de la aplicación. En este criterio se debe tener en cuenta la documentación y de las ayudas que el software entrega.
Aprendizaje: La forma como el software permite al usuario aprender su uso. También es importante considerar la documentación.

Operabilidad: La manera como el software permite al usuario operarlo y controlarlo.

Atracción: La presentación del software debe ser atractiva al usuario. Esto se refiere a las cualidades del software para hacer más agradable al usuario, ejemplo, el diseño gráfico.

Conformidad de uso: La capacidad del software de cumplir los estándares o normas relacionadas a su usabilidad.

EFICIENCIA

La eficiencia del software es la forma del desempeño adecuado, de acuerdo a al número recursos utilizados según las condiciones planteadas. Se debe tener en cuenta otros aspectos como la configuración de hardware, el sistema operativo, entre otros.

La eficiencia se divide en 3 criterios:
Comportamiento de tiempos: Los tiempos adecuados de respuesta y procesamiento, el rendimiento cuando realiza su función en condiciones específicas. Ejemplo, ejecutar el procedimiento más complejo del software y esperar su tiempo de respuesta, realizar la misma función pero con más cantidad de registros.

Utilización de recursos: La capacidad del software para utilizar cantidades y tipos adecuados de recursos cuando este funciona bajo requerimientos o condiciones establecidas. Ejemplo, los recursos humanos, el hardware, dispositivos externos.

Conformidad de eficiencia: La capacidad que tiene el software para cumplir con los estándares o convenciones relacionados a la eficiencia.

CAPACIDAD DE MANTENIMIENTO

La capacidad de mantenimiento es la cualidad que tiene el software para ser modificado. Incluyendo correcciones o mejoras del software, a cambios en el entorno, y especificaciones de requerimientos funcionales.

El mantenimiento se divide en 5 criterios:

Capacidad de ser analizado: La forma como el software permite diagnósticos de deficiencias o causas de fallas, o la identificación de partes modificadas.

Cambiabilidad: La capacidad del software para que la implementación de una modificación se pueda realizar, incluye también codificación, diseño y documentación de cambios.

Estabilidad: La forma como el software evita efectos inesperados para modificaciones del mismo.

Facilidad de prueba: La forma como el software permite realizar pruebas a las modificaciones sin poner el riesgo los datos.

Conformidad de facilidad de mantenimiento: La capacidad que tiene el software para cumplir con los estándares de facilidad de mantenimiento.

Portabilidad
La capacidad que tiene el software para ser trasladado de un entorno a otro.

La usabilidad se divide en 5 criterios:

Adaptabilidad: Es como el software se adapta a diferentes entornos especificados (hardware o sistemas operativos) sin que implique reacciones negativas ante el cambio. Incluye la escalabilidad de capacidad interna (Ejemplo: Campos en pantalla, tablas, volúmenes de transacciones, formatos de reporte, etc.).

Facilidad de instalación: La facilidad del software para ser instalado en un entorno específico o por el usuario final.

Coexistencia: La capacidad que tiene el software para coexistir con otro o varios software, la forma de compartir recursos comunes con otro software o dispositivo.

Reemplazabilidad: La capacidad que tiene el software para ser remplazado por otro software del mismo tipo, y para el mismo objetivo. Ejemplo, la remplazabilidad de una nueva versión es importante para el usuario, la propiedad de poder migrar los datos a otro software de diferente proveedor.

Conformidad de portabilidad: La capacidad que tiene el software para cumplir con los estándares relacionados a la portabilidad.

CALIDAD EN USO

Calidad en uso es la calidad del software que el usuario final refleja, la forma como el usuario final logra realizar los procesos con satisfacción, eficiencia y exactitud. La calidad en uso debe asegurar la prueba o revisión de todas las opciones que el usuario trabaja diariamente y los procesos que realiza esporádicamente relacionados con el mismo software.


La calidad de uso se divide en 4 criterios:

Eficacia: La capacidad del software para permitir a los usuarios finales realizar los procesos con exactitud e integridad.

Productividad: La forma como el software permite a los usuarios emplear cantidades apropiadas de recursos, en relación a la eficacia lograda en un contexto específico de uso. Para una empresa es muy importante que el software no afecte a la productividad del empleado

Seguridad: Se refiere al que el Software no tenga niveles de riesgo para causar daño a las personas, instituciones, software, propiedad intelectual o entorno. Los riesgos son normalmente el resultado de deficiencias en la funcionalidad (Incluyendo seguridad), fiabilidad, usabilidad o facilidad de mantenimiento.

Satisfacción: La satisfacción es la respuesta del usuario a la interacción con el software, e incluye las actitudes hacia el uso del mismo. A continuación se describe un cuadro donde podemos resumir las características y cada uno de sus atributos, este cuadro le ayudara a visualizar el proceso de evaluación.