182

editorial

El usuario tiene
derechos

C
on los años, y como profesional informático, uno va adquiriendo ex-
periencia no sólo en el campo del desarrollo de aplicaciones sino tam-
bién en el trato y relación con los usuarios de las mismas. En este
sentido, todos hemos vivido situaciones tan anecdóticas o tan com-
prometidas que, con el tiempo, nos han hecho acreedores de una cierta
mala fama y de que, en general, se nos acuse de prestar poca aten-
ción a las necesidades reales del usuario. Es más, nosotros, también como usuarios
y en más de una ocasión, nos hemos acordado de aquel programador al que se le
ocurrió la brillante idea de combinar las teclas “Control-Alt-Del” del PC para fina-
lizar, sin ningún tipo de control, alguna que otra sesión de Windows.

Profundizando un poco en el tema, en Internet encontré que en 1998, Claire-

Marie Karat, especialista en el análisis de interfaces de usuario en IBM, propuso
en la revista Business Week (www.businessweek.com/1998/39/b3597037.htm) una
especie de decálogo o “Código de derechos de los usuarios de informática” del que
vale la pena destacar algunos principios:

• El usuario siempre tiene razón. Si hay un problema en el uso de un sistema no es

por su culpa. ¿Cuántas veces nos hemos encontrado en una situación en que nos
dicen que no sabemos usar algo que debería ser muy sencillo de manejar?,
• el usuario tiene derecho a poder instalar fácilmente software y hardware,
• tiene derecho a pedirle al sistema lo que le han prometido que hará,
• tiene derecho a disponer de instrucciones fáciles de comprender,
• tiene derecho a comunicarse con el proveedor de la tecnología para obtener res-
puestas adecuadas,
Imagen de la portada: Mike Friehauf
• los productos (hardware y software) tienen que ser fáciles e intuitivos de usar.
Suscripción: Anual (10 números
al año, no en Julio y Agosto).
España: 96 euros (IVA incluido).
Lo que viene a decir, en resumen, es que los usuarios tenemos derecho a dispo-
Extranjero: 180 $ USA (incluido el ner de un servicio de calidad. Inmediatamente hubo una reacción de los lectores de
envío por Correo Aéreo). Se Business Week que pedían que se empezara a aplicar rápidamente el código. Tam-
distribuye a final de mes.
bién como consecuencia aparecieron las respuestas de los teóricos informáticos
© Publicaciones HELP400, S.L.
Se prohibe la reproducción total o parcial
dudando de la posibilidad de construir sistemas realmente “intuitivos”. En este
de los artículos aparecidos en este número, que temáticamente hemos centrado en la Gestión de Proyectos podemos
número sin la autorización expresa por
escrito de la empresa editora, titular del encontrar argumentos y metodologías que, como mínimo, nos ayudarán a mejorar
Copyright. Todos los derechos reservados
en cualquier idioma.
esta percepción negativa de los usuarios.
ServerNEWS es una publicación
independiente de grupos de usuarios y/o
de distribuidores de marcas. De las ideas Ante una nueva aplicación, el prepararla convenientemente no sólo nos permiti-
expuestas en los artículos firmados son
responsables sus autores. Corresponde al
rá atender mejor la “lista de deseos” del usuario sino que también nos permitirá
lector el asegurar que las noticias, ganar su aprecio y respeto.
técnicas y procedimientos descritos son
adecuados para su instalación.
Publicaciones HELP400 S.L. no
asume ninguna garantía ni implícita ni
explicitamente.
La empresa editora no se responsabiliza de
la asiduidad en la distribución gratuita a
las empresas españolas equipadas con
S/3X o AS/400.

IBM y AS/400 son marcas registradas

Antonio Montía
por International Business Machines. a.montia@help400.com

www.help400.es MARZO 2008 ServerNEWS 3

 sumario
ANTES HELP400, LA REVISTA PARA EL PROFESIONAL DE LOS S/3X Y AS/400

equipo editorial
Director: Antonio Montía
en portada
Redacción: Carlos Bell, Alberto C. Blanch,

10
Equipo internacional de iSeries NEWS
Colaboradores habituales: Jaime Gustavo
Recopilación y documentación de requisitos
Estany, José Mª Martín, Lluís Peiret por Russ Bartlett
Traducciones: Pere J. Francisco Brumós El usuario final de una aplicación es la persona a la que
producción va destinada una aplicación una vez que ésta ha supera-
Realización: Media Limits S.L. do las fases de desarrollo. Descubra cómo conseguir re-
Maquetación: Ramiro Esteve Coll quisitos de los usuarios claros, concisos, fáciles de cuanti-
Impresión: G2B gràfic S.L.
Distribución: Unipost S.A.
ficar y de probar.
administración

14 Cómo decidirse por una solución para

Suscripciones : Nuria Navarro
Publicidad: Tel. 34- 932 310 049
el desarrollo de aplicaciones
Fax: 34-932 310 309
Servicio HelpNet: www.help400.es por Chris Maxcer
edita Si se pregunta si, para equipos pequeños, no sería mejor
PUBLICACIONES adquirir una herramienta de desa-
rrollo de aplicaciones en vez de
Deposito legal: B-2757-90
intentar aprender nuevos len-
I.S.S.N. 1698-4501 guajes y técnicas, puede
APTDO. DE CORREOS 8003 - 08080 Barcelona que en este artículo ha-
Gran Vía Corts Catalanes, 715, Entlo. 3ª lle la respuesta.
08013 - Barcelona
Tel.: 932 310 049
E-mail: help400@help400.com

Director General: Alberto C. Blanch Llangostera

Publicado con la participación de

- iSeries NEWS
www.pentontech.com

Group Publisher/Editor: Wayne Madden

Group Editorial Director: Dale Agger
Penton Technology Media
Darrell C. Denny, President
Penton Media, Inc.
David Nussbaum, Chief Executive Officer

LATINOAMERICA

distribuidores
Belice, El Salvador, Guatemala y Honduras
VIACOMP
6ª Avenida. "A" 2-83 Zona 10
Ciudad de Guatemala, GUATEMALA 01010
Telf. 502-360-0358 y 360-0350
Fax 502-332-33694
email: viacomp@guate.net
www.viacomp.net opinión
Perú

8 La web convierte a las empresas en compañías de

COMMON PERU
Bajada Balta 131, Of. 10, 2º Piso
Miraflores Lima 18, PERU software
Telf. y Fax: 46 31 32
por John Ghrist
Paraguay
ANGEL LIERNUR E HIJO El fin de las aplicaciones web es servir a personas que no tienen la obli-
P.O. BOX 2448 gación de tolerar programas malos, por tanto han de hacer correctamen-
ASUNCION - PARAGUAY
427661@telesurf.com.py te todo lo que se supone que deben hacer. Y eso las sitúa al mismo nivel
e-mail: aliernur@yahoo.com de exigencia que en el desarrollo de software comercial.

4 ServerNEWS MARZO 2008 www.help400.es

 Nº 182 MARZO 2008 www.help400.es
programación y sistemas

20 Configurar un entorno seguro para aplicaciones

escritas en PHP
por Alan Seiden
Dada la naturaleza abierta de Internet, los administradores de sistemas
que instalen aplicaciones web en el entorno PHP de Zend Core para i5
querrán tener garantizada la seguridad. En este artículo se explica cómo
aumentar la protección desde el propio entorno PHP.

management

24 Supervisar el rendimiento del entorno web

por Rachel Eagle y Tim Rowe
El Supervisor de rendimiento Web (WPM) forma parte del IBM HTTP Server
para i5/OS y nos permite, desde la interfaz Web Administration, recopilar
datos sobre el rendimiento de los trabajos que componen un entorno web y
las transacciones realizadas por éstos.

28 Añadir técnicas de SQL Server al repertorio de DB2

por Paul Conte
Más allá del lenguaje SQL en sí, hay varias funciones en el SQL Server de
Microsoft que todavía no están implementadas en DB2 y que puede que le
interese utilizar en sus desarrollos. En este artículo encontrará una rápida
introducción.

estrictamente confidencial

42 Algo se está cociendo en IBM

por Carlos Bell
En la próxima reunión anual de COMMON USA IBM anunciará una impor-
tante iniciativa denominada “The New Power Equation”.
HELP400 Suplemento Técnico i
forum.help400
F orum.help400 es una lista de correos
puesta a disposición de los lectores de
ServerNEWS en la que cada día, entre to-
dos los participantes, se solucionan nume-
rosos problemas. Hallará más información

1 Parámetros y tipos de datos de las API

Por Bruce Vining
Iniciamos una nueva serie de artículos, genéricamente titulada como
en http://www.help400.es/forum.htm

“APIs estándar para los programadores en CL”, para explicar cómo

se pueden utilizar desde ILE CL muchas de las API estándar del
sector. Para familiarizarnos con sus parámetros y tipos de datos,
empezaremos explorando la API getenv.
SECCIONES

12 Como evitar el fracaso de un proyecto

Por Paul Conte
Formando parte de la temática de portada de este número, presen-
HABITUALES

3 Editorial
tamos diez técnicas garantizadas para conseguir que un proyecto
6 Novedades
de desarrollo fracase (y diez remedios infalibles para asegurarse de
todo lo contrario) 40 Guia
42 Confidencial
www.help400.es MARZO 2008 ServerNEWS 5
MARZO 2008 ServerNEWS 5
 novedades
■ Econocom abre
Tango/04 consigue los mejores resultados nuevas oficinas en
Barcelona
de su historia en 2007 Econocom, empresa líder en
renting y gestión de activos infor-
ango/04 Computing Group, líder europeo en desarrollo de software para Gestión de Sistemas,
T Auditoría de Seguridad y Gestión de Servicios de Negocio (BSM) ha conseguido resultados finan-
cieros extraordinarios en el ejercicio 2007, finalizado el pasado 31 de diciembre. La empresa ha dado
máticos y de telecomunicaciones,
ha abierto nuevas oficinas en Bar-
celona “para hacer frente al creci-
beneficios por decimoquinto año consecutivo, con las ventas internacionales creciendo a más del 30% miento que hemos experimentado en
interanual. El crecimiento ha sido más notable en América Latina, alcanzando un crecimiento extraor- la región en los últimos meses”, co-
dinario que la consolida como líder en dicho mercado, con un aumento de ventas del 76,4%. mentó Ángel Benguigui, Director
“Estamos muy contentos con estos resultados”, dice Raúl Cristián Aguirre, Gerente y Fundador de General de Econocom España. La
Tango/04, “evidentemente estamos acertando con nuestro nuevo enfoque de monitorización 1 – 2 – 3, su nueva sede de Econocom en Bar-
facilidad de uso y sus cortos tiempos de implantación. Conseguimos éxitos continuamente justo donde celona está situada en Roger de
nuestros competidores están fallando.” Lluria, 50. Con este cambio,
Durante 2007 se añadieron más de 100 nuevos clientes, incluyendo a ING, Citigroup, Nike, FMO, Econocom continúa con su estra-
Boehringer Ingelheim, Helvetia Previsión, FiatC, Dolce & Gabbana, Louis Vuitton Malletier, Costco, tegia de aumentar el compromiso
Bayer CorpScience, Zurich Seguros, Mapfre, Pernod Ricard, Seur Geopost, Swiss Medical Group, Tele- con Catalunya a más largo plazo.
visa, EDS, BBVA Previsión, Industrial Bank, Center Parcs, Euronet, etc. Según Benguigui, el crecimien-
“Diez de las veinte entidades financieras más grandes del mundo son ya nuestros clientes. Tenemos to que está experimentando el
éxito tanto en proyectos de Seguridad como en los de Gestión de Servicios e Infraestructuras. Hemos renting tecnológico en todo el país
presentado productos innovadores y únicos para simplificar las tareas diarias de los profesionales de TI. está siendo más acusado en Bar-
Año tras año vamos superando hitos históricos en un mercado súper competitivo como es el de la celona, “donde la cultura del Ren-
monitorización multiplataforma. Estamos preparados para ser líderes”, añade Aguirre. ting está muy arraigada. Aunque
Para apoyar el crecimiento continuo, Tango/04 ha abierto durante 2007 nuevas oficinas en Estados nuestra sede central permanecerá
Unidos, Brasil y Colombia. También se han mejorado las operaciones a través del canal con nuevos o en Madrid, porque es un centro de
renovados acuerdos con partners como IBM, PricewaterhouseCoopers, Electronic Data Systems (EDS), negocios clave en España, Barcelo-
PST Business Solutions, Moores Rowland (India) (parte de BDO), Sanwa Contec (Japón), Concord na es un mercado que empieza a
(Taiwán) y muchos otros. ganar protagonismo en el creci-
“Tenemos plena confianza en que en 2008 volveremos a batir todos los récords. Tenemos numerosas miento de nuestra empresa. El mer-
oportunidades comerciales abiertas, vamos a lanzar nuevos productos y el mercado mundial está madu- cado español es, cada día, más re-
rando velozmente para soluciones como las nuestras: prácticas y que aporten un gran valor rápidamente. ceptivo al Renting IT. Cada día
Creo que vamos a hacer historia”, concluye Aguirre. más empresas apuestan por esta
1-2-3: Con Tango/04, llega la monitorización integral opción en lugar de la compra, debi-
Tango/04 es la única solución de monitorización en tiempo real que permite controlar y reaccionar de do a los beneficios inmediatos que
manera proactiva ante cualquier incidencia que afecte a la empresa, ya sea de seguridad, de infraes- experimentan en términos económi-
tructura, o de negocio: cos, financieros y de gestión”.
1) Infraestructura TI: Servidores multiplataforma, base de datos, dispositivos de red, etc. A través de las soluciones de
2) Seguridad: Auditoría y Cumplimiento de Leyes y Regulaciones (LOPD, SOX, HIPAA, etc.) Renting que ofrece Econocom, las
3) Servicios de Negocio: Aplicaciones, Niveles de Servicio (SLM) y gestión de los servicios del negocio empresas no tienen que adquirir y
vincular su capital a equipos infor-
Para más información, Telf.: 932.749.051 - www.tango04.es máticos sometidos a una rápida
depreciación. Además, para hacer
■ Según axesor, la Los subsectores analizados por so del 12,4% en la creación de frente a los continuos desafíos del
mercado y disfrutar de los benefi-
creación de empresas axesor en su informe son: Con- empresas informáticas, lo que
sulta de equipo informático; Con- supone 347 sociedades menos cios ofrecidos por las tecnologías
informáticas desciende
sulta y suministro de aplicaciones Por comunidades autónomas, más modernas e innovadoras, las
un 12,4% en 2007
informáticas; Actividades de pro- Madrid encabeza la lista de crea- empresas tendrían que adecuar
Un total de 2.453 nuevas socieda- ceso de datos; Actividades relacio- ción de empresas informáticas, continuamente sus activos TI, con
des mercantiles se han incorpora- nadas con bases de datos; Mante- con 688 nuevas sociedades, segui- el riesgo de incurrir en gastos
do al sector informático español en nimiento y reparación de equipo da por Cataluña con 583 y en el insostenibles. “El Renting permite
2007. Así lo refleja en su último informático, y Otras actividades tercer puesto Andalucía, con 280. mantener siempre actualizado el
“Estudio Radar sobre el sector relacionadas con la informática. Cierran la clasificación Ceuta y parque TI y poder optimizar su cos-
informático” axesor, empresa es- Comparando los datos con los Melilla (2 nuevas empresas infor- te total”.
pañola especializada en el sumi- registrados en los años 2005 y máticas) y La Rioja (3). El seg- Fundada en 1984, Econocom
nistro de información empresarial 2006, se observa tanto un descen- mento que mayor dinamismo pre- está presente en los ocho merca-
por Internet, que analiza la situa- so en el número de constituciones senta es el de consultoría y dos más importantes de Europa y
ción de altas y disoluciones de como un incremento en el núme- suministro de aplicaciones, con actualmente cuenta con más de
empresas del sector TIC a lo lar- ro de disoluciones. Respecto a 1.872 nuevas sociedades mercan- 2.200 empleados.
go del año pasado, tomando como 2006, año en el que se crearon un tiles. Para más información,
base la clasificación nacional de total de 2.800 empresas en este Para más información, Telf.: 914.119.120
actividades económicas CNAE. sector, se ha producido un descen- www.asexor.es www.econocom.es

6 ServerNEWS MARZO 2008 www.help400.es

■ ACOM Solutions
introduce el
EZContentManager
para System i
Esta firma estadounidense es co-
nocida en España por sus pro-
ductos para la creación de for-
mularios electrónicos, envíos de
documentos por fax y email, así
como el archivo de los mismos en
PDF. Esta familia de productos se
conoce como EZeDocs, siendo su
punto de partida el conocido
EZPrint400.
Ahora lanza el EZContentMa-
nager, cuyo objetivo es la captura
y almacenamiento de los docu-
mentos, creando un sistema de
índices que nos permitirá la ges-
tión y distribución de los mismos,
atendiendo a nuestros criterios de
búsqueda y recuperación. Todo
ello se realiza en un entorno Web
que facilita el acceso a cualquier
usuario, que cuente con las auto-
rizaciones necesarias, y creando
flujos de información que alcan-
zan necesariamente los objetivos
y destinos establecidos.
De esta forma se gestiona el ci-
clo de vida de los documentos, ori-
ginados por las diferentes aplica-
ciones, y se hacen accesibles al
personal autorizado de forma se-
gura, intuitiva y familiar.
El EZContent Manager está
diseñado pensando en las nece-
sidades de la próxima genera-
ción de software Enterprise
Content Manager (ECM) apo-
yándose en interfases de usua-
rio basados en navegadores y
adaptándose a arquitecturas
informáticas flexibles.
Al igual que ocurre con EzeDocs
y EZPrint, este producto se comer-
cializa en España por la empresa
American Top Tools, S.L. que des-
de 1986 está al servicio de la co-
munidad AS/400 distribuyendo
aplicaciones y utilidades que com-
plementan y mejoran los AS400,
iSeries y System i.
Para más información,
Telf.: 933.191.612
email: att@att.es
Si como proveedor posee alguna novedad relacionada con el entorno System i - iSeries
- AS/400 de IBM, recuerde que en esta sección dispone de un espacio gratuito para darla
a conocer a todos nuestros lectores.
Puede enviar sus notas de prensa a Ser verNEWS mediante correo electrónico
(help400@help400.com), o bien a Gran Vía Corts Catalanes, 715, Entlo 3ª 08013 -
Barcelona. Para la inclusión de fotografías o logos, agradeceríamos que las remitieran en
formato electrónico.
www.help400.es
■ LISVA Soluciones
Integradas S.L. anuncia
el Programa 2010
“Para 2010, la mayoría de las
multifuncionales e impresoras se
venderán asociadas a Soluciones
de Impresión y Gestión Documen-
tal.” LISVA, con más de 40 produc-
Una ocasión única
tos/soluciones no necesita esperar erverNEWS y System iNetwork le proponen participar en el
a 2010.
Ofrece a sus clientes la Solución
S 2008 IT Leaders Forum que tendrá lugar en Denver, Colo-
rado (EE.UU.) de los días 20 al 23 de julio, en las mágníficas insta-
que deseen totalmente GRATIS. laciones del Inverness Hotel and Conference Center.
No hay truco. Únase a los líderes en un evento diferente a cualquier otro del
El cliente, al comprar el hard- mercado, centrado en la estrategía, toma de decisiones y el valor
ware (multifuncional y/o impreso- de las TI en su negocio. Esta conferencia ejecutiva incluye semina-
ra), puede seleccionar cualquier rios en profundidad de Gatner, IBM, System iNEWS... ¡y mucho
producto entre una gran variedad: más!
Gestión Documental, Control de Para más información, incluido agenda, precios y perfil de los
Costes de Impresión, Formularios ponentes, acceda a www2.systeminetwork.com/itleadersforum/
Electrónicos, Conversión a PDF,
Impresión segura...y muchos más.
¿Cómo funciona el Progra-
ma 2010?
· El cliente, al comprar las
multifuncionales o impresoras,
indica a su proveedor habitual que
se ponga en contacto con LISVA. Common Europe Annual Congress
El cliente ya ha hablado con
Barcelona, del 17 al 21 de Mayo de 2008
LISVA y quiere un producto soft-
ware determinado. LISVA tiene
El evento de formación de Bajo Coste y Alto Valor del mundo “i”
más de 40 productos e incluso
puede desarrollar uno nuevo, si un
cliente lo solicita.
· El proveedor de equipos llega
E ste evento está organizado por usuarios para los usuarios, de
forma que se eliminan las opiniones influidas que pueden
aparecer en eventos de proveedores. También, el hecho de que sea
a un acuerdo con LISVA.
organizado por usuarios significa que el precio de la inscripción
· El cliente recibe por un lado
puede mantenerse muy bajo ya que se eliminan la mayoría de los
el hardware solicitado inicialmen-
sobrecostes generados por organizaciones comerciales.
te al proveedor y de LISVA recibe
· Enfoque: El evento de Common Europe está dedicado al i5/OS
el producto de software gratis.
principalmente en la plataforma System i. Habrá sesiones presen-
Que algo sea GRATIS resulta
tadas tanto por especialistas de IBM como por desarrolladores in-
normalmente bastante increíble y
dependientes y las habrá tanto técnicas como de gestión y direc-
suele producir desconfianza, pero
ción. También tendremos a usuarios compartiendo sus experiencias
una vez explicado el funciona-
en el mundo real. Todo ello asegura una oferta muy equilibrada en
miento del Programa 2010, el
el congreso.
100% de las empresas contactadas
se han inscrito. El Programa está • Exposición: El congreso de Common Europe ofrece una amplia
en proceso de implantación en exposición en la que los delegados podrán encontrar los produc-
Europa y Latinoamérica. tos más novedosos y sus implantaciones tecnológicas desarro-
Para más información, lladas por empresas del sector.
Telf.: 918.039.495 • Duración: El congreso de Common Europe Congress es un evento
email: Lisva@Lisva.es de 3 días, que empieza en domingo lo que significa que sólo ne-
cesita ausentarse de su oficina durante 2 días.
• Coste: Como ya se ha dicho antes, Common Europe está en una
posición privilegiada ya que, como organización sin ánimo de
lucro que es, puede ofrecer un coste de inscripción sin parangón.
Esperamos sinceramente que todos los clientes de IBM se da-
rán cuenta de que la oferta de Common Eruope es única y decidi-
rán aprovechar esta oportunidad.
Recuerde, el Congreso de Common Europe (CEC) tendrá lugar
del 17 al 21 de Mayo en el hotel AC Barcelona.
Para más información, www.comeur.org
MARZO 2008 ServerNEWS 7
 opinión
La web convierte a las empresas
en compañías de software
E
stoy convencido de que todos co-
nocemos en alguna medida el
proceso de producción del soft-
ware. Aunque formemos parte
de una de las escasas empresas que únicamente utilizan apli-
caciones hechas a medida, al tener que mantener al día las
distintas versiones de i5/OS y Windows, la mayoría de noso-
tros nos hemos acabado adaptando a la naturaleza cíclica de
las nuevas versiones de software y a la idea de que lo nuevo
ha de ser mejor que lo que ya tenemos. Pero si se está
adentrando en el mundo feliz de las aplicaciones basadas en
web diseñadas para los clientes de Internet, aunque se trate
de una simple aplicación para hacer los pedidos de sus pro-
ductos, ¿se ha dado cuenta de qué forma esa actividad está
convirtiendo a su empresa en una compañía de software de
facto?
Hasta cierto punto, cualquier empresa que desarrolle pro-
gramas a medida para sus procesos internos ya se enfrenta a
esta realidad. Cuestiones como seguir el progreso de las nue-
vas versiones, garantizar dentro de lo posible que el software
no contiene errores antes de presentárselo a los usuarios in-
ternos, arreglar problemas imprevistos y gestionar distintas
versiones de la misma aplicación no son nada nuevas en los
departamentos informáticos de las empresas.
Pero, naturalmente, lo que diferencia a las aplicaciones web
es el público al que van destinadas. En vez de ir dirigidas a
usuarios que trabajan para la misma compañía y que están
obligados por sus jefes a utilizar ese software, sea bueno o
malo, el fin de las aplicaciones web es servir a personas que
no tienen la obligación de tolerar programas malos. Esto tie-
ne un gran riesgo y hace que se tenga que poner el acento en
la creación de aplicaciones que se entiendan sin necesidad de
recibir ninguna formación adicional y que realmente hagan
todo lo que se supone que deben hacer, correctamente y des-
de la primera versión. Y eso sitúa al desarrollo de aplicacio-
nes web en la misma liga que la producción de productos de
software comerciales. Una aplicación web tiene que funcio-
nar bien porque ninguna circular del presidente de la empre-
sa puede hacer que todos los usuarios tengan que aguantar
algo que no se aguanta. Además, las aplicaciones web forman
parte de la imagen pública de la empresa, como si se estuvie-
ra vendiendo al público.
En cuanto se entra en la esfera de las aplicaciones web, no
sólo se está compitiendo con la competencia de toda la vida. En
cierto modo se está compitiendo con todos los sitios web del mundo
porque los clientes compararán, al menos de forma subconscien-
te, el suyo con los demás sitios web que hayan visto.
Enfrentarse a esta situación puede obligar a pensar siguien-
do una lógica distinta a la que estamos acostumbrados. La
8 ServerNEWS MARZO 2008
por John Ghrist
preocupación por ofrecer una GUI que sea intuitiva y atrac-
tiva pero no demasiado recargada y por asegurarse de que no
hay errores importantes ni siquiera en funciones secunda-
rias, pensando siempre por adelantado en lo que incluirá la
próxima versión, ya no es discrecional.
Los ejecutivos de las empresas de software parecen haber
nacido pensando así... y esa es la razón de que sigan a flote.
Con las aplicaciones web, los demás hemos de empezar a pen-
sar de la misma forma.
Lo único positivo es que todo el mundo, y no sólo los ejecu-
tivos de las empresas de software, está pasando por los mis-
mos apuros. ¿Y cómo están afrontando este nuevo reto sus
homólogos de otras empresas? No muy bien, por lo que pare-
ce. O al menos, esa es la situación que revela un informe re-
ciente presentado por Interwoven, un proveedor de solucio-
nes de gestión de contenidos, que puede consultarse en
www.interwoven.com/capsurvey.
Interwoven encuestó a 130 profesionales informáticos de
todo el mundo. En resumen, los resultados demuestran que
el 77% de los encuestados dicen que los esfuerzos de desarro-
llo se dedican a proyectos hechos a medida, más de la mitad
piensan que el número de proyectos realizados a medida re-
lacionados con la web se doblarán el año que viene y el 71%
está distribuyendo actualizaciones mediante procesos manua-
les como FTP, scripts de generación, el envío por correo de
discos compactos o la copia de archivos. El 73% cree que sólo
pueden completar una o dos nuevas aplicaciones web cada
mes y el 60% se siente presionado para crear versiones con
más frecuencia. Asimismo, el 54% afirma que tienen que ha-
cer diez “correcciones urgentes” cada mes.
¿Y en nuestro entorno?
El desarrollo de aplicaciones web en general todavía no avanza
a un ritmo tan frenético en la mayoría de empresas que tra-
bajan con System i, pero nuestra plataforma no se libra de
esa necesidad. Cuando surge, la intensidad es incluso mayor
que las presiones que ya acompañan al desarrollo interno de
software a medida. Las cuestiones planteadas por este infor-
me deberían hacer reflexionar a los directores de desarrollo
de software que ven la necesidad de que su empresa tenga
una presencia más dinámica en la Red. Lo que parece claro
es que en el año 2008 va a ser inevitable prestar más aten-
ción a los procedimientos para crear aplicaciones web. E in-
tentar conseguir algo de inspiración en base a la experiencia
de los proveedores de productos genéricos de software no es
una idea descabellada. ■
John Ghrist es redactor de la sección de productos de System iNEWS
www.help400.es
www.help400.es MARZO 2008 ServerNEWS 9
Recopilación y documentación d
Descubra cómo conseguir requisitos de los usuarios claros, concisos, fáciles d
por Russ Bartlett
M
uchos de nosotros conocemos una viñeta en que
se ve una habitación llena de programadores
trabajando en sus terminales. El encargado de-
clara mientras sale de la habitación: “Voy a
averiguar cuáles son los requisitos de los usua-
rios... vosotros empezad a programar”. En la década de 1960
y parte de la de 1970, este “método” solía ser el más habitual.
Pero afortunadamente hoy en día esta técnica sólo se usa en
unos pocos departamentos de informática.
Lo que sigue siendo habitual, es tratar la recopilación, do-
cumentación y análisis de los requisitos de los usuarios de
manera informal. Teniendo en cuenta que los requisitos de
los usuarios son el propósito de la iniciativa –el proyecto–
deberíamos prestar especial atención a la recopilación, docu-
mentación, análisis y gestión de aquéllos. La principal razón
por la que fracasa un proyecto es la mala definición de los
requisitos de los usuarios. Para asegurarnos de que nuestros
proyectos tienen éxito, en este artículo veremos cómo usar
algunos métodos existentes para obtener requisitos claros,
concisos, fáciles de cuantificar y comprobar.
Salirse de la rutina
En este negocio, nos cuesta salirnos de la rutina y, para la
mayoría de nosotros, ésta consiste probablemente en crear
diseños técnicos y escribir código. Al fin y al cabo, lo realmen-
te interesante es el diseño y programación de la base de da-
tos... es lo que mola, ¿no? Fuera de este ámbito, nos encontra-
mos algo menos cómodos, así que solemos prestar menos
atención y hacemos las tareas apresuradamente. Para ilus-
trar esta idea, estableceré una analogía: la de encargar la
construcción de una casa nueva.
En esta situación hipotética, tenemos por un lado al con-
tratista y por el otro al futuro dueño de la casa. El contratis-
ta programa una reunión con el comprador para que éste le
plantee los requisitos para construir la casa. El contratista,
libreta en ristre, aguanta toda la sesión de recopilación de
requisitos. El comprador piensa que está bien preparado y
ha hecho una lista de algunos de los criterios básicos que ha
de satisfacer la casa pero no está tan seguro de otros. Mien-
tras negocia con el comprador, el contratista usa términos
técnicos confusos y pide al comprador que confirme todos los
requisitos antes de continuar. El comprador siente que la toma
de decisiones es demasiado precipitada y no es capaz de
proporcionar todos los detalles necesarios, pero da por su-
puesto que el contratista ha hecho esto muchas veces antes y
que todo saldrá bien.
Si nos imaginamos cuál será el resultado de este caso hipo-
tético, todos llegaremos a la conclusión de que lo más probable
10 ServerNEWS MARZO 2008
es que el comprador no conseguirá la casa de sus sueños. La
verdad es que nadie se construiría una casa de esta manera
y, sin embargo, en el mundo de la informática he visto desa-
rrollar sistemas enteros de forma parecida. A menudo, espe-
ramos que los usuarios tengan claros todos los requisitos antes
de crear el sistema. Pero lo normal es que no los conozcan
todos al principio del ciclo vital del proyecto y, en ocasiones,
puede que esto sea así hasta que el sistema esté en funciona-
miento. La complicación aumenta en un modelo de desarro-
llo por etapas o en cascada ya que en él la fase de obtención
de requisitos aparece como lineal, aunque no es un proceso
estrictamente lineal. Variaciones posteriores de modelos de
proyectos, como los métodos ágiles, reconocen este hecho y
tratan los proyectos, en particular la recopilación de requisi-
tos, como un proceso iterativo.
Obtención de requisitos de calidad
Ahora vamos a explorar algunas formas de obtener requisi-
tos de mayor calidad. Nos centraremos en el método tradicio-
nal usado para la fase de obtención de requisitos y luego ve-
remos cómo se puede mejorar el proceso gracias a la definición
de prototipos. Pero, antes que nada, ¿qué es exactamente un
requisito de software?
El estándar 612.12.1990 del IEEE describe un requisito de
software como:
• una condición o función que necesita un usuario para resol-
ver un problema o lograr un objetivo
• una condición o función que debe satisfacer o procesar un
sistema o el componente de un sistema para cumplir un
contrato o ser conforme a un estándar, especificación u otro
documento impuesto formalmente
En otras palabras, un requisito debe definir lo que el siste-
ma ha de hacer sin explicar cómo se ha de hacer. Este es un
error habitual. Introducir el “cómo” en este momento limita
las opciones. Los requisitos no deben introducirse hasta la
fase de especificación de los requisitos del sistema (más ade-
lante explicaré más detalles sobre el particular).
Antes de ver cómo documentar los requisitos, permítame
definir algunos términos con los que puede que no esté fami-
liarizado. Estos términos constituyen las etapas principales
del diseño de los requisitos de software.
Adquisición de los requisitos. Define el proceso gracias
al cual las partes interesadas proporcionan la información
necesaria para desarrollar y documentar los requisitos. En
pocas palabras, es el proceso por el que se averiguan y re-
únen los requisitos. Esto requiere que el analista de sistemas
www.help400.es
 de requisitos
s de cuantificar y de probar

no simplemente anote pasivamente los requisitos, sino que puede hacerse de forma gradual ordenada-
debe profundizar para entender detalladamente los proble- mente y de forma interativa. Esto no sólo
mas y necesidades de los usuarios. Los requisitos se clasifi- se aplica a la “fase” de especificación de
can a grandes rasgos en dos tipos: funcionales y no funciona- requisitos de los sistemas del proyec-
les (se describen en el apartado siguiente). Además, como parte to, sino también a todo el proyecto en
de este proceso, también se define el alcance del sistema y los su conjunto.
objetivos del proyecto. Todo este proceso, así como las fa-
ses posteriores, puede ser iterativo a lo largo de todo el
ciclo vital del proyecto. Durante esta fase, nuestro ob-
jetivo es capturar y anotar con precisión los requisi-
tos principales.
Análisis de los requisitos. Aquí es donde clasifi-
camos y creamos modelos de los requisitos usando
varias técnicas de creación de modelos, como por ejem-
plo, casos de uso, lenguajes unificados de creación de
modelos (UML) o diagramas de flujo de datos. Además,
los modelos son la base de nuestro diseño arquitectónico.
También es la hora de las negociaciones entre las partes
interesadas y de hacer concesiones. Básicamente, ne-
cesitamos priorizar los requisitos y entender cuá-
les son obligatorios y cuáles no. En esta etapa
podemos eliminar algunos requisitos. La razón
es sencilla: puede que no tengamos tiempo, recur-
sos o presupuesto suficiente para satisfacer todos
los requisitos de los interesados. Los requisitos se
intercambian y canjean en función de las restriccio-
nes del proyecto. De hecho, los usuarios con más expe-
riencia suelen pedir más cosas de las que realmente ne-
cesitan anticipándose a este proceso de negociación. En la
práctica, el análisis de los requisitos suele conducir a la ad-
quisición de más requisitos conforme se conocen más deta-
lles. Si comparamos este método con otros en los que se redu-
ce la planificación del proyecto, comprenderemos porqué en
éste se acaba sacrificando la calidad para ajustarse a la fe-
cha de entrega.
Especificación de los requisitos. Aquí es donde genera-
mos las especificaciones del software creando documentos que
se usarán para crear las especificaciones del sistema (ense-
guida veremos cómo hacerlo).
Validación de los requisitos. Aquí es donde verificamos y
validamos los requisitos llevando a cabo revisiones o definiendo
prototipos. El método que utilizamos se usará en la prueba de
aceptación del usuario. Nuestro objetivo es asegurarnos de la
exactitud con que se han llevado aplicado los requisitos de
los usuarios, uno por uno o en su conjunto.
Aunque he clasificado los pasos anteriores con
fines informativos, en realidad, la adquisición,
análisis, especificación y validación de los requisitos

www.help400.es MARZO
MARZO 2008 ServerNEWS 11
2008 ServerNEWS 11
■ EN PORTADA
Ahora vamos a ver con más detalle cómo se realiza la espe-
cificación de los requisitos.
Requisitos funcionales y no funcionales
Por regla general, se considera que un requisito es o bien
funcional o bien no funcional. Los requisitos funcionales de-
finen lo que el sistema debe hacer desde el punto de vista del
usuario para cumplir los objetivos que se le exigen. Los re-
quisitos no funcionales pueden subclasificarse en restriccio-
nes y cualidades. Las restricciones imponen límites al diseño
o a las funciones. Las cualidades son propiedades o caracte-
rísticas que interesan a los usuarios (como la facilidad de
uso, la fiabilidad, la seguridad, la escalabilidad y la
configurabilidad) y pueden contribuir a que el sistema resul-
te satisfactorio globalmente.
Un requisito debe ser:
• Conciso: debe definirse en términos claros y concisos.
• Correcto: debe describir con precisión cuáles son las cuali-
dades previstas del sistema.
• Inequívoco: debe definirse en términos claros, comprensibles
(sólo debe haber una interpretación del propósito)
• Verificable: debe ser verificable desde el punto de vista de
la comprobabilidad (por ejemplo, en vez de explicar que el
sistema debe permitir recuperar rápidamente la informa-
ción del catálogo, un requisito mejor afirmaría que el siste-
ma debe permitir la recuperación de información del catálogo
en dos segundos, lo que es comprobable desde el punto de vis-
ta de la prueba del sistema y de la de aceptación del usuario).
Los requisitos también deben ser factibles desde un punto
de vista técnico y comercial.
Una vez reunidos todos los requisitos, hemos de realizar
más comprobaciones sobre el grupo de requisitos en su con-
junto. Este grupo debe satisfacer “las tres Ces”:
• Conciso. Los requisitos en su totalidad deben describir de
forma concisa el sistema que se va a construir. Si hay de-
masiados requisitos, se pueden introducir errores e in-
coherencias.
• Completo. En su conjunto, los requisitos deben describir de
forma adecuada todo el sistema que se va a construir.
• Coherente. Los requisitos individuales deben ser compati-
bles con los requisitos en su conjunto. No debe haber in-
coherencias entre requisitos. Si se diera el caso, revise y
resuelva las discrepancias con los usuarios.
Ahora vamos a ver cómo documentar los requisitos de los
usuarios para eliminar cualquier ambigüedad.
Documentación de los requisitos
En primer lugar, redáctelos en estilo afirmativo, usando
términos como “debe” o “ha de”. Por ejemplo, el sistema debe
ser capaz de responder con detalles de la cuenta en dos se-
gundos a todas las peticiones de los usuarios. Que el tiempo
de respuesta de dos segundos sea factible es otra cuestión y
12 ServerNEWS MARZO 2008
FIGURA 1
Ejemplo de esbozo de documentación estándar del IEEE
1. Introducción
1.1. Finalidad: ofrece un resumen del objetivo del documen-
to.
1.2. Alcance: describe el producto que va a desarrollarse y lo
que está dentro y fuera de su alcance. Aquí se puede
usar un diagrama de contexto (diagrama de flujo de
datos de nivel superior para mostrar las relaciones con
otras entidades y los límites del sistema).
1.3. Definiciones, acrónimos y abreviaciones: describe todos
los términos usados en el documento.
1.4. Referencias: proporciona referencias a otros documen-
tos que usados para compilar este documento.
1.5. Visiones generales: ofrece una visión general del domi-
nio del problema.
2. Descripción general
2.1. Perspectiva del producto: describe de qué forma el
producto que va a desarrollarse se relaciona con otros
productos existentes, si forma parte de un sistema
mayor o si será autónomo.
2.2. Funciones del producto: describe en términos funciona-
les qué hará el producto que se va a desarrollar
2.3. Características del usuario: describe las características
especiales del sistema que pueden requerir formación o
experiencia especiales por parte de los usuarios
2.4. Restricciones generales: enumera las restricciones que
influirán en el diseño. Éstas pueden ser normativas
gubernamentales, obligaciones relativas a la seguridad, el
hardware, etcétera.
2.5. Suposiciones y dependencias: describe suposiciones,
como por ejemplo el crecimiento previsto y las posibili-
dades de que la solución satisfaga las necesidades de la
empresa, o si la solución dependerá de que existan
otros sistemas y que estén en marcha.
3. Requisitos concretos: da detalles de todos los requisitos
y proporciona documentación de soporte, como casos
de uso o diagramas de flujo de datos.
obviamente dependerá de cosas como el hardware, el soft-
ware y el número de cuentas al que se acceda durante un
periodo de tiempo dado. Además, el término “detalles de la
cuenta” debe entenderse perfectamente (por ejemplo, el nom-
bre del cliente, el saldo de la cuenta y la fecha de la última
compra). Un análisis posterior puede desvelar requisitos adi-
cionales, a los que se denomina “requisitos derivados” porque
dependen de un requisito principal.
Asimismo, evite el uso de la conjunción “o” al definir un
requisito, ya que puede conducir a interpretaciones erróneas.
Por ejemplo, pensemos en esta frase: La consulta de la cuen-
ta del cliente debe mostrar detalles del saldo o el resumen de
la cuenta. Este tipo de frases dejan abierta su interpretación
y pueden acabar convertidas en funciones incorrectas del sis-
tema. Un diseñador puede creer que esta frase significa que
lo que hay que hacer es mostrar o bien lo uno o bien lo otro,
pero si tenemos información tanto del saldo como del resumen
www.help400.es
 Requisitos
Comprobación Documentación
del prototipo de los requisitos
Diseño del
prototipo
Creación del
prototipo
FIGURA 2
Utilización de prototipos para refinar los requisitos
de la cuenta del cliente, ¿debemos mostrar ambos datos o sólo
el que escojamos?
Otro problema habitual es que a veces el redactor de los
requisitos hace su propia interpretación de éstos e introduce
una restricción innecesaria. Supongamos, por ejemplo, el re-
quisito siguiente: El sistema debe almacenar detalles del
maestro de artículos en un archivo de la base de datos DB2
UDB para poder recuperar rápidamente información del
maestro de productos. Al introducir esta restricción innece-
saria limitamos nuestras opciones de diseño posteriores. El
requisito real es la recuperación rápida de información del
producto y, por si aún no lo ha notado, esto nos lleva al si-
guiente problema: la verificabilidad.
Evite los términos imprecisos que son difíciles de verificar.
¿Qué se entiende por “recuperación rápida”? ¿Basta con dos
minutos o debe realizarse en una fracción de segundo? Otros
términos del mismo género son “robusto”, “ergonómico”, “fá-
cil de usar”, “intuitivo”, “alta capacidad”, “bajo mantenimien-
to” y “flexible”. Todos ellos pueden interpretarse libremente
y deben cambiarse por requisitos cuantitativos. Por ejemplo,
si el requisito dice que el sistema debe proporcionar una fun-
ción de consulta flexible, será necesario un análisis posterior.
El usuario puede querer decir que ha de poder ejecutar la
función de consulta existente desde la función de manteni-
miento del maestro de artículos o algo mucho más complejo.
Resista la tentación de escribir los requisitos de otra forma
que no sea con una o dos frases sencillas. Y para evitar confu-
siones, no use expresiones como “de lo contrario” o “si no”.
Después de haber reunido los requisitos de los usuarios,
tendremos que documentarlos. Mi recomendación es que adop-
te el estándar 930-1998 del IEEE. El IEEE (ieee.org) es el
principal organismo del sector de la informática encargado
de establecer y mantener estándares. En la Figura 1 se
muestra un esbozo basado en un antiguo estándar del IEEE
que al mismo tiempo es un ejemplo de contenido. El nivel y
profundidad de la documentación generada depende del sis-
tema que se va a desarrollar.
Definición de prototipos
Ningún artículo que trate sobre los requisitos estaría com-
pleto sin incluir los prototipos. Pero antes que nada, un
www.help400.es
consejo: su proyecto seguirá necesitando pasar por una etapa
de definición de requisitos. Debe contemplar la definición de
prototipos como un medio de refinar los requisitos de los usua-
rios. En la Figura 2 se ilustra el modelo del ciclo vital cuan-
do se utilizan prototipos.
A menudo, la definición de prototipos se asocia al uso de
lenguajes 4GL. Estos lenguajes fueron bastante populares
en la década de 1980, aunque en la década siguiente dismi-
nuyó el interés por ellos. Algunas organizaciones han tenido
mucho éxito usando lenguajes 4GL para desarrollar aplica-
ciones mientras que a otras no les ha sido tan útil. No obs-
tante, en la actualidad, la herramienta de definición de pro-
totipos elegida puede ser una herramienta de desarrollo
rápido de aplicaciones (RAD) o, en algunos casos, algo tan
simple como un paquete de Post-It o un rotafolio (considera-
das soluciones de “bajo presupuesto”).
En mi caso he tenido mucho éxito usando prototipos; los
usuarios pueden entender los prototipos e interactuar con
ellos mejor que con otros métodos más convencionales, como
las especificaciones funcionales o las especificaciones de re-
quisitos del sistema. La definición de prototipos también fun-
ciona muy bien si se necesita poner a prueba un concepto o
capacidad. Además, cuando los usuarios no tienen claros los
requisitos, utilizar un modelo del ciclo vital en forma de pro-
totipo es una buena estrategia para ayudarles a aclarar sus
necesidades.
En algunos casos, he realizado proyectos en los que la he-
rramienta elegida para crear el prototipo era una herramienta
de PC. En un caso concreto, mi cliente no tenía herramientas
de desarrollo rápido de aplicaciones para el System i pero
tenía conocimientos de FoxPro. Usé el prototipo para probar
una función conceptual y, aunque la aplicación final iba a
estar basada en el System i, acordamos que conceptualmente
podíamos construir un modelo de trabajo. Tenga presente que
cuando se crea un modelo complejo debe determinarse si hay
que adornar el prototipo y entregarlo como producto final o bien
si hay que considerarlo como algo desechable, como era el caso
del prototipo desarrollado en FoxPro. Tenga en cuenta que am-
bas estrategias tienen consecuencias. Muchas veces, cuando a
los usuarios se les presenta un prototipo, presuponen que es el
producto acabado, aunque se les haya dicho lo contrario.
Adaptación a los cambios
A lo largo de esta última década ha ido aumentando el inte-
rés por huir del ubicuo modelo del proceso «en cascada». En
la actualidad, los requisitos de las empresas y de los produc-
tos cambian a un ritmo cada vez mayor y, por ende, también
lo hacen los requisitos de los usuarios. Los informáticos he-
mos de reconocer este hecho y adaptarnos en consecuencia.
La informática sigue evolucionando por lo que nosotros tam-
bién debemos hacerlo. ■
Russ Bartlett trabaja desde hace 39 años en el mundo de la informática.
Posee un certificado CSDP del IEEE y tiene experiencia en todos los campos del
desarrollo de sistemas. Ha sido el responsable de implantar sistemas en
muchas organizaciones, incluyendo soluciones ERP en empresas de la lista
Fortune 500.
MARZO 2008 ServerNEWS 13
Cómo decidirse por una solución
para el desarrollo de aplicaciones
por Chris Maxcer

E
l verano pasado asistí a una lluvia de ideas de aprendizaje y exigen invertir en una metodología para el
desarrollo de aplicaciones. En el mundo del System i estas
de un profesional del entorno sobre el de-
soluciones también suelen ser de distintos tipos. Por ejemplo,
sarrollo de aplicaciones en el mundo actual muchos proveedores de soluciones tienen más de un paquete
de los System i. No recuerdo muy bien cuál de desarrollo de aplicaciones dependiendo de las necesidades
concretas de cada empresa, de modo que las etiquetas pue-
era el contexto, pero me quedé con una de sus ideas:
den ser doblemente complicadas. A efectos prácticos las lla-
“Me pregunto si, para equipos de desarrollo peque- maré soluciones para el desarrollo de aplicaciones.
ños, no sería mejor adquirir una herramienta de
desarrollo de aplicaciones en vez de intentar apren- De vuelta al asunto que nos ocupa
Regresando a aquella conversación, mi contertulio compar-
der nuevos lenguajes y técnicas”. tía su experiencia sobre organizaciones que han podido asu-
Se refería a usar juegos de herramientas que generan códi- mir más trabajo de desarrollo al confiar en una herramienta
go en lugar de herramientas que básicamente mejoran la efi- que les ha servido de base para la modernización de sus apli-
cacia de la programación manual. El término de la vieja caciones, por así decirlo, con la importante ventaja adicional
escuela es CASE, siglas de Computer-Aided Software Engi- de mejorar la productividad.
neering o Ingeniería del software asistida por No obstante, la premisa original del comentario que recuer-
ordenador y aunque el nombre es lo bastante do del verano pasado, se basaba más en la idea de que algu-
genérico como para seguir teniendo impor- nas organizaciones que básicamente utilizan plataformas
tancia hoy en día, no lo había oído desde System i, emplean a programadores de RPG que es poco pro-
bable que progresen en sus conocimien-
tos. En un océano de cambios, ellos sim-
Los programadores pueden invertir plemente se mantienen a flote pero
en formación para adquirir nuevos acabarán cansándose. Con suerte, en
ese momento pasará el barco de su ju-
conocimientos o bien adquirir una bilación; pero lo más probable es que
solución completa y robusta para el se vean nadando para huir de los tibu-
rones o en un bar de la playa tomando
desarrollo de aplicaciones. margaritas, situaciones que pueden
obligarles a actuar para usar lengua-
hacía mucho tiempo. Existen herra- jes y técnicas de programación más modernas o más conoci-
mientas parecidas en la categoría das con el fin de lograr su objetivo, bien sea disfrutar de las
RAD (Rapid Application Development). margaritas o escapar de los tiburones.
También se trata de un término global, pero De un modo u otro, esos programadores flotantes pueden
no tiene las connotaciones negativas asocia- invertir en formación para adquirir nuevos conocimientos o
das con las viejas herramientas CASE. No obs- bien adquirir una solución completa y robusta para el desa-
tante, RAD incluye una filosofía, dependiendo de lo rrollo de aplicaciones. Las dos opciones tienen ventajas e in-
riguroso que se quiera ser, del desarrollo iterativo basado en convenientes, al menos dos escuelas distintas de pensamien-
prototipos. Los actuales entornos de desarrollo integrado to y están asociadas a la desagradable idea de que si los
(IDE) conforman otro juego de herramientas, éste más próxi- programadores no hacen nada, con suerte acabarán perdién-
mo al espíritu de la programación manual y generalmente dose las margaritas y, en el peor de los casos, desmembrados
acompañado de un control más directo sobre la propia crea- por los tiburones.
ción del código.
No quiero empantanarme en una infructuosa exploración Los cimientos de la resistencia
de términos y etiquetas. Lo único que pretendo es hablar de Algunos desarrolladores del System i han empezado a poner
soluciones comerciales, que tienen una determinada curva los cimientos de la resistencia y profesionalmente suelen

14 ServerNEWS MARZO 2008 www.help400.es

www.help400.es MARZO 2008 ServerNEWS 15
■ EN PORTADA
proceder de dos campos: los que se han criado con RPG y su
integración con el AS/400, y los que conocen diversas técni-
cas de programación, pueden utilizar varios lenguajes y cons-
tantemente están aprendiendo cosas nuevas. Todos ellos sue-
len creer que programarlo todo a mano es mejor porque se
crea un código optimizado que es más fácil de mantener.
Además, no quieren que una solución para el desarrollo de
aplicaciones ponga a su compañía entre la espada y la pared.
También puede que les preocupe su currículo y que se pre-
gunten si el uso de una solución para el desarrollo de apli-
caciones limitará sus posibilidades de conseguir un puesto
de trabajo.
En el mundo del System i, también hay una facción radical
partidaria de IBM: los programadores que sólo utilizan he-
rramientas y soluciones de IBM. Si no es de IBM, ni siquiera
cabe plantearse la posibilidad. En este mismo sentido, algu-
nos programadores y responsables se ven entorpecidos por
los presupuestos y, a veces, por las actitudes: jamás compra-
rán una herramienta o solución si no es gratis o si IBM no la
incluye de serie.
Tantas tecnologías
El número de lenguajes y métodos posibles que pueden usar-
se para lograr el resultado buscado puede ser apabullante.
RPG IV, Java, JavaScript, .NET, PHP, XML, CGIDEV2, HTML,
CSS, Python, Ruby y Groovy son sólo unas cuantas posibili-
dades. ¿Qué sucede si una empresa invierte durante meses
en formación para acabar descubriendo que la solución que
se está estudiando no es adecuada para la organización? ¿En
cuántos departamentos informáticos en los que se usa RPG
se ha intentado dar el salto a Java? ¿En cuántos no lo han
conseguido? Y, puede que lo más importante, ¿En cuántos de-
partamentos que trabajan con RPG han tenido noticias de
otros departamentos que hayan intentado migrar a Java, se
han enterado de su fracaso y han acabado abandonando las
nuevas tácticas?
Los siete pasos hacia un futuro sin salida
El mayor riesgo está en la posibilidad de volverse obsoleto
debido a la inacción. Así es como el letargo se está instalando
en algunas organizaciones:
1. Las aplicaciones del negocio (ERP y las desarrolladas in-
ternamente) se ejecutan en el System i.
2. Los programadores y responsables del System i no ponen
al día sus conocimientos y adquieren herramientas de ter-
ceros para desarrollar componentes basados en GUI y apli-
caciones nuevas de apariencia moderna (portales, BI, B2B
o incluso aplicaciones concretas, clientes enriquecidos u
otras) para satisfacer necesidades básicas de la empresa.
3. Los directivos ven que el grupo de desarrolladores del
System i es el responsable de las aplicaciones de pantalla
verdes y poco más.
4. La dirección cree que ni el System i ni el equipo de desa-
rrollo del “i” son capaces de desenvolverse bien con aplica-
ciones GUI modernas.
16 ServerNEWS MARZO 2008
5. Las aplicaciones basadas en Windows parecen bastante
baratas y los partidarios de Windows del grupo están pre-
parados y deseando ampliar su nivel de responsabilidad...
o puede que la empresa subcontrate el trabajo que hay que
hacer en Windows.
6. En algún momento, la organización acaba escindida entre
el grupo del System i y, por ejemplo, el grupo .NET.
7. Los profesionales del System i se dedican a dar soporte y
mantener el código heredado mientras que otros desarro-
lladores de aplicaciones se encargan de crear las nuevas
aplicaciones.
En este contexto, la inacción de los programadores y de los
responsables del System i lleva a quedarse atrapado en el
código existente, situación de la que es difícil salir. Esto es
malo para los amantes del System i y horrible para el
ecosistema de la plataforma.
Capacidad de comercialización
Sí, el mundo que nos rodea es implacable. Dada la enorme
cantidad de código escrito en RPG que existe hoy en día, la
división System i de IBM sin duda podría desaparecer de re-
pente y aún así muchos expertos en RPG todavía podría vivir
bien de RPG hasta su jubilación, aunque tuvieran que hacerse
consultores y pasarse la vida viajando por todo el mundo.
Seguro que algunos se sentirían impelidos hacia soluciones
basadas en la conectividad y SOA. ¿Cuál es la respuesta?
¿Aprender a usar una solución centrada en una herramienta
concreta limita a los programadores?
No. Mientras los programadores conozcan sus puntos fuer-
tes, las claves para tener un trabajo ahora y en el futuro,
progresarán. “Su auténtica habilidad es que son capaces de
equiparar la tecnología con las necesidades de la empresa”,
señala Greg Best, vicepresidente de ventas de Lansa. “Los
más veteranos pueden resolver problemas de la empresa y
tienen valor en el mercado, pero no porque conozcan Lansa o
una herramienta. Conocen el negocio y pueden aplicar la tec-
nología al problema”.
De forma parecida, los proveedores conocen casos de pro-
gramadores o responsables que utilizaban ciertas herra-
mientas en una empresa, cambiaron de trabajo, fueron a
una organización nueva equipada con System i y, con el
tiempo, impusieron las herramientas que habían utilizan-
do antes.
Imagine cómo es esta persona. En 1998 aprende HTML y
se convierte en un experto programándolo a mano. Usando
tablas y marcos, se convierte en una impresionante fábrica
de crear páginas web en solitario capaz de utilizar un juego
limitado de herramientas para crear páginas extraordina-
rias en las que publicar un montón de información de la em-
presa. Entonces, otros desarrolladores web empiezan a usar
JavaScript, XML y bases de datos para crear páginas web
dinámicas. En lugar de aprender esas nuevas tecnologías –o
incluso las herramientas que permiten automatizar la mayo-
ría de las tareas de programación– se atrinchera diciendo
que “Soy un programador de HTML. Yo no utilizo JavaScript.”
www.help400.es
¿Se imagina lo que esta persona está haciendo en el mundo
Web 2.0?
Curvas de aprendizaje
La mayoría de programadores dan gran importancia a las
técnicas de programación manuales y a comprender realmen-
te lo que hace el código y cómo se consigue un determinado
resultado. El problema es que solamente unos pocos pueden
seguir el ritmo de la tecnología. Y no sólo se trata de los len-
guajes de programación; también están los servidores de apli-
caciones, las bases de datos y las estrategias arquitectónicas
en su conjunto.
“La gran ventaja [de las soluciones para el desarrollo de
aplicaciones] es que además de proporcionar la estrategia de
programación, también ofrecen metodologías arquitectónicas”,
observa Don Denoncourt, redactor técnico de System iNEWS
y consultor de CAS Severn, Inc. “Sin esto, además de escoger
RPG, Java, PHP, etcétera, tendría que seleccionar una arqui-
tectura y un juego de herramientas de desarrollo, y en el de-
partamento puede que no tengan ni tiempo ni conocimientos
para hacerlo”.
En general, la curva de aprendizaje para ser eficaz con una
solución para el desarrollo de aplicaciones siempre será más
corta que averiguar cómo hacerlo a mano.
Duncan Kenzie, director técnico de BCD, va al grano: “Puede
esperarse que los desarrolladores, si tienen experiencia, se
pongan al día en dos semanas. Si no tienen tanta experien-
cia, les llevará dos meses”. El promedio, según Kenzie –al
menos para las herramientas de BCD– es de un mes.
Otros proveedores de soluciones para el desarrollo de apli-
caciones señalan curvas de aprendizaje similares, aunque si-
guen variando mucho dependiendo de la herramienta, la ex-
periencia del programador y el interés que tenga en aprender,
y la complejidad de las aplicaciones que se van a crear.
Las ventajas
Cada solución para el desarrollo de aplicaciones tiene distin-
tas ventajas y desventajas, en función de lo que quiera conse-
guir el grupo de desarrollo del System i. Algunas soluciones
crean código en Java y otras en RPG o PHP o una combina-
ción de CSS, JavaScript, HTML y XML. Las opciones varían
y las soluciones permiten que los desarrolladores trabajen
íntimamente con el código u ocultarlo por completo.
“Lo que todas estas herramientas han hecho es reunir un
buen puñado de los problemas más habituales con que nos
encontramos a lo largo del proceso de desarrollo de una apli-
cación y encapsularlos en un nivel más alto para evitarnos
hacer el trabajo pesado y repetitivo”, explica Kenzie.
La ventaja tradicional de las soluciones para el desarrollo
de aplicaciones es la mejora de la productividad. Las empre-
sas que inician grandes proyectos suelen valorar el uso de
herramientas para ayudarlas a terminar antes el trabajo que
haciéndolo a mano, en cuyo caso, la recuperación de la inver-
sión puede calcularse en función del número de desarrolla-
dores y el tiempo previsto para finalizar el trabajo manual.
Éste sigue siendo un factor a tener en cuenta hoy en día. Un
www.help400.es
ejemplo es mrc-Productivity Series, que crea aplicaciones web
basadas en Java controladas por los datos sin necesidad de
escribir código. De cualquier modo, aparte de la decisión bá-
sica sobre el código, mrc ofrece una mejora en la productivi-
dad de un orden de magnitud en comparación con la progra-
mación manual.
Si los planes de desarrollo de una empresa van con retraso
y sus posibilidades de contratar a más programadores para
acabar antes el trabajo son escasas, adquirir una herramien-
ta para aumentar la productividad permite cambiar las re-
glas del juego. La empresa pasará de no tener aplicaciones a
tener alguna aplicación.
“Estamos hablando de un incremento de la productividad
de aproximadamente un orden de magnitud”, apunta Joe
Stangarone, presidente de mrc. “Cuando se reduce el coste de
desarrollar aplicaciones al reducir el tiempo necesario, la de-
manda de aplicaciones crece casi exponencialmente”.
¿Más demanda? Eso es lo último que necesita su equipo de
desarrollo, ¿verdad? Pues no. Una mayor demanda combina-
da con un buen control que garantice que las aplicaciones
aportan valor a la empresa, dará como resultado una organi-
zación de desarrolladores que beneficiará a la compañía. Na-
turalmente, la gente que disfruta manteniendo aplicaciones
durante todo el día, alucinará con las soluciones para el de-
sarrollo de aplicaciones.
Reductores de complejidad
“Muchos de los programadores que empezaron su oficio apren-
diendo RPG en una plataforma que ya disponía de base de
datos, lo que significa que aprendieron con una buena base
sobre la que crear sus aplicaciones, ahora se
encuentran en este mundo web, en el que
de repente los datos provienen de dis-
tintas bases de datos y no tratan con
un ordenador sino con una red”,
comenta Stangarone.
“Se trata de un mun-
do completamente
distinto, pero esas
personas saben cómo
desarrollar aplicaciones
y pueden elegir entre
tomarse un par de
años para aprender
Java o PHP o hacer lo
que realmente se les da
bien con algo como m-
Power y desarrollar cosas
diez veces más deprisa de lo
que tardaría alguien que lo
esté haciendo [a mano] con Java
o PHP”, dice.
Best, de Lansa, señala que
una de las principales ven-
tajas de una buena solu-
ción para el desarrollo
MARZO
MARZO 2008 ServerNEWS 17
2008 ServerNEWS 17
■ EN PORTADA
de aplicaciones es que protege a los desarrolladores no sólo
del mundanal y repetitivo proceso de programación, sino tam-
bién de las conexiones subyacentes y de las actualizaciones y
estándares tecnológicos nuevos.
“Intentamos simplificar las cosas de modo que nosotros nos
encargamos de las cuestiones relativas a la tecnologíay el pro-
gramador se preocupa de los problemas relacionados con la
empresa”, afirma Best. Una buena solución para el desarrollo
de aplicaciones, apostilla Best, puede convertirse en un “se-
guro tecnológico” para la organización.
¿Estándares mejores?
Resulta que no existe una buena correlación entre el número
de desarrolladores de una organización y el número adecuado
para la venta de una solución para el desarrollo de aplicacio-
nes eficaz. Aunque el promedio de desarrolladores activos en
organizaciones basadas en System i parece ser de tres, cuatro
o cinco, los proveedores de soluciones para desarrollar aplica-
ciones del mundo del System i fácilmente pueden tener clien-
tes que cuentan con un solo desarrollador o con varias doce-
nas.
Si se dispone de un cierto número de desarrolladores, una
solución para el desarrollo de aplicaciones tiene ventajas adi-
cionales.
“Una de las cosas que ofrecen las aplicaciones generadas es
la coherencia a la hora de implantar y reforzar estándares de
programación en la organización”, menciona Stangarone de
mrc. Programando a mano, con cinco programadores, se ten-
drá cinco implantaciones ligeramente distintas del estándar,
declara. “Con un generador de código, los estándares se im-
plantarán exactamente de la misma forma cada vez y se aca-
bará teniendo un código más estándar”, explica.
Código ilegible
Entre quienes evitan las soluciones para el desarrollo de apli-
caciones, están los que se preocupan por la legibilidad del có-
digo. Sin duda, puede que funcione, pero ¿en el futuro será
posible acceder a ese código para hacer cambios o arreglar
problemas? Además, si sólo puede realizarse el mantenimien-
to mediante la solución, ¿eso no quiere decir que el proveedor
tiene la sartén por el mango?
Sí y no. El mantenimiento, sin duda, sería más fácil con las
herramientas de cualquier proveedor que sin ellas. La mayo-
ría de los proveedores que existen desde al menos hace media
docena de años son muy conscientes del rechazo que provoca
este asunto en muchos compradores potenciales: los clientes
quiere estar seguros de que su código sobrevivirá, con o sin el
proveedor, durante muchos años.
“Lo que hacemos nosotros es utilizar código RPG estándar
–tan abierto como nos es posible– y enseñar a nuestros clien-
tes cómo se genera el código para que no se sientan atrapados
y conserven el control absoluto”, explica Alex Roytman, direc-
tor técnico de Profound Logic Software. La solución de la com-
pañía usa un entorno de desarrollo controlado por asistentes
que utiliza código escrito en RPG básicamente para controlar
18 ServerNEWS MARZO 2008
código HTML, CSS y JavaScript específico de la web. Al mis-
mo tiempo, Profound Logic tiene una solución para clientes
interesados únicamente en desarrollar aplicaciones para la
web lo más rápidamente posible y que quieren tener el me-
nor contacto posible con cualquier cosa nueva... ni siquiera
HTML.
Los últimos temores
El último gran temor al que se enfrentan los departamentos
informáticos ante una solución para el desarrollo de aplica-
ciones de un ISV es que la empresa con la que trabajan des-
aparezca del mercado o la vendan. La forma de sobrellevarlo
es asegurarse de que todas las licencias sobre el código y las
herramientas cubren el doble de todo lo que se imagine que
vaya a necesitar jamás. Los contratos de mantenimiento tam-
bién deben incluir salidas claras en caso de que al proveedor
lo absorba otra compañía y el resultado no sea de nuestro
agrado. Recuerde que esto es sólo un negocio y todo se puede
negociar. Si no le gustan los términos, déjelo correr. Hay mu-
chas otras soluciones razonables.
¿Qué me dice de IBM? La solución EGL de la compañía
lleva merodeando por la periferia del mundo del System i un
par de años. ¿Puede que una solución de IBM, respaldada
por una compañía tan grande que nadie puede comprarla y
que es tan rica como para tener su propia isla en Second
Life, sea fundamentalmente mejor que la solución de un ISV?
No tan rápido. IBM puede que no vaya a dejarle en la esta-
cada, pero sus soluciones y soporte a veces sí. “En realidad,
IBM cambia de dirección más a menudo que nosotros”, indi-
ca Kenzie, de BCD.
Así que...
¿Cuáles son los indicadores de que su organización necesita
una solución para el desarrollo de aplicaciones? ¿Le interesa
desarrollar aplicaciones web y de cliente enriquecido? ¿El
desarrollo de sus aplicaciones va con retraso? ¿Le gustaría
aumentar su capacidad de desarrollar aplicaciones cuanto
antes? ¿Le gustaría que sus desarrolladores entraran en con-
tacto gradualmente con lenguajes y técnicas más conocidos?
Aunque RPG no está acabado, ¿Le gustaría disponer de una
solución que le permita trabajar con expertos que no conoz-
can RPG? ¿Le gustaría tener la posibilidad de migrar una
aplicación –ay– a otra plataforma?
Si ha respondido afirmativamente a alguna de estas pre-
guntas, puede que sea el momento de (re)considerar la posi-
bilidad de adquirir una solución para el desarrollo de aplica-
ciones. ■
Chris Maxcer es el redactor de noticias de System iNEWS y está especiali-
zado en escribir sobre temas relacionados con la informática empresarial.
www.help400.es
www.help400.es MARZO 2008 ServerNEWS 19
 Configurar un entorno seguro para
aplicaciones escritas en PHP
Zend Core para i5/OS tiene opciones para proteger el sistema
por Alan Seiden
G
racias al soporte del popular lenguaje de pro-
gramación web PHP, el System i puede ejecutar
una gran variedad de programas basados en
PHP para la web. Dada la naturaleza abierta de
Internet, los administradores de sistemas pru-
dentes que instalen aplicaciones web en el entorno Zend Core
para i5/OS de IBM querrán tener garantizada la seguridad.
¿Qué precauciones han de adoptar?
Aunque la arquitectura del System i automáticamente nos
protege contra desbordamientos de buffers, virus y gusanos,
y el PHP de Zend Core ofrece protecciones adicionales a las
del lenguaje PHP genérico, debería protegerse contra otros
peligros, como por ejemplo:
• propagación de virus a los navegadores (aunque el sitio en
sí sea inmune)
• “sniffing” (robo) de contraseñas
• ejecución no autorizada de aplicaciones
• revelación o modificación de datos privados
Algunas de estas medidas de protección requieren técnicas
de programación específicas de PHP, que trataré en un próxi-
mo artículo. En éste explicaré cómo aumentar la protección
desde el propio entorno PHP.
Nota: la seguridad web es un campo que evoluciona muy
deprisa. Todas las recomendaciones que expongo aquí se con-
sideran fiables en Zend Core para i5/OS versión 2.0.1 (es de-
cir, PHP 5.2.1.)
La primera línea de defensa
Independientemente de las aplicaciones que ejecute, un en-
torno de ejecución seguro reduce el riesgo de sufrir proble-
mas, tanto conocidos como desconocidos. El experto en segu-
ridad de PHP Chris Snyder, coautor con Michael Southwell
▲ de “Pro PHP Security” (Apress, 2005), recomienda varios ni-
▲ veles de protección –denominados “defensa en profundidad”–
▲ porque “no se sabe qué puede salir mal”. Snyder, desarrollador
de aplicaciones web de la fundación Fund for the City of New
Programación y sistemas
York, considera que una aplicación web es tan segura como el
entorno en que se ejecuta.
El entorno de ejecución de PHP es el perímetro externo de
la seguridad de una aplicación; queremos detener los ata-
ques aquí, si es posible. En este artículo nos ocuparemos de
ese anillo exterior de defensa, que incluye elementos como el
mantenimiento de PHP y los parches de aplicaciones, el ci-
frado de datos, las estructuras de directorios, los archivos de
configuración y la actualización regular de PHP.
20 ServerNEWS MARZO 2008
Mantenga actualizados PHP y las aplicaciones
En cada nueva versión de PHP se mejora la seguridad elimi-
nando vulnerabilidades notificadas por la comunidad de usua-
rios. Entre versiones, Zend publica “correcciones urgentes”
(parches que corrigen errores que pueden comprometer la
seguridad hasta que la versión siguiente esté disponible).
Shlomo Vanunu, de Zend, recomienda que los administra-
dores se mantengan al día configurando actualizaciones au-
tomáticas desde la Zend Network, que aplicará parches y ac-
tualizaciones según se necesite para mantener la seguridad.
Vanunu, consultor del laboratorio de Zend en Ramat-Gan (Is-
rael) y jefe de equipo del departamento de Servicios mundia-
les para i5 de Zend, señala que IBM ha dispuesto que todos
los clientes de System i puedan conseguir estas actualizacio-
nes mediante la suscripción gratuita al soporte Zend Network
Silver Support.
Estos son los pasos que hay que dar para configurar las
actuaciones automáticas:
1. Registrarse en la Zend Network (zend.com/network). Pue-
de que ya lo haya hecho si ha descargado Zend Core de la
Red.
2. Desde una línea de mandatos del System i, escriba lo si-
guiente: GO ZENDCORE/ZCMENU
3. Seleccione la opción de menú 2: Update via Zend Network
(Actualizar mediante la Zend Network).
4. Desde el menú Update (Actualizar), elija actualizar inme-
diatamente o de forma planificada.
Además de las actualizaciones de PHP, las aplicaciones web
basadas en PHP más conocidas también publican sus pro-
pios parches y actualizaciones de forma regular. Según Chris
Snyder, incluso en los mejores proyectos acaban colándose
algún error que puede ser peligroso. De modo que todos debe-
mos mantenernos informados sobre vulnerabilidades y las
correspondientes actualizaciones usando estos métodos:
• Resúmenes de SecurityFocus, coordinados por Daniel
Convissor (phpsec.org/projects/vulnerabilities/security-
focus.html)
• boletines de noticias distribuidos por correo electrónico por
los equipos de desarrollo
• foros web que son fuente de noticias y una buena forma de
conocer a los desarrolladores
Asimismo, debo decir algunas palabras sobre el archivo de
configuración de PHP, php.ini. Los valores de configuración
globales de PHP –incluyendo los valores de seguridad que se
www.help400.es
muestran en este artículo– se guardan en /usr/local/Zend/
Core/etc/php.ini. Ni que decir tiene que debe controlarse el
acceso a este archivo para mantener un sistema seguro. Esto
significa limitar los usuarios que tienen acceso al archivo y
garantizar que ninguna aplicación web puede modificarlo.
Este archivo puede editarse con el mandato WRKLNK y con
editores de texto de Windows.
El formato del archivo php.ini usa la conocida sintaxis
variable=valor. Por ejemplo:
error_log = /usr/local/Zend/Core/logs/php_error_log
Si el valor es booleano (valores On u Off), la línea sería como
esta:
valor = On o valor = Off
Por ejemplo:
log_errors = On
Nota: se pueden usar indistintamente los números 1 y 0 o
los valores On y Off. También es posible acceder a los valores
de php.ini gráficamente desde el centro de control de Zend
Core basado en web siguiendo estos pasos:
1. Vaya a http://nombrehost:8000/ZendCore.
2. Pulse el menú Configuration (Configuración).
3. Pulse la opción PHP Configuration (Configuración de PHP).
Independientemente de cómo edite php.ini, la actualiza-
ción no surtirá efecto hasta que se reinicie el servidor web
Apache de Zend. Para ello, efectúe estos pasos:
1. Escriba GO ZENDCORE/ZCMENU.
2. Elija la opción 5: menú Service Management (Gestión de
servicios)
3. Elija la opción 6: Restart Apache server instances (Reiniciar
instancias del servidor Apache)
Cuidado con las variables no inicializadas
Por cuestiones de eficiencia, PHP no comprueba si las varia-
bles se han inicializado antes de usarlas. Cuando los progra-
madores olvidan inicializarlas, puede haber “consecuencias
accidentales”. Normalmente, las variables no inicializadas no
representan un problema de seguridad, ni siquiera tienen por
qué provocar un error de la aplicación. Sin embargo, hay un
caso en que las variables no inicializadas se convierten en un
arma cargada: la opción register_globals de PHP.
Este valor de configuración controla si pueden establecer-
se variables directamente desde los argumentos queryString
incluidos en el URL. El valor por omisión de register_globals
es Off, lo que impide la asignación de variables desde el URL.
No obstante, si se establece en On, cualquier usuario podría
manipular variables de script directamente incluyendo asig-
naciones en el URL. Por ejemplo, si el script usa la variable
autenticacionAprobada para indicar que el usuario se ha
autenticado, un intruso podría simplemente añadir la serie
de caracteres “autenticacionAprobada=1” en un URL, con lo
que eludiría hábilmente el código de autenticación.
www.help400.es
La protección obvia contra este abuso es asegurarse de que
register_global sigue teniendo su valor por omisión, Off. En
php.net/register_globals puede hallar más ejemplos de vul-
nerabilidades asociadas a register_globals.
Mensajes de error de programa
¿Qué haríamos sin los mensajes de error de los programas?
No estoy hablando de los mensajes dirigidos a los usuarios
finales, como “es necesario introducir el código postal”, sino
de los errores que describen problemas de programación in-
ternos como “el índice de la matriz está fuera de los límites”.
Necesitamos estos mensajes cuando desarrollamos nues-
tras aplicaciones. No obstante, una vez entregado el sistema
al usuario final, mostrar este tipo de mensajes no sólo parece
poco profesional, sino que puede revelar información confi-
dencial, como la ubicación de archivos o parámetros de API
internas. Más aún, si algún motor de búsqueda indexa los
mensajes de error, los hackers podrán buscar sus vulnerabili-
dades favoritas. Actualmente ésta es una técnica tan difun-
dida que hasta tiene nombre: “Google hacking”.
Puede garantizar que los mensajes de error se añaden a su
archivo de anotaciones (donde poder inspeccionarlos) pero que
quedan fuera de la vista del público con el siguiente valor de
configuración de php.ini:
display_errors = Off
log_errors = On
error_log = /usr/local/Zend/
Core/logs/php_error_log (
the default)
error_reporting =
E_ALL | E_STRICT
Si se especifica E_ALL | E_STRICT, PHP registrará todos
los errores, no importa lo pequeños que sean, incluyendo las
advertencias y los avisos (por ejemplo, de variables no
inicializadas). Hallará más información sobre la notificación
segura de errores en php.net/error_reporting.
Ocultar phpinfo()
La función phpinfo() (página del manual: php.net/phpinfo)
genera una lista de todos los valores de configuración de PHP,
como por ejemplo los valores de php.ini, los nombres de los
módulos de extensión y los números de versión, así como las
variables de Apache (Figura 1).
Programación y sistemas
El uso más habitual de esta función es un sencillo docu-
mento de HTML denominado phpinfo.php, que contiene el
breve fragmento de PHP siguiente:
<?php
phpinfo();
?>
Este minúsculo pedazo de código se ampliará hasta con-
vertirse en un documento de HTML que incluye todos los
▲
valores de configuración de los archivos .ini de PHP, opciones ▲
de compilación, módulos de extensión incluidos y un montón ▲
de información más que prefería que los hackers no vieran.
MARZO 2008 ServerNEWS 21
 ■ CONFIGURAR UN ENTORNO SEGURO

Aunque phpinfo() es una herramienta de depuración de va-

lor incalculable, al recopilar información de fuentes dispares
en una sola página, los hackers pueden usarla para encontrar
debilidades. Sin duda querrá poder acceder fácilmente a la
salida de phpinfo() para resolver los problemas de la aplica-
ción, pero deberá tener cuidado de ocultar este acceso, posi-
blemente protegiéndolo mediante una contraseña.
En la versión 5.2.1 de PHP se ha mejorado esta situación al
añadir palabras clave que indican a los motores de búsqueda
que no indicen las páginas de phpinfo, reduciendo la amenaza
del Google hacking. Aún así, un desconocido que consultara el
documento phpinfo() vería más cosas de las que desearíamos
revelar. Así que, de ninguna manera debería utilizar el conve-
nio phpinfo.php, que todo hacker busca cuando sondea el sitio
de una víctima potencial.

Cifrar los datos

El experto en seguridad Chris Snyder recomienda cifrar los da-
tos (un método de mantener los datos intactos y confidenciales
hasta que lleguen a su destinatario) siempre que sea posible.
¿Por qué cifrarlos? Si su servidor web envía datos sin cifrar,
estos datos pueden espiarse o incluso alterarse antes de que
lleguen a su destino. Este problema puede producirse en mu-
chos sitios: en la LAN corporativa (ya sea por parte de los
empleados o de spyware), en Internet o desde la señal
inalámbrica de un cibercafé.
El cifrado está especialmente justificado cuando se envía
información confidencial como contraseñas, información so-
bre tarjetas de crédito u otro tipo de datos personales o confi-
denciales.
El método de cifrado más habitual es SSL/TLS (Capa de
conexión segura/Seguridad de la capa de transporte) que ci-
fra datos entre el servidor de aplicaciones y el navegador del
usuario de modo que si alguien está interceptando el tráfico
de paquetes de HTTP no podrá decodificarlos.
Sin embargo, tenga en cuenta que SSL/TLS no impide que
el usuario final vea los datos transmitidos por el servidor, in-
cluyendo los datos que se hayan codificado en campos de for-
mulario HTML “ocultos”. Todos los usuarios pueden ver este
contenido usando el mandato Ver código fuente del navegador.
Si desea proteger variables internas, use la gestión de sesio-
nes del servidor en vez de campos de HTML ocultos.
System i es compatible con el cifrado SSL/TLS. Los usuarios
▲ verán el conocido prefijo “https://” en los URL. Hallará instruc-
▲ ciones sobre cómo configurar SSL/TLS en el InfoCenter de i5/OS.
▲ Otra categoría peligrosa es la de los archivos subidos por
Archivos separados
Programación y sistemas
FIGURA 1
Salida de Phpinfo() (fragmento)
Los archivos internos presentan un riesgo si los usuarios tie-
nen acceso directo a ellos.
Ejemplos de archivos externos son index.php, las hojas de
estilo y otros archivos (tanto si son de PHP como si no) que el
navegador web solicitará. Estos archivos pueden ponerse con
total seguridad en el directorio raíz de los documentos, que
en Zend es por omisión /www/zendcore/htdocs.
Ejemplos de archivos internos son los archivos usados por
la aplicación, como el código “include” que se ejecuta en los
archivos externos pero que se guarda por separado. Los ar-
chivos de configuración que contienen contraseñas también
suelen considerarse archivos internos. Estos deben guardar-
se fuera del directorio raíz de los documentos (htdocs), donde
no puedan ejecutarse o consultarse de forma accidental por
los usuarios. Este es un ejemplo de inclusión (ejecución) de
un archivo desde una ubicación segura, como /www/zendcore:
<?php
include (‘/www/zendcore/
includes /config.inc.php’);
// más código
?>
los usuarios. Estos archivos nunca deberían ponerse en el

Sea cual sea la complejidad de un sitio web basado en PHP,
probablemente tendrá una combinación de archivos externos
e internos.
Los navegadores acceden a los archivos externos mediante
los URL que los usuarios teclean en sus navegadores o pulsan
como enlaces. Los navegadores no pueden acceder directamen-
te a los archivos internos, aunque los usan las aplicaciones (y
puede que hasta se muestren a los usuarios), sino que sola-
mente deben poder recuperarse por el código de la aplicación.
directorio raíz de los documentos. Un usuario malintencio-
nado podría subir un script dañino y luego ejecutarlo desde
el servidor. Elija una carpeta que no pertenezca al directorio
raíz, como /www/zendcore/subidas.
Como protección adicional, este directorio debe ser sólo de
grabación para evitar que la aplicación lea o ejecute los ar-
chivos que se guarden allí. Use un script de ejecución por
lotes que no esté escrito en PHP para recuperar los archivos
subidos. Además, asegúrese de que la aplicación detiene

22 ServerNEWS MARZO 2008 www.help400.es


FIGURA 2
Salida de PHPSecInfo (fragmento)
cualquier intento de incluir en los archivos que se suban pe-
ticiones de creación implícita de directorios. Por ejemplo, la
aplicación debe detectar y descartar un nombre de archivo
del tipo laguaridadeloshackers/chucherias/archivo1.
No dé rienda suelta a los scripts
Si se le permite, PHP puede leer el contenido tanto de las
carpetas locales como de Internet. Por ejemplo, las funciones
include() y readfile() pueden leer cómodamente nombres de
archivos locales como /informes/trimestral.xls y URL remo-
tos como http://www.ejemplo.com/archivoremoto.html.
Con tanta potencia a nuestra disposición, lo más sensato
es pensar en qué se necesita realmente y restringir las capa-
cidades que no se necesitan. Este enfoque prudente ofrece
una protección extra contra algunas artimañas y scripts da-
ñinos imprevistos. Algunas de las opciones de php.ini que res-
tringen a qué recursos puede acceder un script son estas:
allow_url_include (valor por omisión: Off; valor recomen-
dado: Off). El valor Off evita que las aplicaciones ejecuten
(“incluyan”) el código que se encuentra en servidores remo-
tos. Normalmente, mandatos como include() o require() pue-
den incluir código no solamente desde el servidor local, sino
también desde uno remoto a través de un URL. El peligro
con el valor On es que se puede acabar ejecutando un script
remoto del atacante. Allow_url_include se introdujo en PHP
5.2 (Zend Core 2.0).
www.help400.es
allow_url_fopen (valor por omisión: On; valor recomen-
dado: Off, si es posible). Cuando se establece en Off,
allow_url_fopen es más restrictivo que allow_url_include,
evitando que las aplicaciones ni siquiera puedan leer archi-
vos remotos mediante URL. Desactive la opción si la aplica-
ción no necesita abrir otros URL o si se puede sustituir la
extensión cURL, que lee URL remotos de forma más segura
que los mandatos nativos.
open_basedir (valor por omisión: permitir abrir todos los ar-
chivos; valor recomendado: las carpetas necesarias para la apli-
cación). Cuando se especifica open_basedir con una lista de car-
petas, mandatos como readfile() y fopen() solamente podrán
acceder a archivos de las carpetas especificadas. En consecuen-
cia, los scripts no podrán leer datos confidenciales o modificar
archivos que estén en otros sitios. Si se especifican varias carpe-
tas, debe separarse mediante dos puntos (:), aunque los siste-
mas Windows usan un punto y coma (;). Por ejemplo:
open_basedir = /tmp/:/www/zendcore/htdocs/:/informes/
limitará las aplicaciones para que sólo puedan acceder a
los datos de las carpetas /tmp, /www/zendcore/htdocs e /in-
formes.
PHPSecInfo
La herramienta gratuita PHPSecInfo del PHP Security
Consortium analiza la configuración y comunica problemas
potenciales de seguridad (Figura 2). PHPSecInfo es una he-
rramienta experimental; sus sugerencias son genéricas y no
deben seguirse ciegamente. Con todo, se trata de una herra-
mienta de gran valor educativo y vale la pena descargársela
de phpsec.org/projects/phpsecinfo.
El poder protector de la configuración
Con algunos cambios sencillos, la configuración de PHP pue-
de evitar o limitar en gran medida el mal uso de las aplica-
ciones. Las directrices ofrecidas en este artículo son una red
de seguridad para su creatividad e innovación en la Red.
Las aplicaciones hechas a medida están mejor diseñadas
cuando se tiene presente la seguridad. Después de utilizar
las técnicas descritas en este artículo para proteger el entor-
no, el paso siguiente será escribir código seguro. En mi próxi-
mo artículo explicaré técnicas para filtrar la entrada e inter-
pretar la salida con el fin de malograr la inyección de código
SQL y la vulnerabilidad XSS (cross-site scripting).
Programación y sistemas
Quiero agradecer a Chris Snyder y Shlomo Vanunu su ayu-
da para escribir este artículo. ■
Alan Seiden disfruta dirigiendo proyectos en colaboración, desarrollando
software y resolviendo problemas que desconciertan a sus clientes.
Miembro del grupo de desarrolladores PHP de Nueva York desde 2004 y ▲
uno de los primeros impulsores de PHP en el System i, Alan fue reseñado ▲
en el boletín de noticias de la New York Software Industry Association. El ▲
blog sobre informática de Alan es alanseiden.com.
MARZO 2008 ServerNEWS 23
 Supervisar el rendimiento
del entorno web
La nueva herramienta WPM permite controlar el rendimiento web

por Rachel Eagle y Tim Rowe

A
l gestionar un entorno web en el System i, como sariales como entidades manejables. El estándar ARM per-
la naturaleza distribuida extiende sus brazos mite que los usuarios amplíen las herramientas de gestión
por muchos trabajos, a veces puede que nos sin- de la empresa directamente a aplicaciones.
tamos como si estuviéramos bregando con un WPM aprovecha el estándar abierto ARM. ARM ayuda a
pulpo. Un entorno típico puede incluir un ser- los usuarios a integrar aplicaciones empresariales y facilita
vidor de aplicaciones (por ejemplo, WebSphere Application ampliar las herramientas de gestión de la empresa directa-
Server) en que se ejecutan las aplicaciones, un servidor HTTP mente a aplicaciones. El servidor de aplicaciones, el servidor
para recibir las peticiones y archivos estáticos del servidor, de la base de datos y el servidor HTTP están diseñados para
una base de datos como DB2 desde la que se acceden a datos sacar partido de ARM. Si crea sus propias aplicaciones, tam-
permanentes, un servidor WebFacing y otros trabajos de las bién podrá beneficiarse de este soporte. En el caso de las apli-
aplicaciones. Recopilar los datos necesarios para depurar los caciones y servidores desarrollados para aprovechar ARM,
problemas de rendimiento y descubrir cuellos de botella rá- cada vez que se solicita una unidad de trabajo y cada vez que
pidamente puede consumir todo nuestro tiempo. El Supervi- un trabajo del proceso hace su parte del trabajo, se anotan
sor de rendimiento Web (WPM), una herramienta nueva de entradas que registran el tiempo que tarda cada trabajo en
la interfaz Web Administration de i5/OS que forma parte de realizar su parte del trabajo.
IBM HTTP Server para i5/OS (DG1-5722), se creó para dar La herramienta WPM recopila todos los tiempos de las
respuesta a este problema concreto. WPM recopila datos so- transacciones y las entradas de todos los trabajos del
bre el rendimiento de los trabajos que componen un entor- System i que forman parte del entorno web. Los datos de
estos trabajos se presentan en una interfaz, me-
El Supervisor de rendimiento Web (WPM), diante la cual pueden verse fácilmente todos los
tiempos de las transacciones y de las respues-
una herramienta nueva de la interfaz Web tas de cada parte del entorno web. Estos datos
Administration forma parte del IBM HTTP pueden adaptarse para que muestren los tiem-
pos de las transacciones y de las respuestas de
Server para i5/OS un usuario o una dirección IP individuales, lo
que permite que el usuario o administrador sepa
no web y las transacciones realizadas por éstos. La herra- dónde se encuentran los problemas potenciales de la apli-
mienta, completamente automatizada, identifica cómo se cación. Los datos también pueden usarse para ayudar a
está utilizando el tiempo y los recursos del sistema, lo que un usuario que tenga dificultades.
permite encontrar los puntos conflictivos y posibles cue- WPM proporciona una interfaz para que los administrado-
llos de botella. res puedan consultar fácilmente los trabajos más importan-
De forma parecida a como el mandato WRKACTJOB (Tra- tes, de forma muy parecida a como lo hace la herramienta
▲ bajar con trabajos activos) muestra todos los trabajos del i5 WRKACTJOB para entornos que no están basados en web.
▲ que se están ejecutando actualmente en el sistema, junto con Si tiene que examinar la información específica del trabajo,
▲ alguna información sobre el rendimiento de cada trabajo, la WPM tiene un enlace directo con iSeries Navigator en la pá-
herramienta WPM muestra únicamente los trabajos del sis- gina del trabajo activo.
tema relacionados con el servidor web seleccionado. Esto per-
mite ver datos concretos de rendimiento de cada trabajo (por Instalación de WPM
Management

ejemplo, el número de transacciones que ha procesado cada Antes de iniciar el Supervisor de rendimiento Web, asegúre-
trabajo o el tiempo necesario para procesar estas peticiones). se de que tiene instalado el PTF de grupo SF99114 Nivel 6 o
Ahora es más fácil determinar qué trabajos están procesan- posterior para IBM HTTP Server para i5/OS en el System i
do las transacciones y qué trabajos tardan mucho tiempo en V5R4. Siga estos pasos para ejecutar WPM:
procesar peticiones.
El estándar Application Response Measurement (ARM) 1. En iSeries Navigator, despliegue su_sistema|Red|Ser-
describe un método habitual de integrar aplicaciones empre- vidores y seleccione TCP/IP.

24 ServerNEWS MARZO 2008 www.help400.es

 Management

▲
▲
▲

www.help400.es MARZO 2008 ServerNEWS 25

 ■ SUPERVISAR EL RENDIMIENTO DEL ENTORNO WEB
2. Pulse con el botón derecho del ra-
tón en Administración HTTP y se-
leccione Inicio.
3. Arranque un navegador web.
4. Escriba http://[su_system_i]:2001 en
el campo del URL para iniciar la
página web Tareas de i5/OS, donde
[su_system_i] es el nombre de su sis-
tema IBM System i (por ejemplo,
http://systemi.acme.com:2001).
5. Pulse IBM Web Administration
para i5/OS.
6. Desde la interfaz IBM Web Admi-
nistration para i5/OS, seleccione el
servidor que le gustaría supervisar. FIGURA 1
7. En el panel de navegación, desplie- Herramienta Supervisor de rendimiento Web
gue Rendimiento web y seleccione
Supervisor de rendimiento Web.

Una vez realizados los siete pasos,

aparece la página de introducción de
WPM, donde ya puede empezar a su-
pervisar el rendimiento del entorno
web.

Supervisión del entorno web

Como es necesario establecer muchos
atributos antes de poder supervisar el
rendimiento web, deberá parar y
reiniciar el entorno web para activar
la supervisión. Antes de poder utili-
zar esta herramienta deberá planear
con antelación una desconexión del
servidor. FIGURA 2
Mediante la interfaz Web Admi- Interfaz Supervisor de rendimiento Web
nistration para i5/OS, empiece por
seleccionar el entorno que desearía
supervisar (sólo puede supervisarse uno a la vez) y active web. Por ejemplo, si el servidor HTTP está en un sistema
la herramienta Supervisor de rendimiento Web (Figura remoto, no se mostrará ningún trabajo del servidor HTTP. La
1). Para activar la supervisión, la herramienta: interfaz incluye las fichas Transacciones y Trabajos.
En la ficha Transacciones (Figura 3) pueden verse esta-
• detiene las instancias del servidor HTTP y actualiza sus dísticas de las transacciones de cada trabajo que genera da-
configuraciones para activar la recopilación de datos de tos de ARM. Para cada transacción, esta pantalla muestra el
▲ ARM tiempo promedio de respuesta y el número de transacciones
▲ • detiene los servidores de aplicaciones y actualiza sus confi- completadas. La ficha Trabajos (Figura 4) muestra los ser-
▲ guraciones para activar la recopilación de datos de ARM vidores y trabajos activos del entorno. Para cada trabajo pue-
• inicia la recopilación de datos de ARM de verse el usuario actual, el porcentaje de utilización de la
• reinicia el servidor HTTP y las instancias del servidor HTTP CPU, la prioridad de ejecución, el número de hebras, el tiem-
po promedio de respuesta de cada transacción y el número de
Management

Una vez detenidos, actualizados y reiniciados los servido- transacciones completadas. Si los valores de los tiempos pro-
res, ya puede empezar a recopilar datos a los que puede medio de respuesta o de los porcentajes de uso de la CPU son
accederse mediante la interfaz Supervisor de rendimiento Web muy grandes, pueden que indiquen un cuello de botella. Este
(Figura 2). El contenido de la interfaz WPM puede ser dife- posible cuello de botella es un buen punto de partida para
rente para cada entorno web supervisado. WPM es específico investigar los problemas de rendimiento.
de cada entorno seleccionado y únicamente se muestran los Para identificar las transacciones de un usuario o grupo de
trabajos directamente implicados en servir a la aplicación usuarios, pulse el botón Preferencias de la ficha Transacciones.

26 ServerNEWS MARZO 2008 www.help400.es


FIGURA 3
Ficha Transacciones
FIGURA 4
Ficha Trabajo
En esta página, puede especificar un usuario o una lista de
usuarios y WPM mostrará solamente información sobre las
transacciones de los usuarios seleccionados. Esto es útil si un
determinado usuario se queja de la lentitud de una aplica-
ción. Compare los tiempos que tarda en ejecutarse la tran-
sacción para distintos usuarios con el fin de asegurarse de
que las quejas son justificadas. También puede optar por exa-
minar los tiempos que tarda en ejecutarse la transacción para
una sola dirección IP o nombre de host, lo que plantea formas
creativas de averiguar qué está pasando con una aplicación.
La información relativa a la transacción muestra qué traba-
jos han procesado las peticiones de cada usuario o dirección
IP. Esta información tan precisa sobre el usuario puede ayu-
darle a identificar qué trabajos están ralentizando el entor-
no web.
www.help400.es
Cuando esté satisfecho con los datos
recopilados, debería desactivar WPM
para liberar los recursos adicionales
del sistema que consume. Cuando se
desactiva la supervisión, la herramien-
ta:
• detiene las instancias del servidor
HTTP y actualiza sus configuracio-
nes para desactivar la recopilación
de datos de ARM
• detiene los servidores de aplicacio-
nes y actualiza sus configuraciones
para desactivar la recopilación de
datos de ARM
• detiene la recopilación de datos de
ARM
• reinicia el servidor HTTP y las ins-
tancias del servidor de aplicaciones,
devolviéndolas a su estado anterior
Aunque hay muchas formas posi-
bles de usar la información que pro-
porciona la herramienta, hágalo con
cautela. Puede sentir la tentación de
dejar que la herramienta se ejecute
en el entorno web todo el tiempo, pero
hay dos problemas. El primero es que
la instrumentación de ARM genera
una actividad general adicional. Aun-
que esta instrumentación se ha dise-
ñado para que sea lo más discreta po-
sible, se puede producir una ligera
disminución del rendimiento cuando
está activada. El segundo es que es-
tamos limitados a supervisar sólo un
entorno web del sistema a la vez, por
lo que tendrá que elegir qué entorno
supervisar.
Con WPM recopilando datos sobre el
rendimiento y las transacciones y ocu-
pando unos cuantos brazos del pulpo, tendrá las manos li-
bres para dedicarse a problemas más importantes o intere-
santes. ■
Management
Rachel Eagle lleva seis años trabajando para IBM. Actualmente es redactora y
jefe de proyecto del departamento de Tecnologías del usuario. Está casada con
otro trabajador de IBM y tienen un hijo y dos perros. En su tiempo libre, trabaja
como voluntaria y se dedica a hacer manualidades y a viajar.
▲
Tim Rowe es jefe del equipo IBM Web Administration, en el que lleva ▲
trabajando los últimos seis años. Se casó hace diecisiete años y tiene cuatro ▲
niños que no le dejan tiempo libre.
MARZO 2008 ServerNEWS 27
 Añadir técnicas de SQL Server
al repertorio de DB2
Aproveche algunas de las posibilidades de SQL exclusivas de SQL Server
por Paul Conte
C
ada vez más empresas que confiaron
únicamente en el System i (o uno de
sus predecesores) y en la base de da-
tos integrada DB2 están asumiendo la
responsabilidad de gestionar un servidor Wintel
que ejecuta SQL Server de Microsoft. Como SQL
tiene estándares formales que tanto IBM como
Microsoft han implementado bastante bien, el co-
nocimiento que tenga de SQL en el System i será
un buen punto de partida para empezar a encar-
garse del desarrollo de SQL Server además del de
DB2. Más allá del lenguaje SQL en sí, hay varias
funciones de SQL Server que todavía no están en
DB2 y que puede que le interese utilizar en sus de-
sarrollos. En este artículo encontrará una rápida
introducción.
Tipo de datos Variant
SQL Server admite muchos tipos de datos internos, inclu-
yendo los numéricos, de tipo carácter y las series binarias,
los tipos de datos de fecha y hora, etcétera. En la mayoría de
los casos, se definen columnas de tablas, variables de proce-
dimientos y parámetros y valores de retorno de funciones con
tipos de datos concretos como Int o Character. En estos casos,
en la columna sólo pueden almacenarse valores del tipo es-
pecificado.
Pero SQL Server también permite definir una columna,
▲ variable, parámetro o valor de retorno de funciones utilizan-
▲ do la palabra clave sql_variant, con el fin de almacenar valo-
▲ ción:
res de distintos tipos de datos en la misma columna. Este
ejemplo permite guardar una referencia numérica o de tipo
carácter para los artículos de un catálogo:
Management
CREATE TABLE Articulo
( NumArt Int,
RefCatalogo sql_variant,
... )
Se puede determinar el tipo de datos de una fila determi-
nada usando una llamada a función, como esta:
28 ServerNEWS MARZO 2008
Sql_Variant_Property(
RefCatalogo, ‘TipoBase’)
Si el valor actual de RefCatalogo es un tipo entero, esta lla-
mada a función devolverá int.
Es posible convertir explícitamente un tipo de datos variant
en otro de los tipos de datos internos:
Cast( RefCatalogo As
VarChar(10) )
En muchas circunstancias, sin embargo, SQL Server con-
vertirá implícitamente el valor variant de una columna en el
momento oportuno, por lo que no es necesario escribir un
operación Cast explícita.
Las UDF en restricciones de comprobación
Las restricciones de comprobación permiten definir reglas
para determinar que los datos son válidos al crear una tabla
o modificar su definición. En SQL Server, se puede especifi-
car una función definida por el usuario (UDF) en la expre-
sión lógica que define la restricción. Las UDF aumentan las
oportunidades de reutilizar el código y permiten definir com-
probaciones de validez complejas.
Una característica interesante es que se pueden usar con-
sultas sobre los datos existente de la tabla como parte de
la restricción. Por ejemplo, se puede crear la UDF Com-
probarIntervaloFecha que devuelve 1 si existe otra fila en
la tabla Articulos con el mismo número de artículo y un
intervalo de fecha que se solapa para el precio. Si no exis-
te solapamiento de ninguna fila, ComprobarIntervaloFecha
devuelve 0. Cuando cree la tabla, se puede añadir una res-
tricción de comprobación que haga referencia a esta fun-
CREATE TABLE Articulos
( NumArt Int,
Precio Decimal( 10, 2 ),
FechaIni Date,
FechaFin Date,
...
Comprobacion ( ComprobarIntervaloFecha (
NumArt,
FechaIni, FechaFin ) = 0 )
www.help400.es
Soporte integrado para el control concurrente
optimista
El control concurrente optimista es una técnica para evitar
actualizaciones concurrentes conflictivas de la misma fila de
una tabla. La técnica básica es extraer filas sin bloquearlas y
utilizar una copia salvada de la indicación de la hora de la
fila extraída (o una suma de comprobación del contenido de
toda la fila) para comprobar si otro proceso ha realizado cam-
bios antes de ejecutar otra operación de actualización de la
fila.
SQL Server se encargará de todas las tareas internas si se
declara un cursor con la palabra clave Optimistic:
Declare CursorTrab Optimistic
For Select IdTrab, NomTrab
From Trabajador
Order By IdTrab
For Update of NomTrab
Con la definición de este cursor, las filas no se bloquean al
extraerlas. Cuando la aplicación intenta una actualización
con ubicación, como:
Update Trabajador
Set NomTrab = :NombreNuevo
Where Current of CursorTrab
SQL Server comprueba la indicación de la hora salvada o
la suma de comprobación con el valor correspondiente de la
fila actual y no permite la actualización si los dos valores no
coinciden.
Resúmenes Rollup y Cube en conjuntos de
resultados
Es posible generar filas de totales y subtotales en el conjunto
de resultados de una sentencia Select usando las palabras
clave Rollup o Cube en la cláusula Group By.
Rollup genera un conjunto jerárquico de filas de resumen.
En el ejemplo de la Figura 1A se muestra una sentencia
Select que genera una fila por cada curso con la suma de los
alumnos matriculados en todas las sesiones que ofrece el cur-
so. En la Figura 1B se muestra una fila de subtotal para
cada departamento (en los puntos A y B) y una fila de suma
total (en el punto C).
Se puede usar la función Grouping, como en este ejemplo,
para especificar un valor para las columnas Group By de las
filas acumuladas. Esto facilita la determinación de los valo-
res de resumen que contiene una fila concreta.
La palabra clave Cube funciona de forma parecida; sin
embargo, el conjunto de resultados contiene filas de
subtotal para todas las combinaciones de valores de la cláu-
sula Group By, no sólo los subtotales jerárquicos genera-
dos por Rollup.

Suscríbase a

Management

y reciba
gratuitamente
el Suplemento ▲
▲
técnico ▲

www.help400.es MARZO 2008 ServerNEWS 29

 ■ AÑADIR TÉCNICAS DE SQL SERVER AL REPERTORIO DE DB2
La función de búsqueda de texto Contains
La función Contains de SQL Server permite buscar en co- FIGURA 1A
lumnas de tipo carácter palabras, frases, prefijos de palabras, Utilización de la palabra clave Rollup
palabras derivadas, sinónimos y palabras semejantes a otras.
La forma de usar Contains en una condición de búsqueda es Select Case When ( Grouping( Dept ) = 1 ) Then ‘All’
similar a la forma de usar la palabra clave Like para especi- Else Dept
End As Dept,
ficar comparaciones sencillas. Case When ( Grouping( Course ) = 1 ) Then ‘All’
En el ejemplo siguiente se buscan filas en que la descrip- Else Course
End As Course,
ción del producto contenga palabras basadas en cortar: Sum( Enrollment ) As EnrollSum
From Classes
Group By Dept, Course With Rollup
Select IdProd, DescProd
From Productos
Where Contains( DescProd,
‘ FormsOf (Inflectional, FIGURA 1B
corta) ‘) Resultado del ejemplo de la palabra clave Rollup

Para buscar descripciones de productos en que aparezca la

Dept Course EnrollSum
palabra cepillo cerca de nailon, especificaríamos: —————————— —————————— —————
Math 217 108
Math 324 211
Contains( DescProd,
Math All 319
‘ cepillo NEAR nailon ‘) Physics 411 121
Physics 412 220
Physics All 341
Hasta pueden buscarse palabras con un significado pareci- All All 660
do. La búsqueda siguiente encontraría motor, propulsor, má-
quina y otras palabras semejantes:

Contains( DescProd, FIGURA 2

‘ FormsOf (Thesaurus, Utilización de la característica Try/Catch
motor) ‘)
Set @RtnErrNbr = 0;
Las condiciones especificadas pueden combinarse en expre- Begin Try
Select CustName Into @RtnName
siones lógicas con los operadores And, Or y Not, como en esta From Customer
expresión: Where CustId = RqsId;
End Try
Begin Catch
‘cable And ((cobre And Not Set @RtnName = ‘Error’;
Set @RtnErrNbr = Error_Number();
trenzado) Return;
Or (solido And verde))’ End Catch;

Manejo de excepciones Try/Catch en

procedimientos de SQL
El manejo de excepciones estándar de SQL para procedimien-
tos almacenados es difícil de usar. El lenguaje procedural de
SQL Server (que forma parte de Transact-SQL) incluye un
▲ mecanismo Try/Catch más simple, parecido al que se usa en
▲ Java y en otros lenguajes de programación contemporáneos.
▲ En el ejemplo de la Figura 2 se puede ver un fragmento de
código que ejecuta una sentencia Select Into en el bloque Try.
Si esta sentencia no provoca una excepción, la ejecución pasa
a la sentencia que hay justo después del final del bloque Catch.
Management
funciones Error_Xxx que devuelven la gravedad del error, el
número de línea de la sentencia que ha provocado el error y
otra información relacionada con el error.
Los conocimientos de SQL son perfectamente aplicables a
muchas bases de datos relacionales, pero no basta con cono-
cer las características comunes multiplataforma. Si la
portabilidad del código no es importante, también vale la pena
entender y usar con sensatez las características de cada pla-
taforma. Tras leer este artículo, ya puede empezar a sacar

Si una sentencia del bloque Try (por ejemplo, la sentencia partido a algunas de las capacidades relacionadas con SQL
Select Into de la Figura 2) provoca una excepción, entonces exclusivas de SQL Server. ■
se ejecutarán las sentencias del bloque Catch.
La característica Try/Catch de Transact-SQL no permite
especificar qué excepciones capturar, algo que sí se puede
hacer en Java. Pero se puede usar la función integrada Paul Conte es redactor técnico de System iNEWS y presidente de PCES, una
Error_Number para determinar el error. También hay otras empresa de formación y consultoría de Eugene (Oregón).

30 ServerNEWS MARZO 2008 www.help400.es

 Management

▲
▲
▲

www.help400.es MARZO 2008 ServerNEWS 31

GUIA

32 ServerNEWS MARZO 2008 www.help400.es

 GUIA

MANTENIMIENTO Y BROKERAGE
INFORMÁTICO, S.L.

Mantenimiento / Alquiler y
Brokerage / Venta / Redes
Backup Center

Pere IV 78-82, 7º 3ª
08005 - Barcelona (Spain)
T. 34 934 854 427 Fax 34 934 850 168
P.T.A. Edificio CENTRO EMPRESAS 29590 Málaga

www.help400.es MARZO 2008 ServerNEWS 33

 confidencial por Carlos Bell

Algo se está cociendo en IBM

Según me indica el olfato, algo gordo se está cocinando en
las marmitas de IBM. No se si recordaréis que en esta mis-
ma columna, en octubre de 2007 (número 177) os comenta-
ba que entre las muchas iniciativas emprendidas por IBM
para mejorar los resultados de la familia de productos
System i, la última, la de julio de 2007, se basa en la reorganización del esfuerzo comercial en dos divisiones o líneas de
negocio distintas, la Business Systems responsable de la comercialización de los modelos “pequeños” 515, 520, 525, y 550
para atender las necesidades de las Pymes, y la Power Systems que agrupa a los “grandes” System i 570 y 595 con el resto
de modelos de la plataforma System p –los sucesores de aquel RS/6000 presentado en febrero de 1990 y que ahora compar-
ten arquitectura con los System i– para satisfacer las necesidades de las grandes corporaciones. En aquel momento hubiera
sido muy temerario valorar los posibles resultados, y más teniendo en cuenta el inminente anuncio de Systems i con
tecnología POWER6. En enero de 2008 (número 180) pude hacerlo con satisfacción: por primera vez en los dos últimos años,
los resultados del System i habían sido positivos en el cuarto trimestre de 2007, con un 2% de crecimiento en comparación
al mismo periodo del año anterior...
Pero ¿en cuál de esas dos líneas de negocio se han producido? Evidentemente, no es lo mismo: para conseguir los mismos
ingresos, en la Business Systems es necesario realizar muchísimas más ventas que en la Power Systems. ¿Quienes son sus
responsables a nivel internacional? ¿También se ha reorganizado en España? ¿Quién dirige la división del System i en su
conjunto, si es que todavía existe como tal? En enero de 2005, el cargo de director general de la división iSeries lo asumió
Mark Shearer, vicepresidente de estrategia de marketing para sistemas y mano derecha de Bill Zeitler en el Grupo de
Sistemas y Tecnología de IBM. Según se desprende de la entrevista realizada a Mark Shearer por IT Jungle el pasado 3 de
marzo (http://www.itjungle.com/tfh/tfh030308-story01.html), esta reestructuración es más profunda de lo que puede
parecer a simple vista. Para empezar, después de la reorganización de julio de 2007, todo el desarrollo del hardware de
sistemas basados en tecnología POWER pasó a depender de la división Power Systems, bajo la dirección de Ross Mauri;
además, una pequeña división creada sigilosamente por IBM en enero de 2007 para incrementar sus ventas entre las
Pymes, la Business Systems, dirigida por Marc Dupaquier, pasó a hacerse cargo de la comercialización de los System i
inferiores al modelo 570. Shearer dejó de ser responsable de la línea de productos System i y pasó a ser vicepresidente de
marketing y ejecutivo de líneas de negocio en la división Power Systems. Finalmente, y como último paso de esta reorgani-
zación, en enero de 2008 la Business Systems se ha convertido en una mera organización de ventas y marketing para
clientes y, dentro del Grupo de Sistemas y Tecnología al frente del cual sigue Bill Zeitler, un veterano ex director del AS/400,
aparece una nueva división, la Modular Systems que ha absorbido la línea de productos System x.

IBM: “The new Power Equation”
¿Y, aparte de todo este lío de cargos y responsabilidades, qué
hay de nuevo? Pues que está a punto de celebrarse la reunión
INDICE DE ANUNCIANTES MARZO 2008
Empresa Página
AMERICAN TOP TOOLS ..................... Interior portada
AMERICAN TOP TOOLS ....... Interior contraportada
CACOVAI ................................................................................ 19
GUÍA ................................................................................. 40, 41
IBM .................................................................. Contraportada
COMON ESPAÑA ................................................................. 25
SOFTWARE GREENHOUSE .............................................. 15
SUSCRIPCION ServerNEWS ............................................ 35
TANGO/04 ................................................................................ 9
VISION SOLUTIONS ............................................................ 15
anual de COMMON USA y todos los expertos del sector an-
dan haciendo cábalas acerca de una presentación especial
por parte de IBM, prevista para el día 2 de abril. De acuerdo
con la página web del evento (http://www.common.org/
conferences/2008/annual/), los asistentes podrán escuchar
en persona a Mark Shearer, vicepresidente de marketing y
ofertas, así como a Ross Mauri, General Manager de Power
Systems, cuando conjuntamente anuncien una importante
iniciativa de IBM denominada “The New Power Equation”.
¿...? Sobre este tema, en otro artículo de IT Jungle (http://
www.itjungle.com/tfh/tfh030308-story06.htm) se especula no
sólo sobre el posible lanzamiento de dos nuevos servidores
basados en POWER6, los 520 y 550, sino también sobre una
nueva estrategia de ventas donde, de una parte se crearían
productos Power y de otra dos divisiones se encargarían de
su comercialización, bien fueran sistemas de gama alta
(Enterprise Systems Division) o de gama baja y gama media
(Business Systems Division). Habrá que esperar al 2 de abril
para saber qué es lo que se está cocinando en IBM. ■
Como sabes, esta información es estrictamente confidencial. Aunque nosotros
neguemos haberlo dicho o escrito, te autorizo a que obres en consecuencia

34 ServerNEWS MARZO 2008 www.help400.es