Selección de paquetes informáticos: metodologías, criterios de valoración. Inconvenientes y ventajas frente al desarrollo propio

Transcripción

1 Selección de paquetes informáticos: metodologías, criterios de valoración. Inconvenientes y ventajas frente al Índice de contenido Selección de paquetes informáticos: metodologías, criterios de valoración. Inconvenientes y ventajas frente al...1 Licencia...1 Alternativas...1 Compra...1 Desarrollo propio...2 Desarrollo externo...2 Criterios de valoración...2 Comparación posibilidades...2 Coste...2 Adaptabilidad...3 Soporte...3 Tiempo de implantación...4 Resumen...4 Metodología...5 Software libre vs software privativo...5 Software privativo...5 Software libre...6 Propiedad total...7 Anexo: Métricas...8 Total Cost of Ownership (TCO)...8 Return on Investment (ROI)...9 Análisis de puntos función...9 Método Albrecht Método MARK II...11 Licencia Este obra de Jesús Jiménez Herranz está bajo una licencia Creative Commons Atribución- LicenciarIgual 3.0 España. Basada en una obra en oposcaib.wikispaces.com. Alternativas A la hora de seleccionar un paquete informático para nuestra organización, se presentan diferentes opciones sobre la mejor manera de conseguir un producto apropiado. A continuación se explican brevemente las opciones más comunes: Compra Consistiría en comprar un paquete informático ya hecho. Esta opción no requiere tiempo de desarrollo, si bien no siempre está disponible, salvo para funcionalidades comunes para las que exista un mercado importante, como p. ej. la gestión de nóminas, contabilidad, etc. Si nuestra organización realiza tareas más específicas, es posible que los productos disponibles no contemplen todos nuestros procesos e, incluso, que el producto realice tareas que no necesitemos (pero que también estaríamos pagando). Jesús Jiménez Herranz, 1

2 Desarrollo propio El consiste en disponer en nuestra organización de un equipo de desarrollo que se encargue de crear el sistema informático deseado en función de las necesidades. Lógicamente, requiere disponer de personal cualificado para la tarea. Desarrollo externo Si no se dispone de un equipo de desarrollo, el desarrollo externo consiste en subcontratar a una empresa para realizar el desarrollo. Se diferencia de la opción de compra de un paquete en que, en este caso, no se utiliza un programa ya hecho, sino que el desarrollo es a medida para las necesidades concretas de nuestra organización. Criterios de valoración Las diferentes opciones en cuanto a la adquisición de nuevo software pueden evaluarse desde diferentes puntos de vista: Coste: Coste económico de la opción. Adaptabilidad: Capacidad de personalizar el sistema informático para las características concretas de nuestra organización. Tiempo de implantación: Tiempo entre que se decide la implantación del sistema y que éste empieza a funcionar. Soporte: Capacidad de hacer frente a problemas con el nuevo aplicativo, tanto durante el proceso de implantación como durante la fase de explotación del mismo. Comparación posibilidades A continuación se evalúan las diferentes aproximaciones a la selección de paquetes, en función de los criterios expuestos en el apartado anterior. Coste En lo que respecta al coste, la opción más económica acostumbra a ser la compra de un paquete. Esto es así debido a que el mayor coste de un programa está en su desarrollo, y en el caso de un paquete informático el coste de desarrollo está distribuido entre todos aquellos que lo compran (además de, por supuesto, el margen de beneficio del desarrollador). La comparación entre o externo es más complicada. A priori podría parecer que el desarrollo externo siempre será más costoso, ya que al desarrollo en sí hay que añadir el margen de beneficio que añade la empresa desarrolladora. No obstante, existen factores adicionales que pueden cambiar la situación: Se dispone o no de un equipo de : Si no es así, en caso de que quisiéramos desarrollar el programa dentro de nuestra organización habrá que añadir al coste de personal, recursos, etc. el coste de creación inicial del equipo, teniendo también en cuenta que la productividad del equipo (que al fin y al cabo también es coste) no será inicialmente la misma que la de un equipo con experiencia. Por tanto, en este caso probablemente sería más económica la opción del desarrollo externo. La tipología del proyecto: Si el sistema de información que se necesita es relativamente convencional tanto en su tipología como en las tecnologías que utiliza (p. ej., un sistema de gestión de nóminas), probablemente el desarrollo externo sea más económico al existir Jesús Jiménez Herranz, 2

3 muchas empresas a las que recurrir para el desarrollo. Si, por el contrario, se trata de un proyecto muy específico o que usa tecnologías muy concretas (p. ej. el sistema de gestión del censo de un país), puede ser más eficiente crear un equipo de desarrollo a la medida del proyecto. Un último aspecto a tener en cuenta es que, cuando se habla del coste, hay que tener en cuenta no sólo el coste inicial de comprar/desarrollar el producto, sino todos aquellos costes indirectos u ocultos que se producen durante toda la vida del producto, y que pueden ser muy considerables. Entre estos costes estarían el soporte de la aplicación, la formación a los usuarios, la facilidad para acometer actualizaciones, etc. En el anexo a este documento se explican en profundidad algunas métricas como el TCO (Total Cost of Ownership) o el ROI (Return on Investment) que permiten estimar con precisión el coste total de un producto teniendo en cuenta todos estos factores. De la misma forma, también se explica la técnica del análisis de puntos función, que permite obtener una estimación del coste de un desarrollo software. Adaptabilidad En el caso de la adaptabilidad a las necesidades de nuestra organización, hay que tener en cuenta que la adaptabilidad puede enfocarse de diferentes maneras: Adaptabilidad respecto a la funcionalidad del programa: Es decir, la capacidad de ir modificando el programa para añadir nuevas funcionalidades o modificar las existentes. Adaptabilidad frente a cambios tecnológicos: Aunque se mantenga la misma funcionalidad, cambios tecnológicos externos (de hardware, sistema operativo, etc.), pueden requerir un mantenimiento específico de la aplicación. Está claro que la opción que da una mayor adaptabilidad es el, ya que se dispone de un control total sobre el sistema, seguido de cerca por el desarrollo externo. La diferencia entre ambos sería en principio inexistente, si bien hay diferentes factores que hacen que pueda existir una cierta diferencia: El hecho de tratar con una organización externa, que no está tan integrada con el funcionamiento de nuestra organización como un equipo propio, hace que puedan surgir malentendidos a la hora de diseñar el sistema. Esto puede dar lugar a efectos que van desde los simples retrasos en la entrega del producto hasta deficiencias en la funcionalidad. Una organización externa puede tener condicionantes en cuanto al desarrollo (uso de determinados lenguajes o tecnologías) que impidan una adaptabilidad total. La opción que está claramente por detrás del resto en cuanto a la adaptabilidad es la de la compra de un software empaquetado. En este caso, se compra un paquete tal cual, desarrollado pensando en unas necesidades que no tienen por qué ser las de nuestra organización, y la adaptabilidad es nula o muy limitada. Soporte La comparación en cuanto al soporte es similar a la de la adaptabilidad. Así, está claro que la opción que ofrece un mejor soporte en todas las fases de uso del sistema es la del, Jesús Jiménez Herranz, 3

4 ya que el disponer del equipo de desarrollo de la aplicación dentro de la propia organización permite hacer frente con garantías a cualquier problemática que pueda surgir. Simplemente hay que tener en cuenta que existe un sobrecoste añadido, que es el mantenimiento en plantilla del equipo de desarrollo una vez finalizado el mismo, que puede ser asumible o no en función del caso. En lo que respecta al desarrollo externo, el grado de soporte también es alto, puesto que la mayoría de empresas ofrecen la opción de soporte al producto desarrollado. Así, se puede considerar que está opción está un punto por debajo debido a que, además del coste del soporte, se genera una fuerte dependencia hacia la empresa que ha desarrollado el software. En el caso del software empaquetado, el soporte disponible varía mucho en función del caso, desde ninguno en absoluto (el paquete tal cual), hasta documentación abundante e incluso servicios de soporte proporcionados por la empresa desarrolladora del paquete. Debido a esta variabilidad, es importante informarse adecuadamente de este punto en el caso de optar por este tipo de software. Tiempo de implantación El tiempo de implantación menor de entre todas las opciones disponibles es claramente el de la compra de software empaquetado. Esto es así porque el desarrollo ya está hecho, y la implantación es generalmente rápida al ser un desarrollo rígido que no admite demasiadas adaptaciones. Por el contrario, tanto el como externo requieren de un tiempo considerable, tanto por lo que respecta al desarrollo del software como para la implantación posterior. La diferencia entre estas dos opciones dependerá mucho del caso, y generalmente consistirá en uno de los dos siguientes casos: Si se ha creado un equipo de desarrollo específico para el proyecto, el tiempo de implantación será probablemente mayor que el de una empresa externa, que dispondrá de un equipo más rodado y con mayor experiencia. Si se dispone de un equipo de desarrollo con experiencia, el tiempo será similar al del desarrollo externo, o incluso mejor al disponer de mayor conocimiento sobre la organización. Resumen A continuación se muestra una tabla resumen de los apartados anteriores: Software empaquetado Desarrollo propio Desarrollo externo Coste Bajo Alto Alto Tiempo de implantación Bajo Alto Alto Adaptabilidad Escasa o nula Máxima Alta Soporte Variable Alto Alto Conclusión Cuando exista un paquete que coincida en gran medida con nuestras necesidades, no se esperen cambios futuros y tenga un coste razonable Si disponemos de un equipo propio de desarrollo, o no lo tenemos pero el soporte y la adaptabilidad son cruciales Cuando no se dispone de un equipo de desarrollo, y no se quiere asumir el coste inicial de formar uno Jesús Jiménez Herranz, 4

5 Metodología A continuación se expone una posible metodología para afrontar el proceso de selección de un paquete informático. 1. Evaluar necesidades: Realizar una evaluación exhaustiva de las necesidades existentes, determinando claramente los requisitos funcionales de la nueva aplicación 2. Estudiar opciones existentes: Estudiar en primer lugar qué paquetes hay disponibles en el mercado, determinando hasta qué punto se adaptan a nuestras necesidades, así como calculando qué coste tienen. Debe analizarse el coste real, que incluye: Precio del paquete Coste del soporte Tipo de licencia: Determinará si nos atamos a una empresa para futuras actualizaciones, o bien si tenemos acceso al código fuente y, por tanto, disponemos de flexibilidad a la hora de modificar la aplicación. 3. Estimar coste de : Si se dispone de un equipo de desarrollo, evaluar el coste del desarrollo de la aplicación, teniendo en cuenta el personal del que disponemos, su formación, etc. Si no se dispone de equipo de desarrollo, realizar el mismo cálculo añadiendo el coste de formación inicial del equipo (contrataciones, formación, etc.). 4. Estimar coste de desarrollo externo: Pedir presupuestos a una muestra de empresas externas para el desarrollo de la aplicación. Tener en cuenta: Coste del desarrollo Posibilidad y coste del soporte Coste de las ampliaciones y cambios futuros 5. Evaluación y selección final: Evaluar todas las posibilidades y escoger la más ventajosa evaluando la relación funcionalidades/coste. Es posible utilizar algún tipo de métrica para representar el grado de cubrimiento de las necesidades, pudiendo calcular así el coste de la solución según los diferentes esquemas (paquete, o desarrollo externo). Software libre vs software privativo Una aspecto importante a la hora de seleccionar un paquete informático es la licencia del software que vamos a usar, ya que las condiciones de uso, acceso y modificación pueden limitarnos en el futuro. A continuación se muestran las posibilidades más comunes, con sus ventajas e inconvenientes. Software privativo En este caso, la empresa desarrolladora conserva los derechos de acceso, modificación y distribución sobre el software, otorgándonos únicamente licencias de uso que pueden ser permanentes, o renovables periódicamente. Es prácticamente la norma en el software empaquetado, y puede darse también en el caso del desarrollo externo. Esta opción supone básicamente un alquiler del software, que da lugar a tres consecuencias principales: Dependencia de la empresa desarrolladora: Dado que la empresa desarrolladora es la única capaz de realizar modificaciones, se crea una situación de dependencia que puede ser Jesús Jiménez Herranz, 5

6 problemática si, en el futuro, esta empresa desaparece, decide incrementar sus precios o toma decisiones técnicas (p. ej. un cambio de arquitectura) incompatibles con nuestras políticas. Dificultades de adaptación: Por el mismo motivo, se depende de la empresa original para cualquier tipo de adaptación del programa a nuestras necesidades particulares. Dependiendo del caso, esta adaptación puede ser posible o no siempre en función de la empresa desarrolladora. Problemas seguridad: Dado que no existe acceso al código del programa, se hace difícil auditarlo frente a vulnerabilidades de seguridad. Las restricciones en cuanto a quién puede modificar el programa también afectan al tiempo de respuesta si se descubre un fallo de seguridad, ya que se depende de la empresa original para arreglar el problema. En definitiva, el uso de software privativo es una decisión con riesgos, ya que supone ceder el control del programa a la empresa desarrolladora, cuyas estrategias y objetivos no tienen por qué coincidir con los nuestros. Software libre El software libre es aquél que concede a sus usuarios los siguientes derechos: Uso Distribución Acceso al código fuente del programa, y modificación para adaptarlo. Distribución de las modificaciones Existen diferentes variantes de licencias libres, siendo las más comunes las dos siguientes: GPL: Otorga las cuatro libertades, obligando además a que cualquier producto derivado las mantenga. Por esta obligación se la conoce como una licencia vírica. BSD: Si bien también otorga las cuatro libertades, no añade restricciones en cuanto a la licencia que deben tener productos derivados. De esta forma, es posible utilizar un producto libre con licencia BSD para derivarlo en un software privativo. El uso de software libre presenta las siguientes ventajas: Control total: Existe un control total sobre el software, en el sentido de que se dispone del código fuente y se puede acometer cualquier modificación o adaptación sin depender del desarrollo original, independientemente de que éste desaparezca o cambie sus políticas. De hecho, el carácter libre hace que si nuestra organización no está preparada para modificar/adaptar el software, sea posible recurrir a cualquier empresa (y no sólo a la desarrolladora) para la tarea. Mejor seguridad: Diferentes estudios demuestran que el hecho de disponer públicamente del código fuente del programa aumenta la seguridad. Esto, aunque resulte inicialmente contraintuitivo, se debe a que la mayor exposición del código permite detectar más fácilmente posibles problemas, y al mismo tiempo acelera su resolución. De esta forma, si en lugar de emprender un desarrollo desde cero se realiza una adaptación de un producto libre ya existente, es posible aprovechar la experiencia previa para obtener Jesús Jiménez Herranz, 6

7 un producto probado a una fracción del coste que supondría alcanzar el mismo grado de madurez en un desarrollo de nueva creación. Ahorro de costes: Si bien no es la norma, el carácter libre de muchos programas permite disponer de una gran cantidad de software de forma gratuita. Fomento de la industria de TIC local: El hecho de poder acometer modificaciones a los programas sin depender de empresas externas, que generalmente son multinacionales foráneas, hace que se fomente la industria local de TIC. Esto, aunque no tenga por qué ser un argumento decisivo en una empresa privada, sí debería ser un argumento de peso en una administración pública (como es el caso). Hay que hacer notar que el software libre también tiene desventajas: Inmadurez: Determinados productos libres no están al mismo nivel de madurez que sus equivalentes propietarios, ya sea porque se encuentra en sus primeras fases de desarrollo, o bien porque el desarrollo de software libre tiende a ser más caótico al requerir la coordinación de una comunidad heterogénea de desarrolladores, en comparación con una organización cerrada. Aunque este problema se reduce día a día, hay que considerarlo y evaluar con precisión si un producto libre cubre nuestras necesidades. Falta de habituación de los usuarios: Dado que tradicionalmente el software privativo ha sido predominante, la gran mayoría de usuarios se encuentra más habituado a su uso y el paso a determinados productos libres puede ser problemático. Por ello, en el coste de transición a software libre hay que considerar que probablemente se requiera de una formación adicional. De esta forma, el software libre es una opción a considerar debido al hecho de que da el control a los usuarios del programa y no a sus desarrolladores. Por ello, y pese a sus problemas, debería ser una opción a evaluar en la medida de lo posible. Propiedad total Otra opción consiste en que la empresa desarrolladora nos ceda la propiedad y, por tanto, la totalidad de los derechos sobre el software. Es un caso común en el desarrollo externo, y lógicamente es la norma en el. En este caso, se dispone de una mezcla de las ventajas e inconvenientes: Ventajas Control total sobre el producto Independencia del desarrollador original Inconvenientes Costes generalmente elevados Potenciales vulnerabilidades de seguridad al tratarse de código de nueva creación Una posibilidad potencial en caso de optar por este tipo de licencia es la de, una vez finalizado el desarrollo, liberar el software con una licencia libre. Esta opción es apropiada si se desea optar por licencias libres, pero ningún producto libre disponible se ajusta totalmente a nuestras necesidades, y se considera que la adaptación de uno existente sería más costosa que el desarrollo a medida. Jesús Jiménez Herranz, 7

8 La opción de liberar el desarrollo a medida tiene la ventaja de que, a medio/largo plazo, permite hacer más robusto el producto a base de exponerlo a un número mayor de usuarios/desarrolladores (que en este caso serían los nuestros, más aquellos terceros que también usasen el producto). Por tanto, sería posible detectar posibles errores no detectados durante el desarrollo. Anexo: Métricas En este apartado se muestran algunas métricas útiles para evaluar la viabilidad de un proyecto informático, desde diferentes puntos de vista. Concretamente son: TCO (Total Cost of Ownership): Permite calcular el coste total de un proyecto, teniendo en cuenta no sólo los costes iniciales directos, sino aquellos posteriores, indirectos, u ocultos. ROI (Return On Investment): Análisis de puntos función: Más que una métrica, el análisis de puntos función es una técnica que permite estimar el coste de un desarrollo software, teniendo en cuenta tanto las características del desarrollo como cualquier factor, interno o externo, que pudiese influir durante el mismo. Total Cost of Ownership (TCO) El TCO (Total Cost of Ownership) es una métrica financiera que pretende calcular el coste total de un producto/proyecto. El TCO tiene en cuenta los costes generados durante todo el ciclo de vida de un proyecto, no sólo los iniciales. De esta forma, se tienen cuenta costes indirectos u ocultos, que pueden ser difíciles de ver inicialmente y que pueden aumentar notablemente el coste aparente inicial. El análisis del TCO tiene en cuenta dos grandes grupos de costes: Coste de adquisición Costes operativos En el ámbito de un producto software, algunos costes que se tienen en cuenta al calcular el TCO, además de los directos de la compra/desarrollo del producto, son los siguientes: Hardware y software De operación A largo plazo Equipos necesarios: estaciones, servidores, etc. Instalación y configuración de los equipos Configuración de la red Costes de licencias Migración desde otros productos Electricidad Infraestructura necesaria: locales, etc. Realización de backups Formación a los usuarios Coste de la sustitución Escalabilidad ante incremento de usuarios Al calcular el TCO también se tienen en cuenta los riesgos asociados a cada producto, desde diferentes puntos de vista: Jesús Jiménez Herranz, 8

9 Sistema Susceptibilidad a vulnerabilidades Disponibilidad de actualizaciones y parches Posibles cambios en las licencias Físicos Caídas del sistema Errores del aplicativo Return on Investment (ROI) El ROI (Return on Investment) es una medida porcentual que indica el ratio de dinero ganado o perdido en una inversión, comparado con el dinero invertido. El ROI permite hacerse una idea de la rentabilidad de un producto/proyecto a largo plazo, así como analizar en qué momento la inversión empieza a ser rentable, de cara a plantearse su viabilidad. El ROI se calcula como: ROI = [ Beneficio Inversión] Inversión El ROI puede calcularse para diferentes periodos de tiempo, y así el ROI del primer año desde la inversión puede ser sustancialmente diferente del ROI al final del ciclo de vida del producto. Así, por ejemplo, la siguiente tabla muestra el ROI acumulado para diferentes años de un proyecto en el que se han invertido 1000 euros: Año 1 Año 2 Año 3 Beneficios ROI [ ] = 50% 1000 [ ] = 10% 1000 [ ] =20% 1000 Puede verse como, a pesar de que inicialmente el proyecto es deficitario y los beneficios son decrecientes, a partir del tercer año se consigue la rentabilidad. Un aspecto a tener en cuenta es que, aunque el ROI se mida en dinero, éste no tiene por qué ser siempre dinero efectivo, sino que se pueden cuantificar otros aspectos como ganancias retornadas por la inversión, tales como una mejora de la imagen de la organización, o el establecimiento de compromisos beneficiosos con terceros. Dado que para calcular con precisión el ROI es importante cuantificar con precisión tanto el coste inicial como los costes futuros derivados, indirectos y ocultos, el ROI se complementa perfectamente con el cálculo del TCO. Análisis de puntos función La estimación del coste de los productos de software es una de las actividades más difíciles y propensas a error de la ingeniería del software. Es difícil hacer una estimación exacta de coste al comienzo de un desarrollo debido al gran número de factores conocidos o esperados que determinan la complejidad y desconocidos o no esperados que van a producirse en cualquier momento, determinando la incertidumbre. Las técnicas de estimación ayudan en esta tarea y dan como resultado un número de horas de esfuerzo, a partir de las cuales se calculará el coste correspondiente. La estimación nos aportará un número de horas aproximado que habrá que combinar con los recursos para obtener la planificación de actividades en el tiempo y establecer los hitos del proyecto. Jesús Jiménez Herranz, 9

10 Las técnicas de estimación más fiables se basan en el análisis de Puntos Función. La técnica de Puntos Función permite la evaluación de un sistema de información a partir de un mínimo conocimiento de las funcionalidades y entidades que intervienen. Las características más destacables de esta técnica son: Es una unidad de medida empírica. Contempla el sistema como un todo que se divide en determinadas funciones. Es independiente del entorno tecnológico en que se ha de desarrollar el sistema. Es independiente de la metodología que vaya a ser utilizada. Es independiente de la experiencia y del estilo de programación. Es fácil de entender por el usuario. El resultado de la aplicación de esta técnica viene dado en Puntos Función, que posteriormente habrán de ser pasados a días de esfuerzo, para lo que sí habrán de tenerse en cuenta la experiencia del equipo de desarrollo y el estilo de programación, la aplicación de una u otra metodología y la tecnología. Este cálculo de días por punto función debe basarse en la experiencia adquirida en la valoración y realización de sistemas anteriores, debiendo actualizarse el valor de conversión con posterioridad a la finalización de cada proyecto. Entre las técnicas de estimación basadas en el análisis de puntos función, se destacan los siguientes dos métodos: Método Albrecht. Consiste en los siguientes pasos: 1. Identificación de componentes: Consiste en identificar una serie de componentes del sistema, que serán evaluados en función de su complejidad de acuerdo a una serie de tablas predefinidas por el método. Los componentes a identificar son: Entradas externas: Ficheros, dispositivos de entrada y cualquier fuente de datos. Salidas externas: Informes, mensajes por pantalla, etc. Grupos lógicos de datos internos: Datos generados y mantenidos por el programa. Grupos lógicos de datos de interfaz: Datos internos que se usan para comunicarse con otras aplicaciones. Consultas externas: Consultas externas de datos que no implican actualización 2. Cálculo de puntos función no ajustados: Una vez se han identificado los componentes del sistema y calculado el número total, se les aplican una serie de multiplicadores en función del grado de complejidad calculado en el punto anterior. Así, se obtiene una suma de puntos función no ajustados. 3. Ajuste de puntos función: Corrección de los PF calculados en el paso anterior, en base a diferentes criterios. Así, para cada criterio se puntúa de 0 a 5 en función del grado de influencia. Algunos criterios son: Importancia de las prestaciones del SI final Si la aplicación es distribuida o no Énfasis en la facilidad de uso/instalación Jesús Jiménez Herranz, 10

11 Etc Una vez se ha obtenido esta suma de ajustes, se obtiene el número final de puntos función con la fórmula: PFA=PFNA 0,65 0,01 SVA Donde PFNA son los puntos función no ajustados y SVA es la suma de ajustes. El número de días equivalente se calculará mediante el baremo de días por punto función que establezca cada organización. Generalmente se comienza con el baremo de 1 día=1 PF, y se va ajustando en función de la experiencia. Método MARK II El método MARK II es una evolución del método Albrecht, y tiene un funcionamiento similar, si bien tiene en cuenta un mayor número de factores tanto en lo que respecta a la identificación de componentes como al ajuste de los puntos función. Jesús Jiménez Herranz, 11