miércoles, 20 de abril de 2016

MODELOS PARA EL ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE

¿Qué es un modelo de Calidad?
Un modelo de calidad es una metodología que permite a cualquier organización realizar una autoevaluación, por medio de una revisión sistemática de sus estrategias y prácticas de gestión.
Un modelo de calidad del software es un conjunto de buenas prácticas para el ciclo de vida del software, enfocado en los procesos de gestión y desarrollo de proyectos.

Un modelo de calidad del software nos dice QUÉ hacer más no CÓMO hacerlo.

CMMI (Modelo de Capacidad de Madurez Integrado)
Este modelo proporciona una buena oportunidad para evitar y eliminar barreras a través de modelos integrados que trascienden a las disciplinas. Los modelos del CMMI consisten en las mejores prácticas que están dirigidas al desarrollo y mantenimiento del producto, y se dirige también a las prácticas que están dirigidas al desarrollo y mantenimiento del producto, desde su planeación, entrega y mantenimiento.
Este modelo se creó para resolver el problema de usar múltiples CMMs.
HISTORIA DE CMMI



OBJETIVOS DE CMMI BUENOS PARA EL NEGOCIO

  • Producir servicios y productos de alta calidad
  • Crear valor para los accionistas
  • Mejorar la satisfacción del cliente
  • Incrementar la participación en el mercado
  • Ganar reconocimiento en la industria
NIVELES DE MADUREZ POR ETAPAS
CMMI tiene 5 niveles de madurez los cuáles son:

  • Nivel 1 (Inicial): El proceso es impredecible, es reactivo y probablemente controlado.

Los procesos son ad hoc y caóticos.
Se producen productos y servicios que funcionan, pero frecuentemente se excede y no se cumplen los calendarios.
Se comprometen con exceso, a abandonar los procesos en tiempos de crisis y a una incapacidad para repetir sus éxitos.

  • Nivel 2 (Administrado): El proceso es reactivo y se caracteriza por su aplicación a proyectos.

Los productos de trabajo y servicios se controlan de forma apropiada. Los productos de trabajo y servicios satisfacen sus descripciones de proceso especificadas, estándares y procedimientos.

  • Nivel 3 (Definido): El proceso es proactivo y se ve a nivel de la organización.

Los procesos son bien caracterizados y comprendidos, y se describen en estándares, procedimientos, herramientas y métodos. 
Los procesos se describen más rigurosamente y se aplican las prácticas genéricas asociadas con la meta genérica.

  • Nivel 4 (Administrado Cuantitativamente): El proceso es medido y controlado.

La organización y los proyectos establecen  objetivos cuantitativos en cuanto al rendimiento de calidad y del proceso, y los utilizan como criterios en la gestión de los procesos.
En este nivel el rendimiento de los procesos se controla utilizando técnicas estadísticas y otras técnicas cuantitativas.

  • Nivel 5 (Optimizado): El proceso se enfoca en la mejora.

La organización mejora continuamente sus procesos basándose en una comprensión cuantitativa de las causas comunes de variaciones inherentes a los procesos. 

El nivel de madurez 5 se centra en mejorar continuamente el rendimiento de procesos mediante mejoras incrementales e innovadoras de proceso y tecnológicas.


MOPROSOFT
(Modelo de Proceso de Software)


Se desarrollo a solicitud de la Secretaría de Economía para servir de base a la Norma Mexicana para la Industria de Desarrollo y Mantenimiento de Software bajo convenio con la Facultad de Ciencias de la Universidad Nacional Autónoma de México.
Este modelo se aplica a las pequeñas y medianas empresas desarrolladoras de software y tomo como referencia CMMI, ISO 15504, PMBOK e ISO 9000:2000.

MOPROSOFT es un conjunto de mejores prácticas para el desarrollo del software, está enfocado desde el punto de vista organizacional.
ESTRUCTURA
  • Categoría de Alta Dirección (DIR): Se establecen los lineamientos para los procesos de la Categoría de Gerencia y se retroalimenta con la información generada por ellos en apoyo a la estrategia de la organización.
  • Categoría de Gerencia (GER): Se definen los elementos para el funcionamiento de los procesos de la Categoría de Operación en función de la estrategia de Dirección, recibe y evalúa información generadas por estos y comunica los resultados a la categoría de Alta Dirección.
  • Categoría de Operación (OPE): Se realizan las actividades de acuerdo a los elementos proporcionados por la Categoría de Gerencia y entrega a a ésta la información y productos generados.
NIVELES
  1. Realizado
  2. Gestionado
  3. Establecido
  4. Predecible
  5. Optimizado



En mi opinión, implementar una modelo de calidad como lo es CMMI o MOPROSOFT en una empresa de desarrollo de software facilitaría la ejecución de los procesos.
Así mismo, implementar un modelo puede ser costoso para la organización, pero es una buena inversión ya que garantizas calidad a tus clientes y lo más importante es que se reducen costos, cuándo adquieres un nivel de madurez más alto son más los ahorros que tienes.








VORTICE IT

El área de TI tiene una gran oportunidad en el estado de Querétaro y un reflejo de esto es que el estado tiene un clúster de empresas de Tecnologías de la Información.


El área de TI puede complementarse con otras áreas cómo con el sector aeronáutico, el cuál también se desarrolla en el estado.
El sector aeronáutico requiere que el área de TI se involucre y a la vez se complementen en áreas como:

  • Cloud Computing
  • Sistemas de simulación
  • Advance and additive Manufacturing
  • Móvilidad
  • Enterprise Resource Planning
  • Customer Relationship Management
  •  Supply Chain Management
  • Product Lifecycle Management
  • Internet of yhings
  • Machine Learning
  • APPS
  • Guardia Digital
  • Biometric Chapture
  • Big Data
  • Quantium Computer
  • Transmisión de Energía.
Estas son la áreas de oportunidad que el sector aeronáutico ofrece al sector de TI y que debemos aprovechar.

 EMPRESA DEL CLÚSTER VORTICE IT CON CERTIFICACIONES DE CALIDAD



HISTORIA
Es una empresa Brasileña fundada en 1987 como una compañía de capacitación, Stefanini se ha convertido en una importante empresa multinacional de tecnología.
En 1989 fue la apertura de la primera oficina.
En 1990 inicio como desarrollando y dando mantenimiento a sistemas.
En 2000 México y Chile integran la segunda fase de expansión internacional con esta empresa.
En 2005 Obtiene una de las certificaciones más valoradas en el mundo de las TI: CMMI - Nivel 5.
En 2009 obtiene la certificación MPS.BR nivel A.
En 2014 inicio operaciones en Malasia, reforzando la estrategia de crecimiento en el mercado asiático, y la obtención de la certificación ISO 27001.
MISIÓN, VISIÓN Y VALORES
  1. Misión: Transformar en realidad los sueños de sus clientes, colaboradores y accionistas, por medio de soluciones de Tecnologías e Innovación.
  2. Visión: Ser el mejor proveedor de Tecnología, ser reconocida a nivel global, y admirado como un socio estratégico, actuando con pasión y energía para conquistar nuevos clientes.
  3. Valores: Integridad, Energía y actitud positiva, Respeto, Enfoque en resultado sostenible.

CERTIFICACIONES
Stefanini cuenta con las siguientes certificaciones:
  • NMR ISO 9001:2008
  • CMMI-5
  • MPS/BR - Nivel A: esta certificación valora la reutilización del sistema y ofrece siete niveles que van de A, mayor grado de madurez, a G. Además es parte de un grupo selecto de cuatro compañías nacionales que lograron obtener la misma certificación.
  • MoProSoft: Es la primera empresa brasileña avalada y aprobada en el modelo mexicano MoProSoft.
  • ISO 27001: la norma más respetada en seguridad de información y referencia mundial.
  • ISO 20000: la norma más respetada mundialmente en gestión de servicios. 
Referencias:
https://stefanini.com/es/quienes-somos/certificaciones-y-autorizaciones/

jueves, 31 de marzo de 2016

TÉCNICAS DE ESTIMACIÓN

Cuándo se definen las métricas de Software, se pueden considerar  diferentes técnicas para realizar la estimación.
Es muy importante realizar una estimación al momento de planear el desarrollo de un software para estimar el costo del proyecto, el recurso humano, el tiempo y los recursos que se usarán para el mismo.
Técnicas de Estimación

Puntos de Casos de Uso
La metodología de los puntos de casos de uso es una derivación de la metodología de puntos de función propuesta por Albretch. Este método de estimación fue desarrollado en 1993 por Gustav Karner de Rational Software, quien se basa en una metodología orientada a objetos y en la utilización de casos de uso como datos de entrada para calcular el esfuerzo en horas hombre (hh) que son necesarias para el desarrollo de un proyecto de software. 

Objetivo de la técnica
Estimar las horas necesarias para ejecutar un conjunto de casos de uso. Es decir, se necesita predecir cuanto tiempo llevara el desarrollo de software y cuantas personas se requieren para realizarlo. Para ello, es necesario cuantificar la complejidad del sistema y el tiempo necesario para producir una unidad de complejidad.

Clasificación de los Casos de Uso
Los casos de uso son clasificados de acuerdo a la cantidad de transacciones que poseen, incluyendo las transacciones de escenarios alternativos y excluyendo las extensiones o incluso de otros casos de uso. Un caso de uso simple (peso=5) es aquel que posee 3 o menos transacciones; uno medio (peso=10)  es aquel que posee de 4 a 7 transacciones; y un caso de uso complejo (peso=15)  es aquel que posee más de 7 transacciones. A   cada caso de uso le corresponde un peso. 

Factor de Complejidad Técnica del Proyecto de Software
Los factores técnicos (T) están definidos por las influencias técnicas que puedan afectar el proceso de desarrollo del sistema a construir. Cada factor técnico posee un grado de complejidad, que oscila entre 0 y 5, donde 0 significa un valor irrelevante o nulo y 5 determina un valor con alto grado de influencia. Cada factor técnico posee un valor de peso.

Factores de entorno del proyecto
Los factores de entorno (E) indican la influencia del grupo humano involucrado en el proyecto sobre el sistema a desarrollar. De manera similar a los factores técnicos, los factores de entorno poseen un grado de influencia que oscila entre 0 y 5, donde 0 significa un valor irrelevante o nulo y 5 determina un valor con alto grado de influencia. Cada factor de entorno posee un valor de peso. 


Pasos para determinar la estimación
Para determinar la estimación de los Puntos de Caso de Uso se deben cumplir los siguientes pasos:
  • Clasificar los actores para determinar el valor de UAW (Unadjusted Actor Weight).
UAW=Sumatoria de todos los pesos de los actores identificados.
  • Clasificar los casos de uso para determinar el valor de UUCW (Unadjusted Use Case Weight).
UUCW=Sumatoria de los pesos de los casos de uso.
  • Determinar el valor del UUCP (Unajusted Use Case Point, Puntos de Casos de Uso No Ajustados)
UUCP=UAW+UUCW
  • Determinar el valor de TCF (Technical Complexity Factor, Factores Técnicos de Complejidad)
TCF=0.6+(0.01*∑(T1 … T3)).
  • Determinar el valor de EF (Enviroment Factor, Factores de Entorno)
EF=1.4+(-0-03*∑(E1…E8))

  • Determinar el valor de AUCP(Adjusted Use Case Point)
AUCP=UUCP*TFC*EF
Karner establece un factor de 20hr hombre por punto de caso de uso para realizar la estimación de un proyecto de software.
UCP=AUCP*20
El valor de Use Case Point (UCP) obtenido indica el esfuerzo de horas hombre que se deben invertir para desarrollar el proyecto de software.
ESTIMACIÓN DEL ESFUERZO
Una vez obtenido el tamaño, se puede obtener el esfuerzo. Para ello se utiliza la expresión:
Esfuerzo=UCP* Factor de Productividad
El método originario propone usar un factor de ajuste similar al que se usa en el método de Puntos de Función clásico.
Contar los factores de entorno entre R1 y R6 cuya influencia es inferior a 3 (influencia promedio) y los factores de entorno entre R7 y R8 que son superiores a 3.
Entonces:
  • 20 horas-hombre por UCP si el valor es =2
  • 28 horas-hombre por UCP si el valor es=4
  • 36 horas-hombre por UCP si el valor es=5, en este caso se debería replantear el proyecto.

Puntos de Función

La técnica de Análisis de Puntos de Función fue introducida por Allan Albrecht de IBM. Albrecht comenzó a analizar sistemas buscando identificar los factores críticos que determinan el tamaño del software y por consiguiente, estimar el esfuerzo y el costo de desarrollarlo. Luego de analizar cientos de sistemas, nació la técnica de Análisis de Puntos por función. La técnica mide una aplicación con base en las funciones que éste realiza para y por solicitud del usuario final. 
Componentes de los Puntos de Función (PF)

La técnica mide lo que es el sistema y no como será o cómo será diseñado.
Características de los Puntos de Función:
  • Método independiente de las herramientas de análisis, diseño y programación, ya que solo se preocupa de la complejidad de las funciones a implementar.
  • Requerir de una descomposición funcional del proyecto a realizar, que se detecten todas las piezas elementales que componen el producto final.
  • Estimar la cantidad de Puntos de Función de las funciones medidas, se realiza contando la cantidad de entradas, salidas, archivos, consultas e interfaces que se utilizan. Entre mayor cantidad, mayor es el peso de complejidad que se le asignará.
  • Ajustar la estimación del esfuerzo requerido, para determinar la presencia de ciertos elementos que dificultan el desarrollo del proyecto.
  • Permitir realizar una estimación del esfuerzo requerido en etapas tempranas del proyecto. 
Para desarrollar la técnica de puntos de función se debe desarrollar una serie de pasos los cuáles se pueden ver en el siguiente link:
O se puede seguir el desarrollo que se explica en los siguientes vídeos.







El uso de técnicas de estimación es muy importante al momento de desarrollar software para poder mostrar al cliente una estimación del costo del proyecto y del tiempo, de acuerdo a los requerimientos que especifica.

jueves, 3 de marzo de 2016

MÉTRICAS DE SOFTWARE

MÉTRICA DE SOFTWARE
Es la aplicación continua de mediciones basadas en técnicas para el proceso de desarrollo del software y sus productos, de esta forma poder suministrar información relevante a tiempo y así el administrador junto con el empleo de estas técnicas mejorara el proceso y sus productos.

ACTIVIDADES DEL PROCESO DE MEDICIÓN
  • Formulación: La obtención de medidas y métricas del software apropiadas para la representación de software en cuestión.
  • Colección: El mecanismo empleado para acumular datos necesarios para obtener las métricas formuladas.
  • Análisis: Es 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: Recomendaciones obtenidas de la interpretación de métricas técnicas transmitidas al equipo de software.
MÉTRICAS DE PRODUCTO
  • Se centran en las características del software y no en cómo fue producido.
  • También son productos los artefactos, documentos, modelos, y componentes que conforman el software.
  • Se miden cosas como el tamaño, la calidad, la totalidad, la volatilidad, y el esfuerzo.
MÉTRICAS DE PROCESO

Evalúan el proceso en sí de fabricación del producto correspondiente. Ejemplos de este tipo de métricas:
  • Tiempo de desarrollo del producto.
  • Esfuerzo que conlleva dicho desarrollo.
  • Número y tipo de recursos empleados (personas, máquinas. etc).
  • Costo del proceso.

Se emplean para fines estratégicos.
Se recopilan de todos los procesos y durante un largo periodo de tiempo.
MÉTRICAS DE PROYECTO
  • Permiten evaluar el estado del proyecto
  • Permiten seguir la pista de los riesgos
  • Son tácticas, las cuales permitirán al desarrollador de proyectos del software una evaluación al proyecto que sigue en continuo desarrollo, equivalente podrá ver los defectos que logren provocar riesgos a largo plazo (áreas problema) y observar si el área de trabajo (equipo) y las distintas tareas se ajustarán. 
MÉTRICAS DE CALIDAD
Las métricas de calidad ayudan a evaluar los modelos de análisis y diseño en donde proporcionarán una indicación de la complejidad de diseños procedimentales y de código fuente, y ayudan en el diseño de pruebas más efectivas.
Modelos:
  • MCCALL: Describe la calidad como un concepto elaborado mediante relaciones jerárquicas entre los factores de calidad, en base a criterios. Los factores de calidad se concentran en tres aspectos importantes de un producto de software: características operativas, capacidad de cambios y adaptabilidad a nuevos entornos.
  •  FURPS: Modelo desarrollado por Hewlett-Packard (HP) en 1987, desarrollando un conjunto de factores de calidad de software y sus respectivos atributos.
    Se basa en el modelo MCCALL y se utilizan para establecer métricas de la calidad para todas las actividades del proceso de desarrollo de un software, inclusive de un sistema de información. 
  • GILB: Definido en 1988 por Gilb, presenta como aspecto fundamental la definición de los atributos y el nivel de calidad que debe tener cada uno de ellos para satisfacer al usuario. La especificación de requisitos de calidad la realiza conjuntamente el usuario con el analista.
  • DROMEY: 
  1. Resalta el hecho de que la calidad del producto es altamente determinada por los componentes del mismo (incluyendo documentos de requerimientos, guías de usuario, diseños y código).
  2. Sugiere el uso de cuatro categorías que implican propiedades de calidad que son: Correctitud, internas, contextuales y descriptivas. 
  • ISO 9126: 
El modelo ISO/IEC 9126  presenta el concepto de calidad en uso, la calidad externa y la calidad interna que corresponden con la visión del productor y del producto.
  1. Este modelo de ha desarrollado en un intento de identificar los atributos más importantes para la calidad interna y externa en un producto software.
  2. Define a la calidad interna como la totalidad de las características del producto software desde una perspectiva interna.
  3. La calidad externa se define como la totalidad de las características del producto software desde una perspectiva externa. 

  • MOSCA:  
Consta de 4 niveles: dimensiones, categorías, características y las métricas.
  1. Nivel 0. Dimensiones. Eficiencia del proyecto, efectividad del proceso, eficiencia del producto y efectividad del producto.
  2. Nivel 1. Categorías. Se contemplan 11 categorías: Producto: Funcionalidad (FUN), Fiabilidad (FIA), Usabilidad (USA), Eficiencia (EFI), Mantenibilidad (MAB) y Portabilidad (POR). Proceso: Cliente-Proveedor (CUS), Ingeniería (ENG), Soporte (SUP), Gestión (MAN) y Organizacional (ORG).
  3. Nivel 2. Características. Cada categoría tiene asociado un conjunto de características (56 asociadas al producto y 27 al proceso de desarrollo), las cuales definen las áreas claves a satisfacer para lograr, asegurar y controlar la calidad tanto en el producto como en el proceso.
  4. Nivel 3. Métricas. Para cada característica se propone una serie de métricas utilizadas para medir la calidad sistémica. 

Implementar métricas en el proceso de desarrollo de software garantizara a los clientes que su software será de calidad y que durante el desarrollo se cumplirá con cada requerimiento que se definió para cada fase  el tiempo estimado. A su vez el uso de métricas reduce los costos en el desarrollo ya que permite que se aprovechen todos los recursos en el menor tiempo posible y de esta manera entregar un producto funcional a los clientes que sea mantenible, robusto y sobre todo que se pueda adaptable.



viernes, 26 de febrero de 2016

PSP

PERSONAL SOFTWARE PROCESS

El Personal Software Process (PSP) es un modelo que se deriva del Modelo de capacidad y madurez (CMM) y fue definido por Watts S. Humphrey en el Instituto de Ingeniería del Software Engineering Institute (SEI) en la Carnegie Mellon University.
Este modelo nace de la necesidad de reducir los costos de un "test and fix" y fue diseñado para ser utilizado en cualquier lenguaje de programación y cualquier metodología de diseño.
PSP es un modelo que se concentra en las prácticas de trabajo de los ingenieros en una forma individual.
PSP se diseño con el fin de ayudar a profesionales del software a utilizar constantemente prácticas sanas de ingeniería de software y sirve para producir software de calidad.




PSP se basa en principios de planeación y calidad que indican a los ingenieros como deben de trabajar con este proceso.
Es por esto que el primer paso en el proceso PSP es la planificación y dentro de esta es muy importante definir los requerimientos. Después de esto se debe realizar la estimación de tamaño y del esfuerzo.

Tener una planificación desde el principio ayudara a reducir los costos por pruebas y corrección, ya que es más sencillo corregir desde las primeras fases de desarrollo del proyecto que en las fases de prueba y Post Mortem. Los ingenieros deben de adoptar nuevas prácticas para que el desarrollo de software sea de calidad y se lleven a cabo de una manera más productiva.
Invertir en aprender este proceso es una gran ventaja, aunque implica un gran compromiso ya que para aprender este proceso se deben invertir aproximadamente 130 horas y después se debe aprender a definir los tiempos para la implementación de lo Scripts. 
ELEMENTOS DE PSP
  •  Scripts: definen pasos para cada etapa del proceso.
  •  Logs y Forms: templates para registrar y almacenar datos.
  • Guía Estándar: indica la manera de realizar el trabajo.
Referencia: http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/gonzalez_d_h/capitulo2.pdf

viernes, 29 de enero de 2016

ANDROID

¿Qué hace de Android especial?

En la actualidad existen muchas plataformas para móviles (iPhone, Symbian, Windows Phone, BlackBerry, Palm, Java Mobile Edition, Linux Mobile), sin embargo Android presenta una serie de características que lo hacen diferente. Es el primero que combina en una misma solución las siguientes cualidades:

  • Plataforma realmente abierta: Es una plataforma de desarrollo libre basada en Linux y de código abierto. 
  • Adaptable a cualquier tipo de hardware: Actualmente podemos encontrar el S.O Android en dispositivos como teléfonos, tabletas, relojes, cámaras, electrodomésticos y gran variedad de sistemas empotrados que se basan en este sistema operativo. La aplicación ha de funcionar correctamente en dispositivos con gran variedad de tipos de entrada, pantalla, memoria, etc. Contrastando con la estrategia de Apple. En iOS tenemos que desarrollar una aplicación para iPhone y otra diferente para iPad.
  • Portabilidad asegurada: Las aplicaciones finales son desarrolladas en Java lo que nos asegura que podrán ser ejecutados en cualquier tipo de CPU, tanto presente como futuro. Esto se consigue gracias al concepto de máquina virtual.
  •  Arquitectura basada en componentes inspirados en internet: El diseño de la interfaz de usuario se hace en XML, lo que permite que una misma aplicación se ejecute en un móvil de pantalla reducida o en TV.
  •  Filosofía de dispositivos siempre conectado a internet
  •  Gran cantidad de servicios incorporados: La localización basada en GPS como en redes, bases de datos con SQL, reconocimiento y síntesis de voz, navegador, multimedia, etcétera.
  •  Aceptable nivel de seguridad: Los programas se encuentran aislados unos de otros gracias al concepto de ejecución dentro de una caja que hereda de Linux. Además, cada aplicación dispone de una serie de permisos que limitan su rango de actuación.
  • Optimizado para baja potencia y poca memoria: Android utiliza una máquina virtual Dalvik. Se trata de una implementación de Google de la máquina virtual de Java optimizada para dispositivos móviles.
  • Alta calidad de gráficos y sonido: Gráficos vectoriales suavizados, animaciones inspiradas en Flash, gráficos en 3 dimensiones basados en OpenGL. Incorpora codecs estándar más comunes de audio y vídeo.   

Tomás Girones, J. (2013). El gran libro de Android. México: Alfaomega.




El SO operativo Android ha ganado un gran mercado en los últimos años, gracias a su portabilidad y facilidad de uso. Cada vez más tiene más usuarios y una gran ventaja es que el SO es de código abierto y por esto se puede adaptar a nuevos requerimientos de los usuarios.
Otra ventaja es que se puede usar en varios dispositivos como Smartphones, Tablets e incluso Smart Watch.

    FACTORES Y CARACTERÍSTICAS DE LA CALIDAD DEL SOFTWARE

    FACTORES Y CARACTERÍSTICAS DE LA CALIDAD DEL SOFTWARE

    Los factores de calidad que afectan a la calidad del software se dividen en dos grupos:
    • Los que miden directamente.
    • Los que se miden directamente.

    En cada caso debe presentarse una medición. Se debe comparar el software con algún conjunto de datos y obtener así algún indicio sobre la calidad.

    MANTENIBIIDAD

    (Asociación Española para la Calidad, 2016) Capacidad de un elemento, bajo determinadas condiciones de uso, para conservar, o ser restaurado a, un estado en el que pueda realizar la función requerida, cuando el mantenimiento se realiza bajo determinadas condiciones y usando procedimientos y recursos establecidos.
    (openstax CNX, 2016) El IEEE (19990) define mantenibilidad como: “La facilidad con la que un sistema o componente software puede ser modificado para corregir fallos, mejorar su funcionamiento u otros atributos o adaptarse a cambios en el entorno”.
    Esta definición está directamente conectada con la definición del IEEE para mantenimiento del software: “es el proceso de modificar un componente o sistema software después de su entrega para corregir fallos, mejorar su funcionamiento u otros atributos o adaptarlo a cambios en el entorno”.
    En consecuencia, la mantenibilidad es una característica de calidad del software relacionada con la facilidad de mantenimiento.
    A mayor mantenibilidad, menores costes de mantenimiento (y viceversa).

    PORTABILIDAD

    (EcuRed, 2016) Es la propiedad de un programa o una aplicación informática que le permite funcionar bajo diferentes sistemas. Cuando el programa informático es portable puede ser utilizado en diferentes tipos de equipos.
    (openstax CNX, 2016) Es el esfuerzo necesario para transferir el programa de un entorno hardware/software a otro entorno diferente.

    OPORTUNIDAD

    El vocablo oportunidad proviene del latín “Opprtunitas” cuyo significado es “delante de un puerto”, y se utilizaba para referirse al momento de llegar al puerto a salvo después de haber pasado una larga travesía en el mar.
    (Definición, 2016) Se denomina oportunidad a toda circunstancia en la cual existe la posibilidad de lograr algún tipo de mejora de índole económica, social, laboral, etc.
    Capacidad de un sistema de software de ser lanzado cuando los usuarios lo desean, o antes.
    Un gran producto software que aparece demasiado tarde puede no alcanzar su objetivo.

    DISPONIBILIDAD

    (Universidad de los Andes, 2016) Capacidad de que el sistema este total o parcialmente operativo al mismo tiempo que es requerido para manejar eficazmente las fallas que puedan afectar la disponibilidad del sistema.
    La disponibilidad de un sistema se basa en el concepto de confiabilidad mediante la adición de la noción de recuperación.
    La disponibilidad es una de las características de las arquitecturas empresariales que mide el grado con el que los recursos del sistema están disponibles para su uso por el usuario final a lo largo de un tiempo dado.

    FUNCIONABILIDAD

    ·         La funcionalidad debe lograr que el usuario pueda utilizar el software.
    ·         (Diccionario de la Lengua Española) Conjunto de características que hacen que algo sea práctico y utilitario.
    ·         (Navarro, 2016) El software deberá cubrir las funcionalidades que publica; en resumen, debe hacer lo que dice que hace.

    CORRECCIÓN

    ·         Debe ser capaz de darle mantenimiento al software.
    ·         (eumed.net, 2016) Grado en que un producto de software satisface sus especificaciones y consigue los objetivos de la misión encomendada por el usuario.

    CONFIABILIDAD

    ·         Se encarga de asegurar que los datos sean íntegros.
    ·         (Universidad de Belgrano, 2016) Es la probabilidad de operación libre de fallas de un programa de computadora en un entorno determinado y durante un tiempo específico.  La confiabilidad del software se encuentra en una etapa de formación de desarrollo  y es la característica de rendimiento más costosa de conseguir y difícil de conseguir y de garantizar. La naturaleza del proyecto ayuda para la formulación de estimaciones de costo y el esfuerzo que asegure la confiabilidad requerida.
    ·         Grado en el que se puede esperar que un producto de software lleve a cabo sus funciones esperadas con precisión requerida.

    EFICIENCIA

    ·         (Eumed.net, 2016) Sistema que hace bien lo que debe de hacer, lo hace a tiempo y no derrocha recursos.
    ·         Cantidad de recursos computacionales y de código requeridos por un producto de software para llevar a cabo las funciones encomendadas.

    USABILIDAD

    ·         (ChiapaneCode, 2016) Definido por la norma ISO 9241 como el grado en el que un producto de software puede ser utilizado por usuarios específicos para conseguir objetivos específicos con efectividad, eficiencia y satisfacción en un determinado contexto de uso.
    ·         Fácil de usar, que sea fácil de aprender a usar.
    ·         Es un nivel superior en donde no sólo un software debe hacer lo que dice que hace; también debe permitirnos hacerlo de forma adecuada, natural.

    ROBUSTEZ

    (Universidad de la República, 2016) Un programa es robusto si se comporta en forma razonable aún en circunstancias que no fueron anticipadas en la especificación de requerimientos.
    (Universidad de la República -Uruguay, 2016) Un programa es robusto si reacciona en forma adecuada frente a situaciones a priori imprevistas. Un programa robusto es también confiable y correcto.
    (Lenguajes y Ciencias de la Computación, 2016) Es la capacidad del producto software para poder funcionar incluso en condiciones fuera de lo normal.

    COMPATIBILIDAD

    (Lenguajes y Ciencias de la Computación, 2016) Es la facilidad de los programas para combinarse entre sí. También se puede ver como la posibilidad de usar los resultados de un programa como entrada a otro.
    La clave de la compatibilidad es la homogeneidad en el diseño y un consenso en las convenciones sobre estandarización para las comunicaciones entre programas; en definitiva, la reutilización de los formatos de bloques de información.


    Para que un sistema sea considerado de calidad debe cumplir todos los factores antes mencionados, debe brindar seguridad al usuario y evitar que personas no autorizadas tengan acceso a su información y lo perjudiquen.
    Un sistema debe ser portable y se debe poder acceder a él desde cualquier lugar. También debe ser eficiente y cumplir con los requerimientos del cliente y hacer lo que el cliente especifico que haga. Además debe tener la capacidad de ser mantenible, adaptarse a nuevos requerimientos o actualizaciones que el cliente requiera.