Capitulo 12 Metodologias

-

12.2 Elaboración deprototipos

• Etapasen la construcción.de prototipos

• Ventajas y desventajas dela elaboración de losprototipos ,VENTANA SOBRE TECNOLOGIA:elaboración de prototipos deinterfases gráficas con elusuario: nuevas herramientasal rescate

Brookstone cambia su .estrategia de desarrollode sistemas

lZ.1 El cieDode vida'tradicional de lossistemas

, Etapasdel ciclo de vida delossistemas

8 Limitaciones del enfoquedel ciclo de vida

------12.3 DesarroUo de

sistemas conpaquetesde ~~ft.waiede'éllplicacüones

• Ventajas y desventajas delos paquetes de software

• Selección de paquetes desoftware

• Los paquetes y el procesode desarrollo de sistemas

112.4 D4!sarrollo por

usuarios fi!li~le!i}.'

• Herramientas de cómputodel usuario final: fuerzas ylimitaciones

• Beneficios y problemas deadministración

• Administración deldesarrollo de usuariofinalVENTANA SOBREADMINISTRACiÓN:¿Qué se debe permitir quehagan los usuarios fina/es?

12.5 Fuentes externas enlos sistemas deinformación .

• Ventajas y desventajas deacudir a fuentes externas

• Cuándo utilizar a losprovedores externos

• Administración de laconcesión a fuentesexternasVENTANA SOBREINSTITUCIONES:

~ las empreses petrolerascanadienses hacen unmovimiento audaz haciafuentes externas

Retos de administraciónResumenTérminos clavePreguntas de repasoPreguntas para la discusiónProyecto de grupoCaso de estudio: ¿Puede un

gigante etemén delsoftware conquistar aNorteamérica?

Referencias

1it T-

r

I/

(}df!~tn;!iddf~#4, los SIS~d?,dt- I/1/1:71 »ea el au" O1tul/~de 10V1 t

k«. nne. +h ¿J" !.avdv 17

::¡~~Pc1atJ1Jo/l ¡.(J/'f. Pr/n-ltBrookstone cambia su estrategia dedesarrollo de sistemas

Brookstone Tools, la empresa de Peterborough, Nue-va Hampshire, especialista en pedidos por correo yventas al detalle, encontró que su enfoque primarioestaba cambiando de las ventas por correo a las ven-tas al detalle. La mayoría de sus operaciones deventas ocurrían durante un estrecho período de tresmeses. Brookstone necesitaba de sistemas de infor-

• Seguimiento de ventas• Asegurar que los sistemas

de información apoyenoperaciones de negocios

~ Seguimiento de costos ensistemas de información

• Min.cornputadorasIBM AS/400

• MacrocomputadoraIBM 4381

• Paquetes de software

• Operaciones de pedidosi:X correo

o Tiendas de ventasal detalle

mación que permitieran las ventas al detalle asícornolas ventas por correo y manejaran grandes volúme-nes de operaciones de ventas durante el período picode ventas. Desafortunadamente, los sistemas basa-dos en macrocomputadoras que originalmente sedesarrollaron para permitir operaciones de ventas'por correo no tenían la capacidad de manejar estas

Retos de negocios ••••••••••• Enfoque desplazándose de las ventas

por correo a las ventas 01detalle•• Periodo reducido de ventas máximas

Administración

Tecnología (le información Sistema de i~ormación

Institución

SOIUdO~~,\de negocIOs "

rí'tl)\? ''Í'\

• Reducir costos de sistem~~'deinformación '

• Incrementar servicio al cliente

fli'tu",cle-'

COI",te'-rrner~,<'"iI{~(

rE'

pab<tein

• Procesamiento de operaciones aldetalle y por correo

• Proporcionar acceso a datosdetallados de ventas

ción de bases de datos, y el Arthur Planning de laComshare lnc., un sistema de planeación de comer-cialización e información ejecutiva de ventas al deta-lle que podría permitir el acceso a las grandes canti-dades de datos empleados en las operaciones deventas al detalle.

Al usar los paquetes de software como la basepara los nuevos sistemas de información, Brookstoneredirigió las energías de su departamento de siste-mas de información. En vez de gastar la mayor partede su esfuerzo en desarrollo costoso y consumidor detiempo de nuevos sistemas, el uso de los paquetesde software los liberó para enfocarse en cuestiones denegocios, como la manera de incrementar las opor-tunidades y el servicio del procesamiento de pedidosde Brookstone durante el periodo de ventas má-ximas.

Al buscar otros métodos para el desarrollo de sussistemas, Brookstone también esperaba ahorrar másde un millón de dólares por año reduciendo personaly disminuyendo los gastos de soporte técnico paralos sistemas de información. Tan pronto como en1992, pudo reducir a la mitad su plantilla de progra-madores.

o

:03-

:slS

Fuente: Christoper Lindquist, "Changing the Game at Brookstone", Computerworld (enero 27, 1992).

Así como la Brookstone Tools, muchas instituciones están examinan-lo otrosmétodos para construir nuevos sistemas de información. Así como diseñan :'construyen algunas aplicaciones dramáticamente, también están cambiando a lospaquetes de software y a otras estrategias para reducir tiempo, costo e inenciencis.En este capítulo se examina el uso de prototipos, paquetes de software de aplicacio-nes, desarrollo por usuarios finales y el recurso a fuentes externas como alternativaspara el desarrollo de sistemas, contra el método tradicional del ciclo de vida o,,: lossistemas para el desarrollo de un sistema total de información a partir de la nada

funciones Y estaban en peligro de sufrir un colapsoinminente. Esta configuración era también muy cos-tosa. Brookstone estaba gastando un 1.2 por cientode sus ingresos por ventas en sistemas de informa-ción, mientras que el promedio del sector industrialera sólo de 0.8 por ciento. Para resolver ambosproblemas, en 1989 Brookstone dio pasos para reor-ganizar totalmente la manera como desarrollaba sussistemas de información.

Brookstone decidió mantener su pequeña rnacro-computadora IBM 4381, para que corrieran solamen-te sus sistemas de ventas por correo, y usar unaminicomputadora IBM ASj400 para los nuevos siste-mas de ventas al detalle y otros aspectos de susoperaciones menudas. En vez de desarrollar su pro-pio software para estos sistemas nuevos, Brookstonedecidió emplear exclusivamente paquetes de softwa-re disponibles en el mercado.

Hasta que los nuevos sistemas de ventas al detallese construyeran, Brookstone sacó ventajas de lospaquetes de software para crear nuevas aplicacionesbasadas en sus sistemas y sus bases de datos existen-tes. Usó el Data Interpretation System de IBM, unainterfase gráfica de su sistema DB2 de administra-

~----- ~-

Brookstone cambia su estrategia de I ~:2desan 0110 de sistemas ¡ ..•

No existe un enfoque que pueda ser usado en todas las situaciones y tipos desistemas. Cada uno de estos enfoques tiene ventajas y desventajas, y cada unoproporciona a los administradores una amplia gama de alternativas, de manera qUeestos puedan escoger. .

Luego de terminar este capítulo se tendrá la capacidad de:

• Distinguir las distintas alternativas de desarrollo de sistemas, el ciclo tradicionalde vida de los sistemas, los prototipos, paquetes de software para aplicacionesdesarrollo por los usuarios y fuentes externas. '

• Entender las ventajas y limitaciones de cada enfoque.• Describir los tipos de problemas para los cuales cada uno es más adecuado.• Describir las soluciones a los problemas de administración creados por estos

enfoques.

'12.1 El ciclo de vida tradicional delos sistemas '

Ciclo de vida de los sistemas:Metodología tradicional paradesarrollar un sistema deinformación que hace unapartición del proceso dedesarrollo en seis etapas formalesque deben ser recorridas enforma secuencial con una muyformal división del trabajo entre

s usuarios finales y los.:specialistas en el diseño desistemas.

El ciclo de vida de los sistemas es el método más antiguo para el desarrollo desistemas de información, y aún se utiliza para proyectos de sistemas complejosmedianos o grandes. Esta metodología supone que un sistema de información tieneun ciclo de vida semejante al de todo organismo vivo, con un comienzo, una vidamedia y un final. El ciclo de vida de un sistema de información tiene seis fases:definición del proyecto, estudio de sistemas, diseño, programación, instalación ypostimplantación, que se ilustran en la figura 12.1. Cada fase consta de actividadesbásicas que deben ser realizadas antes de que la siguiente fase pueda iniciarse.

La metodología del ciclo de vida es un enfoque muy formal para el desarrollo desistemas. Hace una partición del proceso de desarrollo de los sistemas en distintasfases y desarrolla un sistema de información de manera secuencial, fase por fase.La metodolo ía del ciclo de vida también implica una división del traba'o muy-~al entre usuarios finales y es ecialistas en SIstemas de información. Especia- -listas técnicos como analistas de sistemas y programadores son responsables de lamayoría de los análisis, diseño y trabajo de implantación de los sistemas; losusuarios finales se limitan a proporcionar requerimientos de información y revisanel trabajo del personal técnico. Acuerdos o convenios formales entre los usuariosfmales y los especialistas técnicos son necesarios a medida que se termina cada etapa.

En la figura 12.1 también se muestra el producto o resultado de cada etapa delciclo de vida que es la base de tales convenios. El resultado de la etapa de definiciónes una propuesta para el desarrollo de un nuevo sistema. El estudio del sistemaproporciona un informe detallado con una propuesta donde se destacan las distintassoluciones y se establece la factibilidad de todas ellas. El resultado de la etapa dediseño es un informe sobre las especificaciones de diseño para el sistema soluciónque se haya seleccionado. El resultado de la etapa de programación en un códigoreal de software para el sistema ..La etapa de instalación tiene como producto elresultado de las pruebas para evaluar el desempeño del sistema. La etapa posteriora la implantación concluye con una auditoría posterior a la implantación para medirel grado hasta el cual el nuevo sistema ha cumplido con sus objetivos originales.Ahora se describen con detalle las etapas del ciclo de vida.

_tapas del ciclo de vida de los sistemasLa etapa de definición del proyecto trata de responder a las siguientes preguntas:¿Por qué se necesita un nuevo proyecto? ¿Qué es lo que se desea alcanzar? En esta

Capitulo 12Otros métodos de diseño de sistemas

figura 1Metodoel desaren cadaque pro

ET.t

Defini.pro'

Event.tniciacdel pr

Deflni,del cicen doninstitu,proble.resueltsistern,Análisciclo ddondede losdefine:alcaazevalúa

PRODUCTOS FINALES

Año 1

flqU(~;I~;ía del ciclo de vida para un desarrollo de sistemas. Este método divide'vietosarrollo de sistemas en seis etapas formales con cuentas y productos finales específicosel de da una de ellas. Un proyecto típico de tamaño mediano requiere de dos años paraen a raduzca y tiene una vida útil de 3-8 años.qUe P

Informe de propuesta------------------------------, definitiva

Informe de propuesta desistemas

ETAPAS

[§ÓOd"proyecto

Diseño Especificaciones de diseño

Estadio desistemas

Código de------------ •., especificaciones de

programa

InstalaciónPruebas de desempeño desistemas

Auditoría luego de laimplantación

Posimplantación.

~ t_· __ t t__ ~Evento 1Iniciacióndel proyecto

OPERACIONESEvento 2Decisiónsobresolución deldiseño

. Evento 4·Decisiónde producción

Evento 3Firma deespecificacionesde diseño

Año 2 3-8 Vida útil

etapa se determina si la institución tiene un problema y si puede ser resueltomediante el desarrollo de un nuevo sistema de información o la modificación del yaexistente, Si se opta por un proyecto de sistemas, en esta etapa se identifican losobjetivos generales, se especifica el alcance del proyecto y se desarrolla un plan delproyecto que pueda ser presentado a la dirección.

En la etapa de análisis de sistemas se estudian los problemas de los sistemasexistentes (manuales o automatizados) en detalle, se identifican los objetivos a seralcanzados por una solución y se describen las diversas soluciones. En la etapa eanálisis de sistemas se examinan la factibilidad de cada una de las distintas solu ic-nes para que la dirección las analice. Se dan respuesta a las siguientes preguntas:¿Qué hacen los sistemas ya existentes? ¿Cuáles son sus fuerzas, debilidades, pun 05

conflictivos y problemas? ¿Qué debe hacer un nuevo sistema u otro modificado rararesolver estos problemas? ¿Qué requerimientos de información para usuario be

12.1 El cic.o de vida tradicional de I 2.'los sistemas •

Definición del proyecto: Etapadel ciclo de vida de los sistemasen donde se determina si lainstitución tiene o no unproblema y si puede o no serresuelto con un proyecto desistemas.Análisis de sistemas: Etapa delciclo de vida de los sistemas endonde se analizan los problemasde los sistemas existentes, sedefinen los objetivos a seralcanzados por la solución y seevalúan las distintas soluciones.

Diseño: Etapa del ciclo de vidade los sistemas en donde seproducen las especificaciones deldiseño lógico y fisico de lasolución de sistemas.

Programación: Etapa del ciclode vida de los sistemas en.dondese traducen las especificacionesde diseño producidas en laetapa de diseño en códigode programación.

Instalación: Etapa del ciclo devida de los sistemas en donde serealizan las pruebas, capacitacióny conversión, las etapas finalesque se requieren para poner enmarcha a un sistema.

Posimplantación: Etapa delciclo de vida de los sistemas endonde el sistema se usa, seevalúa en operación y semodifica para hacer mejoras osatisfacer nuevos requerimientos.

ser satisfechos por la solución? ¿Qué opciones de distintas soluciones son factibles?¿Cuáles son sus beneficios y sus costos? .

La respuesta a estas preguntas requiere de una extensa recopilación e investiga.ción de la información; meterse a íos documentos, informes y papeles de trabajoproducidos por los sistemas existentes; observar cómo trabajan tales sistemasencuestar a los usuarios y realizar entrevistas. Toda la información recopilad~durante la fase de análisis de sistemas será usada para determinar los requerimientosdel sistemas de información. Finalmente, la etapa de análisis de sistemas describe adetalle las actividades restantes del ciclo de vida y las tareas en cada fase.

La etapa de diseño produce las especificaciones de diseño lógicas y fisicas parala solución. Como el ciclo de vida destaca las especificaciones formales y ladocumentación, muchas de las herramientas de diseño y documentación que sedescriben en el capítulo 13, como diagramas de flujo de datos, gráficas de estructuradel programa, flujogramas del sistema, tablas o árboles de decisiones, tienen altaprobabilidad de ser utilizadas.

En la etapa de programación se traducen las especificaciones de diseño produ,cidas durante la etapa de diseño en código de programación. Los analistas desistemas trabajan con los programadores para preparar las especificaciones paracada programa del sistema. Estas especificaciones describen lo que cada programadebe hacer, el tipo de lenguaje de programación a ser usado, entradas y salidas,lógica de procesamiento, calendarios de procesamiento y enunciados de control,como los de la secuencia de los datos de entrada. Los programadores escriben uncódigo de programa adaptado en general usando un lenguaje convencional detercera generación como FORTRAN y COBOL o un lenguaje de alta productividadde cuarta generación. Como los grandes sistemas tienen muchos programas concientos de miles de líneas de código, puede llegar a necesitarse de equipos comple-tos de programadores.

La fase de instalación consiste en los pasos finales para poner al sistema nuevoo modificado en operación: pruebas, capacitación y conversión. Se prueba elsoftware para estar seguros que opera adecuadamente desde el punto de vistatécnico y del funcional de negocios. (En el capítulo 13 pueden encontrarse másdetalles sobre pruebas.) Los especialistas de negocios y los técnicos son capacitadospara usar el nuevo sistema. Un plan formal de conversión permite un cronogramadetallado de todas las actividades necesarias para instalar el nuevo sistema y que elviejo se convierta al nuevo.

La etapa de posimplantación consiste en el uso y evaluación del sistema luegode que se ha instalado y se encuentra en producción. También incluye actualizar alsistema para hacer mejoras. Los usuarios y especialistas técnicos estarán sujetos auna auditoría formal de postimplantación que determina qué tan bien ha cumplidoel nuevo sistema con sus objetivos originales y si se requieren revisiones o modifi-caciones. Luego de que el sistema se ha puesto a punto, es necesario darle man-tenimiento mientras esté en producción para corregir errores, cumplir con losrequerimientos o mejorar la eficiencia de procesamiento. Con el tiempo, el sistemapuede necesitar de tanto mantenimiento para permanecer eficiente y cumplir conobjetivos de los usuarios que llegará al final de su vida útil. Una vez que el ciclo devida del sistema llega a su fin, un sistema completamente nuevo se necesita y elciclo se inicia de nuevo.

limitaciones del enfoque del ciclo de vidaEl ciclo de vida de los sistemas se emplea aún para desarrollar sistemas con un granprocesamiento de operaciones (SPO) Y-.1Lstema~_dejnform-ªción_p_ara admi~s~a-ción (SrA), en donde los requerimientos son altamente estructurados y bien defini-dos. También permanece como adecuado para sistemas técnicos complejos, comolos lanzamientos espaciales, control de tráfico aéreo y operaciones en refineríaspetroleras. Tales aplicacicncs implican un análisis riguroso y formal de requeri-

Capítulo 12Otros métodos de diseiio de sistemas

III•II

1Psbeus

1r1

e

Elaboración de prototipos:Proceso de desarrollo de unsistema no funciona! rápido ybarato para demostración yevaluación, de manera que losusuarios puedan determinar mejorsusrequerimientos de información.

Prototipo: Versión operativapreliminar de un sistema deinformación para fines dedernostracíón y evaluación.

mientos, especificaciones predefinidas y férreos controles sobre el proceso dedesarrollo de sistemas. Sin embargo, la metodología del ciclo de vida de lossistemas tiene serias limitaciones y no es muy adecuada para los pequeños sistemasde escritorio que predominarán durante los noventas y el siglo XXI.

El enfoque del ciclo de vida es muy costoso y consumidor de tiempo. Una grancantidad de tiempo se emplea en la recopilación de la información y en la prepara-ción de especificaciones voluminosas y documentos de autorización. Pueden pasaraños antes de que un sistema quede finalmente instalado. Si el tiempo de desarrolloes demasiado prolongado, los requerimientos de información pueden cambiar antesde que el sistema esté en condiciones de operar. El sistema que toma para sudesarrollo muchos años y dinero puede quedar obsoleto cuando aún se encuentra enla mesa de diseño.

El enfoque del ciclo de vida es inflexible y desmotiva el cambio. El enfoque delciclo de vida permite revisiones al sistema para asegurarse de que los requerimien-tos sean satisfechos. Cuando los requerimientos son incorrectos o se encuentra unerror, la secuencia de las actividades del ciclo de vida debe repetirse. Pero losnuevos volúmenes de documentos deben generarse otra vez, incrementando sustan-cialmente el tiempo y costo de desarrollo. A causa del tiempo y costo de repetir lasecuencia de actividades del ciclo de vida, la metodología estimula el congelamien-to de las especificaciones temprano durante el proceso de desarrollo. Esto significaque los cambios no pueden ser realizados. Una vez que los usuarios aprueban losdocumentos de especificaciones se congelan las especificaciones. Sin embargo,los usuarios siempre han tenido problemas para distinguir entre un sistema defini-tivo y los documentos de especificaciones. En la realidad necesitan ver o usar unsistema para estar seguros de qué es lo que necesitan o desean. Como esto no esposible con el enfoque del ciclo de vida, es común que los usuarios aprueben losdocumentos de especificaciones sin comprender totalmente su contenido, sólo paraenterarse durante la programación y las pruebas de que las especificaciones estánincompletas o que no es lo que tenían en mente. Las especificaciones adecuadas nosiempre pueden ser captadas desde la primera vez cuando, temprano en el ciclo devida, son fáciles de cambiar.

El método del ciclo de vida es poco apropiado para las aplicaciones orientadasa la toma de decisiones. La toma de decisiones puede ser más bien poco estructu-rada y fluida. Los requerimientos cambian constantemente o las decisiones puedenno tener modelos o procedimientos bien definidos. Quienes toman las decisiones amenudo no pueden especificar sus necesidades de información con antelación.Pueden necesitar de experimentación con sistemas concretos para aclarar los tiposde decisiones que desean hacer. Este elevado nivel de incertidumbre no puede serfácilinente introducido en el enfoque del ciclo de vida.

Algunos de estos problemas pueden ser resueltos mediante otras estrategias dedesarrollo de sistemas que serán descritas en el resto de este capítulo.

12.2 Elaboración de prototiposLa elaboración de prototipos consiste en el desarrollo de un sistema no funcionalrápido y barato para que los usuarios finales lo evalúen. Al interactuar con elprototipo, los usuarios pueden tener una mejor idea de sus requerimientos de in-formación. El prototipo avalado por los usuarios puede ser usado como marco dereferencia para crear el sistema definitivo.

El prototipo es una versión operativa de un sistema de información o parte delsistema, pero se trata sólo de un modelo preliminar. Una vez que opera, el prototiposerá luego mejorado hasta que se apegue exactamente a los requerimientos de losusuarios. Para muchas aplicaciones, un prototipo puede ser extendido y mejorado


Iteratívo: Proceso de repeticiónde los pasos una y otra vez alconstruir un sistema.

una y otra vez antes de aceptar el diseño final. Una vez que el diseño se haYaterminado, el prototipo puede convertirse en un sistema pulido de infonnación.

El proceso de desarrollo de un diseño preliminar, de probarlo, afinarlo y probarlode nuevo se ha denominado proceso iterativo de desarrollo de sistemas, porque 108

pasos necesarios al desarrollar el sistema pueden repetirse una y otra vez. Ya se dijoque el ciclo de vida tradicional implicaba alguna medida de reproceso y afinación.Sin embargo, la elaboración de prototipos es más explicítamente iterativa que elciclo de vida convencional y promueve activamente cambios en el diseño desistemas. Se ha dicho que la elaboración de prototipos reemplaza al reproceso noplaneado en iteraciones planeadas, y que cada una de las versiones reflejando Conmayor precisión los requerimientos de los usuarios.

La versión del prototipo no tendrá los toques finales del sistema ya tenninadoInformes, secciones de archivos y las operaciones de entrada puede no esta;completas; el procesamiento puede no ser muy eficiente, pero una versión operativadel sistema o de parte del sistema estará disponible para que los usuarios la evalúen.Pues pueden iniciar a interactuar con el sistema, decidir qué les gusta y qué lesdisgusta, qué desean o qué no. Como la mayoría de los usuarios no puede poner porescrito todos los requerimientos, los prototipos permiten trabajar con un sistema Conel objeto de determinar exactamente qué es lo que necesitan. La metodologíaanticipa que cambiarán de parecer; estos cambios pueden incorporarse fácil yeconómicamente durante una etapa temprana del desarrollo.

El método de prototipos es menos formal que el del ciclo de vida. En vez degenerar especificaciones detalladas y documentos de autorizaciones, el prototipogenera rápidamente un modelo operativo del sistema. Los requerimientos se deter,minan dinámicamente a medida que el prototipo se construye. El análisis delsistema, el diseño y la implantación ocurren al mismo tiempo.

e Etapas en la construcción de prototiposEn la figura 12.2 se muestra un modelo de cuatro etapas para el proceso dedesarrollo de prototipos. Éstas son las siguientes:

43°1

ETAPA 1. Identificar los requerimientos básicos de/usuario. El diseñador delsistemas (en general un especialista en el diseño de sistemas) trabaja con el usuariosÓlo lo suficiente gara btener sus necesidades básicas de infonnación.ET APA 2. Desarro ar un prototipo inicial. E diseñador del sistema crea rápida-mente un prototipo operativo, muy probablemente usando las harramientas desoftware de cuarta generación que se describen en el capítulo 7, las que aceleran eldesarrollo de aplicaciones. (Algunas características de las herramientas del softwarede ingeniería asistido por computadora [CASE] que se describen en el capítulo 13,pueden también ser usadas para los prototipos.) El prototipo puede llevar a cabosólo las funciones más importantes del sistema propuesto o puede ser todo elsistema con un archivo restringido. .ETAPA 3. Uso del prototipo. Se estimula al usuario a que trabaje con el sistema conel objeto de determinar qué tan bien satisface sus necesidades y para hacer recomen-daciones para mejorarlo.ETAPA 4. Revisión y mejora del prototipo. El desarrollador del sistema anota todoslos cambios solicitados por el usuario y afina el prototipo de acuerdo con ellos.Luego de que el prototipo ha sido revisado, el ciclo regresa a las etapas 3 y 4, quese repiten hasta que el usuario quede satisfecho.

Cuando ya no se requieren más iteraciones, el prototipo aprobado se transformaen un prototipo operativo que proporciona las especificaciones finales para laaplicación. Algunas veces el prototipo mismo se adopta como la versión definitivade producción del sistema. Hacer prototipos es más rápido, iterativo e informal delo que ha demostrado ser el método del ciclo de vida.

Capítulo 12Otros métodos de diseño de sistemas

...._._----_._-----.-.

I

FIguraEl procEprototi¡constn ..puede.cuatroprototide marquienepasar¡donde4conl

mejoréllegaroperai

Vel

Ventajas y desventajas de la elaboración de los prototiposCiertos tipos de sistemas de información pueden desarrollarse más eficazmenteusando prototipos que con el uso del tradicional sistema del ciclo de vida. Porejemplo, cuando la Du Pont Company usó prototipos junto con un fuerte involucra-miento de los usuarios para desarrollar sus sistemas, produjo más de 400 nuevosprogramas sin fallas y redujo el mantenimiento entre 70 y 90 por ciento (Arthur,1992).

Los prototipos son de mayor utilidad cuando existe alguna incertidumbre sobrelos requerimientos o soluciones de diseño. Puede ser dificil señalar por adelanta-do los requerimientos o pueden cambiar sustancialmente a medida que progresa laimplantación. Esto es particularmente cierto en el caso de las aplicaciones orienta-das a las decisiones, en donde los requerimientos tienden a ser muy vagos. Laadministración está consciente de que se necesita mejor información pero no estásegura de lo que esto implica. Por ejemplo, una importante empresa de valoresrequiere información consolidada para analizar el desempeño de sus ejecutivos decuenta, pero, ¿cuáles pueden ser los parámetros de medición del desempeño?¿Puede la información ser extraída sólo del sistema de personal, o se debenincorporar los datos de las facturaciones a clientes? ¿Qué rubros son los que se

Figura 12.2El proceso de elaboración deprototipos. El proceso de -construcción de un prototipopuede descomponerse encuatro etapas. Como unprototipo puede ser construidode manera rápida y barata,quienes lo desarrollan puedenpasar por varias iteraciones endonde se repiten las etapas 3 y4 con el objeto de afinar ymejorar el prototipo antes de .llegar al prototipo final a niveloperativo.

Identificarrequerimientosbásicos

Desarrollo deun prototipooperativo

Uso del -prototipo

Si ¿Usuariosatisfecho 7

No

IPrototipo Revisar y

operativo mejorar -prototipo

Etapa 1

Etapa 2

Etapa 3

Etapa 4

12.2 Elaboración de I 431prototipos

---~~5~-::~~=~__:-,~f~..-J---------------- - ---- ~"==~~ =-- -~-.:=--:=~ ~ --, --= ::;

deben comparar en los informes? ¿Es necesario involucrar procesamiento interme-dio basado en alguna forma de análisis estadístico? Para muchas aplicaciones deapoyo a decisiones, es poco probable que los requerimientos sean obtenidos en sutotalidad en las especificaciones iniciales por escrito. El sistema definitivo no puedeser claramente visualizado porque los administradores no pueden prever cómodeberá funcionar el sistema.

Los prototipos son especialmente útiles para el diseño de la interfase con elusuario final de un sistema de información (la parte del sistema con la que elusuario interactúa, como las pantallas en línea y las pantallas o informes de accesode datos [ver Ventana sobre Tecnología]). Las necesidades del usuario y el compor-tamiento no son enteramente predecibles (Gould, 1985) y seo fuertemente depen-dientes del contexto. El prototipo permite que los usuarios reaccionen de inmediato

UNIX es un sistema operativo flexible,poderoso y transportable pero puedepresentar una interfase prohibitiva ofea para los usuarios finales. los usua-rios de las aplicaciones UNIX deseaninterfases gráficas con el usuario (IUG)atractivas y fáciles de usar, como lainterfase gráfica con el usuario de Mi-crosoft Windows o la de Macintosh;pero la generación de tales interfasesno es fácil para los usuarios a causa dela inmensa cantidad de tiempo nece-sario para codiflcarlas a partir de lanada.

Nuevas herramientas especiales parala construcción de IUG pueden ayu-dar. Si bien las herramientas no gene-ran toda la interfase, pueden ahorrarcerca del 80 por ciento del tiempo detrabajo, liberando a los programado-res para que pasen más tiempo en los .componentes subyacentes de las aplí- .caciones y aprovechen las fuerzas delUNIX. Dos tipos de herramientas sonespecialmente útiles: las herramientaspara el desarrollo de interfases y lossistemas de administración de interfa- .ses para usuarios.

las herramientas para el desarrollo deinterfases como el Builder Xcessory dela Integrated Computer Solutions (ICS)de Cambridge, Massachusetts, o laUIM/X de la Visual Edge Software Ud.en St. laurent, Quebec, manejan elprototipo de interfases con el usuarioy generan código de programa para la •parte de la interfase que el usuariovería. Para usar estas herramientas es-

Interfase con el usuario final:La parte de un sistema deinformación por la cual unusuario final interactúa con elsistema tal como las pantallas enlínea y los comandos.


Elaboración de prototipos de interfases gráficas con . ti

el usuario: nuevas herramientas al rescate ¡4"

VENTANA SOBRE

peciales, los expertos en sistemas deinformación deben poseer capacida-des en el lenguaje de programación C.la mayoría de las herramientas de de-sarrollo de interfases se adhieren a lasnormas lUG"complementando el lotede herramientas IUG para Motif, lanorma IUG usada por UNIX. Esta ca-racterística atrae al departamento dedivisas del Chemical Bank de nuevaYork. Eldepartamento usaba el BuilderXcessory de ICS cuando desarrolló unsistema de transacciones para Motif. ElChemical Bank necesitaba de una he-rramienta para desarrollar una interfa-se que fuera fácil de manejar y queusara el conjunto estándar de elerrren-tos gráficos de Motif para ventanas,barras de códigos, ventanas súbitasy otras.

los sistemas de administración de in-terfases con el usuario como el X.des-ktop de IXICorporation de San Ra-món, California, o la de looking Glass •Professional de la Visix Software Inc.de Reston, Virginia, son menos pode-rosas que las herramientas de desarro-llo de interfases, pero son más fácilesde usar. la mayoría ayudan a los dise-ñadores a generar prototipos de inter-fases de usuario de manera 'rápidausando un mouse (o ratón) y una seriede menús descendentes. Sin embargo,pocas pueden generar aplicacionescompletas por, sí mismas. Estas auto-matizan códigos de generación o deinterfase, El código restante debe ser

.. :scrito. en C o UI1 lenguaje de cuarta

generacron, Por ello los sistemas de '1administración de lnterfases con fre- ~cuencia se usan para desarrollar proto. "tipos para la interfase con' el usuarioantes que la lógica del programa sub.,yacente se cree. Como el IUG puede .ser desarrollado por separado de la'aplicación, la herramienta puede usar-se de manera concurrente para cons:-truir más de- una IUC para la mismaaplicación. Por ejemplo. se puede.construir una IUG para ser desarrolla"da por novatos y otra por profeslona-zles más sotisticados. Alguíio~ sistemasde administración de interfases usanjuegos de herramientas particularesque pueden conducir a problemas de .incompatibilidad con futuras versionesdel Motif. En el futuro, estos producto.'''-'pueden estar produciendo, lnterfases ,no estandarizadas., ~,.,'" . ..;;.

';"4¡ ••• 0.../ ~i~ ...' l~~

Fuente: Bob Francis,:"GUft Buildérs- Take";' .'on UNIXH

, Datamation. (l"de julio¡"l992),,!r;f4) ... ;..~ l' •. J~..

. ~ 4(1, ..;J--"

-;f-" ~ - -

Para reflexlónan LCY:afs.eriaer :Impado sobre ef lr~~"cf •. ' "

desarrollo de sIstemaS 51< .:~.~': 'herramientas comO,éStU ño_.¡. ~~estuvieran dlsponlblesl_¿.f;~,eS,' , .son las ventajas y desventajas de; ~.cada una de estas herramientas?¿Qué fadores de administración,' .";Instltuclonales y de tecnología ~ , (l'deberían consld~rar par;r. decid'!! '1usar o no una de estas·herramientas?

flfpr(ade51

elédeadapadeavamilabeeSfi~rn-péhéecinsise\"

-=~ - -~~ --~~~~~~~~ - ------- - ---- -

~:- _::._. --~ -=---_-: =.- -~~~ ~ ~ -~~-~~ - --- =- -" - - =-~ - - --~~-=--- ~-. -- -- -------- - -- - -- -- ---- - -- -==---~-- --=-

--------- ---=--- - -----=-- - -~.... -. - ---=- -~ ~ _.~~~~ ~-:::.=-:::..~~:::~- ~-" ~---. - - - -- ~ -

~ ~R_ ~

e-le;Ule10

elel;0r-1

to

f1gMra 12.3 ..,totipO de una aplicación de

pro ., d rt EdministraClon e ca era. na ta figura se ilustra el proceso de~abOración de un prototipodeuna pantalla. para.eldministrador financiero, una

:plicación p.~ra la .administraclon de dientes yartera para corredores de

calores.En la figura 12.3A, se~uestra una versión anterior dela pantalla de la agenda en líneabasadaen las necesidadesespecialesde un cliente. En lafigura 12.38 se tienen dosmejoras: una llamada "hacer",paracuando la actividad sehayallevado a cabo, y "link",como referencia de lainformación mantenida en elsistemasobre el cliente con elcualel agente tiene la cita.

¡Hola Beto! Aquí tienes tu agendade citas y actividades para hoy

SMTWTFS30 31 1 2 3 4 5

6 7 8 9 10 11 1213 14 15 16 17 18 1920 21 22 23 24 25 2627 28 29 30 31 1 2

3 4 5 6 789Viernes 18

Hora Actividad Etiqueta

( OK ) ( Mes ) 0SU~ ( Anterior)

(A)

¡Hola Susi! Aquí tienes tu agenda de citas. y actividades para hoy

SMT"WTFS30 31 1 2 3 4 5

6 7 8 9 10 11 1213 14 15 16 17 181920 21 22 23 24 25 2627 28 29 30 31 1 2

3. 4 5 6 7 8 9Jueves 17 de agosto de 1989

Hecho Actividad EtiquetaHora

__.-)~0 Ciguiente) ( Anterior)

(B)


a las partes del sistema con las cuales tratarán. En la figura 12.3 se muestra una partdel-pr-Ocesode elaboración de prototipos de una agenda en línea para corredores d~valores al detalle. La primera versión de la pantalla se construyó de acuerdo COnlasespecificaciones proporcionadas por el usuario para una agenda de seguimiento decitas y actividades. Pero cuando los usuarios trabajaron en la realidad con la agendaen la pantalla, sugirieron que se añadieran etiquetas para el mes y el año en lapantalla, y un cuadro para indicar si la cita se cumplió o la actividad se realizó. Loscorredores también encontraron que deseaban accesar información que se mantu.viera en el sistema sobre clientes con los cuales hubieran tenido citas. El diseñadordel sistema añadió un enlace (link) que permitiera a los corredores pasar directa.mente de la agenda en pantalla a los registros del cliente.

Por otra parte, los requerimientos de los usuarios pueden ser lo suficientementeclaros, pero los desarrolladores de sistemas pueden no estar seguros de ciertascaracterísticas técnicas del diseño de la solución. Por ejemplo, una importantecadena de supermercados contempla reconstruir su sistema de control de inventa.rios. Desea un acceso fácil en línea a sus archivos maestros desde distintas local],dades. La aplicación requerirá de numerosas pantallas para el acceso de datos enlínea y para la recuperación de elementos claves de información. Pero el equipo desistemas no está seguro de cómo las pantallas deberán fluir de unas a otras en línea,y también necesita afinar los formatos de las pantallas. De esta manera, el equipodecide hacer un prototipo de muchas de las pantallas usando una herramienta paragenerar aplicaciones interactivas. Las pantallas se desarrollan rápidamente paramostrar a los usuarios cómo fluirán y cómo aparecerán en línea .

. Los prototipos han sido ampliamente publicitados como una panacea para losproblemas inherentes en el proceso tradicional de desarrollo de sistemas. Estimulanel involucramiento intenso de los usuarios finales a todo lo largo del desarrollo delciclo de vida de los sistemas. Los usuarios interactúan con un sistema de trabajodesde muy temprano en el proceso de diseño. A medida que reaccionan antes yafinan cada versión del prototipo, los usuarios se involucran más íntimamente enelesfuerzo de diseño (Ceverny y otros, 1986). Es muy probable que los prototiposproduzcan sistemas que satisfagan los requerimientos de los usuarios, en especialcuando son usados en aplicaciones para el soporte de la toma de decisiones.Prometen eliminar el exceso en los costos de desarrollo y los errores de diseño queocurren cuando los requerimientos no son totalmente captados desde la primera vez.La satisfacción y la moral del usuario se ven estimuladas porque se le puedepresentar un sistema que trabaja en la realidad, aun cuando sea preliminar por unperíodo corto.

Sin embargo, los prototipos pueden no ser adecuados para todas las aplicaciones.Tampoco deben ser sustitutos para el caso de que se requiera de un análisiscuidadoso de los requerimientos, de metodologías de análisis estructurado o unadocumentación muy profunda; tampoco pueden sustituir a los métodos y herra-mientas tradicionales de desarrollo. El método y las herramientas de desarrollousadas en la alaboración de prototipos, tienen limitaciones muy serias.

Las aplicaciones que están orientadas hacia el manejo sencillo de datos yadministración de registros son buenos candidatos para los prototipos. Sin embargo,sistemas basados en procesamientos por lotes o que descansan en operacionescomplejas de cálculos y en una lógica de procedimientos compleja son en generalinadecuados para el proceso de prototipos. Los prototipos están mejor adaptadospara las aplicaciones más pequeñas. Los grandes sistemas deben subdividirse demanera que los prototipos puedan construirse en partes, una a la vez (Alavi, 1984).La subdivisión de un gran sistema puede no ser posible sin un análisis de requeri-mientos profundo que use el enfoque convencional, pues es dificil ver desde elprincipio cómo se afectan las diferentes partes unas a otras.

Hacer un prototipo de manera muy rápida puede soslayar pasos esenciales en eldesarrollo de sistemas. El análisis básico de sistemas y el de requerimientos no sepueden hacer en cortos circuitos. El atractivo de un prototipo desarrollado con

434 I Capítulo 12Otros métodos de diseño de sistemas

Paqiaplícprogpreeaplicdisprent,

eeseaas

ese

nel,

sn:1Jy,1s.1

Paquetes de software deaplicaciones: Conjunto deprogramas de software,preescritos y precodificados deaplicaciones que estándisponibles para su adquisición orenta,

facilidad y rapidez puede estimular al equipo de desarrollo a moverse demasiadoaprisa hacia un modelo operativo sin siquiera captar un conjunto básico de requeri-mientos. Esto puede ser especialmente problemático cuando un sistema muy grandese encuentra en desarrollo. Puede no quedar claro cómo los prototipos serán creadospara este gran sistema (O partes de él) a menos que el prototipo haya sido precedidopor un análisis comprensivo y profundo de los requerimientos.

Las etapas finales para convertir el prototipo en un sistema de producción afinadono pueden llevarse a cabo. Una vez terminado, el prototipo a menudo formará partede! sistema final de producción. Si el prototipo trabaja razonablemente bien, laadministración puede ver que no existe la necesidad de reprogramación o rediseño.Algunos de estos sistemas producidos al vapor pueden ser dificiles de mantener yapoyar en un ambiente normal de producción. Como los prototipos no han sido bienconstruidos, su desempeño técnico puede ser muy ineficiente. Fácilmente puedenfallar en alojar grandes cantidades de datos o un gran número de usuarios dentro deun ambiente de producción.

Los sistemas que dan origen a prototipos deben ser probados y documentados,pero con frecuencia estos pasos se acortan. Como los prototipos son construidos contanto esfuerzo, los administradores suponen que las pruebas pueden ser manejadaspor los usuarios mismos; cualquier cosa que se pase por alto en las pruebas puedeser corregida más tarde. Como e! sistema puede cambiar con tanta facilidad, ladocumentación puede no mantenerse bien actualizada.

12.3 Desarrollo de sistemas conpaquetes de software deaplicaciones

e

n

sa

)

sIs

:1

1e,1

Una estrategia diferente es desarrollar un sistema de información comprando unpaquete de software de aplicaciones. Tal como se presentaron en el capítulo 7, lospaquetes de software de aplicaciones son conjuntos de programas precodificadosy preescritos que están disponibles para ser adquiridos o rentados. Los paquetes desoftware de aplicaciones pueden ir desde una sencilla tarea (por ejemplo, imprimiretiquetas de direcciones de una base de datos en una microcomputadora) a más de400 módulos de programas con 500,000 líneas de código para un sistema complejode macrocomputadora. Cuando un paquete de software de aplicaciones adecuadose encuentra disponible, elimina la necesidad de escribir programas de software aldesarrollar un sistema de información y disminuye también la cantidad de diseño,pruebas, instalaciones y trabajo de mantenimiento. En la tabla 12.1 se dan ejemplosde aplicaciones para las cuales existen paquetes comerciales disponibles.

Los paquetes han florecido porque existen muchas aplicaciones comunes a todaslas instituciones de negocios; por ejemplo nóminas, cuentas por cobrar, libro mayoro control de inventarias. Para las funciones universales con prácticas contablesgeneralmente aceptadas, un sistema generalizado satisfará los requerimientos demuchas instituciones. Por tanto, no es necesario ara una empresa e e 'bi ~propios ro ramas' el aqucte de software preescrito, re Iseñado a robado

uede satis e los re ue' ientos y pue e a su vez ser sustituido. Como el rovee-dar el a uete a ha hecho la ma or oarte deJaiseño, ro ramación ruebas' elI!lill"code tiernJ1O-J:los costos ara des' o lar un nuevo sistema pueden reducirseconsiderabl mente.

Los paquetes pueden selcccionarse como una estrategia de desarrollo bajo lassiguientes circunstancias:

11,3 Desarrollo de sistemas con paquetes I 435de software de aplicaciones

l. Donde las funciones son comunes ara muchas em resas. Por ejemplo, tOdaempresa tiene un sistema de nóminas. En general, todos los sistemas denóminas llevan a cabo las mismas funciones: calculan el ingreso bruto, el netodeducciones e impuestos. También imprimen los cheques de pago y lo~informes. En consecuencia, los paquetes de software para aplicaciones hansido utilizados ampliamente para el desarrollo de sistemas de nóminas.

2. En donde los recursos ara el desarrollo i terno de sistemas de in ormación.•son escasos. on poca disponibilidad de profesionales con entrenamiento y

experiencia,muchas empresas no tienen el personal que esté ya sea disponibleo calificado para llevar a cabo proyectos internos de desarrollo de granenvergadura. Bajo tales circunstancias, los paquetes pueden ser sólo unamanera desarrollar el nuevo sistema. A la mayoría de las empresas tambiénles falta el presupuesto para desarrollar todos sus sistemas internamente. Enconsecuencia, la estrategia de desarrollo más eficiente, desde el punto de vistacostos, es ciertamente involucrar paquetes de software para aplicaciones.

3. Cuando las a licaciones ara microcomputadoras se desarrollan ara USUa-

rios zna es. Numerosos paquetes de aplicaciones fáciles de usar se handesarrollado para las microcomputadoras y son la fuente primaria de aplica-ciones para sistemas de escritorio.

Tabla 12.1 EJEMPLOS DE APLICACIONES PARA LAS QUE EXISTEN PAQUETES DISPONIBLES

Cuentas por pagar

Cuentas por cobrar

Diseño arquitectónico

Sistemas bancarios

Administración de acciones y bonos

Verificación de procesamiento

Diseño apoyado por computadora

Costos de construcción

Sistemas de administración de datos

Imágenes de documentos

Ingeniería eléctrica

Educación

Correo electrónico

Control financiero

Pronósticos y modelos

Diseño de formas

Libro mayor

Gráficas

Compras de gobierne

Cuidado de la salud

Seguros sobre salud

Administración de hoteles

Recursos humanos

Préstamos en abonos

Control de inventarios

Contabilidad de puestos

Costeo de puestos

Sistemas de biblioteca

Seguros de vida

Etiquetas de correo

Modelos matemáticos y estadísticos

Acceso de pedidos

Nóminas

Evaluación del desempeño

Control de proceso

Administración de bienes raíces

Programación de rutas

Ventas y distribución

Sistemas de ahorro

Administración de acciones y vaiores

Contabilidad fiscal

Control de servicios públicos

Procesamiento de la palabra

Programación del trabajo


Vent

t

!

1I

veníé\j¡iS y desventajas de los paquetes de softwareResulta tentador considerar a los paquetes de software como el antídoto largamenteesperado contra la escalada de costos de software y desarrollo. Los paquetes desoftware para las aplicaciones pueden facilitar el diseño, pruebas e instalación,apoyo al mantenimiento de sistemas y aceptación institucional para un nuevosistema. Los paquetes tienen también serias limitaciones.

12.3 Desarrollo de sistemas ,~,I',paq ..retesde software df.:::p':caciones

VENTAJAS DE LOSPAQUETES

DESVENTAJAS DE LOSPAQUETES

Adaptabilidad: La modificaciónde un paquete de software parasatisfacer los requerimientosespecíficos y únicos de unainstitución sin destruir laintegridad del paquete desoftware.

Esta pantalla muestra unaaplicación adaptada a lasnecesidades específicas delcliente para una aplicación <queusa el paquete de softwareCA-Clipper de la empresaComputer Associates. Elpaquete está creando una basede datos interactiva de losarchivos leídos ópticamente deun libro técnico.

sos humanos tuvieron que desarrollar paquetes especializados para procesar bene.ficios para el retiro de empleados o seguimiento de solicitudes, porque estasfunciones no estaban bien manejadas por los paquetes más comprensivos y depropósito múltiple de recursos humanos.

En al unas circunstancias los aa et s . eden en eali ad atentar co te..§...uerzo de desarrollo al incrementar los costos de conversión. Aunque los provee.dores de paquetes a menudo ofrecen software de conversión y ayuda de consultoría,un paquete puede en realidad prolongar el proceso de conversión, en especial si esdesde un sistema automatizado poderoso. En tales casos, se sabe que los costos deconversión han llegado a ser de tal manera astronómicos que hacen imposible todoel esfuerzo de desarrollo. !--aconversión a un a uete es de lo más fácil desdesencillas aplicaciones manuales o desde aplicaciones automatizadas que no SOn

mu so icadas.Los paquetes ueden no cum lir con todos los re uerimientos de las instituc'o

...!}g". ara.maximizar la atracción del mercado los paquetes están engrana os con lo~requerimientos más comunes de todas las instituciones. Pero, ¿qué pasa si un,institución tiene requerimientos únicos que el paquete no cubre? En diversosgrados, los diseñadores de paquetes de software se anticipan a este problemaproporcionando características de adaptación que no alteren al software básico. Lascaracterísticas de adaptabilidad permiten que unpaquete de software sea modifi.cado para cumplir con los requerimientos únicos de una institución sin destruir laintegridad del paquete de software. Por ejemplo, el paquete puede asignar partes desus archivos o bases de datos para mantener los elementos de datos exclusivos.Algunos paquetes tienen un diseño modular que permite que los clientes escojansólo las funciones de software, con el procesamiento que requieren, de un menú deopciones. Los paquetes pueden también, ser adaptados con salidas para usuarios,lugares en el código de programa del paquete donde los clientes pueden salir delprocesamiento llevado a cabo por los programas para llamar a módulos de softwareescritos por ellos mismos para sus funciones únicas de procesamiento.

Es ¡!.ti establecida e os az <:0. a sus roductossi se han hecho cambios gue alteren el códi o ente del a uete. Al unos a uetes

'han sido tan fuertemente modificados con cambios en el código fuente de usuariosue son imposi e ea e mantener. Además dé acer un uso maximo de

las herramientas de adaptación del paquete, una manera de evitar esta situación esañadir programas de fachada y traspatio que corran antes o después del paquete yno interfieran con él. Estos extremos posteriores o anteriores pueden ser mucho másextensos que el software del paquete usado. Por ejemplo, una corporación estudiadadesarrolló un sistema de nóminas usando un paquete líder de nóminas para macro-

~Auto Ui_! Oli OFF

lJaep ConI'l••••••tion

~..

43~ I Capítulo 12Ot.ros métodos de diseño de sistemas

rp(1

loe

\.

tr~tr

tiempo necesarios para instalar seis importantes paquetes de aplicaciones (quincluían manufactura, planeación de recursos, el libro mayor, cuentas por cOb~ar~activos fijos) mostraba que los costos totales de implantación oscilaban de 1.5a 11veces al precio de adquisición del paquete. La razón era más alta en paquetes canmuchas interfases con otros sistemas. El mismo estudio mostró que los costos deadministración y soporte para el primer año promediaban el doble del costo de ad,quisición del paquete.

Selección de paquetes de softwareRequisición de propuesta (RP): Los paquetes de software para las aplicaciones deben ser evaluados a profundidadLista detallada de preguntas antes de que puedan ser usados como el cimiento de un nuevo sistema de infonna.hecha a los proveedores de ción. Los criterios más im ortantes de evaluación son las funciones proporciosoftware en paquetes u otros l fl ibilid d . di' h d ftwservicios de cómputo para or e .a~uete, eXI I la_ amIsta con e usu~no, aro:vare, recurs?s . e so are•.•determinar si el producto del requenmIentos de base de datos esfuerzo de mstalaclOn y mantemmIento, cloc.proveedor cumple con los mentació ea' ad e o eedor costo. El p~~_«~Q e eva uacion del paquete se:eq~e~ientos específicos de la. basa con frecuencia en una requisición de propuesta (RP), que es una listainstitución. detallada de preguntas que se remite a los proveedores de software. La RP pro.

bablemente incluya preguntas como las siguientes.

CRITERIOS PARA LAEVALUACiÓN DE

PAQUETERíA

F . . luid. /'unciones tnc ui asLas funciones incluidas varían con la aplicación, pero para la aplicación específicalas siguientes consideraciones son de importancia.

• ¿Cuántos de los requerimientos serán satisfechos por el paquete?• ¿Cuántas de estas funciones son básicas?• ¿Qué funciones pueden ser apoyadas únicamente modificando el código del

paquete?• ¿Qué tan extensas son las modificaciones que se requieren?• ¿Qué funciones no pueden ser apoyadas de ninguna manera por el paquete?• ¿Qué tan bien apoyará el paquete las neces.idades actuales así como las futuras?

Flexibilidad /

• ¿Qué tan fácil de modificar es el paquete?• ¿Qué características de adaptación se incluyen (salidas de usuarios, áreas de

.datos del usuario)?• ¿El proveedor está dispuesto a modificar el software para el cliente?

Amistad hacia el usuario

• ¿Qué tan fácil de usar es el paquete desde un punto de vista no técnico?• ¿Qué tanta capacitación se requiere para entender el sistema objete del paquete?• ¿Qué tanto control por parte del usuario permite el paquete?

Recursos de hardware y software //

• ¿En qué modelo de computadora puede correr el paquete?• ¿Qué sistema operativo se requiere?• ¿Es dependiente la emisión del paquete?• ¿Qué tantos recursos de entrada/salida y centrales r~q~iere?• ¿Cuáles son los requerimientos en memoria de disco de cinta?• ¿Qué tanto tiempo de cómputo se necesita para correr el paquete?• ¿Puede correr en el ambiente operativo actual del cliente (modelo de computa-

dora, sistema operativo, sistema de administración de base de datos etc.)?


(lt;~•.t:;.-~·, .• Ir~

12.3 Desarrollo de sistemas con paquetes I 441de software de aplicaciones

Características de base de datos

• ¿Qué tipo de estructura de base de datos/archivo utiliza el paquete?• ¿Corresponden los campos originales del paquete con los elementos de datos

especificados por los requerimientos de la aplicación?• ¿Soportan el diseño de la base de datos o de los archivos los requerimientos del

cliente de procesamiento y recuperación?• ¿Están previstos para añadirse campos especiales del usuario para elementos de

datos que no son comunes a los del paquete?

j Esfuerzo de instalación

s • ¿Qué tantos cambios de procedimientos requeriría el paquete?• ¿Qué tan dificil sería una conversión del sistema actual al sistema del paquete?

"

e Mantenimientoa

• ¿Proporciona el proveedor actualizaciones o mejoras para el sistema?• ¿Qué tan fáciles son de aplicar?• ¿Cuál es el personal interno mínimo necesario para proporcionar mantenimiento

y soporte corriente (programadores de aplicaciones, analistas, especialistas debase de datos)?

• ¿Es el código fuente claro, estructurado y fácil de mantener?a

Documentación

• ¿Qué tipo de documentación (del sistema y de usuarios) se proporciona con elpaquete?

• ¿Es fácil de entender y usar?• ¿Está completa la documentación, o el cliente debe escribir instrucciones adicio-

nales con objeto de usar el paquete?

Calidad del proveedor

e

• ¿Tiene el proveedor experiencia en esta área de aplicación?• ¿Tiene el proveedor una imagen fuerte en ventas y en finanzas?• ¿Continuará activo el proveedor y dará soporte al paquete?• ¿Qué tipos de soporte (personal de soporte, líneas telefónicas de emergencia,

instalaciones de capacitación, personal de investigación y desarrollo) se re-quiere?

• ¿Es el proveedor receptivo a las sugerencias de mejoras por parte de los clientes?• ¿Cuenta el proveedor con un grupo de usuarios activos que se reúna con

frecuencia para intercambiar información sobre sus experiencias con el paquete?

Costo' /

~ ¿Cuál es el precio de venta o arrendamiento del software básico?• ¿Qué se incluye en el precio de adquisición (módulos complementarios, adita-

mentos para generación de pantallas, en línea, tiempo de recuperación, tiempo derespuesta, capacitación, soporte para instalación)?

• ¿Existe un cargo anual por concepto de mantenimiento y contrato?• ¿Cuáles son los costos operativos anuales para el volumen estimado de procesa-

miento del paquete?• ¿Cuál sería el costo de hacer el paquete a la medida exacta de las necesidades del

cliente e instalarlo?

?

los paquetes y el proceso de desarrollo de sistemasEn la tabla 12.2 se muestra cómo el uso de un paquete de software de aplicacion •afecta al proceso de desarrollo de sistemas. El análisis de sistemas incluirá ~sesfuerzo de evaluación del paquete que normalmente se lleva a cabo al envinsolicitudes de propuestas (RP) a diversos proveedores de paquetería. Las respuestr

a las RP serán comparadas con los requerimientos de los sistemas generados duran~esta fase, y el paquete de software que mejor lo satisfaga será el elegido. L~actividades de diseño se enfocarán en la satisfacción de los requerimientos a la.características del paquete. En vez de ada tar las especificaciones de diseño de~sistema directamente a los requerimientos de los usuarios, el esfuerzo de dis -consistifa en tratar de moldear os re uerimientos de los usuarios para apegarselas características del a uete.

Uno de los temas principales de este libro ha sido la necesidad de diseñarsistemas que se apeguen bien a la institución a la que sirven. Pero cuando se eligeuna solución de paquete tal apego puede ser muy dificil de alcanzar. La instituciónya no tiene el control total sobre el proceso de diseño del sistema. Aun con elpaquete más flexible y fácilmente adaptable existen límites a la cantidad de adapta.ción permitida. Las empresas experimentadas en el uso de paquetes de softwarepara las principales aplicaciones de negocios ya se han dado cuenta de que aun Conlos mejores paquetes no se puede esperar que se cumpla con más del 70 por cientode la mayor parte de sus requerimientos. ¿Qué pasa con el 30 por ciento restante?Deberá irse sin ser satisfecho por el paquete o buscar otros medios. Si el paquete nopuede adaptarse a la institución, es ésta la que debe adaptarse al paquete y cambiarsus procedimientos. Uno de los impactos de más largo alcance de los paquetes desoftware es su impacto potencial en los procedimientos organizacionales. El tipode información que una empresa puede almacenar para una aplicación, como lade

Tabla 12.2

4421

CICLO DE DESARROLLO DE PAQUETES DE APLICACiÓN

\

/r'Análisis de sistemasIdentificar problema.Identificar requerimientos de usuariosIdentificar alternativas de soluciónidentificar proveedores de paquetesEvaluar paquetes VS. desarrollo intramurosEvaluar paquetesSeleccionar paquetesDiseño de sistemasAdaptar los requerimientos del usuario a las caracteristicas del paqueteCapacitar al personal técnico sobre el paquetePreparar el diseño físicoAdaptar el diseño de paqueteRediseño de los procedimientos organizacionalesProgramación, pruebas y conversiónInstalar el paqueteImplantar modificaciones al paqueteDiseñar interfases del programaProducir documentaciónConversión al sistema del paqueteProbar el sistemaCapacitar a los usuarios sobre el paqueteProducción y mantenimientoCorregir problemasInstalar actualizaciones o mejoras al programa______________________ , ====_~~1!I"¡,"'f.'"


..•~_.~

--pesarrl(males:de [nforfinales I

asistencespecia

He.

ne,;tas•t el'ee,ría. '1 es•de)dosdesan

:io-los

un,sos:maLas¡iti-r la;-de'os.'Jan1 deios,del'are

etes.iosI de1 es:e y.násada::ro-

I

.~ ",;"".!,,.'

f19ura 12.4ete totalmente adaptado a

paqusidadesde una institución.neeeAdaptar algunos paquetes para

Cumplan con losqUe íf duerimientos espeCl,lCos. ereq institución puede Implicaruna ifiras modi icaciones, que estan ibi deeesarioescn Ir gran esnrogramas de facha?a yfraspatio para manejar<>r1uerimlentosder".., .

procesamiento que no sonsatisfechos por el paqueteriginal; si se requiere de una

o d . o Iexcesivaa aptaocn, osprogramas suplementarios soncon frecuencia más elaboradosque el paquete de las,característICasdel oriqinal. queprácticamente se pierde,

Figura 12.5Efectosde adaptación de unpaquete sobre los costos totalesde implantación. La instalaciónde un paquete siempre implicamodificaciones. Pero a medidaque las modificaciones crecen,también crece el costo deimplantación del paquete.Algunas veces los ahorrosprometidos por el paquete sonanulados por los excesivoscambios. A medida que elnúmero de líneas de códigocambiadas se aproxima al cincopor ciento de las líneas totalesdel paquete, el costo deimplantación se multiplica porcinco.

Paquete

computadora. El paquete dejó tantos requerimientos importantes sin satisfacer quela empresa tuvo que usar sus propios programadores para escribir inmensos progra-mas anteriores y posteriores para complementar el paquete. La estructura final delsistema con extremos anterior y posterior se veía como la de la figura 12.4.

Tal modificación y programación adicional puede ser necesaria para adaptar unpaquete si la implantación se prolonga seriamente. La adaptación que se permitadentro del marco del paquete puede ser tan costosa y consumir tanto tiempo queelimina muchas de las ventajas del paquete. En la figura 12.5 se muestra cómo loscostos de los paquetes, en relación con los costos totales de implantación, crecencon el grado de adaptación.

El precio inicial de compra del paquete puede ser una decepción a causa de estoscostos ocultos de implantación. Un estudio interno de una empresa del costo y

c::'0'ulOelOa.

,~

Q)""O

'" 5Q)

roB 4'"o \l1;;lO 31.9

2

1 2 3 4 5%Grado de adap~ación (% de líneas totales de código modificadas)

12.3 Desarrollo de sistemas con paquetes I 439de software de aplicaciones

11

S

)

1

r

1

l

1

)

?)

re)

e

-e

_e

cuentas por cobrar, por ejemplo, y la manera como la empresa organiza, clasifica,alimenta y recupera esta información puede ser en gran medida determinado por elpaquete que utiliza.

12.4 Desarrollo por usuariosfinales- En muchas insti ciones los usuarios finales son

porcentaje de sistemas de información con poca o nin una aSIstencia de arte de losespecialistas técnicos. Este e ó eno se llama desarrollo or usuarios finales. Eldesarrollo por usuarios finales ha sido posible gracias a las herramientas de sofuVa-re de cuarta generación (que se presentaron en el capítulo 7). Aun cuando estasherramientas sean menos eficientes desde el punto de vista computacional que loslenguajes convencionales de cómputo, los costos decrecientes del hardware los hanhecho técnica y económicamente posibles. Con len ua'es de a eneraciónlen ua' es os herramientas de microcom utadoras los usua . s finales ue-den accesar datos crear inform s desarrollar sistemas de información totalesro ios sin analistas de sistemas o ro ramadores rofesionales. Por otra parte, los

usuarios pueden confiar en especialistas de sistemas de información para el soportetécnico pero pueden realizar muchas. actividades de desarrollo de sistemas por símismos, las que anteriormente habían sido exclusivas del departamento de sistemasde información. Muchos de estos sistemas desarrollados Qorusuarios finales uedenser creados muc·ho"más rá .d ue con el ciclo tradicional de vida de los sistemas.Eñla figura 12.6 se muestra el concepto del desarrollo de usuario final.

Herramientas de cómputo del usuario final: fuerzas y limitacionesLas herramientas de cómputo del usuario final han aumentado la velocidad yfacilidad con las que cierta clase de aplicaciones suelen ser creadas. Muchasherramientas de la cuarta generación incluyen conocimientos de diseño de aplica-ciones interconstruidos. Por ejemplo, cuando los lenguajes de cuarta generaciónestán enlazados con bases de datos, ésta ya ha sido organizada y definida. Muchasherramientas de cuarta generación pueden accesar fácilmente datos, generar infor-mes o gráficas o aun generar operaciones sencillas entre datos.

Muchas instituciones han informado ganancias apreciables en la productividaddel desarrollo de aplicaciones usando herramientas de la cuarta generación. Lasmejoras en la productividad basadas en los lenguajes tradicionales de cómputo,como la programación estructurada (ver el capítulo 13), han tenido como únicoresultado un incremento máximo de productividad del 25 por ciento (Jones, 1979).En contraste, algunos estudios de instituciones que desarrollan aplicaciones conherramientas de cuarta generación han informado sobre ganancias de entre 300 y500 por ciento (Green, 1984-85; Harel, 1985). Aun cuando estas ganancias no sondel orden de magnitud de diez, tal como al principio se quiso hacer creer con losmétodos de cuarta generación, siguen siendo muy impresionantes.

Finalmente Jas...he .e s de cuarta eneración tiene uevas capacidades,.como gráficas ho·as de cálculo, modela'e recu eración de información ad hocque satisface~ imRortantes necesidades de ne ocios.

Desafortunadamente, las herramientas de cuarta generación aún no puedensustituir las herramientas convencionales para algunas aplicaciones de negocios,porque sus habilidades permanecen limitadas. La mayoría de estas herramientasfueron diseñadas para sistemas sencillos que manejaban archivos pequeños. Elprocesamiento de cuarta generación es relativamente ineficiente y los lenguajes

12.4 Desarrollo por I 443usuarios finales

Desarrollo por usuariosfmales: El desarrollo de sistemasde información por los usuariosfmales con poca o ningunaasistencia formal de parte de losespecialistas técnicos.


Figura 12.6Desarrollo de usuarios vs.desarrollo del ciclo de vida delos sistemas. Los usuarios finalespueden accesar directamenteinformación computarizada odesarrollar sistemas deinformación con mínima o nulaasistencia técnica formal; engeneral, los sistemas técnicoselaborados para usuarios finalespueden ser conducidos másrápidamente que aquellosdesarrollados mediante el ciclode vida convencional.Fuente: Adaptado de JamesMartín, ApplicationsDevelopment WithoutProgrammers, © 1982,p. 119. Adapted by permissionof Prentice-Hall, Englewood'C1iffs, NJ.

Desarrollo de sistemas tradicionales (ciclo de vida)

Diseño ProgramaAdministra-ción del nivelmedio osuperior

Test

_____ JSemanas o meses 1

Desarrollo de usuarios

: ( ';Personal ,'-.j , ., í.

I... :

Herramientas de cómputo de .",.,usuario final 'Lenguajes de consultaLenguajes de gráficasGeneradores de informes'Generadores de aplicaciones.Lenguajes de muy alto nivel' ~Herramientas de lmicrocomputadoraAdministración

de nivel medioo superior

Minutoso días

consumen grandes cantidades de recursos de la computadora. La mayoría de l3S

lenguajes de cuarta generación procesan las operaciones individuales demasiadolentamente y a un costo demasiado alto para que sean adecuados para grandessistemas de procesamiento de operaciones. El tiempo de respuesta lento y ladegradación en el desempeño de la computadora con frecuencia ocurren cuandose manejan archivos grandes. Por ejemplo, la división del estado de Nueva Jerseyde Motor Vehicles tenía un retraso de 1.4 millones de registros de vehículos y deregistros de propiedad, que no podían ser procesados rápidamente porque habíaconstruido su sistema de registro de vehículos usando Ideal, una herramienta d'>cuarta generación. Una parte del sistema hubo de ser reprogramada en COBOL parapoder manejar el muy alto volumen de operaciones.

La ma or parte de las herramientas de cuarta eneración están más fuera derocedimientos ue los len ua' es tradicionales de ro ramación. Por tan o no

pueden manejar fácilmente aglica '0 es con una extensa ló ica de roe dimien~üsrequenmIentos de actualización. Por ejemplo, aplicaciones como las usadas para

el diseño de reactores nucleares, programación óptima de producción o el seguí-miento de las transacciones diarias de acciones, obligaciones y otros valores requi~·re de un procesamiento complejo y con frecuencia la conjunción de múltiplesarchivos. La lógica de procedimientos debe usarse para especificar las funciones deprocesamiento, funciones de servicios, condiciones de manejo de errores interfases

l

Jlosidoles

lado.eydeoía

deara

denotosaraui-líe-.les

ses

especializadas e información con alto nivel de adaptación. La lógica de talesfunciones se puede expresar y controlar de manera más fácil mediante el códigoconvencional de procedimientos. La especificación de la lógica de procedimientosen los lenguajes de cuarta generación es lenta comparada con la especificacionespara funciones que no son de procedimientos, como la generación de pantallas,informes o gráficas, Para aplicaciones basadas en una gran cantidad de lógicaespecializada en procedimientos, la ventaja total en productividad de los lenguajesde cuarta generación puede perderse (Martin, 1982).

Las herramientas de cuarta generación hacen su contribución más importante enlos aspectos de programación y de diseño en detalle del proceso de desarrollo desistemas, pero tienen muy poco impacto en otras actividades de construcción de sis-temas. La productividad en el análisis de sistemas, los cambios de procedimientos,la conversión y otros aspectos del diseño son en gran medida independientes de laelección de la herramienta de programación. Los lenguajes de cuarta generación porsí solos no pueden superar los problemas tradicionales de carácter organizacional yde infraestructura, como la falta de bases de datos bien definidas y mejor integradas,técnicas estandarizadas de administración de datos y redes integradas de comunica-ciones que en general obstruyen lasimplantaciones de los sistemas de información(Grant, 1985).

Beneficios y problemas de administraciónComo los usuarios finales pueden crear muchas aplicaciones totalmente propias ocon una asistencia mínima de los especialistas en sistemas de información, lossistemas de información desarrollados por usuarios finales pueden ser creados demanera mucho más rápida e informal que los sistemas tradicionales. Esta situaciónha generado beneficios y problemas para las instituciones porque estos sistemasquedan fuera de las restricciones del ambiente formal de sistemas de información.

Sin duda alguna, el desarrollo de usuarios finales proporciona muchos beneficiosa las instituciones, Entre éstos se incluyen los siguientes:

• Mejora en la definición de requerimientos. Como los usuarios desarrollan suspropios sistemas, existe una menor necesidad de apoyarse en especialistas desistemas de información para el análisis de requerimientos y menor posibilidadde que los requerimientos de los usuarios puedan ser mal interpretados por losespecialistas.

o Involucramiento y satisfacción de los usuarios. Los usuarios pueden usar yaprobar más fácilmente los sistemas que ellos mismos diseñan y desarrollan.

o Control del proceso de desarrollo de sistemas por los usuarios. Las herramientasde cuarta generación permiten a los usuarios finales desempeñar un papel másactivo en el proceso de desarrollo de sistemas. Pueden crear ellos mismos o conmínima ayuda aplicaciones totales. Las herramientas con frecuencia apoyan eldesarrollo de prototipos, permitiendo a los usuarios finales crear sistemas expe-rimentales que pueden ser revisados rápida y económicamente para hacer frentea los requerimientos cambiantes. Como los usuarios finales tienen un papelmayor en la creación de aplicaciones, las herramientas de cuarta generación hanayudado a romper la barrera entre usuarios y programadores que ha obst.aculiza-do tanto el desarrollo de los sistemas convencionales.

• Disminuir rezago en cuanto al desarrollo de aplicaciones. Los sistemas desarro-lIados por usuarios pueden ayudar con el retraso en la elaboración de apl.cacio-nes al transferir la responsabilidad del desarrollo del personal de sistemas deinformación a los usuarios finales. La productividad de los especialistas profe-sionales en sistemas de información puede también incrementarse sensiblementemediante el uso de lenguajes de cuarta generac.ión.


- -------=- - --~- ---=--- - -- - ---= - ~

~~": -~ -"~ - -=---- - --= - - -==--::...=.. -=-= -= -=---- --= -

-- -' --- ------------ : -

w __ ~ _:;::" ~ --=~ _-;-~ ~---=--=-__~ = _ __ _ _

-----=--------= --=- - - --:=:=:==------- -====------==- - - - -

Al mismo tiempo, la computación de usuarios finales presenta riesgos institucio.nales porque ocurre fuera de los mecanismos tradicionales de administración 'icontrol de sistemas de información. La mayoría de las instituciones aún no hadesarrollado estrategias para asegurarse de que las aplicaciones de los usuario~finales cumplan con los objetivos institucionales o con las normas de aseguramientode la calidad apropiada para su función. Los retos más críticos que trae consigo lacomputación de usuarios finales son los siguientes:

Revisión y análisis insuficiente cuando las funciones de analistas y usuarios Yano están separadas. Sin analistas formales de sistemas de información, lasaplicaciones desarrolladas por usuarios no tienen una revisión externa inde.pendiente. No existen fuentes independientes de análisis de problemas o de otrassoluciones. También puede ser dificil para los usuarios especificar requerimien.tos completos y comprensibles.

• Falta de normas adecuadas y controles para el aseguramiento de la caJlidad.lossistemas desarrollados por usuarios con frecuencia son creados rápidamente, sinuna metodología formal de desarrollo. Si bien resultan ventajas en productividady en diseño al evitar las metodologías convencionales de desarrollo, los sistemasdesarrollados por usuarios a menudo adolecen de la falta de normas, controles 'iprocedimientos de aseguramiento de la calidad adecuados. Puede no haberdisciplinas adecuadas de pruebas y documentación. Los sistemas desarrolladospor usuarios pueden carecer de controles para la integralidad y validez de lasentradas y actualizaciones, seguimientos de auditorías; controles operativoscontroles de proyectos y normas para interfases estables entre los subsistemas (eicapítulo 18 proporciona mayores detalles sobre estos controles.)

• Datos no controlados. Con herramientas de cómputo de usuarios finales, estosgrupos fuera del departamento tradicional de sistemas de información puedenfácilmente crear sus propias aplicaciones y archivos. Muchos de estos archivoscontendrán elementos de información idénticos, pero cada aplicación de usua-rios puede actualizar y definir estos datos de una manera diferente. Sin discipli.nas formales de administración de datos, será cada vez más dificil determinardónde se localizan los datos y asegurar que la misma pieza de información (comoun número de producto o ingresos anuales) sea usado de manera consistente a lolargo de toda la institución. (Más detalles sobre el problema de los datos nocontrolados pueden encontrarse en los capítulos 8 y 10.)

• Proliferación de los sistemas "privados" de información. Los usuarios puedenusar herramientas, de cuarta generación para crear sus propios sistemas deinformación "privados", que queden ocultos del resto de la institución. Talessistemas pueden ocultar información a los otros grupos. Un sistema privado nodocumentado no puede ser fácilmente encargado a otra persona cuando elcreador de tal sistema deja su trabajo (Davis y Olson, 1985).

Administración del desarrollo de usuario final¿Cómo pueden las instituciones maximizar los .beneficios del desarrollo de lasaplicaciones de los usuários finales al tiempo que las mantienen bajo control? Sehan sugerido muchas estrategias. Algunas, como el uso de las disciplinas de laadministración de datos, ya han sido descritas en el capítulo 10. Entre otras medidasse incluyen el uso de centros de información y otras instalaciones de capacitación yapoyo para el desarrollo por usuarios finales, estableciendo prioridades de desarro-llo de aplicaciones y controles bien definidos para las aplicaciones desarrolladas porlos usuarios finales.

CENTROS DEINFORMACIÓN

Una manera de facilitar y administrar el desarrollo de las aplicaciones por usuariosfinales es establecer un centro de información. El centro de información es unainstalación especial que proporciona capacitación y soporte para el cómputo de los

446\ Capítulo 12Otros métodos de diseño de sistemas

ceO!1tlStaiJlSti1capacóIJl

ElesccC2

Ir.

1_"w:)1

1

S

s

'snd.S

y:r.slS

s,el

lS

:n18

~.•l-ar10

lo10

endelesnoel

.as:Sela

las1y~o-)()r

centro de información:Úlstalac,i?nespecial de~tro de laiJlstituClOnque proporciona'apacitación y apoyo para el~órnputode usuarios finales.

usuarios finales. En los centros de información se encuentran especialistas ensoftware, hardware y técnicos que proporcionan a los usuarios finales herramientas,capacitación y consejos expertos de manera que puedan crear sus propias aplicacio-nes de sistemas de información. Con las herramientas de los centros de información,los usuarios pueden crear sus propios reportes de cómputo, hojas de 'cálculos ográficas y extraer datos para la toma de decisiones y el análisis con una asistenciatécnica mínima. Los consultores de los centros de información están disponiblespara instruir a los usuarios y ayudarles en el desarrollo de aplicaciones máscomplejas.

En los miembros del centro de información se combinan la experiencia en elconocimiento del software, hardware y las bases de datos para las aplicaciones deusuario final junto con fuertes habilidades para la comunicación interpersonal.Operan principalmente como maestros y consultores de los usuarios, pero tambiéntoman parte en el análisis, diseño y programación de aplicaciones más complejas.Entre los servicios típicos que proporcionan se tienen los siguientes:

• -Capacitación en lenguajes de alto-nivel y herramientas de desarrollo.• Asistencia técnica en el acceso de los datos .• Asistencia en depuración de programas. " -• Asistencia para aplicaciones, consultas e informes que requieran lenguajes de

programación de alto nivel.Consulta sobre las herramientas y metodologías apropiadas para el desarrollo deaplicaciones.

\• Generación y modificación de prototipos.

.- • Proporcionar materiales de referencia sobre los recursos de los centros deI información.

~

J ••• Proporcionar enlaces con otros grupos de procesamiento de información (comoespecialistas en bases de datos) que dan soporte a los recursos de los centros deinformación.Mantener un catálogo de aplicaciones y de bases de datos existentes.Evaluar nuevo hardwarc y software.

Elpersonal de esta corporaciónestá tomando una clase decomputación en su centro decapacitación auspiciado por lamisma empresa.

12.4 Desarrollo porusuarios finales

, 447I

POLÍTICAS YPROCEDIMIENTOS PARA

ADMINISTRAR LACOMPUTACiÓN DE LOS

USUARIOS FINALES

El hardware de los centros de información puede consistir en macrocomputado.ras, minicomputadoras, microcomputadoras, estaciones de trabajo o una combina.ción de estas máquinas. Entre las típicas herramientas de software en los centros deinformación se incluye software para el procesamiento de palabras, de modelaje oplaneación, de bases de datos para computadoras de escritorio, de gráficas, genera.dores de informes, lenguajes de cuarta generación amigables con el usuario Paraconsultas o aplicaciones sencillas o lenguajes de programación de alto nivel para eldesarrollo de aplicaciones de cuarta generación.

Los centros de información pueden proporcionar muchos beneficios adminis.ativos:

• Pueden ayudar a los usuarios finales a encontrar herramientas y aplicaciones quelos hagan más productivos.

• Evitan la creación de aplicaciones redundantes.• Promueven la compartición de los datos y minimizan los problemas de integra.

lidad (ver el capítulo 8).Aseguran que las aplicaciones desarrolladas por los usuarios finales cumplan Conlas normas de auditoría, calidad y seguridad.

Otro beneficio importante es que pueden ayudar al establecimiento y cumpli.miento de las normas para el hardware y el software de manera que los usuariosfinales no introduzcan muchas tecnologías diferentes e incompatibles a la empresa(Fuller y Swanson, 1992; ver el capítulo 10). El centro en general trabaja con eldepartamento de sistemas de información de la empresa para establecer normas ylineamientos para la compra de software y hardware. El centro de información sóloayudará a usuarios con hardware y software aprobados por la administración.

Además de los centros de información, los administradores pueden seguir otrasestrategias para asegurarse de que la computación de los usuarios finales sirva a lasgrandes metas organizacionales (Alavi, Nelson y Weiss, 1987-88; Rockart y Flan-nery, 1983).

Los administradores ueden com lementar a los centros de información centralcon entros más e ueños distribuidos que prºporc~ capacitación y herra-mientas de cóm uto a la medidf!.para las diferente~ unidades oQerativas y unidadesde área funcionales. Los administradores también en ase urarse de ue elso orte proporcionado se a ecua a as necesidades de los diferentes tipos dediseñadores de a licaciones ara el usuario lOa. Por ejemplo, los usuarios que sólo·usan comandos o sencillos lenguajes de consulta para accesar datos requierendiferente capacitación y herramientas que los que de hecho pueden escribir progra-mas de software y aplicaciones con herramientas de cuarta generación (Rockart yFlannery, 1983). La ea -ª..citación y el soporte también deben tener en mente las!lctitudes de los usuarios hacia las comp-utadora-ª,~niv~es educativos, estilos [email protected] y receptlvioad al~am~o_ (Harrison y Rainer, 1992).

La administracion no debe de permitir que las aplicaciones de usuarios finalessean desarrolladas al azar. La institución debe de incorporar los sistemas de usuariofinal dentro de su plan estratégico de sistemas. Las metodologías para establecer losrequerimientos de información al nivel de toda la empresa que se describieron en elcapítulo 11 pueden identificar las aplicaciones de usuario final con beneficios paratoda la institución.

La administración debe también desarrollar controles sobre el cómputo deusuarios finales. Entre éstos pueden incluirse los siguientes:

• Justificación de los costos de los proyectos de sistemas de información deusuarios finales.

• .Normas de software y hardware para las aplicaciones de los usuarios fmales.


>J

• Normas a nivel de empresa para las microcomputadoras, software de procesa-miento de palabras, sistemas de administración de bases de datos, softwares degráficas y herramientas de consulta e información.

• Revisiones de aseguramiento de la calidad, que.especifiquen si sólo usuariosfinales individuales o si los especialistas de sistemas de información o losdepartamentos de auditoría interna deben verificar los sistemas de informaciónde los usuarios finales.


• Controles para aplicaciones desarrolladas para usuarios finales que cubran Prue.bas, documentación, precisión e integridad de entradas y actualizaciones, respal_do, recuperación y supervisión.

Estos controles se describen con detalle en el capítulo 18. El proceso de Controldebe señalar aplicaciones críticas que proporcionan datos a otros sistemas im_portantes. Tales sistemas garantizan normas más rigurosas. Por ejemplo, la North.west Airlines Inc., estableció políticas y lineamientos para el desarrollo de losusuarios finales que piden a los usuarios que clasifiquen las aplicaciones quedesarrollen de acuerdo con su naturaleza crítica, de manera que la empresa puedatomar medidas especiales para asegurar la integralidad y seguridad de los datos(McMullen, 1992).

Los usuarios finales pueden resentir las normas y controles impuestos por eldepartamento de sistemas de información. En la Ventana sobre Administración sedescriben varias opciones que la administración puede seguir para manejar esteproblema.

12.5 Fuentes externas en lossistemas de información

Fuentes externas: Práctica decontratación, para lasoperaciones de los centros decómputo, redes detelecomunicaciones o desarrollode aplicaciones, de proveedoresexternos.

Si la empresa no desea usar sus recursos internos para desarrollar y operar lossistemas de información, puede contratar a una institución externa que se especia-lice en proporcionar estos servicios. El proceso de dar las operaciones del centro decómputo, redes de telecomunicaciones o desarrollo de aplicaciones de una institu-ción a proveedores externos se llama acudir a fuentes externas.

Como los sistemas de información juegan un papel tan importante en las institu-ciones actuales, la tecnología de la información ahora es responsable de casi lamitad de los gastos de capital de la empresa. En las empresas donde la función delcosto de los sistemas de información se ha incrementado rápidamente, los adminis-tradores buscan medios para controlar estos costos y dan a la tecnología de infor-mación el trato de inversión de capital en vez de un costo de operación. Una opciónpara controlar los costos es acudir a fuentes externas.

Ventajas y desventajas de acudir a fuentes externasSe ha popularizado el acudir a fuentes externas porque algunas instituciones lasperciben como más eficaces desde el punto de vista costos de lo que sería mantenerel propio centro de cómputo y personal de sistemas de información. El proveedor

. de servicios externos puede beneficiarse de las economías de escala (el mismoconocimiento, habilidades y capacidad puede ser compartido con muchos clientesdistintos) y puede cobrar precios competitivos por sus servicios de sistemas deinformación. Acudir a fuentes externas permite a una empresa con necesidadesvariables de procesamiento de cómputo pagar sólo por lo que usa en vez de construirsu propio centro de cómputo para que éste permanezca subutilizado cuando no setienen cargas máximas. Algunas empresas acuden al exterior porque su personalinterno de sistemas de información no puede mantener el paso con los cambiostecnológicos. Pero no todas las instituciones se benefician de las fuentes externas ylas desventajas de esta práctica pueden crear serios problemas a las instituciones sino las entienden y manejan adecuadamente.

450 I Capítulo 12Otros métodos de diseño de sistemas

-----------------

VEr--

e01Q~'1~

)8lela)8

el

rsi-

et-

[-

a:1

'-n

srr)

s

sr

s{

VENTAJAS DE ACUDIR AFUENTES EXTERNAS

DESVENTAJAS DERECURRIR A FUENTES

EXTERNAS

Las explicaciones más comunes para acudir a fuentes externas son las siguientes:Economía. Los proveedores de servicios externos son especialistas en los serviciosy tecnologías de sistemas de información que venden. Mediante especialización yeconomías de escala, pueden proporcionar el mismo servicio y valor por menosdinero de lo que le cuesta a la institución. Por ejemplo, la American Standardinformó haber ahorrado 2 millones de dólares al año al dar al exterior sus operacio-nes financieras y de nóminas. Wabco y American Ultramar cortaron a la mitad suscostos de procesamiento de sus sistemas de información. Aunque algunos provee-dores de servicios externos han prometido reducciones anuales de 50 por ciento enlos costos de tecnología de información, ahorros de entre 15 y 30 por ciento son máscomunes (Loh y Venkatraman, 1992).Calidad en el servicio. Como los proveedores de servicios externos perderán susclientes si el servicio no es satisfactorio, las empresas en general tienen mayorapalancamiento sobre los proveedores externos que sobre sus propios empleados.La empresa que opera con el exterior puede ser capaz de obtener un nivel más altode servicio de los proveedores por los mismos costos o menores.Predecibilidad. Un contrato con el exterior a precio fijo para un nivel específico deservicios reduce los costos de incertidumbre.Flexibilidad. El crecimiento de los negocios puede. integrarse sin hacer cambiosimportantes en la infraestructura de los sistemas de información de la institución ..Como la tecnología de la información pennea toda la cadena de valor en negocios,acudir al exterior puede proporcionar un mejor control de negocios porque suscapacidades y costos pueden ser ajustados a las necesidades cambiantes (Loh yVenkatraman, 1992).Hacer de los costos fijos variables. Algunos de los acuerdos con los promotoresexternos, como correr la nómina, se basan en el precio por unidad de trabajorealizado (como el costo de procesamiento de cada cheque). Muchos proveedoresexternos tomarán en cuenta las variaciones en los volúmenes de operacionesprocesadas que puedan ocurrir durante el año en el transcurso del convenio deservicios externos. Los clientes sólo deben pagar por el volumen de servicios queconsumen al contrario de pagar un costo fijo de mantenimiento de los sistemasinternos que no son utilizados en su totalidad.Liberación de recursos humanos para otros proyectos. El talento escaso y carodentro de la institución se puede reenfocar e., actividades de mayor valor y utilidadque las que se tendrían al operar una fábrica de tecnología.Liberación de capital financiero. Algunos acuerdos con fuentes externas incluyenla venta en efectivo de la tecnología y otros activos de capital de la empresa alproveedor mismo. Por ejemplo, cuando Blue Cross y Blue Shield de Massachusettscontrataron sus operaciones y desarrollo de sistemas con Electronic Data Systems(EDS), éste pagó a Blue Cross en efectivo y en pagarés por su centro de cómputo yotros equipos de computación (CaldweIl, 1992).

No todas las instituciones obtienen los beneficios anteriores al recurrir a fuentesexternas. Existen peligros al poner el desarrollo de los sistemas de informaciónfuera de la institución. Recurrir a fuentes externas, puede crear serios problemastales como la pérdida de control, vulnerabilidad en la información estratégica ydependencia en la suerte de la empresa externa.Pérdida de control. Cuando una empresa cede la responsabilidad y la operación deSl'S sistemas de información a otra, puede perder el control del funcionamientode sus sistemas de información. Recurrir a fuentes externas coloca al proveedor enposición de ventaja respecto al cliente, pues este debe aceptar lo que haga elproveedor y lo que le quiera cobrar. Si el proveedor llega a ser la única alternativapara operar y desarrollar sus sistemas de información, el cliente debe aceptarcualesquiera tecnologías que el proveedor le dé. La dependencia puede tener comoresultado costos más elevados o perder el control de la dirección de la tecnología.

12.5 Fuentes externas en los I 451sistemas de información

~~/ner~bilidad de la información estratégica. ~os secretos comerciales o informa.cion pnvada pueden filtrarse hasta los competidores por el hecho que los sistemasde información de la empresa están siendo operados por externos. Esto podría serespecialmente dañino si la empresa permite que un proveedor externo se encargudel des~ollo u operación de aplicaciones que signifiquen algún tipo de ventaj:competitiva.Dependencia. La empresa se hace dependiente de la viabilidad del proveedor. Unproveedor con problemas financieros o servicios que se deterioran puede crearseveros problemas a sus clientes.

Cuándo utilizar a los proveedores externosComo el uso de proveedores externos tiene beneficios y responsabilidades, y noesuna solución para todas las instituciones ni en todas las situaciones, los administra.dores deben evaluar el papel que desempeñan los sistemas de información en susinstituciones antes de tomar una decisión hacia el exterior. Existe una cantidad decircunstancias dentro de las cuales acudir a proveedores externos tiene gran sentido:

• Cuando existe una oportunidad limitada de la empresa para distinguirse antelacompetencia a causa de una aplicación o una serie de aplicaciones enparticularde un sistema de información. Por ejemplo, el desarrollo y la operación de un sis-tema de nóminas con frecuencia se dan al exterior para liberar al personal desistemas de información y que se concentre en actividades de mayor utilidadprofesional, tales como los sistemas de servicios o manufactura. En la figura 12.7se muestra una matriz que podría ayudar a las empresas a determinar lasaplicaciones apropiadas para darlas al exterior. Aplicaciones como la nómina ola contabilidad de la cafetería, por las que una empresa obtienen muy pocasventajas competitivas de la excelencia, son fuertes candidatas para ser llevadasal exterior. Si se manejan con cuidado, como las reservaciones en aerolíneas,laprogramación de plantas le podría dar a la empresa una ventaja neta sobre loscompetidores. La empresa podría perder utilidades, clientes o participación demercado si tales sistemas tienen problemas. Las aplicaciones en donde la recom-pensa por la excelencia son elevadas y donde también lo son los castigos por elfracaso, probablemente deberían ser desarrolladas y operadas internamente.

Las empresas también pueden ayudar a desarrollar aplicaciones a nivelinterno mientras dan al exterior sus operaciones del centro de cómputo cuandono necesiten sacar ventajas competitivas realizando su procesamiento de cómpu-to en el interior. Por ejemplo, la Eastman Kodak Co., que fue uria de las primerasen usar fuentes externas, al principio realizaba por ella misma las operaciones desus sistemas de información, incluyendo el procesamiento en macrocomputado-ras, telecomunicaciones y el soporte a computadoras personales IBM y DEC.Conservó el desarrollo de aplicaciones y el soporte porque pensó que talesactividades tenían un valor competitivo (Clermont, 1991).

• Cuando la predecibilidad de la interrupción de los sistemas de información noes muy importante. Por ejemplo, las reservaciones en líneas aéreas o los sistemasde ventas por catálogo son demasiado "críticas" para ser confiadas al exterior. Sitales sistemas dejaran de operar sólo por unos cuantos días o aun por horas,podrían quebrar el negocio (capítulo 2). Por otra parte, un sistema para procesarreclamaciones de seguros por empleados puede ser más fácilmente concesionadoal exterior, porque la interrupción en el procesamiento de reclamaciones no escrítico para la sobrevivencia de la empresa.

• Cuando concesionar servicios al exterior no aleja a la empresa del know howtécnico para innovaciones futuras en los sistemas de información. Si una empre-sa da al exterior algunos de sus sistemas pero conserva sus propio personal desistemas de información, podría asegurar que se mantenga actualizado y cuentecon los conocimientos para desarrollar futuras aplicaciones.

flgUprerfuerpreren ipo<:bajéprocanfuecte.Wit(se¡19!FraReJ

4521


Administración de la concesión a fuentes externasPara obtener utilidad de las fuentes externas, las instituciones deben asegurarse deque el proceso está adecuadamente administrado. Con un buen análisis y sanacomprensión de las fuerzas y limitaciones de las fuentes externas, los administrado-res pueden identificar las aplicaciones más adecuadas para ser desarrolladas ycontroladas por fuentes externas y desarrollar un plan viable de uso de estas fuentes.

La segmentación de las actividades de sistemas de información en elementos quepuedan ser dados a fuentes externas hace el problema más manejable y ayuda a lasempresas a dar a un proveedor externo la labor adecuada. Las aplicaciones nocríticas son con frecuencia las candidatas adecuadas para las fuentes externas. Lasempresas deben identificar las aplicaciones críticas para la misión así como losrecursos humanos críticos para la misión que se requieren para desarrollar yadministrar estas aplicaciones. Esto permitirá a la empresa retener a su personalmás capacitado y enfocar todos sus esfuerzos al desarrollo de las aplicaciones máscríticas (Roche, 1992).

La Ventana sobre Instituciones muestra que algunas veces tiene sentido dar alexterior no solamente aplicaciones de los sistemas de información sino tambiéntoda el área funcional que da soporte a tales aplicaciones.

El establecimiento de la estrategia tecnológica es una de las áreas en [as que lasempresas no deberían ceder a las fuentes externas. La tarea estratégica debe perma-necer en casa.

f19ura 12.7 . .Premios y castigos por recurnr afuentes exter.nas. Esta matrizpremios/castigos muestra queen aquellas aplicaciones conpocos premios por excelencia ybaja penalidad por losproblemas son buenos.candidatos para recurrir afuentes externas. Fuente: PaulClermont, "OutsourcinqWithout Guilt", Computerworld,(septiembre 9, 1991). Copyright1991 by CW Publishing, Inc.,Framingham, MA 01701.Reprinted from Computerworld.

'"10

EQJ]leQ.

oQ.

oC'I

'5'0u

Premios por la excelencia

Cuando las capacidades de sistemas de información de la empresa son limita-das, ineficaces o técnicamente inferiores. Algunas instituciones acuden a provee-dores externos como una manera fácil de mejorar su tecnología de sistemas deinformación. Por ejemplo, pueden usar un servicio externo para ayudarles a hacerla transición de un cómputo tradicional basado en macrocomputadoras a unnuevo ambiente de cómputo distribuido propio de nueva arquitectura de infor-mación.

Si el desarrollo y la función de sistemas de información están bien administradosy son productivos, puede no existir un beneficio inmediato que pueda ser propor-cionado por un proveedor externo.

12.5 :uent.e~ e:t.:~nas"~~.¡?~I 4:>3sistemas de intorrna ..." .. ,

VENTANA

Idealmente, la empresa debe de tener una relación confiable de trabajo con unproveedor de servicios externos. El proveedor debe entender el negocio del clientey trabajar con él como socio, adaptando los acuerdos para satisfacer las necesidadescambiantes del cliente. Por ejemplo, el contratista de defensa General DynamicsCorporatíon en Falls Church, Virginia, seleccionó a Computer Science Corporation(CSC) de El Segundo, California, para que maneje su centro de administración dedatos, sus operaciones de redes, desarrollo de aplicaciones y otros servicios deinformación. La General Dynamics firmó un contrato a 10 años con valor de 3,000millones de dólares porque CSC conocía el negocio de la defensa. Comprendía lasreglamentaciones y los factores críticos de éxito para la industria. En otro caso, laGeneral Dynamics debería haber hecho llegar a otros contratistas las reglas delambiente de la defensa antes de que pudieran hacer el trabajo (Lívingston, 1992).

Capítulo "12Otros métodos de diseño de sistemas

~-~-~~~-----~------

E

Iel

"ir'

}1

II

Tabla 12.3

Enfoque OesventllJils

Las empresas deben entender claramente las ventajas proporcionadas por elproveedor y lo que tienen que abandonar para obtener tales ventajas. Para menorescostos de operación, ¿puede el cliente vivir con un tiempo de respuesta de cincosegundos durante las horas pico o la reparación al día siguientes de sus computado-ras en sitios remotos?

Las instituciones no deben delegar responsabilidad administrativa al usar fuentesexternas. Deben administrar al proveedor externo de la misma manera en que admi-nistrarían sus propios departamentos internos de sistemas de información estable-ciendo prioridades, asegurando que las personas adecuadas participen y garantizan-do que los sistemas de información operan con fluidez. Para evaluar al proveedorexterno, deben establecer criterios que incluyan expectativas de desempeño ymétodos de medición para el tiempo de respuesta, volúmenes de operaciones,seguridad, recuperación en caso de desastre, respaldo en el caso de una catástrofe(ver capítulo 18), requerimientos de procesamiento para nuevas aplicaciones yprocesamiento distribuido en microcomputadoras, estaciones de trabajo y LAN.

Las empresas deben diseñar los contratos externos cuidadosamente, de maneraque los servicios externos se ajusten si la naturaleza del negocio mismo cambia. Porejemplo, el Meritor Savings Bank de Filadelfia era un coloso de 12,000 millones dedólares cuando firmó un contrato de servicios externos con Electronic Data Servi-ceso Tres años después, Meritor había cerrado las· dos terceras partes de sussucursales y se redujo a 4,000 millones en activos. El adelgazamiento de susnegocios requirió de mucho menos servicios de procesamiento. Afortunadamente,Meritor había establecido una cláusula en el contrato original de manera que losservicios de EDC pudieran ajustarse al tamaño del banco (Schatz, 1993).

Características

COMPARACiÓN DE ENFOQUES DE DESARROLLO DE SISTEMAS

VentllJils

Ciclode vida de sistemas

Eláboraciónde prototipos

Paquetede software para laaplicación

Desarrollo de usuarios finales

Fuentesexternas

SecuencialProceso formal paso a pasoEspecificaciones y aprobacionespor escritoPapel limitado de usuarios

Requerimientos especificadosdinámica mente con sistemaexperimentalProceso rápido, informal eiterativoLos usuarios interactúanrápido con el proyecto

El software comercial evitanecesidad de programas desoftware desarrolladasinternamente

Sistemas creados para usuariosfinales usando herramientas desoftware de cuarta generaciónRápido e informalPapel mínimo de losespecialistas en sistemas deinformación

Sistemas construidos y algunasveces operados por proveedorextremo

Necesario para sistemas yproyectos complejos y muygrandes

Rápido y baratoÚtil cuando los requerimientosinciertos o cuando la interfasecon usuarios finales sonimportantes

Se reduce diseño,programación, instalación ytrabajo de mantenimientoPermite ahorrar tiempo y costoal desarrollar aplicacionescomunes de negociosDisminuye la necesidad derecursos internos deinformación de los sistemas

Los usuarios controlan laconstrucción de los sistemasAhorra costo y tiempo dedesarrolloDisminuye el trabajo pendientede aplicaciones

Permiten reducir o controlarcostosPermiten producir sistemascuando los recursos internos noestán disponibles o sontécnicamente deficientes

Lento y costosoDesestimula cambiosMucha documentación a sermanejada

Inadecuado para sistemasgrandes y complejosPuede ser muy superficial yobviar pasos importantes en elanálisis, documentación ypruebas

Puede no satisfacer losrequerimientos exc"'pc!onalesde la instituciónPuede no desempeñar bienmuchas funciones de negociosUna excesiva adaptaciónincrementa los costos dedesarrollo

Puede conducir a unaproliferación de sistemas deinformación sin controlLos sistemas no siemprecumplen con las normas deaseguramiento de la calidad

Pérdida de control sobre lafunción (área) de sistemas deinformaciónDependencia de la dirección dela técnica y la prosperidad deproveedores externos------------------------------------------~.~.. ,-

12.5 Fuentes externas en 105sistemas de información I s', t::,~'.: ..;:,

En la tabla 12.3 se comparan las ventajas y desventajas de cada una de lasalternativas de construcción de sistemas que se describen en este capítulo.

1. Determinación de la estrategia adecuada para el desarrollo de sistemas.Algunas ocasiones, las instituciones encuentran problemas que no pueden seratacados por ninguna de las estrategias de desarrollo de sistemas que sedescriben en este capítulo. Por ejemplo, un sistema grande y complejo puedetener algunas características no estructuradas. La configuración final delsistema no puede ser decidida de antemano porque los requerimientos deinformación o la tecnología apropiada son inciertas. De otra manera, unsistema propuesto requiere de cambios importantes de carácter organizacionalasí como técnico. En tales casos, puede ser necesaria una empresa para seguiruna estrategia de compromiso por fases en donde los proyectos de sistemas serompan en partes más pequeñas y sean desarrolladas paso a paso, o puedenecesitar posponer todo el proyecto.

2. Controlar el desarrollo de los sistemas de información fuera del departa_mento de sistemas de información. Puede no haber una manera de establecernormas y controles, apropiados para usuarios finales. Estas normas y controlescuando son muy restrictivas pueden no sólo generar resistencia de los usuariosfinales sino también inhibir las innovaciones de los usuarios finales. Si loscontroles son muy débiles la empresa puede encontrar serios problemas conla integralidad y conectividad de los datos. No siempre es posible encontrar elbalance adecuado.

3. Seleccionar una estrategia de desarrollo de sistemas que se adapte a laarquitectura de la información y al plan estratégico de la empresa. Eldesarrollo por usuarios finales, los paquetes de software de aplicaciones o eluso de fuentes externas pueden ser buenas soluciones a corto plazo, peropueden no servir mejor a largo plazo a los intereses de la empresa. Estassoluciones pueden tener como resultado aplicaciones tan distintas que no -puedan ser integradas fácilmente a la arquitectura general de información dela empresa. Las instituciones necesitan evaluar cuidadosamente el impacto alargo plazo de sus estrategias de desarrollo de aplicaciones.

Resumen

Distinguir entre las distintas alternativas de desarrollo de sistemas: el del ciclode vida tradicional de los sistemas, la elaboración de prototipos, paquetes desoftware de aplicaciones, desarrollo por usuarios finales y fuentes externas.El ciclo de vida tradicional de los sistemas (el más antiguo método para el desarrollode sistemas) divide el desarrollo de los sistemas de información en seis etapasformales: definición del proyecto, análisis de sistemas, diseño, programación,instalación y postimplantación. Las etapas deben llevarse a cabo de manera secuen-cial, tienen productos definidos y requieren de autorización formal antes de queprincipie la siguiente etapa luego de terminar la anterior.

La elaboración de prototipos consiste en desarrollar un sistema no-funcional rápidoy barato para que los usuarios finales interactúen con él y lo evalúen. El prototipose afina y se mejora hasta que los usuarios quedan satisfechos porque cumple contodos sus requerimientos y puede ser usado como marco para crear el sistema final.

El desarrollo de un sistema de información usando un paquete de software deaplicación elimina la necesidad de escribir programas de software al desarrollar unsistema de información. El uso de un paquete de software reduce fuertemente lacantidad de trabajo de diseño, pruebas, instalación y mantenimiento que se requierepara construir un sistema.


- _._._-_ .. _------------

El desarrollo por usuarios finales es el desarrollo de sistemas de información porusuarios finales, ya sea solos o con muy poca asistencia de los especialistas ensistemas de información. Los sistemas desarrollados por los usuarios finales puedencrearse rápida e informalmente con herramientas de software de cuarta gene-ración.

Recurrir a fuentes externas consiste en utilizar un proveedor externo para desa-rrollar (u operar) los sistemas de información de la empresa. El sistema puede serhecho a la medida o puede emplear un paquete de software. En ambos casos, eltrabajo lo hace el proveedor en vez del personal interno de sistemas de informaciónde la empresa.

Entender las fuerzas y limitaciones de cada enfoque.El ciclo de vida tradicional de los sistemas es aún útil para los grandes proyectosque requieren de especificaciones formales y un férreo control administrativo sobrecada etapa de la construcción de sistemas. Sin embargo, el método tradicional esmuy rígido y costoso para la construcción de un sistema y no es apropiado paraaplicaciones no estructuradas y orientadas hacia las decisiones en donde los reque-rimientos no pueden ser visualizados de inmediato.

La elaboración de prototipos estimula el involucramiento de los usuarios finalesen el desarrollo e iteración de sistemas hasta que las especificaciones sean adecua-damente captadas. La rápida creación de prototipos puede tener como resultadosistemas que no hayan sido totalmente probados o documentados o que son técni-camente inadecuados para un ambiente de producción.

Los paquetes de software de aplicaciones son útiles si una empresa no cuenta conel personal de sistemas de información o recursos financieros para desarrollar unsistema a la medida. Para cumplir con los requerimientos exclusivos de una institu-ción, los paquetes pueden requerir modificaciones sustanciales que pueden incre-mentar fuertemente los costos de desarrollo. Un paquete puede no ser una soluciónfactible si la implantación requiere de una adaptación y cambios excesivos en losprocedimientos de la institución.

Los principales beneficios del desarrollo por usuarios es la determinación mejo-rada de los requerimientos, menor retraso en el desarrollo de aplicaciones y unamucho mayor participación de usuarios finales en el control del proceso de desarro-llo de sistemas. Sin embargo, el desarrollo por usuarios finales, junto con lacomputación distribuida, ha introducido nuevos riesgos institucionales al propagarsistemas de información y recursos de datos que no necesariamente cumplen conlas normas de aseguramiento de la calidad y no pueden ser controlados fácilmentepor los medios tradicionales.

Las fuentes externas pueden ahorrar costos de desarrollo de aplicaciones opennitirque las empresas desarrollen aplicaciones sin necesidad de personal internode sistemas de información, pero también puede ocurrir que las empresas pierdancontrol sobre sus sistemas de información y se hagan demasiado dependientes deproveedores externos.

Iel

I

•..-JIIf.

Resumen I 457

Describir los tipos de problemas para los cuales cada enfoque es el másapropiado.El ciclo de vida tradicional de los sistemas es adecuado para sistemas de procesa-miento de operaciones que son muy grandes (SPO) y sistemas de información paraadministración (SrA) con un procesamiento complejo y requerimientos de análisisrigurosos y formales, especificaciones previamente definidas y fuertes controlessobre el proceso de construcción de sistemas.

La elaboración de prototipos es útil para aplicaciones sencillas cuyos requeri-mientos son vagos o no estructurados, o para el diseño de porciones de interfases de

Términosclave

Preguntasde repaso

Ciclo de vida de los sistemasDefinición del proyectoAnálisis de sistemasDiseñoProgramaciónInstalaciónPosimplantaciónElaboración de prototiposPrototipo

usuario final de sistemas grandes y complejos. Los prototipos no son adecuadospara diseñar todos los aspectos de los sistemas grandes que requieren de procesa.miento por lotes o una lógica compleja de procesamiento.

Los paquetes de software son más adecuados para aplicaciones con requerimien.tos comunes a muchas instituciones y con un número limitado de funciones quepueden estar soportadas mediante software comercial.

Los mejores candidatos para el desarrollo por usuarios son las aplicaciones Conlógica de procesamiento relativamente sencilla y archivos pequeños que pueden serdesarrollados fácilmente con herramientas de cuarta generación.

El recurrir a fuentes externas es adecuado en el caso de aplicaciones que no seanfuente de ventajas competitivas o que requieran de conocimientos técnicos que nopuedan ser proporcionados por la empresa.

Describir la solución a los problemas administrativos creados por estos enfoques.Las instituciones pueden superar algunas de las limitaciones del uso de paquetesde software realizando un análisis profundo de requerimientos y mediante el uso deprocedimientos rigurosos de selección de paquetes para determinar hasta dónde unpaquete puede satisfacer tales requerimientos. En la institución se puede adaptarel paquete o modificar sus procedimientos para asegurar una mejor adaptación aléste.

Los centros de información pueden ayudar a promover y controlar el desarrollode usuarios finales. Proporcionan a los usuarios hardware, software y conocimien,tos técnicos adecuados para crear sus propias aplicaciones y estimular la adherenciaa las normas para el desarrollo de aplicaciones. Las instituciones también puedendesarrollar nuevas políticas y procedimientos en relación con las normas para eldesarrollo de sistemas, capacitación, administración de datos y controles paraadministrar con eficacia la computación de usuarios finales.

Las instituciones pueden beneficiarse de fuentes internas al dar al exterior partede sus sistemas de información, al comprender muy bien qué funciones de lossistemas de información son apropiadas para ser concesionadas al exterior, aldiseñar con cuidado los contratos con fuentes externas y al tratar de construir unasociedad de trabajo con el proveedor de servicios externos.

lterativolnterfase con el usuario finalPaquete de software de aplicacionesAdaptabilidad (sobre medida)Requisición de propuesta (RP)Desarrollo por usarios finalesCentro de informaciónFuentes externas

1. ¿Cuál es el ciclo de vida tradicional de los sistemas? ¿Cuáles son sus caracte-rísticas?

2. Describir cada una de las etapas del ciclo de vida de los sistemas.3. ¿Cuáles son las ventajas y desventajas del desarrollo de un sistema de infor-

mación usando el método del ciclo de vida tradicional de los sistemas?4. ¿Qué significa prototipo del sistema de información?5. ¿Bajo qué condiciones es el uso de prototipos un enfoque útil de sistemas?

¿Qué tipos de problemas puede ayudar a resolver?6. Describir cinco cosas en las que la elaboración de prototipos difiere del

método del ciclo de vida tradicional de los sistemas.


Preguntas paradiscusión

Proyectode grupo

7. Enlistar y describir las etapas del proceso de elaboración de prototipos.8. Enlistar y describir cuatro limitaciones de la elaboración de prototipos.9. ¿Qué es un ps quete de software de aplicaciones? ¿Bajo qué circunstancias

deberían usarse los paquetes para la construcción de los sistemas de infor-mación?

10. ¿Cuáles son las principales ventajas del uso de paquetes de software deaplicaciones para el desarrollo de un sistema de información? ¿Por qué lospaquetes ejercen un gran atractivo para los administradores?

11. Enlistar y describir las principales desventajas de los paquetes de softwarepara apíicaciones.

12. ¿Qué significa la adaptación de paquetes? ¿Bajo qué circunstancias puedecrearse un problema al implantar un paquete de software de aplicación?

13. Enumerar los principales criterios para evaluar un paquete de software deaplicación.

14. ¿Cómo se altera el proceso de desarrollo de sistemas cuando un paquete desoftware de aplicación se considera y se selecciona?

15. ¿Qué significa desarrollo por usuarios finales?16. ¿Cuáles son las ventajas y desventajas del desarrollo por usuarios finales?

¿Para qué tipo de problemas es adecuado?17. ¿Qué es un centro de información? ¿Cómo pueden los centros de inforrnación

resolver algunos de los problemas de administración creados por el desarrollode los usuarios finales?

18. Citar algunas políticas y procedimientos para administrar el desarrollo porusuarios finales.

19. ¿Qué son las fuentes externas de los sistemas? ¿Bajo qué circunstancias sedeben utilizar para la construcción de sistemas de información?

20. ¿Cuáles son las ventajas y desventajas del uso de las fuentes externas?21. Describir algunas soluciones a los problemas de administración creados por

recurrir a las fuentes externas.

1. Un informe multicitado de investigación encontró que la elaboración de proto-tipos facilitaba la comunicación entre los usuarios y los diseñadoresde sistemasde información pero que los diseñadores que usaban los prototipos tenían di-ficultades para el control y la administración del proceso de diseño. Discutirlo.

2. Se ha observado que el uso exitoso de los prototipos depende menos de la se-lección de las herramientas de software que de la cultura corporativa. Discutir.

3. Algunos han dicho que la mejor manera de evitar el servicio de los programa-dores profesionales es la instalación de un paquete de software de aplicación.Discutir.

4. Una publicación de sistemas de información afirmó que, a lo sumo, el desarro-llo intramuros de un sistema que ya se tiene disponible en forma de paquetedebe costar tanto como quince veces más que la versión en paquete y tardar detres a cuatro veces más para que la inversión directa se recupere. Discutir.

5. ¿Qué teorías de las que discuten el impacto de los sistemas de información enlas instituciones podrían ser aplicadas para describir el recurso a fuentesexternas?

Con un grupo de compañeros de clase, obtener información sobre un producto oasistir a una demostración de un paquete de software para aplicaciones en micro-computadora como DacEasy, ContabilidadlNóminas, Quicken, Managing YourMoneyo Microsoft Profit for Windows. Escribir un análisis de las fuerzas y laslimitaciones del paquete que se hubiera elegido. Presentar los hallazgos al grupo.

Resumen I 459I

....- ,

-~'

t.

I. tegracic:"nadaptativos de las aplicaciones existentes haciaInel R/3.ROyalLeP¡;<geReal E~tate Ser~ice L~d., una empresa deb'enes raíces comerciales y residenciales de Taranta, con~~cursale',;en todo Canadá, que factura 450 millones dedólares optó por el RJ'3.en 1991. Inicialmente usaba el Rj3r ara COI rer una aplicación del libro mayor en su estación defrabajO con UNIX RSj6000 de IBM. La aplicación del libro'ayor tenía que enlazarse con una aplicación financiera deni

macrocomputadora ya existente que usaba un paquetede Dun & Bradstreet Software, un proveedor rival. EntoncesRoyal LePage inició el uso del Rj3 para aplicaciones decictivos fijos y cuentas por pagar y está añadiendo compo-nentes de cuentas por cobrar, compras, nóminas y recursoshumanos al sistema Rj3.

A Royal LePage le qustó el Rj3 porque apoyaba la meta dela empresa de crear un ambiente de cómputo distribuidoque diera a cada rama más datos y capacidad de procesa-miento e integrara sus aplicaciones y ramas más que antes.Don Logan, el vicepresidente y contra lar, cree que el Rj3permitió a la empresa ahorrar inicialmente más de dosmillones de dólares en desarrollo de sistemas y costos deapoyo y probablemente un millón más con el tiempo. Lamitad de los ahorros provienen de la reducción del tiempode programación mediante el uso del Rj3.

Klaus Besier, director de SAP America Ine. (sucursal enLester, Pensilvania de SAP A.G.), cree que la característica·más importante de Rj3 es que ayuda a las empresas aautomatizar sus procesos de negocios. Al adoptar el diseñode sistemas ofrecido por el paquete, las empresas pueden

aluar y agilizar sus procesos de negocios. La promesa dereihgeniería fue lo que inicialmente atrajo a la EastmanKod-él:\hacia el software de SAP.:Kodak lanzó un proyectopiloto €:,,'1991 que instaló programas SAP para redefinir laactividad de entrada de pedidos. El paquete SAP deja quequienes toman los pedidos tomen inmediatamente las de-cisiones sobre dar a los clientes crédito y les deja, directa-mente en línea, acceso a los datos de producción de mane-ra que pueden informar a sus clientes cuándo estarán suspedidos listos para ser embarcados. El proyecto tuvo comoresultado una disminución de un 70 por ciento en el tiempode entrega de productos; el tiempo de respuesta a losdientes se redujo a la mitad. Estos resultados hicieron queKodak pronto usara el software SAP como la arquitecturaglobal para todos sus sistemas centrales.

Las características intrincadas y sofisticadas del softwareSAP afectan profundamente la estructura de la corpora-ción. La instalación de dos o más módulos SAP con todaslas alteraciones del negocio que se requieren puede tardarfácilmente de uno a tres años. Desafortunadamente, SAPestá a la zaga en cuestión de soporte al producto.

SAP tiene una gran plantilla de personal interno para darsoporte a sus paquetes de software, pero también emplea

r.: 1 f • .,,--..,

- t'

a legiones de expertos de empresas de COi -sultoría talescomo Price Waterhouse, Andersen Consultinc. EDS Corpo-ration y Coopers & tybrand, Estos consultores externoscolaboran con los clientes de SAP para instalar los paquetesde SAPoSegún John Van de Graaf, analista de Vil lores en el.Deutsche Bar.k Capital Corporation con sede en r~ueva York(el brazo bancario de inversión del German Oeutsche Bank),existe una gran carestía a nivel mundial de expertos en SAPo

Louis Dingerdissen, vicepresidente de SIA para el qrupo deproductos para la salud de Kodak, observó que los expertosen software de SAP son escasos y que los usuarios 'finalespueden necesitar hasta 16 semanas para tener fluidez en elsoftware de SAP: demasiado. Como SAP capta rápidamen-te nuevos clientes, la situación de soporte puede empeorarantes de que mejore, o SAP debe desacelerar un poco sucrecimiento ..

Una razón para la escasez de los consultores en SAP es ~uepuede tomar años aun para los técnicos con experienciaentender todas las complejidades y metodologías del SOf~.•

ware SAPo El vicepresidente y cofundador de SAP, HassoPlattner, admite que se requieren cerca de tres años, o doso tres instalaciones del paquete, antes de que un consultorsea experto en el software. El SAP coloca a uno o más desus veteranos con más de ocho o diez años con los menosexpertos consultores de SAP de los Estados Unidos en cadainstalación. Pero según Greg Staszko, un socio de la rama.de Cincinnati de Deloitte & Touche (una muy importanteempresa de contabilidad y consultoría), los expertos de SAPtienden a ser solucionadores de problemas O expertos deproductos más que consultores de negocios. Por ello losclientes no necesariamente obtienen el mejor consejo de có-mo integrar el software a sus operaciones de negocios demanera eficiente e indolora. La percepción que domina enalgunas empresas de los Estados Unidos es de que aun unexperto SAP que domine el módulo de contabilidad finan-ciera no puede corregir un error en el módulo de ventas ydistribución.

Para incrementar la cantidad de consultores calificados, SAPconstruyó unas instalaciones mundiales de capacitación enWalldorf, con un costo aproximado de 50 a 60 millones dedólares. Reclutó más. consultores al firmar acuerdos connuevas empresas de consultoría como Cap Gemini Américay Coopers & Lybrand y enfrió sus relaciones con empresa',como Computer Sciences Corporation y KPMG Peat Mar-wick, las que a su juicio nc habían trabejedo bien.

Jim Bensman, el anterior presidente de SAP America Inc. (lasubsidiaria de SAP en los Estados Unidos) ai:rm) que elconvenio con KPMG Peat Marwick habla ~-acasado el i ·.'~t~país porque no se había capacitado lo suficiente '" i(\~;

consultores. Sin ernbaroo, SAP continúa trabejundo C-:':I.

KPMG Peat Marwick en Europa. Las fuentes itl :-:a:, ql.'.cComputer Sciences Corporation qastó mucho· ';¡ lE.. ··' el'capacitación, pero no captó dientes para el Sl ,;\

Fuentes: Doug Bartholomew, "An American Beachhead", InformationWEEK (marzo 9, 1992) and Mikf': Ricciuii anrl : '"Jiiiiarn- -¡ Semich, "SAP's Client/Server Battle Plan" Deuuoetion (marzo 15,19'H).

r

l

II

~~~~_.--..:;; •• ' -.- LJ •••••••••• ~~~

C'-'.$'·, el\:;

estcdlo l' ..tC·,'

".,'\, :,~~

<,

---

•..•

'--.-

-.

T,

Capitulo 12 Metodologias

Documents

Transcript of Capitulo 12 Metodologias