Servernews -182 (marzo 2008)

182

editorial

El usuario tiene derechos

C

on los años, y como profesional informático, uno va adquiriendo experiencia no sólo en el campo del desarrollo de aplicaciones sino tambié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 comprometidas que, con el tiempo, nos han hecho acreedores de una cierta mala fama y de que, en general, se nos acuse de prestar poca atenció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 finalizar, 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, ClaireMarie 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:

Imagen de la portada: Mike Friehauf Suscripción: Anual (10 números al año, no en Julio y Agosto). España: 96 euros (IVA incluido). Extranjero: 180 $ USA (incluido el envío por Correo Aéreo). Se distribuye a final de mes. © Publicaciones HELP400, S.L. Se prohibe la reproducción total o parcial de los artículos aparecidos en este número sin la autorización expresa por escrito de la empresa editora, titular del Copyright. Todos los derechos reservados en cualquier idioma. ServerNEWS es una publicación independiente de grupos de usuarios y/o de distribuidores de marcas. De las ideas expuestas en los artículos firmados son responsables sus autores. Corresponde al lector el asegurar que las noticias, 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 por International Business Machines.

www.help400.es

• 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 respuestas adecuadas, • los productos (hardware y software) tienen que ser fáciles e intuitivos de usar. Lo que viene a decir, en resumen, es que los usuarios tenemos derecho a disponer de un servicio de calidad. Inmediatamente hubo una reacción de los lectores de Business Week que pedían que se empezara a aplicar rápidamente el código. También como consecuencia aparecieron las respuestas de los teóricos informáticos dudando de la posibilidad de construir sistemas realmente “intuitivos”. En este número, que temáticamente hemos centrado en la Gestión de Proyectos podemos encontrar argumentos y metodologías que, como mínimo, nos ayudarán a mejorar esta percepción negativa de los usuarios. Ante una nueva aplicación, el prepararla convenientemente no sólo nos permitirá atender mejor la “lista de deseos” del usuario sino que también nos permitirá ganar su aprecio y respeto.

Antonio Montía [email protected] MARZO 2008 ServerNEWS 3

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

equipo editorial

en portada

Director: Antonio Montía Redacción: Carlos Bell, Alberto C. Blanch, Equipo internacional de iSeries NEWS Colaboradores habituales: Jaime Gustavo Estany, José Mª Martín, Lluís Peiret Traducciones: Pere J. Francisco Brumós

10

Recopilación y documentación de requisitos por Russ Bartlett El usuario final de una aplicación es la persona a la que va destinada una aplicación una vez que ésta ha superado las fases de desarrollo. Descubra cómo conseguir requisitos de los usuarios claros, concisos, fáciles de cuantificar y de probar.

producción Realización: Media Limits S.L. Maquetación: Ramiro Esteve Coll Impresión: G2B gràfic S.L. Distribución: Unipost S.A.

administración

14

Suscripciones : Nuria Navarro Publicidad: Tel. 34- 932 310 049 Fax: 34-932 310 309 Servicio HelpNet: www.help400.es

Cómo decidirse por una solución para el desarrollo de aplicaciones por Chris Maxcer Si se pregunta si, para equipos pequeños, no sería mejor adquirir una herramienta de desarrollo de aplicaciones en vez de intentar aprender nuevos lenguajes y técnicas, puede que en este artículo halle la respuesta.

edita PUBLICACIONES

Deposito legal: B-2757-90 I.S.S.N. 1698-4501 APTDO. DE CORREOS 8003 - 08080 Barcelona Gran Vía Corts Catalanes, 715, Entlo. 3ª 08013 - Barcelona Tel.: 932 310 049 E-mail: [email protected] 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: [email protected] www.viacomp.net Perú COMMON PERU Bajada Balta 131, Of. 10, 2º Piso Miraflores Lima 18, PERU Telf. y Fax: 46 31 32 Paraguay ANGEL LIERNUR E HIJO P.O. BOX 2448 ASUNCION - PARAGUAY [email protected] e-mail: [email protected]

4 ServerNEWS MARZO 2008

opinión

8

La web convierte a las empresas en compañías de software por John Ghrist El fin de las aplicaciones web es servir a personas que no tienen la obligación de tolerar programas malos, por tanto han de hacer correctamente todo lo que se supone que deben hacer. Y eso las sitúa al mismo nivel de exigencia que en el desarrollo de software comercial. 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 importante 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 todos los participantes, se solucionan numerosos problemas. Hallará más información en http://www.help400.es/forum.htm

1

Parámetros y tipos de datos de las API

12

Como evitar el fracaso de un proyecto

SECCIONES HABITUALES

Por Paul Conte Formando parte de la temática de portada de este número, presentamos diez técnicas garantizadas para conseguir que un proyecto de desarrollo fracase (y diez remedios infalibles para asegurarse de todo lo contrario)

3 6

Editorial Novedades

40 42

Guia Confidencial

Por Bruce Vining Iniciamos una nueva serie de artículos, genéricamente titulada como “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.

www.help400.es

MARZO 2008 ServerNEWS 5 MARZO 2008 ServerNEWS 5

novedades Tango/04 consigue los mejores resultados de su historia en 2007 T

ango/04 Computing Group, líder europeo en desarrollo de software para Gestión de Sistemas, Auditoría de Seguridad y Gestión de Servicios de Negocio (BSM) ha conseguido resultados financieros extraordinarios en el ejercicio 2007, finalizado el pasado 31 de diciembre. La empresa ha dado beneficios por decimoquinto año consecutivo, con las ventas internacionales creciendo a más del 30% interanual. El crecimiento ha sido más notable en América Latina, alcanzando un crecimiento extraordinario que la consolida como líder en dicho mercado, con un aumento de ventas del 76,4%. “Estamos muy contentos con estos resultados”, dice Raúl Cristián Aguirre, Gerente y Fundador de Tango/04, “evidentemente estamos acertando con nuestro nuevo enfoque de monitorización 1 – 2 – 3, su facilidad de uso y sus cortos tiempos de implantación. Conseguimos éxitos continuamente justo donde nuestros competidores están fallando.” Durante 2007 se añadieron más de 100 nuevos clientes, incluyendo a ING, Citigroup, Nike, FMO, Boehringer Ingelheim, Helvetia Previsión, FiatC, Dolce & Gabbana, Louis Vuitton Malletier, Costco, Bayer CorpScience, Zurich Seguros, Mapfre, Pernod Ricard, Seur Geopost, Swiss Medical Group, Televisa, EDS, BBVA Previsión, Industrial Bank, Center Parcs, Euronet, etc. “Diez de las veinte entidades financieras más grandes del mundo son ya nuestros clientes. Tenemos éxito tanto en proyectos de Seguridad como en los de Gestión de Servicios e Infraestructuras. Hemos presentado productos innovadores y únicos para simplificar las tareas diarias de los profesionales de TI. Año tras año vamos superando hitos históricos en un mercado súper competitivo como es el de la monitorización multiplataforma. Estamos preparados para ser líderes”, añade Aguirre. Para apoyar el crecimiento continuo, Tango/04 ha abierto durante 2007 nuevas oficinas en Estados Unidos, Brasil y Colombia. También se han mejorado las operaciones a través del canal con nuevos o renovados acuerdos con partners como IBM, PricewaterhouseCoopers, Electronic Data Systems (EDS), PST Business Solutions, Moores Rowland (India) (parte de BDO), Sanwa Contec (Japón), Concord (Taiwán) y muchos otros. “Tenemos plena confianza en que en 2008 volveremos a batir todos los récords. Tenemos numerosas oportunidades comerciales abiertas, vamos a lanzar nuevos productos y el mercado mundial está madurando velozmente para soluciones como las nuestras: prácticas y que aporten un gran valor rápidamente. Creo que vamos a hacer historia”, concluye Aguirre. 1-2-3: Con Tango/04, llega la monitorización integral Tango/04 es la única solución de monitorización en tiempo real que permite controlar y reaccionar de manera proactiva ante cualquier incidencia que afecte a la empresa, ya sea de seguridad, de infraestructura, o de negocio: 1) Infraestructura TI: Servidores multiplataforma, base de datos, dispositivos de red, etc. 2) Seguridad: Auditoría y Cumplimiento de Leyes y Regulaciones (LOPD, SOX, HIPAA, etc.) 3) Servicios de Negocio: Aplicaciones, Niveles de Servicio (SLM) y gestión de los servicios del negocio Para más información, Telf.: 932.749.051 - www.tango04.es

■ Según axesor, la

creación de empresas informáticas desciende un 12,4% en 2007 Un total de 2.453 nuevas sociedades mercantiles se han incorporado al sector informático español en 2007. Así lo refleja en su último “Estudio Radar sobre el sector informático” axesor, empresa española especializada en el suministro de información empresarial por Internet, que analiza la situación de altas y disoluciones de empresas del sector TIC a lo largo del año pasado, tomando como base la clasificación nacional de actividades económicas CNAE. 6 ServerNEWS MARZO 2008

Los subsectores analizados por axesor en su informe son: Consulta de equipo informático; Consulta y suministro de aplicaciones informáticas; Actividades de proceso de datos; Actividades relacionadas con bases de datos; Mantenimiento y reparación de equipo informático, y Otras actividades relacionadas con la informática. Comparando los datos con los registrados en los años 2005 y 2006, se observa tanto un descenso en el número de constituciones como un incremento en el número de disoluciones. Respecto a 2006, año en el que se crearon un total de 2.800 empresas en este sector, se ha producido un descen-

so del 12,4% en la creación de empresas informáticas, lo que supone 347 sociedades menos Por comunidades autónomas, Madrid encabeza la lista de creación de empresas informáticas, con 688 nuevas sociedades, seguida por Cataluña con 583 y en el tercer puesto Andalucía, con 280. Cierran la clasificación Ceuta y Melilla (2 nuevas empresas informáticas) y La Rioja (3). El segmento que mayor dinamismo presenta es el de consultoría y suministro de aplicaciones, con 1.872 nuevas sociedades mercantiles. Para más información, www.asexor.es

■ Econocom abre nuevas oficinas en Barcelona

Econocom, empresa líder en renting y gestión de activos informáticos y de telecomunicaciones, ha abierto nuevas oficinas en Barcelona “para hacer frente al crecimiento que hemos experimentado en la región en los últimos meses”, comentó Ángel Benguigui, Director General de Econocom España. La nueva sede de Econocom en Barcelona está situada en Roger de Lluria, 50. Con este cambio, Econocom continúa con su estrategia de aumentar el compromiso con Catalunya a más largo plazo. Según Benguigui, el crecimiento que está experimentando el renting tecnológico en todo el país está siendo más acusado en Barcelona, “donde la cultura del Renting está muy arraigada. Aunque nuestra sede central permanecerá en Madrid, porque es un centro de negocios clave en España, Barcelona es un mercado que empieza a ganar protagonismo en el crecimiento de nuestra empresa. El mercado español es, cada día, más receptivo al Renting IT. Cada día más empresas apuestan por esta opción en lugar de la compra, debido a los beneficios inmediatos que experimentan en términos económicos, financieros y de gestión”. A través de las soluciones de Renting que ofrece Econocom, las empresas no tienen que adquirir y vincular su capital a equipos informáticos sometidos a una rápida depreciación. Además, para hacer frente a los continuos desafíos del mercado y disfrutar de los beneficios ofrecidos por las tecnologías más modernas e innovadoras, las empresas tendrían que adecuar continuamente sus activos TI, con el riesgo de incurrir en gastos insostenibles. “El Renting permite mantener siempre actualizado el parque TI y poder optimizar su coste total”. Fundada en 1984, Econocom está presente en los ocho mercados más importantes de Europa y actualmente cuenta con más de 2.200 empleados. Para más información, Telf.: 914.119.120 www.econocom.es www.help400.es

■ ACOM Solutions

introduce el EZContentManager para System i Esta firma estadounidense es conocida en España por sus productos para la creación de formularios 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 EZContentManager, cuyo objetivo es la captura y almacenamiento de los documentos, creando un sistema de índices que nos permitirá la gestió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 autorizaciones necesarias, y creando flujos de información que alcanzan necesariamente los objetivos y destinos establecidos. De esta forma se gestiona el ciclo de vida de los documentos, originados por las diferentes aplicaciones, y se hacen accesibles al personal autorizado de forma segura, intuitiva y familiar. El EZContent Manager está diseñado pensando en las necesidades de la próxima generación de software Enterprise Content Manager (ECM) apoyándose en interfases de usuario basados en navegadores y adaptándose a arquitecturas informáticas flexibles. Al igual que ocurre con EzeDocs y EZPrint, este producto se comercializa en España por la empresa American Top Tools, S.L. que desde 1986 está al servicio de la comunidad AS/400 distribuyendo aplicaciones y utilidades que complementan y mejoran los AS400, iSeries y System i. Para más información, Telf.: 933.191.612 email: [email protected]

■ 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 Documental.” LISVA, con más de 40 productos/soluciones no necesita esperar a 2010. Ofrece a sus clientes la Solución que deseen totalmente GRATIS. No hay truco. El cliente, al comprar el hardware (multifuncional y/o impresora), puede seleccionar cualquier producto entre una gran variedad: Gestión Documental, Control de Costes de Impresión, Formularios Electrónicos, Conversión a PDF, Impresión segura...y muchos más. ¿Cómo funciona el Programa 2010? · El cliente, al comprar las multifuncionales o impresoras, indica a su proveedor habitual que se ponga en contacto con LISVA. El cliente ya ha hablado con LISVA y quiere un producto software determinado. LISVA tiene más de 40 productos e incluso puede desarrollar uno nuevo, si un cliente lo solicita. · El proveedor de equipos llega a un acuerdo con LISVA. · El cliente recibe por un lado el hardware solicitado inicialmente al proveedor y de LISVA recibe el producto de software gratis. Que algo sea GRATIS resulta normalmente bastante increíble y suele producir desconfianza, pero una vez explicado el funcionamiento del Programa 2010, el 100% de las empresas contactadas se han inscrito. El Programa está en proceso de implantación en Europa y Latinoamérica. Para más información, Telf.: 918.039.495 email: [email protected]

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 ([email protected]), 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

Una ocasión única erverNEWS y System iNetwork le proponen participar en el 2008 IT Leaders Forum que tendrá lugar en Denver, Colorado (EE.UU.) de los días 20 al 23 de julio, en las mágníficas instalaciones del Inverness Hotel and Conference Center. Únase a los líderes en un evento diferente a cualquier otro del mercado, centrado en la estrategía, toma de decisiones y el valor de las TI en su negocio. Esta conferencia ejecutiva incluye seminarios en profundidad de Gatner, IBM, System iNEWS... ¡y mucho más! Para más información, incluido agenda, precios y perfil de los ponentes, acceda a www2.systeminetwork.com/itleadersforum/

S

Common Europe Annual Congress Barcelona, del 17 al 21 de Mayo de 2008 El evento de formación de Bajo Coste y Alto Valor del mundo “i”

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 organizado por usuarios significa que el precio de la inscripción puede mantenerse muy bajo ya que se eliminan la mayoría de los sobrecostes generados por organizaciones comerciales. · Enfoque: El evento de Common Europe está dedicado al i5/OS principalmente en la plataforma System i. Habrá sesiones presentadas tanto por especialistas de IBM como por desarrolladores independientes y las habrá tanto técnicas como de gestión y dirección. También tendremos a usuarios compartiendo sus experiencias en el mundo real. Todo ello asegura una oferta muy equilibrada en el congreso. • Exposición: El congreso de Common Europe ofrece una amplia exposición en la que los delegados podrán encontrar los productos más novedosos y sus implantaciones tecnológicas desarrolladas por empresas del sector. • Duración: El congreso de Common Europe Congress es un evento de 3 días, que empieza en domingo lo que significa que sólo necesita 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 darán cuenta de que la oferta de Common Eruope es única y decidirá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

por John Ghrist

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

E

stoy convencido de que todos conocemos en alguna medida el proceso de producción del software. Aunque formemos parte de una de las escasas empresas que únicamente utilizan aplicaciones hechas a medida, al tener que mantener al día las distintas versiones de i5/OS y Windows, la mayoría de nosotros 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 productos, ¿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 programas a medida para sus procesos internos ya se enfrenta a esta realidad. Cuestiones como seguir el progreso de las nuevas versiones, garantizar dentro de lo posible que el software no contiene errores antes de presentárselo a los usuarios internos, 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 tiene 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 desde la primera versión. Y eso sitúa al desarrollo de aplicaciones web en la misma liga que la producción de productos de software comerciales. Una aplicación web tiene que funcionar bien porque ninguna circular del presidente de la empresa 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 estuviera 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 subconsciente, el suyo con los demás sitios web que hayan visto. Enfrentarse a esta situación puede obligar a pensar siguiendo una lógica distinta a la que estamos acostumbrados. La 8 ServerNEWS MARZO 2008

preocupación por ofrecer una GUI que sea intuitiva y atractiva pero no demasiado recargada y por asegurarse de que no hay errores importantes ni siquiera en funciones secundarias, 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 pensar de la misma forma. Lo único positivo es que todo el mundo, y no sólo los ejecutivos de las empresas de software, está pasando por los mismos apuros. ¿Y cómo están afrontando este nuevo reto sus homólogos de otras empresas? No muy bien, por lo que parece. O al menos, esa es la situación que revela un informe reciente presentado por Interwoven, un proveedor de soluciones 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 desarrollo se dedican a proyectos hechos a medida, más de la mitad piensan que el número de proyectos realizados a medida relacionados con la web se doblarán el año que viene y el 71% está distribuyendo actualizaciones mediante procesos manuales 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 hacer 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 trabajan 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 informe 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 atención a los procedimientos para crear aplicaciones web. E intentar 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 declara mientras sale de la habitación: “Voy a averiguar cuáles son los requisitos de los usuarios... 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, documentació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, documentació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 realmente interesante es el diseño y programación de la base de datos... es lo que mola, ¿no? Fuera de este ámbito, nos encontramos algo menos cómodos, así que solemos prestar menos atención y hacemos las tareas apresuradamente. Para ilustrar 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 contratista y por el otro al futuro dueño de la casa. El contratista 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. Mientras 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 supuesto 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 hipoté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 desarrollar sistemas enteros de forma parecida. A menudo, esperamos 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 funcionamiento. La complicación aumenta en un modelo de desarrollo 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 requisitos, como un proceso iterativo.

Obtención de requisitos de calidad Ahora vamos a explorar algunas formas de obtener requisitos de mayor calidad. Nos centraremos en el método tradicional usado para la fase de obtención de requisitos y luego veremos 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 resolver 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 sistema 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 adelante 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é familiarizado. 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 debe profundizar para entender detalladamente los problemas y necesidades de los usuarios. Los requisitos se clasifican a grandes rasgos en dos tipos: funcionales y no funcionales (se describen en el apartado siguiente). Además, como parte de este proceso, también se define el alcance del sistema y los objetivos del proyecto. Todo este proceso, así como las fases posteriores, puede ser iterativo a lo largo de todo el ciclo vital del proyecto. Durante esta fase, nuestro objetivo es capturar y anotar con precisión los requisitos principales. Análisis de los requisitos. Aquí es donde clasificamos y creamos modelos de los requisitos usando varias técnicas de creación de modelos, como por ejemplo, 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, necesitamos 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, recursos o presupuesto suficiente para satisfacer todos los requisitos de los interesados. Los requisitos se intercambian y canjean en función de las restricciones del proyecto. De hecho, los usuarios con más experiencia suelen pedir más cosas de las que realmente necesitan anticipándose a este proceso de negociación. En la práctica, el análisis de los requisitos suele conducir a la adquisición de más requisitos conforme se conocen más detalles. Si comparamos este método con otros en los que se reduce la planificación del proyecto, comprenderemos porqué en éste se acaba sacrificando la calidad para ajustarse a la fecha de entrega. Especificación de los requisitos. Aquí es donde generamos las especificaciones del software creando documentos que se usarán para crear las especificaciones del sistema (enseguida 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

puede hacerse de forma gradual ordenadamente y de forma interativa. Esto no sólo se aplica a la “fase” de especificación de requisitos de los sistemas del proyecto, sino también a todo el proyecto en su conjunto.

MARZO MARZO 2008 2008 ServerNEWS ServerNEWS 11 11

■ EN PORTADA Ahora vamos a ver con más detalle cómo se realiza la especificació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 definen lo que el sistema debe hacer desde el punto de vista del usuario para cumplir los objetivos que se le exigen. Los requisitos no funcionales pueden subclasificarse en restricciones y cualidades. Las restricciones imponen límites al diseño o a las funciones. Las cualidades son propiedades o caracterí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 resulte 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 cualidades 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 información del catálogo, un requisito mejor afirmaría que el sistema debe permitir la recuperación de información del catálogo en dos segundos, lo que es comprobable desde el punto de vista 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 conjunto. 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 demasiados requisitos, se pueden introducir errores e incoherencias. • 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 compatibles con los requisitos en su conjunto. No debe haber incoherencias 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 segundos 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 documento. 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 documentos que usados para compilar este documento. 1.5. Visiones generales: ofrece una visión general del dominio 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 funcionales 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 posibilidades 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 software 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 nombre del cliente, el saldo de la cuenta y la fecha de la última compra). Un análisis posterior puede desvelar requisitos adicionales, 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 cuenta 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 sistema. 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 del prototipo

Documentación 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 requisito 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 innecesaria 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 siguiente 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 mantenimiento” 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 funció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 mantenimiento 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 confusiones, 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 adopte 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 sistema que se va a desarrollar.

Definición de prototipos Ningún artículo que trate sobre los requisitos estaría completo 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 usuarios. En la Figura 2 se ilustra el modelo del ciclo vital cuando 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 disminuyó el interés por ellos. Algunas organizaciones han tenido mucho éxito usando lenguajes 4GL para desarrollar aplicaciones mientras que a otras no les ha sido tan útil. No obstante, en la actualidad, la herramienta de definición de prototipos 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 (consideradas 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 requisitos del sistema. La definición de prototipos también funciona 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 prototipo es una buena estrategia para ayudarles a aclarar sus necesidades. En algunos casos, he realizado proyectos en los que la herramienta 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 ambas 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 interés por huir del ubicuo modelo del proceso «en cascada». En la actualidad, los requisitos de las empresas y de los productos cambian a un ritmo cada vez mayor y, por ende, también lo hacen los requisitos de los usuarios. Los informáticos hemos de reconocer este hecho y adaptarnos en consecuencia. La informática sigue evolucionando por lo que nosotros tambié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

E

por Chris Maxcer

l verano pasado asistí a una lluvia de ideas de un profesional del entorno sobre el desarrollo de aplicaciones en el mundo actual de los System i. No recuerdo muy bien cuál era el contexto, pero me quedé con una de sus ideas: “Me pregunto si, para equipos de desarrollo pequeños, no sería mejor adquirir una herramienta de desarrollo de aplicaciones en vez de intentar aprender nuevos lenguajes y técnicas”.

de aprendizaje y exigen invertir en una metodología para el desarrollo de aplicaciones. En el mundo del System i estas soluciones también suelen ser de distintos tipos. Por ejemplo, muchos proveedores de soluciones tienen más de un paquete de desarrollo de aplicaciones dependiendo de las necesidades concretas de cada empresa, de modo que las etiquetas pueden ser doblemente complicadas. A efectos prácticos las llamaré soluciones para el desarrollo de aplicaciones.

De vuelta al asunto que nos ocupa

Regresando a aquella conversación, mi contertulio compartía su experiencia sobre organizaciones que han podido asuSe 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 aplicacia 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 recuerordenador y aunque el nombre es lo bastante do del verano pasado, se basaba más en la idea de que algugené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 probable que progresen en sus conocimientos. En un océano de cambios, ellos simLos programadores pueden invertir plemente se mantienen a flote pero acabarán cansándose. Con suerte, en en formación para adquirir nuevos ese momento pasará el barco de su juconocimientos o bien adquirir una bilación; pero lo más probable es que se vean nadando para huir de los tibusolución completa y robusta para el rones o en un bar de la playa tomando desarrollo de aplicaciones. margaritas, situaciones que pueden obligarles a actuar para usar lenguahacía mucho tiempo. Existen herra- jes y técnicas de programación más modernas o más conocimientas 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 desatante, RAD incluye una filosofía, dependiendo de lo rrollo de aplicaciones. Las dos opciones tienen ventajas e inriguroso que se quiera ser, del desarrollo iterativo basado en convenientes, al menos dos escuelas distintas de pensamienprototipos. 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énmo 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écnicas de programación, pueden utilizar varios lenguajes y constantemente están aprendiendo cosas nuevas. Todos ellos suelen 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 pregunten si el uso de una solución para el desarrollo de aplicaciones 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 herramientas y soluciones de IBM. Si no es de IBM, ni siquiera cabe plantearse la posibilidad. En este mismo sentido, algunos programadores y responsables se ven entorpecidos por los presupuestos y, a veces, por las actitudes: jamás comprará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 usarse 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 posibilidades. ¿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 departamentos 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 internamente) 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 terceros para desarrollar componentes basados en GUI y aplicaciones 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 desarrollo del “i” son capaces de desenvolverse bien con aplicaciones GUI modernas. 16 ServerNEWS MARZO 2008

5. Las aplicaciones basadas en Windows parecen bastante baratas y los partidarios de Windows del grupo están preparados 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 desarrolladores 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 repente 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 fuertes, 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 tecnología al problema”. De forma parecida, los proveedores conocen casos de programadores o responsables que utilizaban ciertas herramientas 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 utilizando 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 extraordinarias en las que publicar un montón de información de la empresa. 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 mayorí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 realmente 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 lenguajes de programación; también están los servidores de aplicaciones, 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 arquitectura y un juego de herramientas de desarrollo, y en el departamento 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 experiencia, 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 aplicaciones señalan curvas de aprendizaje similares, aunque siguen variando mucho dependiendo de la herramienta, la experiencia 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 distintas ventajas y desventajas, en función de lo que quiera conseguir el grupo de desarrollo del System i. Algunas soluciones crean código en Java y otras en RPG o PHP o una combinació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 aplicació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 empresas 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 inversión puede calcularse en función del número de desarrolladores 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 productividad de un orden de magnitud en comparación con la programació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 herramienta para aumentar la productividad permite cambiar las reglas 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 demanda de aplicaciones crece casi exponencialmente”. ¿Más demanda? Eso es lo último que necesita su equipo de desarrollo, ¿verdad? Pues no. Una mayor demanda combinada con un buen control que garantice que las aplicaciones aportan valor a la empresa, dará como resultado una organización de desarrolladores que beneficiará a la compañía. Naturalmente, la gente que disfruta manteniendo aplicaciones durante todo el día, alucinará con las soluciones para el desarrollo de aplicaciones.

Reductores de complejidad “Muchos de los programadores que empezaron su oficio aprendiendo 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 distintas bases de datos y no tratan con un ordenador sino con una red”, comenta Stangarone. “Se trata de un mundo 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 mPower 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 ventajas de una buena solución para el desarrollo MARZO MARZO 2008 2008 ServerNEWS ServerNEWS 17 17

■ EN PORTADA de aplicaciones es que protege a los desarrolladores no sólo del mundanal y repetitivo proceso de programación, sino tambié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 programador 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 “seguro 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 aplicaciones 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 aplicaciones del mundo del System i fácilmente pueden tener clientes que cuentan con un solo desarrollador o con varias docenas. Si se dispone de un cierto número de desarrolladores, una solución para el desarrollo de aplicaciones tiene ventajas adicionales. “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 tendrá cinco implantaciones ligeramente distintas del estándar, declara. “Con un generador de código, los estándares se implantarán exactamente de la misma forma cada vez y se acabará teniendo un código más estándar”, explica.

Código ilegible Entre quienes evitan las soluciones para el desarrollo de aplicaciones, 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 mantenimiento 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 mayorí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 clientes cómo se genera el código para que no se sientan atrapados y conserven el control absoluto”, explica Alex Roytman, director técnico de Profound Logic Software. La solución de la compañí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 mismo 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 menor 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 aplicaciones de un ISV es que la empresa con la que trabajan desaparezca 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 tambié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 muchas 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 estacada, pero sus soluciones y soporte a veces sí. “En realidad, IBM cambia de dirección más a menudo que nosotros”, indica 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 contacto 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 conozcan RPG? ¿Le gustaría tener la posibilidad de migrar una aplicación –ay– a otra plataforma? Si ha respondido afirmativamente a alguna de estas preguntas, puede que sea el momento de (re)considerar la posibilidad de adquirir una solución para el desarrollo de aplicaciones. ■

Chris Maxcer es el redactor de noticias de System iNEWS y está especializado 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

G

por Alan Seiden

racias al soporte del popular lenguaje de programació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 prudentes 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óximo 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 consideran fiables en Zend Core para i5/OS versión 2.0.1 (es decir, PHP 5.2.1.)

La primera línea de defensa

Programación y sistemas

▲ ▲ ▲

20

Independientemente de las aplicaciones que ejecute, un entorno de ejecución seguro reduce el riesgo de sufrir problemas, tanto conocidos como desconocidos. El experto en seguridad de PHP Chris Snyder, coautor con Michael Southwell de “Pro PHP Security” (Apress, 2005), recomienda varios niveles 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 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 ataques 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 cifrado de datos, las estructuras de directorios, los archivos de configuración y la actualización regular de PHP.

ServerNEWS MARZO 2008

Mantenga actualizados PHP y las aplicaciones En cada nueva versión de PHP se mejora la seguridad eliminando vulnerabilidades notificadas por la comunidad de usuarios. 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 administradores se mantengan al día configurando actualizaciones automáticas desde la Zend Network, que aplicará parches y actualizaciones según se necesite para mantener la seguridad. Vanunu, consultor del laboratorio de Zend en Ramat-Gan (Israel) y jefe de equipo del departamento de Servicios mundiales para i5 de Zend, señala que IBM ha dispuesto que todos los clientes de System i puedan conseguir estas actualizaciones 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). Puede 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 siguiente: 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 inmediatamente o de forma planificada. Además de las actualizaciones de PHP, las aplicaciones web basadas en PHP más conocidas también publican sus propios 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 debemos mantenernos informados sobre vulnerabilidades y las correspondientes actualizaciones usando estos métodos: • Resúmenes de SecurityFocus, coordinados por Daniel Convissor (phpsec.org/projects/vulnerabilities/securityfocus.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

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 actualizació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

www.help400.es

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 internos como “el índice de la matriz está fuera de los límites”. Necesitamos estos mensajes cuando desarrollamos nuestras 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 confidencial, 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 vulnerabilidades favoritas. Actualmente ésta es una técnica tan difundida 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). El uso más habitual de esta función es un sencillo documento de HTML denominado phpinfo.php, que contiene el breve fragmento de PHP siguiente:

Programación y sistemas

Por cuestiones de eficiencia, PHP no comprueba si las variables se han inicializado antes de usarlas. Cuando los programadores 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 establecerse 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 asignaciones 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.

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 vulnerabilidades asociadas a register_globals.

Este minúsculo pedazo de código se ampliará hasta convertirse 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.

▲ ▲ ▲

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:

MARZO 2008 ServerNEWS

21

■ CONFIGURAR UN ENTORNO SEGURO Aunque phpinfo() es una herramienta de depuración de valor 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 aplicación, pero deberá tener cuidado de ocultar este acceso, posiblemente 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 convenio phpinfo.php, que todo hacker busca cuando sondea el sitio de una víctima potencial.

Cifrar los datos

Programación y sistemas

▲ ▲ ▲

22

El experto en seguridad Chris Snyder recomienda cifrar los datos (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 muchos 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 sobre tarjetas de crédito u otro tipo de datos personales o confidenciales. El método de cifrado más habitual es SSL/TLS (Capa de conexión segura/Seguridad de la capa de transporte) que cifra 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, incluyendo los datos que se hayan codificado en campos de formulario 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 sesiones 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á instrucciones sobre cómo configurar SSL/TLS en el InfoCenter de i5/OS.

Archivos separados 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 directamente a los archivos internos, aunque los usan las aplicaciones (y puede que hasta se muestren a los usuarios), sino que solamente deben poder recuperarse por el código de la aplicación.

ServerNEWS MARZO 2008

FIGURA 1 Salida de Phpinfo() (fragmento) Los archivos internos presentan un riesgo si los usuarios tienen 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 archivos de configuración que contienen contraseñas también suelen considerarse archivos internos. Estos deben guardarse 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:

Otra categoría peligrosa es la de los archivos subidos por los usuarios. Estos archivos nunca deberían ponerse en el directorio raíz de los documentos. Un usuario malintencionado 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 archivos 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

www.help400.es

allow_url_fopen (valor por omisión: On; valor recomendado: 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 archivos remotos mediante URL. Desactive la opción si la aplicació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 archivos; valor recomendado: las carpetas necesarias para la aplicación). Cuando se especifica open_basedir con una lista de carpetas, mandatos como readfile() y fopen() solamente podrán acceder a archivos de las carpetas especificadas. En consecuencia, los scripts no podrán leer datos confidenciales o modificar archivos que estén en otros sitios. Si se especifican varias carpetas, debe separarse mediante dos puntos (:), aunque los sistemas 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 /informes.

PHPSecInfo

cualquier intento de incluir en los archivos que se suban peticiones 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

www.help400.es

Con algunos cambios sencillos, la configuración de PHP puede evitar o limitar en gran medida el mal uso de las aplicaciones. 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 entorno, el paso siguiente será escribir código seguro. En mi próximo artículo explicaré técnicas para filtrar la entrada e interpretar la salida con el fin de malograr la inyección de código SQL y la vulnerabilidad XSS (cross-site scripting). Quiero agradecer a Chris Snyder y Shlomo Vanunu su ayuda 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

Programación y sistemas

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 remotos 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 capacidades 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 restringen a qué recursos puede acceder un script son estas: allow_url_include (valor por omisión: Off; valor recomendado: Off). El valor Off evita que las aplicaciones ejecuten (“incluyan”) el código que se encuentra en servidores remotos. Normalmente, mandatos como include() o require() pueden 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).

El poder protector de la configuración

▲ ▲ ▲

FIGURA 2 Salida de PHPSecInfo (fragmento)

La herramienta gratuita PHPSecInfo del PHP Security Consortium analiza la configuración y comunica problemas potenciales de seguridad (Figura 2). PHPSecInfo es una herramienta experimental; sus sugerencias son genéricas y no deben seguirse ciegamente. Con todo, se trata de una herramienta de gran valor educativo y vale la pena descargársela de phpsec.org/projects/phpsecinfo.

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 la naturaleza distribuida extiende sus brazos por muchos trabajos, a veces puede que nos sintamos como si estuviéramos bregando con un pulpo. Un entorno típico puede incluir un servidor de aplicaciones (por ejemplo, WebSphere Application Server) en que se ejecutan las aplicaciones, un servidor HTTP para recibir las peticiones y archivos estáticos del servidor, una base de datos como DB2 desde la que se acceden a datos permanentes, un servidor WebFacing y otros trabajos de las aplicaciones. Recopilar los datos necesarios para depurar los problemas de rendimiento y descubrir cuellos de botella rápidamente puede consumir todo nuestro tiempo. El Supervisor de rendimiento Web (WPM), una herramienta nueva de la interfaz Web Administration de i5/OS que forma parte de IBM HTTP Server para i5/OS (DG1-5722), se creó para dar respuesta a este problema concreto. WPM recopila datos sobre el rendimiento de los trabajos que componen un entor-

Management

▲ ▲ ▲

24

sariales como entidades manejables. El estándar ARM permite que los usuarios amplíen las herramientas de gestión de la empresa directamente a aplicaciones. WPM aprovecha el estándar abierto ARM. ARM ayuda a los usuarios a integrar aplicaciones empresariales y facilita ampliar las herramientas de gestión de la empresa directamente a aplicaciones. El servidor de aplicaciones, el servidor de la base de datos y el servidor HTTP están diseñados para sacar partido de ARM. Si crea sus propias aplicaciones, también podrá beneficiarse de este soporte. En el caso de las aplicaciones y servidores desarrollados para aprovechar ARM, cada vez que se solicita una unidad de trabajo y cada vez que un trabajo del proceso hace su parte del trabajo, se anotan entradas que registran el tiempo que tarda cada trabajo en realizar su parte del trabajo. La herramienta WPM recopila todos los tiempos de las transacciones y las entradas de todos los trabajos del System i que forman parte del entorno web. Los datos de estos trabajos se presentan en una interfaz, mediante la cual pueden verse fácilmente todos los El Supervisor de rendimiento Web (WPM), tiempos de las transacciones y de las respuesuna herramienta nueva de la interfaz Web tas de cada parte del entorno web. Estos datos pueden adaptarse para que muestren los tiemAdministration forma parte del IBM HTTP 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 aplimienta, 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 cueWPM proporciona una interfaz para que los administradollos de botella. res puedan consultar fácilmente los trabajos más importanDe 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 permite ver datos concretos de rendimiento de cada trabajo (por Instalación de WPM ejemplo, el número de transacciones que ha procesado cada Antes de iniciar el Supervisor de rendimiento Web, asegúretrabajo 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|Servidores y seleccione TCP/IP. describe un método habitual de integrar aplicaciones empre-

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 ratón en Administración HTTP y seleccione 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 sistema IBM System i (por ejemplo, http://systemi.acme.com:2001). 5. Pulse IBM Web Administration para i5/OS. 6. Desde la interfaz IBM Web Administration para i5/OS, seleccione el servidor que le gustaría supervisar. 7. En el panel de navegación, despliegue Rendimiento web y seleccione Supervisor de rendimiento Web.

FIGURA 1 Herramienta Supervisor de rendimiento Web

Una vez realizados los siete pasos, aparece la página de introducción de WPM, donde ya puede empezar a supervisar el rendimiento del entorno web.

Supervisión del entorno web

Management

▲ ▲ ▲

26

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 utilizar esta herramienta deberá planear con antelación una desconexión del FIGURA 2 servidor. 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 daconfiguraciones 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 servidores y trabajos activos del entorno. Para cada trabajo pueguraciones para activar la recopilación de datos de ARM de verse el usuario actual, el porcentaje de utilización de la • inicia la recopilación de datos de ARM • reinicia el servidor HTTP y las instancias del servidor HTTP CPU, la prioridad de ejecución, el número de hebras, el tiempo promedio de respuesta de cada transacción y el número de Una vez detenidos, actualizados y reiniciados los servido- transacciones completadas. Si los valores de los tiempos prores, 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.

ServerNEWS MARZO 2008

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 herramienta:

FIGURA 4 Ficha Trabajo

www.help400.es

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

Management

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 aplicación. Compare los tiempos que tarda en ejecutarse la transacción para distintos usuarios con el fin de asegurarse de que las quejas son justificadas. También puede optar por examinar 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é trabajos han procesado las peticiones de cada usuario o dirección IP. Esta información tan precisa sobre el usuario puede ayudarle a identificar qué trabajos están ralentizando el entorno web.

Aunque hay muchas formas posibles de usar la información que proporciona 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. Aunque esta instrumentación se ha diseñado para que sea lo más discreta posible, se puede producir una ligera disminución del rendimiento cuando está activada. El segundo es que estamos 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 ocupando unos cuantos brazos del pulpo, tendrá las manos libres para dedicarse a problemas más importantes o intere■ santes.

▲ ▲ ▲

FIGURA 3 Ficha Transacciones

• detiene las instancias del servidor HTTP y actualiza sus configuraciones para desactivar la recopilación de datos de ARM • detiene los servidores de aplicaciones 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 instancias del servidor de aplicaciones, devolviéndolas a su estado anterior

27

Añadir técnicas de SQL Server al repertorio de DB2 Aproveche algunas de las posibilidades de SQL exclusivas de SQL Server

C

por Paul Conte

ada vez más empresas que confiaron únicamente en el System i (o uno de sus predecesores) y en la base de datos 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 conocimiento que tenga de SQL en el System i será un buen punto de partida para empezar a encargarse 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 desarrollos. En este artículo encontrará una rápida introducción. Tipo de datos Variant

Management

▲ ▲ ▲

SQL Server admite muchos tipos de datos internos, incluyendo 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 procedimientos 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 especificado. Pero SQL Server también permite definir una columna, variable, parámetro o valor de retorno de funciones utilizando la palabra clave sql_variant, con el fin de almacenar valores 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: CREATE TABLE Articulo ( NumArt Int, RefCatalogo sql_variant, ... )

Se puede determinar el tipo de datos de una fila determinada 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 llamada 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 convertirá 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 especificar una función definida por el usuario (UDF) en la expresión lógica que define la restricción. Las UDF aumentan las oportunidades de reutilizar el código y permiten definir comprobaciones de validez complejas. Una característica interesante es que se pueden usar consultas sobre los datos existente de la tabla como parte de la restricción. Por ejemplo, se puede crear la UDF ComprobarIntervaloFecha 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 existe solapamiento de ninguna fila, ComprobarIntervaloFecha devuelve 0. Cuando cree la tabla, se puede añadir una restricción de comprobación que haga referencia a esta función: 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 cambios 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 curso. 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 valores 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áusula Group By, no sólo los subtotales jerárquicos generados 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 columnas de tipo carácter palabras, frases, prefijos de palabras, palabras derivadas, sinónimos y palabras semejantes a otras. La forma de usar Contains en una condición de búsqueda es similar a la forma de usar la palabra clave Like para especificar comparaciones sencillas. En el ejemplo siguiente se buscan filas en que la descripción del producto contenga palabras basadas en cortar: Select IdProd, DescProd From Productos Where Contains( DescProd, ‘ FormsOf (Inflectional, corta) ‘)

Para buscar descripciones de productos en que aparezca la palabra cepillo cerca de nailon, especificaríamos: Contains( DescProd, ‘ cepillo NEAR nailon ‘)

Hasta pueden buscarse palabras con un significado parecido. La búsqueda siguiente encontraría motor, propulsor, máquina y otras palabras semejantes: Contains( DescProd, ‘ FormsOf (Thesaurus, motor) ‘)

Las condiciones especificadas pueden combinarse en expresiones lógicas con los operadores And, Or y Not, como en esta expresión: ‘cable And ((cobre And Not trenzado) Or (solido And verde))’

FIGURA 1A Utilización de la palabra clave Rollup Select Case When ( Grouping( Dept ) = 1 ) Then ‘All’ Else Dept End As Dept, Case When ( Grouping( Course ) = 1 ) Then ‘All’ Else Course End As Course, Sum( Enrollment ) As EnrollSum From Classes Group By Dept, Course With Rollup

FIGURA 1B Resultado del ejemplo de la palabra clave Rollup Dept Course —————————— —————————— ————— Math 217 Math 324 Math All Physics 411 Physics 412 Physics All All All

EnrollSum 108 211 319 121 220 341 660

FIGURA 2 Utilización de la característica Try/Catch Set @RtnErrNbr = 0; Begin Try Select CustName From Customer Where CustId = End Try Begin Catch Set @RtnName = Set @RtnErrNbr = Return; End Catch;

Into @RtnName RqsId;

‘Error’; Error_Number();

Manejo de excepciones Try/Catch en procedimientos de SQL

Management

▲ ▲ ▲

30

El manejo de excepciones estándar de SQL para procedimientos 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. Si una sentencia del bloque Try (por ejemplo, la sentencia Select Into de la Figura 2) provoca una excepción, entonces 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 Error_Number para determinar el error. También hay otras

ServerNEWS MARZO 2008

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 conocer 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 plataforma. Tras leer este artículo, ya puede empezar a sacar partido a algunas de las capacidades relacionadas con SQL exclusivas de SQL Server. ■

Paul Conte es redactor técnico de System iNEWS y presidente de PCES, una empresa de formación y consultoría de Eugene (Oregón).

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

www.help400.es

P.T.A. Edificio CENTRO EMPRESAS 29590 Málaga

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 misma columna, en octubre de 2007 (número 177) os comentaba 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 comparten 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 reorganizació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

34 ServerNEWS MARZO 2008

anual de COMMON USA y todos los expertos del sector andan 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 www.help400.es