“…Algunas de las fortalezas de este método son: (1) que puede ser utilizado en una fase temprana para estimar el esfuerzo, y es medido en base a un modelo de casos de uso que define el alcance funcional del sistema de software a ser desarrollado (Kusumoto, Matukawa, Inoue, Hanabusa & Maegawa, 2005), (2) es versátil y extensible a una variedad de proyectos de desarrollo y de pruebas, fácil de aprender y rápido para aplicar (Clemmons, 2006), (3) es conocido y ampliamente aceptado ya que utiliza dos prácticas comunes en la industria: el paradigma orientado a objetos y casos de uso para describir los requisitos de funcionalidad (Wang, Yang, Zhu & Chen, 2009). Sin embargo, también presenta algunas debilidades que están asociadas a los factores que afectan la precisión de la estimación del método de Puntos de Caso de Uso las cuales se muestran a continuación: (1) la primera versión del método de Puntos de Caso de Uso carece de validación y examinación sobre su fiabilidad para las organizaciones de software (Azzeh & Nassif, 2016), (2) incertidumbre asociada a los factores de costo y clasificación abrupta de los casos de uso (Wang, Yang, Zhu & Chen, 2009), (3) necesidad de calibración respecto a los niveles de complejidad de casos de usos y clasificación de actores (Nassif, Capretz & Ho, 2010), (4) carencia de información acerca del conteo del número de actores y de casos de uso y desfase de los factores técnicos y ambientales (Singh & Sahoo, 2012) y (5) discusión al asumir que la relación entre el esfuerzo del software y el tamaño sea lineal (Satapathy & Rath, 2014). Como resultado de las debilidades del método de Puntos de Caso de Uso existen varios factores que afectan la precisión en la estimación de este método.…”