INTRODUCCIÓN
En los temas anteriores se analizaron los diferentes tipos de Sistemas de Información y se mostraron características y funciones específicas de cada uno de ellos. Además de conocer los diferentes tipos de sistemas, es necesario analizar el proceso que puede seguirse para su desarrollo, con el fin último de poner a la disposición de las empresas y de los usuarios las ventajas que se derivan de los sistemas.Ahora trataremos el tema del Desarrollo de Sistemas tomando en cuenta el ambiente actual que demanda calidad y competitividad y que está caracterizado por una creciente globalización. Para cumplir con este objetivo se explican las alternativas para que una organización pueda desarrollar un Sistema de Información.
Existen dos tipos de software: software interno y software de aplicación. El primero es un conjunto de programas que nos permiten interactuar con el sistema computacional. Ejemplos de este software son los sistemas operativos como DOS, UNIX, OS/2 y WINNDOWS. El software de aplicación son los programas que resuelven problemas funcionales a los usuarios, como un sistema desarrollado para apoyar el proceso de toma de decisiones o un sistema transaccional. Aquí nos referiremos al software de aplicación y usaremos de manera indistinta las palabras software de aplicación y Sistema de Información, ya que ambas se refieren al mismo concepto.
Por otro lado, debido a los avances tecnológicos existe una tendencia a la disminución de los costos de los recursos de hardware, mientras que los productos de software tienen una tendencia a la alza. Un ejemplo de esto es que las computadoras continúan bajando de precio (en dólares) y ofreciendo nuevas y mayores capacidades, mientras que el software continúa especializándose e incrementando sus costos. Lo anterior puede observarse en la figura 10.1. Este fenómeno explica la importancia que tiene el desarrollo de sistemas por los altos costos que origina en una organización.
Un estudio realizado en diversas organizaciones respecto al desarrollo de software, reportó que el 25% de los proyectos iniciados fueron cancelados; menos del 1% de los proyectos fueron terminados en el tiempo que se estimó, con los requerimientos especificados por el usuario y dentro del costo presupuestado; los proyectos grandes concluyeron con más de un año de retraso y con el doble de los costos estimados. Estos resultados nos indican que es necesario analizar el proceso de desarrollo que se está siguiendo para determinar si es el adecuado y para mantener un esquema de competitividad en relación al desarrollo de los sistemas.
Para llevar a cabo el desarrollo de sistemas es necesario contar con la infraestructura de equipo computacional adecuada para ello. Más adelante se propone una metodología para que el administrador de la función de información pueda elegir el equipo que mejor satisfaga los requerimientos de la empresa.
Aquí se presentará la siguiente información:
· El Ciclo de vida de los Sistemas de Información.
· Impacto de la calidad en el proceso de desarrollo de sistemas.
· Métodos alternos para la adquisición de sistemas.
· Método tradicional.
· Compra de paquetes.
· Cómputo del usuario final.
· Outsourcing.
· Caso de aplicación.
· Tendencias futuras.
· Conclusiones
CICLO DE VIDA DE LOS SISTEMAS DE INFORMACIÓN
Antes de analizar la calidad en el proceso de desarrollo de sistemas es importante explicar el ciclo de vida de los Sistemas de Información. En la figura 10.2 puede observarse este ciclo y las fases que incluye, tales como nacimiento, desarrollo, operación, mantenimiento y muerte. A continuación se explica de manera breve cada una de ellas.
Nacimiento. Esta fase da inicio al ciclo de vida con el surgimiento de una necesidad o de un requerimiento por parte del usuario. En este momento debe hacerse un estudio de factibilidad para decidir si en realidad se justifica el desarrollo del sistema.
Desarrollo. Una vez realizado un estudio de factibilidad, se procede al desarrollo del sistema en el cual se analizan los requerimientos y se elabora un diseño que servirá de base para el desarrollo. Además, se elaboran los programas necesarios para que el sistema pueda operar. La fase de desarrollo consiste en diseñar, construir y/o adecuar los programas que se requieren para resolver el problema del usuario.
Operación. En este momento el sistema ya está terminado y el usuario trabaja introduciendo datos y obteniendo información y reportes que soporten la operación de la empresa. Si el sistema no satisface los requerimientos funcionales del usuario o si se detecta algún error en los programas, es necesario pasar a la fase de mantenimiento.
Mantenimiento. Consiste en corregir los errores que se detectan en los programas o en las funciones que realiza el sistema. En esta fase además el usuario puede agregar nuevos requerimientos.
Muerte. Un Sistema de información llega a esta fase cuando deja de ser necesario o cuando debe remplazarse por otro mejor. Si al sistema original se le hacen mejoras o cambios se inicia nuevamente el proceso, debido a que el sistema anterior ya ha muerto y se desarrollará uno nuevo.
IMPACTO DE LA CALIDAD EN EL PROCESO DE DESARROLLO DE SISTEMAS
Una vez que se ha analizado el ciclo de vida, hay que tomar en cuenta las variables que pueden impactar en el proceso de desarrollo. Estas variables, ilustradas en la figura 10.3, son: calidad, especificaciones del usuario, recursos y tiempo. Es importante que el usuario del sistema conozca las variables que afectan el proceso de desarrollo para que coopere lo más posible y evite que el sistema que desarrolle presente problemas durante su operación.
Calidad se refiere a que el sistema satisfaga los requerimientos de confiabilidad y eficiencia de la mejor manera posible, y que éste no requiera mantenimiento o modificaciones una vez que se termina. Normalmente un sistema de buena calidad tiene alta duración en su ciclo de vida Por el contrario, si el ciclo de vida de un sistema es corto, puede asumirse que la calidad de este sistema es pobre.
Especificaciones del usuario son todos los requerimientos que define el usuario antes de iniciar el desarrollo del sistema, es decir, las funciones que necesita que realice. El sistema debe cumplir con todas las especificaciones y expectativas que tiene el usuario para que el proceso de se considere exitoso.
Recursos son las personas que realizan el proceso de desarrollo, el equipo y el dinero necesario para el desarrollo del sistema. Un desarrollo adecuado y competitivo deberá consumir la cantidad mínima de recursos sin sacrificar calidad ni las especificaciones de los usuarios.
Tiempo se refiere a la duración de todo el proceso de desarrollo, desde su inicio hasta que está en operación. El desarrollo de un Sistema de Información debe cumplir con las expectativas de tiempo que fijan de forma conjunta el analista del sistema y el usuario.
Ahora, se analizará la relación que existe entre estas variables, ya que si alguna de las variables cambia durante el proceso puede producir un cambio en una o más de las otras variables. Por ejemplo:
- Si se incrementan las especificaciones del usuario, el tiempo de desarrollo puede aumentar de la misma manera que pueden necesitarse más recursos, esto puede provocar que haya una disminución en la calidad final del software. Si el usuario solicita que se agreguen más funciones a las definidas en el inicio se supone que será necesario incrementar los recursos asignados y el tiempo estimado si se desea cumplir con lo planeado. En caso de que no haya una reconsideración de estas variables la calidad del sistema puede verse afectada negativamente.
- Si el tiempo de terminación del software requiere acortarse es necesario incrementar los recursos (contratar más personal) o recortar las especificaciones del usuario, ya que debido a la limitante del tiempo no es posible cumplir con todo lo planeado y esto puede disminuir la calidad final del sistema.
- Si se desea incrementar la calidad del sistema puede ser necesario incrementar la cantidad de recursos asignados al proyecto y/o incrementar el tiempo asignado al proyecto. Si se quiere tener un producto final que tenga una calidad aceptable para una buena operación, deberá analizarse si los recursos asignados al proyecto y si su tiempo estimado de desarrollo son adecuados para cumplir con las especificaciones del usuario a través de un sistema de alta calidad.
Puede observarse que el cambio en cualquiera de las variables impacta en la calidad del proceso de desarrollo de sistemas. Es importante que desde la fase inicial se definan los requerimientos de calidad del sistema, y así también establecer las especificaciones del usuario y estimar correctamente el tiempo y los recursos que se requieren.
MÉTODOS ALTERNOS PARA LA ADQUISICIÓN DE SISTEMAS
Una vez que se analizan las variables que impactan en la calidad del desarrollo de sistemas y de conocer el ciclo de vida, es importante que una empresa u organización considere las tres diferentes fuentes o maneras de proveerse de sistemas. Cada una de éstas se explica a continuación:
- El método tradicional consiste en desarrollar el sistema internamente en la empresa o contratar servicios externos para ello. Esto se explicará más adelante al hablar de Outsourcing. En este método se desarrolla un sistema específico para las necesidades de una empresa en particular, en la mayoría de los casos se utiliza para desarrollar Sistemas Estratégicos debido a que no existen sistemas similares en el mercado. Por ejemplo, un sistema para determinar la mejor localización geográfica de una planta manufacturera o un sistema que pueda tomar información de competidores y proporcione alternativas de precios para la venta de un producto.
- La compra de paquetes consiste en adquirir paquetes desarrollados y terminados o desarrollados de manera parcial, por otras compañías que se encuentran en el mercado de desarrollo de software. Por ejemplo, comprar un paquete para el manejo de una caja registradora de una empresa comercial o un paquete que sirva para llevar la contabilidad.
- El cómputo del usuario final consiste en que el usuario final del sistema sea el que desarrolle sus propias aplicaciones, para esto utiliza las herramientas computacionales disponibles como son los paquetes y lenguajes de cuarta generación. Normalmente no se requieren conocimientos profundos de programación para este tipo de aplicaciones. Ejemplo de esto es un modelo de planeación financiera desarrollado directamente por el Gerente de Finanzas o utilizando Excel.
Anteriormente el método tradicional era el más utilizado por las organizaciones, debido a la falta de paquetes disponibles y de herramientas fáciles de usar para el desarrollo de aplicaciones. Ahora es importante decidir si el sistema se desarrollará desde el inicio, se optará por comprar un paquete o por que el usuario final desarrolle su propia aplicación. En la figura 10.4 puede observarse el cambio que se ha dado en la forma de adquirir los sistemas a través del tiempo.
MÉTODO TRADICIONAL
El método tradicional de desarrollo consiste en una serie de fases consecutivas que inician con un estudio de factibilidad de la realización del proyecto y terminan con la operación del sistema. A este método se le conoce como cascada o caída de agua debido a que las fases son consecutivas. A pesar de que se sigue un orden en la realización de cada una de las fases, es posible regresar la fase anterior para hacer correcciones en caso de ser necesario.
Al estar un sistema en operación el usuario puede darse cuenta si cumple con las funciones que requiere o si es necesario incrementar algunas otras. En este caso es necesario regresar a las fases anteriores y hacer las correcciones.
La gráfica de este método es la siguiente:
Factibilidad. Consiste en realizar un estudio para determinar qué tan factible es el desarrollo del proyecto, considerando los aspectos técnicos y económicos. Debe analizarse si en realidad un Sistema de Información ayudará a lograr los objetivos que se pretenden o si no es conveniente realizarlo, ya que hay maneras mejores de cumplir con los objetivos.
La factibilidad corresponde a la fase de nacimiento del ciclo de vida de desarrollo de sistemas, en la cual se parte de una necesidad o requerimiento del usuario y se decide realizar o no el sistema. Las fases de análisis, diseño, programación, pruebas e implantación del método tradicional corresponden a la fase de desarrollo que se presentó antes en el modelo del ciclo de vida de sistemas de la sección 10.2.
Análisis. Consiste en determinar las especificaciones del usuario del sistema, pronosticar los recursos que serán necesarios y estimar el tiempo de desarrollo. En esta fase se definen los datos que se van a introducir al sistema y la información procesada que se generará vía reportes o pantallas de consulta. Es importante que el usuario responsable autorice por escrito el análisis antes de iniciar con el diseño.
Diseño. Una vez realizado el análisis se prosigue con la fase de diseño, en la cual se traduce el análisis en forma de pasos o algoritmos que constituirán la base para la programación. En esta etapa se diseñan los procedimientos que servirán para cumplir con el objetivo del sistema y la forma de cómo entrarán los datos al sistema' Además, se especifica el proceso para producir los resultados deseados y la forma en que se van a transmitir esos resultados al usuario. Por último, se define la forma en que los datos se almacenarán en la computadora.
Programación. Consiste en elaborar los programas considerados en el diseño para cumplir con lo especificado por el usuario. Si la fase anterior se realizó adecuadamente, los encargados de desarrollar los programas sólo deberán seguir la secuencia que se especifica en el diseño. En esta fase se inicia la elaboración de la documentaci6n del sistema, la cual servirá para que el usuario sepa cómo operar el sistema y qué hacer cuando se presente algún problema.
Pruebas. Consiste en verificar si el sistema cumple con las especificaciones del usuario y su correcto funcionamiento; es decir, probar que haga lo que el usuario desea y que lo haga bien. Antes de implantar un sistema debe probarse utilizando datos ficticios y reales con el fin de cerciorarse de que está libre de errores, ya que si un error no se detecta, impactará de manera negativa durante la operación del sistema.
Implantación. Consiste en instalar el sistema en el ambiente en que operará y en realizar los procesos necesarios para que opere correctamente. Al terminar esta fase el usuario puede iniciar con la operación real del sistema, para lo cual requerirá capacitación sobre el uso adecuado de cada una de las funciones que se realizan. En esta fase es muy importante que el usuario participe activamente para que la capacitación sea exitosa y después pueda operar el sistema en forma correcta.
Operación. Consiste en que el usuario utilice el sistema desarrollado en el ambiente real de trabajo, es decir, que trabaje con él para cumplir con los objetivos deseados al momento de definirlo. Esta fase del método tradicional corresponde a la fase de operación presentada en el modelo del ciclo de vida de sistemas.
Como ya se mencionó, las fases anteriores son consecutivas, el resultado de una es el inicio de la otra, pero es posible regresar a la fase anterior y, si es necesario, hacer correcciones o agregar nuevas funciones. Existen dos conceptos relacionados con el proceso de aseguramiento de la calidad durante el desarrollo del sistema al utilizar la alternativa del método tradicional:
- El usuario del producto desarrollado es el factor más importante en el establecimiento y evaluación de la calidad, es decir, el usuario es quién determina si el sistema satisface con sus requerimientos.
- Es mucho menos costoso corregir un problema de calidad en sus primeras etapas antes de que el problema se envuelva en quejas del usuario y resulte en crisis. Este concepto está ilustrado en la figura 10.6.
En la gráfica se relaciona la naturaleza o tipo del error, es decir, la fase en que se generó el error versus la etapa en la cual se detectó el error. Así, si un error es detectado con mayor prontitud, será menos costoso corregirlo. En la gráfica el costo menor está indicado con la raya del "Modelo óptimo", luego con el número 1 y el mayor con 5. Lo óptimo o deseable es que los errores se detecten oportunamente, es decir, en la fase en que se generaron. Por ejemplo, un error de factibilidad debe detectarse en la fase de factibilidad, uno de diseño en la de diseño y así de forma sucesiva. Si un error de factibilidad se detecta en la fase de pruebas, resulta muy costoso corregirlo, si se observa en la gráfica, aparece un 5, en cambio si ese error se detecta en la fase de diseño es menos costoso (2 en la gráfica).
Para poder lograr un modelo de desarrollo óptimo es necesario considerar en el proceso los siguientes aspectos:
Aseguramiento de Calidad total?(T.Q.A: Total Quality Assurance)
El proceso de desarrollo de sistemas involucra muchos riesgos, sobre todo en sus fases iniciales, en las cuales debe quedar bien definido, es por eso que las empresas que inicien el desarrollo del sistema deben asegurar desde las fases iniciales la calidad total del sistema terminado.
El aseguramiento de calidad total consiste en controlar el sistema durante todo el proceso de desarrollo, estableciendo una responsabilidad activa a los usuarios. Deben estar involucrados desde el inicio el analista del sistema y el usuario responsable para lograr asegurar la calidad del producto terminado.
Una de las acciones más fuertes que se derivan del concepto de Calidad Total es llevar a cabo en forma rutinaria revisiones estructuradas, con el fin de monitorear todo el proceso, detectar problemas y considerar las soluciones propuestas para la corrección de los problemas detectados durante el proceso de desarrollo. El objetivo de estas revisiones es evaluar el sistema conforme se va desarrollando y no esperar a que se concluya para determinar la calidad del mismo.
Técnicas de Diseño y Documentación
Es necesario contar con técnicas adecuadas para realizar la fase de diseño y para tener documentado todo el proceso. El diseño de un sistema puede ser ascendente (bottom-up) o descendente (top-down). Cuando se realiza un diseño ascendente se inicia por los niveles operativos de la organización y, posteriormente, se definen los requerimientos de los niveles más altos, dependiendo de las necesidades de sistemas que se tengan. En el caso del diseño descendente, el diseñador parte de la estructura global de la empresa y de sus objetivos y busca la mejor manera de satisfacerlos al desarrollar el sistema. El diseño más recomendado es el descendente, debido a que integra a la organización en el sistema desde su inicio.
Por otro lado, la documentación constituye un problema porque en ocasiones los estándares para realizarla se implantan después de que se llevó a cabo el proceso de desarrollo, además, documentar requiere de tiempo y de recursos, lo cual provoca que se realice mantenimiento al sistema sin contar con la documentación adecuada. Generalmente la documentación se realiza hasta que se concluye el desarrollo del sistema y en ocasiones con premura para cumplir con el tiempo estimado. Esto puede tener como consecuencia una calidad pobre en la documentación, y afecta después la operación y el mantenimiento del sistema.
La documentación de un sistema debe proporcionar un panorama del mismo, especificar los procedimientos que se llevan a cabo y la forma de operarlo. Además de esta documentación, la cual con mayor frecuencia se dirige al usuario, debe documentarse y detallarse la estructura de archivos y programas con el objetivo de que pueda realizarse un mantenimiento adecuado.
Pruebas del Sistema
Este proceso se realiza con el fin de asegurar que el sistema esté libre de errores y debe de realizarse durante todo el proceso y no sólo en la fase final.
La evaluación de un sistema involucra diferentes niveles y tiempos antes de que el sistema inicie su operación. Para realizar las pruebas puede utilizarse el modelo de Kendall & Kendall, el cual consta de cuatro tipos de pruebas. El primer tipo de pruebas se realiza a nivel de los programadores para comprobar los programas utilizando datos de prueba o ficticios. El segundo deben realizarlo los analistas para probar el funcionamiento entre los programas, utilizando para ello datos de prueba, para verificar que el sistema trabaje como una unidad. En el tercero participan los operadores, probando todo el sistema con datos de prueba y, por último, en el cuarto nivel participan los usuarios, probando todo el sistema con datos reales. Este modelo está ilustrado en la figura 10.7. Aquí se muestran las personas involucradas durante las pruebas del sistema y en cada una de ellas indica el nivel de la prueba que se realiza y el tipo de datos que se usa. Sólo en el caso de los usuarios el sistema se prueba con los datos reales, en los otros casos se usan datos ficticios.
Mantenimiento
Es el proceso mediante el cual se realizan mejoras a un sistema para que tenga una vida útil mayor. También se le llama mantenimiento a las modificaciones que deben hacerse cuando el usuario cambia los requerimientos iniciales o cuando se detectan fallas durante la operación. En esta fase es necesario cuidar la calidad del sistema, de manera que se evite que se introduzcan errores e ineficiencias.
Muchas organizaciones invierten recursos económicos cuantiosos para dar un buen mantenimiento a sus sistemas. Estos costos pueden llegar a elevarse a niveles alarmantes, por lo que se sugiere controlar estrictamente este renglón del presupuesto de Informática.
Prototipeo
La otra técnica en la estructuración de los sistemas es el prototipo o prototipeo. El problema fundamental de este método es que en muchas aplicaciones, el determinar de antemano las necesidades es muy difícil la mayoría de las veces. La técnica del prototipeo se basa en el siguiente principio fundamental: Los usuarios pueden indicar con mayor facilidad los dispositivos que más les gusten o les desagraden en un sistema ya existente que describirlos en un sistema imaginario o propuesto.
El prototipo se estructura como un sistema de trabajo para permitir que los usuarios identifiquen los dispositivos esenciales en un sistema de información. En esencia, es una versión experimental del nuevo sistema. Cuando se utiliza en la evolución de los sistemas de información, el establecimiento de un prototipo no puede ser un proceso largo, ni tampoco el costo del modelo debe ser considerablemente diferente del costo del sistema eventual.
Existen cinco pasos básicos para la creación de un prototipo:
- Identificar las necesidades conocidas de información del usuario.
- Elaborar un modelo de trabajo
- Utilizar el modelo o prototipo mencionando las mejoras y los cambios necesarios.
- Revisar el prototipo.
- Repetir los pasos anteriores según sea necesario.
Durante el primer paso, tanto los analistas como el usuario determinan cuál es la información que debe producir el sistema e identificar los datos que deben ser procesados. Este paso toma menos de una semana y, normalmente, se termina en una o dos sesiones de trabajo.
La creación del prototipo de trabajo es responsabilidad de los analistas de sistemas. El prototipo del sistema consta de tres partes: interfase del usuario, rutinas de procesamiento y salida. Todos los diálogos con el usuario deben permitir entender fácilmente como alimentar los datos o las preguntas del sistema y cómo obtener resultados. Sin embargo, no necesita contener todos los mensaje o exhibir toda la información que normalmente se requieren en un sistema totalmente terminado y bien pulido.
COMPRA DE PAQUETES
Hay ocasiones en que una empresa necesita un sistema que ya se encuentra disponible en el mercado, en este caso resulta más costeable comprarlo que desarrollarlo utilizando el método tradicional. La compra de paquetes consiste en adquirir los sistemas que la empresa necesita, y ésta elige entre los que están disponibles en el mercado, es decir, ver y analizar los diferentes sistemas que ofrecen las empresas que se dedican sólo al desarrollo de paquetes y determinar cuál o cuáles son útiles para la empresa.
Un error en la compra de paquetes puede impactar mucho en las operaciones diarias de una empresa, provocar un incremento en costos y, por consecuencia, una disminución de las utilidades y del nivel de servicio a clientes y usuarios. Debido a lo anterior, el comprador debe asegurarse de la calidad del sistema que está adquiriendo. Para ello debe tomar en cuenta lo siguiente:
- Que el paquete satisfaga todos los requerimientos del usuario, es decir, que cumpla con los objetivos.
- Que opere con alta confiabilidad, que no ocurran errores con frecuencia.
- Que sea entregado a tiempo para poder iniciar con su operación.
- Que cumpla con los requerimientos de presupuesto, que no sea muy costoso o que el costo se justifique.
Este método difiere en varios aspectos del método tradicional:
- El desarrollo de un sistema utilizando el método tradicional involucra todos los costos asociados a él, es decir, el costo por el pago de las personas que participan en el proceso y el uso del equipo para el desarrollo. Cuando se opta por comprar un paquete debe cubrirse el costo del paquete y el de las modificaciones necesarias para adecuarlo a las necesidades de la empresa.
- Por otro lado, el tiempo que transcurre desde el estudio de factibilidad hasta la implantación y operación del sistema, utilizando el método tradicional, es mayor que al comprar un paquete en el mercado, ya que en el primer caso los programas deben ser desarrollados. En el caso de compra de paquetes los programas ya existen y solamente se requiere hacer las adecuaciones. Esto último debe ser menos tardado que desarrollar los programas partiendo de cero.
- En lo referente al mantenimiento del sistema, cuando se utiliza el método tradicional éste se hace internamente. Sin embargo, existe el riesgo de la rotación del personal, por lo que es necesario que exista buena documentación para facilitar dicho proceso. Cuando se compra un paquete el mantenimiento se realiza en forma externa a la empresa, lo cual generalmente resulta muy costoso. La empresa que compra el paquete debe tratar de negociar con el proveedor para que acepte que el mantenimiento lo haga ella misma.
- El método tradicional generalmente se utiliza cuando se desea un sistema hecho a la medida de las necesidades de la empresa, en este caso se llama sistema «ad?hoc» o específico a los requerimientos. Cuando se adquiere un paquete se trata de una aplicación general, en la cual será necesario modificar algunos aspectos para que funcione de acuerdo a las necesidades de la empresa, ya que el objetivo de un paquete es que sirva a la mayoría de los usuarios y no sólo a uno en particular.
- Al desarrollar un sistema utilizando el método tradicional debe tenerse cuidado con el tiempo estimado para realizar este proceso, no deben prometerse fechas demasiado optimistas, pues lo más probable será que no se cumplan. También debe tomarse en cuenta que puede existir rotación de personal durante el proceso de desarrollo y ello involucra que se retrase el avance del proyecto, pues será necesario capacitar a la persona nueva sobre lo que se está haciendo. En el otro enfoque (compra de paquetes) el usuario debe ser cuidadoso para no ser el «conejillo de indias» en el desarrollo y uso del paquete.
- También, la empresa debe considerar al usuario antes de adquirir el paquete, ya que finalmente el usuario será quien lo opere y no debe asumir que van a necesitarse pocas modificaciones. La empresa debe estar consciente de que el costo de un paquete representa sólo una parte de los costos totales de la operación y mantenimiento.
- Al implantar un sistema se incurre en costos similares, tanto si se utilizó el método tradicional para desarrollarlo, como si se adquirió en alguna empresa. Esto se debe a que el proceso de implantanción debe realizarse independientemente del método utilizado para el desarrollo.
Concepto
|
Método Tradicional
|
Compra de paquetes
|
Costo
|
Costo del desarrollo.
|
Costo del paquete más el costo de las modificaciones necesarias.
|
Tiempo
|
Mayor.
|
Menor.
|
Mantenimiento
|
Se realiza internamente.
|
Se realiza en forma externa a la empresa.
|
Tipo de aplicación
|
«Ad?hoc» hecho a la medida.
|
Aplicación general.
|
Cuidado con:
|
Fechas optimistas.
Rotación durante el proceso
|
No ser «conejillos de indias».
Asumir que las modificaciones son menores.
Tener el visto bueno del usuario antes de comprar.
El costo del paquete puede ser mínimo con respecto al costo total.
|
Implantación
|
Costos similares.
|
Costos similares
|
CÓMPUTO DEL USUARIO FINAL
El cómputo de usuario final se refiere al sistema que se desarrolla directamente por el usuario final, utilizando herramientas de desarrollo de alto nivel sin la participación operativa de analistas o programadores del área de Informática.
Un ejemplo de esta alternativa es el desarrollo de un modelo de pronósticos en Excel, que se realice por un Gerente de Finanzas de una empresa, que es quien lo utilizará. Este método difiere en varios aspectos del método tradicional, algunos de los cuales se comentan a lo largo de esta sección.
Cuando se desarrolla un sistema utilizando el método tradicional es necesario definir todos los requerimientos en la fase inicial de desarrollo, cuando el usuario desarrolla su propia aplicación los requerimientos se pueden ir integrando conforme se va realizando este proceso, ya que el mismo usuario es quien los define y desarrolla.
El papel del analista de sistemas varía, en el caso del método tradicional es completamente responsable del análisis y del desarrollo, y en el caso del cómputo del usuario final únicamente asesora y aconseja a quien lo usará.
Las herramientas que se utilizan para desarrollar sistemas siguiendo el enfoque del método tradicional son lenguajes de III y IV generación, tales como Pascal y Visual Basic; en cambio en el cómputo del usuario final se utilizan lenguajes de IV generación, debido a la facilidad que tienen para desarrollar aplicaciones sin necesidad de tener conocimientos muy profundos de programación. Además estos lenguajes tienen la característica de que son amigables, lo cual facilita su uso. Ejemplos de herramientas para que el usuario desarrolle sus propias aplicaciones son: Excel, Power Point y Word, entre otros.
Las aplicaciones que el usuario final desarrolla para su uso generalmente son Sistemas de Soporte a la Toma de Decisiones, los cuales apoyan sus funciones y le permiten realizar análisis de sensibilidad para ver qué pasa si se presenta alguna situación en particular. Un ejemplo de lo anterior puede ser el tratar de analizar efecto que tiene sobre la utilidad del negocio el incremento en el precio de venta de algún producto. En el caso del método tradicional, con mayor frecuencia se desarrollan aplicaciones, que apoyan las operaciones transaccionales de una empresa o que recolectan información para apoyar el proceso de toma de decisiones. Tal puede ser el caso de un sistema de facturación o de nómina.
La siguiente tabla muestra un resumen de lo antes explicado:
Concepto
|
Método Tradicional
|
Cómputo de usuario final
|
Identificación de necesidades
|
100% antes de iniciar el desarrollo.
|
Se pueden detectar e integrar las necesidades durante toda la vida de la aplicación en forma directa por parte del usuario.
|
Analista del sistema
|
Es responsable 100% del análisis y desarrollo. El usuario participa en forma limitada.
|
El usuario es el responsable.
El analista sólo aconseja y asesora
|
Herramienta de desarrollo
|
Lenguajes de III y IV generación.
|
Lenguajes de IV generación. Paquetes.
|
Tipo de aplicación
|
Nivel transaccional.
Recolectores de información.
|
Sistemas de Soporte a la
Decisión (D.S.S.).
Análisis de sensibilidad “What if”. Explotadores
de información.
|
Por otro lado. el desarrollo de sistemas por parte del usuario final puede presentar una serie de riesgos inherentes a la calidad del producto final, entre los cuales se pueden mencionar:
- Información incorrecta que se genera por una aplicación y que es consecuencia de fórmulas o modelos incorrectos, utilización de información obsoleta o no actualizada y falta de prueba de modelos. Esto se debe a que el usuario no es experto en el área de desarrollo de sistemas, por lo cual puede estar utilizando procedimientos incorrectos para generar su aplicación, sin tener cuidado de hacer pruebas y validar resultados. Por ejemplo, un ejecutivo que haga su propio modelo para proyecciones financieras, tal vez obtenga información incorrecta si no utilizó los modelos adecuados o si no hizo las pruebas suficientes.
- Desaparición de la fase de análisis, la cual constituye la base para el desarrollo de las demás fases. Generalmente el usuario final se enfoca al desarrollo de la aplicación sin considerar un análisis previo, esto puede ocasionar errores en el sistema, los cuales requerirán ser ajustados durante su operación.
- Proliferación de sistemas aislados debido a que cada quien desarrolla lo que necesita y es probable que se esté duplicando el trabajo dentro de la organización. Es muy importante tener un control sobre las aplicaciones que desarrolla un usuario, debido a que es probable que una misma aplicación sirva a diferentes usuarios y que cada uno de ellos la esté desarrollando. Debe minimizarse el esfuerzo, y esto se logra permitiendo que se comparta una aplicación con todos los usuarios que la necesitan.
- Reducción de la calidad y estabilidad de los sistemas desarrollados debido a que cada quien sigue sus propios estándares de desarrollo. La empresa debe tener establecidos los estándares de calidad para el desarrollo de sistemas y darlos a conocer a los usuarios interesados en desarrollar sus propias aplicaciones, para que sean cumplidos y se estandarice el desarrollo individualizado de sistemas.
- Especificaciones incompletas de los requerimientos del sistema debido a que se va realizando conforme se necesita. Esto se debe a que no se hace un planteamiento formal de cuáles son los requerimientos del sistema y éstos se van incorporando conforme el usuario se da cuenta de que los necesita.
Los métodos de adquisición explicados antes (método tradicional, compra de paquetes y cómputo del usuario final) están relacionados con la evolución que han tenido los Sistemas de Información y con las etapas de Nolan que se mencionaron en el capítulo 1. En la figura 10.8 puede observarse esta relación.
En cuanto a la evolución de los Sistemas de Información se tienen los Sistemas Transaccionales, los Sistema de Apoyo a las Decisiones y los Sistemas Estratégicos, cada uno de ellos está relacionado con un método de adquisición: compra de paquetes, cómputo del usuario final y método tradicional, respectivamente.
Cuando una empresa se inicia en el uso de los Sistemas de Información, con frecuencia adquiere paquetes para automatizar las operaciones transaccionales, conforme va avanzando en las etapas de contagio y control busca automatizar actividades que apoyen el proceso de toma de decisiones, para lo cual es el propio usuario el que desarrolla sus aplicaciones. Al final. y mediante el método tradicional de desarrollo de sistemas. desarrolla Sistemas Estratégicos con el objetivo de obtener ventaja competitiva.
En la parte inferior de la figura 10.8 pueden observarse las etapas mencionadas por Nolan en la evolución de sistemas: inicio, contagio, control, integración, administración de datos y madurez. Estas etapas, fueron explicadas en el capítulo 1.
OUTSOURCING
El desarrollo de sistemas en una empresa es un proceso que requiere una gran inversión en recursos, tanto económicos como humanos. Hay empresas en las cuales se justifica tener un departamento de sistemas interno, que sea el encargado de realizar todas las funciones de sistemas; sin embargo, en otras empresas no es rentable contar con un departamento de sistemas interno, debido a que están muy enfocadas a su actividad básica y no tienen la experiencia necesaria en el área de sistemas. Para estas empresas que desean concentrarse más en su actividad principal y tener buenos sistemas existe una opción apropiada: Outsourcing.
Outsourcing consiste en contratar en forma externa algunos o todos los servicios que proporciona un departamento de Sistemas de Información. Este concepto se basa en dos aspectos: primero, una empresa debe concentrar sus esfuerzos en aquellas actividades que sabe hacer y, segundo, una empresa debe utilizar las ventajas de las economías de escala y de las economías de expertise o experiencia que tienen las empresas que se dedican exclusivamente a proporcionar servicios de Sistemas de Información. Por ejemplo, una empresa manufacturera debe dedicarse a producir los bienes que fabrica, un banco debe dedicarse a manejar el dinero y una empresa de sistemas debe dedicarse a sistemas.
Outsourcing es un concepto relativamente nuevo, en 1989 Kodak hizo un trato con IBM para subcontratar sus servicios de Informática. Este hecho marcó el inicio y el éxito que tiene este servicio en la actualidad.
Ventajas del Outsourcing
Utilizar outsourcing tiene numerosas ventajas, las principales son ahorro en costos mediante economías de escala y consolidaciones (ya que la empresa que ofrece el outsourcing se especializa en ello), una mayor liquidez al: deshacerse de equipo computacional que ya no es necesario para el desarrollo de sistemas (solo para la operación) y un decremento de los gastos por depreciación de equipo. como consecuencia de la disminución en el equipo computacional.
Por otro lado, el outsourcing proporciona acceso a los avances tecnológicos sin inversión de capital, debido a que la empresa que realiza el outsourcing es quien debe invertir en ello para después recomendarlo a sus clientes. También permite la descentralización de actividades en la empresa, ya que generalmente el área de sistemas está centralizada, además de tener acceso a utilerías para recuperas y respaldar sistemas, mismas que son proporcionadas por la empresa que realiza el outsourcing. De manera paralela. es posible convertir al departamento de sistemas de la empresa en un centro de utilidades, ya que se dedicará a ofrecer servicios de outsourcing a otras empresas.
Desventajas del Outsourcing
El outsourcing tiene numerosas ventajas, esto puede verse en lo antes mencionado; sin embargo, también tiene algunas desventajas. Una de las principales desventajas de este servicio es la pérdida de control sobre el proceso desarrollo, ya que el usuario no está cien por ciento involucrado en ello. También el outsourcing puede ocasionar costos por cambio o conversión a nuevas tecnologías que son recomendadas por la empresa que brinda el servicio y cambios organizacionales que pueden causar problemas, ya que lo más probable es que el área de sistemas disminuya su número de empleados.
Cuando se contrata un servicio externo de sistemas es importante que se negocien los siguientes aspectos, entre otros:
- Características del servicio, qué incluye y determina la manera en que se proporcionará
- Tiempos de entrega y fechas estimadas.
- Estándares de desempeño.
- Las condiciones en caso de cancelar el contrato.
- Condiciones sobre personal transferido temporalmente a la empresa que realiza el outsourcing.
- Los derechos de propiedad sobre el servicio prestado.
- La confidencialidad del trabajo realizado.
- El ajuste de los precios dependiendo de la inflación.
- El soporte que brinda una vez terminado el servicio.
- Los beneficios por avances tecnológicos.
- La flexibilidad del contrato en cuestiones no consideradas al principio.
El outsourcing puede proporcionar innumerables ventajas si se utiliza adecuadamente y si la empresa está preparada para llevar de esta manera los Sistemas de Información. Antes de contratar este servicio debe hacerse un análisis de la empresa para ver que posibles cambios generará y cómo canalizar de la mejor manera los problemas que pudieran presentarse.
TENDENCIAS FUTURAS
El alto costo del método de desarrollo tradicional y el crecimiento de la cantidad de diferentes aplicaciones, ha hecho muy atractivo el uso de paquetes para los usuarios. La tendencia actual es ver el software como cualquier otro producto terminado, el cual puede ser desarrollado y vendido en diferentes países. Esto introduce un concepto que impactará el mercado de software en los próximos años: la globalización del software o como algunos autores la llaman: la internacionalización del software.
Se han realizado proyectos conjuntos en donde interactúan países desarrollados con países en desarrollo contando con personal especialista en Sistemas de Información, Sistemas Computacionales y Bases de Datos. Es necesario estar preparados para ello. La realización de proyectos conjuntos generan ventajas tanto para los países desarrollados como para los países que están en vías de desarrollo. Las ventajas para los países desarrollados son:
- Disminución de los costos de desarrollo de software principalmente en lo referente a la mano de obra (disminuyen entre un 10 y 40%). Esto se debe a que para un país desarrollado es menos costoso contratar mano de obra especializada de un país en vías de desarrollo.
- Penetración en nuevos mercados que son atractivos. Esto permite estrechar lazos comerciales con países en desarrollo abriendo un mercado potencial de nuevos compradores para sus productos. Los países en desarrollo constituyen un mercado muy fuerte para la introducción de productos por parte de los países desarrollados, si se realizan proyectos conjuntos habrá más oportunidad de ampliar los mercados para sus productos en los países en vías de desarrollo.
Por otra parte, las ventajas para los países en desarrollo son:
- Son receptores en la transferencia de la tecnología. Esto se logra al realizar proyectos conjuntos que absorban con rapidez la tecnología de punta, permitiendo administrar los proyectos de software, utilizar conceptos de ingeniería de software y herramientas productivas para el desarrollo.
- Obtienen beneficios relacionados con ingresos económicos que reciben los profesionistas que se involucran en proyectos conjuntos.
Otra tendencia que es importante considerar es el incremento en el uso de tecnologías de integración para el desarrollo de sistemas, específicamente de CASE (Computer Aided Software Engineering), que es una herramienta que permite mejorar las tareas rutinarias automatizándolas e integrando el desarrollo de un sistema desde su fase inicial hasta la final. Utilizar herramientas CASE incrementa la productividad, permite una mejor comunicación entre los usuarios e integra todo el ciclo de desarrollo.
Casi a la par con el uso de las herramientas CASE se está incrementando la utilizaci6n de tecnologías orientadas a objetos, las cuales cambian radicalmente el enfoque tradicional y estructurado de realizar el desarrollo de sistemas con base en funciones. La tecnología orientada a objetos se basa más que en funciones en los objetos sobre los cuales se realiza la función, o sobre los que son responsables de realizarla. Por ejemplo, un objeto puede ser un botón de aceptar o cancelar en una sección de un sistema.
Una ventaja importante de la tecnología orientada a objetos es que promueve la reutilizaci6n de partes de un sistema por otros sistemas diferentes, con lo cual se ahorra tiempo de desarrollo. Para ilustrar la reutílizaci6n veamos el siguiente ejemplo: la primera vez que se ensambla un carro es necesario hacer cada una de sus partes y tenerlas disponibles en cierto orden, cuando se desea ensamblar otro carro pueden reutilizarse piezas del primer vehículo.
4.5
Apple
No hay comentarios:
Publicar un comentario