La fluencia de funciones es la expansión continua excesiva o la adición de nuevas funciones en un producto, [1] especialmente en software de computadora , videojuegos (donde no debe confundirse con fluencia de energía ) y electrónica de consumo y comercial . Estas características adicionales van más allá de la función básica del producto y pueden resultar en un software sobrecargado y complicado, en lugar de un diseño simple.
La definición de lo que se considera "deslizamiento de funciones" varía entre los usuarios finales , donde lo que algunos usuarios perciben como tal puede ser considerado una funcionalidad práctica por otros. [2] La fluencia de funciones es una de las fuentes más comunes de sobrecostos y cronogramas. [3] [ verificación necesaria ] Por lo tanto, pone en peligro e incluso puede matar productos y proyectos.
El desplazamiento de características puede surgir del deseo de proporcionar al consumidor un producto más útil o deseable para aumentar las ventas o la distribución. Una vez que un producto hace todo para lo que fue diseñado, el fabricante puede agregar funciones que algunos usuarios podrían considerar innecesarias (a veces a costa de la eficiencia) o continuar con la versión original (a costa de una percepción de falta de mejora).
La variación de funciones también puede surgir como resultado del compromiso de un comité que implementa varios puntos de vista o casos de uso diferentes en el mismo producto, incluso por razones oportunistas. [4] A medida que se agregan más funciones para respaldar cada enfoque, las funciones de conversión cruzada entre los múltiples paradigmas pueden complicar aún más las funciones totales.
Existen varios métodos para controlar la variación de funciones, que incluyen: límites estrictos para las funciones permitidas, variaciones múltiples y poda de funciones excesivas.
Se puede evitar la proliferación de funciones posteriores basando el diseño inicial en sólidos fundamentos del software, como la separación lógica de la funcionalidad y el acceso a los datos, por ejemplo, utilizando submenús a los que pueden acceder opcionalmente los usuarios avanzados que desean más funcionalidad y una mayor verbosidad de la información. Se puede controlar activamente con una gestión de cambios rigurosa y retrasando los cambios a fases posteriores de entrega de un proyecto. [5]
Otro método para controlar la proliferación de funciones es mantener múltiples variaciones de productos, donde las funciones son limitadas y reducidas en las variaciones más básicas, por ejemplo, las ediciones de Microsoft Windows . Para las interfaces de usuario de software , se pueden utilizar modos de visualización o modos de operación (por ejemplo, modo básico o modo experto), entre los cuales los usuarios pueden seleccionar según sus propias necesidades.
Tanto en muchas interfaces gráficas de usuario como en interfaces de línea de comandos , los usuarios pueden optar por una mayor detalle manualmente. En el último caso, en muchos programas de línea de comandos, agregar una opción -vo --verbosemanualmente muestra información más detallada que puede ser menos relevante para usuarios mínimos, pero útil para usuarios avanzados o para fines de depuración y resolución de problemas.
Debido a que la incorporación cada vez mayor y en constante expansión de nuevas funciones puede exceder los recursos disponibles, se puede mantener por separado una versión "básica" mínima de un producto para garantizar el funcionamiento en entornos operativos más pequeños. Utilizando la " regla 80/20 ", las variaciones más básicas del producto podrían satisfacer las necesidades de la mayoría (por ejemplo, ~80%) de los usuarios, por lo que no estarían sujetos a la complejidad (o gasto adicional) de las funciones solicitadas por el avanzó el 20% de los usuarios. Las funciones adicionales todavía están disponibles, pero son opcionales y están listas para ser utilizadas por quienes las soliciten, pero no se han implementado en las versiones básicas de los productos.
Otra solución para la proliferación de funciones es la modularidad . Los usuarios avanzados que requieren más funcionalidad pueden actualizar las características necesarias descargando módulos de software, complementos , complementos (también conocidos como complementos) y temas personalizados para satisfacer sus necesidades personales.
En algún momento, el costo de mantener un subconjunto particular de características puede volverse prohibitivo y se puede utilizar la poda. Una nueva versión del producto puede omitir las características adicionales, o tal vez se usaría un período de transición, donde las características antiguas quedarían obsoletas antes de su eventual eliminación del sistema. Si hay múltiples variaciones de productos, es posible que algunas de ellas dejen de utilizarse. Un ejemplo importante es el Samsung Galaxy S6 , lanzado en marzo de 2015, del cual se eliminaron significativamente muchas características de software/menú y también algunas características de hardware. No se ha lanzado una variación "más funcional". [ cita necesaria ]
En ocasiones, el cambio incontrolado de funciones puede dar lugar a productos que superen el alcance de lo que se pretendía originalmente; esto se conoce como desplazamiento del alcance . Una consecuencia común del cambio de funciones es el retraso o la cancelación de un producto, que puede resultar más caro de lo previsto originalmente. [ cita necesaria ]
A menudo, un proyecto de software con funciones razonablemente completas, o uno con cantidades moderadas de funciones progresivas, puede sobrevivir e incluso prosperar a través de muchas iteraciones, pero su versión sucesora puede sufrir retrasos sustanciales una vez que se toma la decisión de reescribir todo el código base además de introduciendo nuevas tecnologías. Por ejemplo, se planeó que Windows Vista de Microsoft fuera una versión menor entre Windows XP y su sucesor con nombre en código Windows "Blackcomb" (lanzado como Windows 7), pero después de adaptar más y más funciones de Blackcomb (muchas de las cuales finalmente fueron canceladas), Vista resultó convertirse en un lanzamiento importante que requirió cinco años de desarrollo.
Un destino similar sufrió Netscape 6 , que originalmente se suponía que sería Netscape 5 . La decisión de Netscape Communications en 1998 de abrir el código fuente de su navegador Netscape Navigator y de su paquete de Internet Communicator (ambos con el nombre clave de Mozilla) pronto hizo evidente que el código subyacente era demasiado difícil y requirió una reescritura completa de Mozilla, lo que fomentó la creación de el marco de aplicación de Mozilla . Esto provocó retrasos importantes, se omitió Netscape 5 y AOL compró la empresa. El lanzamiento posterior de Netscape 6.00 en 2000 fue ampliamente criticado como código de nivel alfa, y el proyecto alcanzó la estabilidad con Netscape 6.1 en 2001, tres años después de la decisión de reelaborar la suite de Internet. En ese momento, el navegador Internet Explorer de Microsoft había eclipsado durante mucho tiempo a Netscape en cuota de uso, que había disminuido a un solo dígito.
Incluso después de alcanzar la estabilidad y obtener algunas características nuevas necesarias, el Mozilla Application Suite de código abierto (entonces llamado simplemente Mozilla), sobre el cual AOL construyó Netscape, fue visto como " inflado ". Apenas un año después, un grupo de desarrolladores de Mozilla decidió separar el componente del navegador, que finalmente se convirtió en Firefox .
El proyecto de Kickstarter de Double Fine Adventures, Broken Age, es otro ejemplo de un proyecto que se retrasa debido a un cambio de funciones. Originalmente se suponía que tendría una fecha de lanzamiento en octubre de 2012, la primera mitad del juego se lanzó en enero de 2014, mientras que la segunda mitad siguió a finales de abril de 2015 y requirió dos rondas de financiación separadas para completarse. [6]
La proliferación de funciones combinada con plazos cortos a menudo conducirá a una "solución hacky" . El cambio deseado puede ser lo suficientemente grande como para justificar un rediseño de la base del proyecto existente, pero la presión de la fecha límite requiere que los desarrolladores se apresuren y presenten un producto menos refinado. El término Spoonerismo "creaturismo feeping" fue acuñado para enfatizar el disgusto de un desarrollador por esta situación, [7] personificando el producto de alcance lento como "una criatura deforme de hacks... merodeando en la oscuridad", [8] y el presagio de más asco por venir. [9] ("Feeping" es un sinónimo en la jerga de "pitido".) [10]
