Software Guru

Estimacin de proyectos Aseguramiento de calidad Capas en J2EE
SOFTWARE GURU CONOCIMIENTO EN PRCTICA

Ao 01 No.01 Enero-Febrero 2005
ENTREVISTA:
Martn Mndez
Director de TI en GNP
Aplicando PSP y TSP
CASO DE ESTUDIO:
MUCHOS CAMINOS,
UN DESTINO
Conociendo los diferentes modelos de procesos de software
A Fondo
GXportal 4
Adems: Noticias Eventos Fundamentos Biblioteca Tecnologa Carrera
DIRECTORIO A>
Edicin Ejecutiva Pedro Galvn Coordinacin Editorial Mara Ruvalcaba Edicin y Produccin Edgardo Domnguez Direccin de Arte Oscar Smano Consejo Editorial Francisco Camargo, Guillermo Rodrguez y Ral Trejo, ITESM Campus Estado de Mxico; Hanna Oktaba, UNAM-AMCIS; Luis Cuellar, Softtek. Colaboradores Jorge Palacios, Antonio Reyes, Omar Ruvalcaba, Francisco Lpez Lira, Paulina Olivares, Raul Achoy, Luz Ma. Luckie, Isabel Chillopa, Artemio Mendoza, Ricardo Vidrio, Ricardo Domnguez, Rodrigo Garca, Mariana Prez-Vargas, Elizabeth Almeraz, Rams Rodrguez, Ariel Garca. Ventas David Gonzlez Marketing Natalia Snchez Webmaster www.aguilahosting.com Agradecimientos Hilda Lpez, Martha Kondo, AMCIS, Gastn Snchez, Martn Mndez. Contacto info@softwareguru.com.mx +52 55 5239 5502
Software Guru es una publicacin editada por Brainworx, S.A. de C.V., Parque de la Malinche No. 6, Col. El Parque, Naucalpan, Estado de Mxico. Ejemplar de cortesa. Derechos reservados por Brainworx, S.A. de C.V. Certicado de licitud de Derechos de Autor en trmite. Certicado de licitud de ttulo e ISSN en trmite. Certicado de licitud de contenido en trmite. Prohibida la reproduccin total o parcial sin previa autorizacin escrita de los editores. Se termin de imprimir en el mes de enero de 2005 en Litogrca Roma S.A. de C.V. Todos los artculos son responsabilidad de sus propios autores y no necesariamente reejan el punto de vista de la editorial.
EDITORIAL
Bienvenidos al nmero de Enero-Febrero 2005 de Software Guru. En esta ocasin hemos escogido a los procesos de software como tpico central. Este es un tema de gran inters en la industria de software mundial, pero que tiene especial importancia en Mxico y el resto de Amrica Latina. La falta de madurez en capacidad de procesos es uno de los principales puntos dbiles de la industria de software en nuestros pases. Un estudio recientemente realizado por la Secretara de Economa en Mxico, mostr que el nivel de madurez de procesos promedio en la industria de software mexicana es de 0.9 (en base a la escala dada por ISO 15504, que va de 0 a 5). Esta estadstica reeja nuestra falta de competitividad en este rubro, donde tenemos cerca de diez aos de retraso respecto a los lderes de la industria mundial. Afortunadamente estamos conscientes de esta situacin y existen diversos esfuerzos para mejorarla. Justamente hace un par de meses se llev a cabo la primera edicin de la conferencia SEPG (Software Engineering Process Group) Latinoamrica, donde ingenieros de procesos de diversos pases intercambiaron experiencias y promovieron mejores prcticas para desarrollar la capacidad de procesos en esta regin. Poco a poco las empresas demuestran un mayor inters en este tema y asignan recursos para mejorar su madurez de procesos. Sin embargo, este tema presenta gran complejidad debido a lo abstracto que es y la diversidad de posibilidades existentes. La gran mayora de las empresas no sabe qu camino tomar hacia la madurez de procesos: CMM? CMMi? ISO 15504? MoProSoft? RUP? TSP? PSP? XP? Es muy fcil perderse entre tantas opciones. Es por ello que en nuestro artculo central nos enfocamos en explicar estas opciones y cmo se relacionan entre s, para ayudar a las organizaciones a entenderlas y poder elegir el camino que ms les convenga. Equipo Editorial
P.D. Agradecemos el enorme apoyo que hemos recibido de parte de todos ustedes. Es alentador recibir sus comentarios, porras y opiniones para continuar este esfuerzo y generar un producto de gran valor para todos. Les reiteramos la invitacin para que participen a travs de los foros en www.softwareguru.com.mx o por correo electrnico en editorial@softwareguru.com.mx
02
ENE-FEB 2005
www.softwareguru.com.mx
contenido ene-feb 2005
nmero 01
EN PORTADA
Procesos de Software: Gua para el Viajero
Es un hecho que los procesos son la base para desarrollar software de calidad de manera predecible y repetible. Sin embargo, con tantas opciones, normas y modelos, es difcil saber cul es el camino adecuado. Este artculo es una gua para ayudarlo a elegir el mejor camino en este viaje tan importante.
20
Martn Mndez, Director de Tecnologa de Informacin en GNP.
ENTREVISTA
18
Productos
LO QUE VIENE 10 Apache Beehive y Amazon Simple Queue Service A FONDO GXportal 4 12
Prcticas
ADMINISTRACIN DE PROYECTOS Estimacin de Proyectos
La estimacin de tiempos y esfuerzos es un tema de gran inters para todo administrador de proyectos de software. En este artculo Rodrigo Garca nos explica las bases de la estimacin, y aborda dos mtodos para realizar esta difcil e importante tarea.
30
14 HERRAMIENTAS Gestin de Portafolio de Proyectos TIPS El Sndrome ERwin 16
ASEGURAMIENTO DE CALIDAD SQA? Slvese quien pueda!

Qu es el aseguramiento de calidad? En qu consiste el rol de SQA? Cules son sus actividades y para qu las realiza? Mariana Prez-Vargas y Elizabeth Almeraz nos contestan todas estas preguntas a travs de este interesante artculo.
34
CASO DE ESTUDIO
Columnas
Tejiendo Nuestra Red por Hanna Oktaba Mejora Continua por Luis Cuellar Ctedra y Ms por Ral Trejo 06 08 41
26 QuarkSoft nos gua a travs de la aplicacin de PSP y TSP para rescatar un proyecto.
ARQUITECTURA Capas Conceptuales para Sistemas J2EE
38
J2EE nos provee una plataforma poderosa para desarrollar sistemas empresariales. Sin embargo, es fcil perderse en ella. Rams Rodrguez comparte con nosotros una estrategia basada en cinco capas conceptuales para organizar la arquitectura de un sistema basado en esta plataforma.
En Cada Nmero
Noticias y Eventos Fundamentos Tecnologa Biblioteca Carrera 04 42 44 46 48
ENE-FEB 2005
03
Noticias
Oracle
CONSOLIDA RELACION CON ISVs
Oracle tiene en curso un programa para consolidar su relacin con las empresas desarrolladoras independientes de software (Independent Software Vendors - ISVs), a fin de proveer a sus clientes de las soluciones tecnolgicas que les permitan enfrentar los retos de la actualidad. Gerardo Flores, Gerente de ISV en Oracle Mxico, comenta: Los ISVs son socios de negocios crticos no slo porque fortalecen el portafolio de soluciones verticales de Oracle, sino que fortalecen el modelo de alianzas a travs de una especializacin respecto a las necesidades del negocio del cliente. A nueve meses de implementar el modelo mencionado en Mxico, se alcanzaron doce nuevas aplicaciones de industria que fortalecen el negocio y la operacin de las organizaciones de nuestro pas e incluso en muchos casos, del extranjero..
INFO
MoProSoft
PROYECTO DE PRUEBAS CONTROLADAS
El modelo de procesos para la industria de software (MoProSoft) y el mtodo de evaluacin de capacidad de procesos (EvalProSoft), actualmente se encuentran en pruebas controladas en cuatro empresas. Los objetivos de este proyecto son: 1. Probar que MoProSoft eleva la capacidad de procesos en las PyMEs de software donde es implantado. 2. Probar que EvalProSoft es aplicable para evaluar la capacidad de los procesos de una organizacin. 3. Establecer el costo, tiempo y esfuerzo necesarios para alcanzar un nivel de capacidad especfico. Este proyecto comenz en julio del 2004 y se espera que termine en febrero del 2005. Durante este tiempo tambin se est capacitando a ocho personas del interior del pas como consultores en formacin.
ProSoft
APOYO PARA CLUSTERS
Los clusters de Aguascalientes, Baja California, Guanajuato, Jalisco, Morelos, Nuevo Len, Puebla, Sinaloa, Sonora y Yucatn, recibieron apoyos del fondo ProSoft para diversos proyectos durante el cuarto trimestre del 2004. Los rubros ms apoyados fueron: incubacin de empresas, equipamiento de centros de investigacin, adopcin de metodologas de calidad. El pasado 30 de noviembre se llev a cabo una reunin con la participacin de Microsoft, la AMITI y los representantes de los clusters de Coahuila, Sinaloa y Yucatn para intercambiar experiencias sobre empresas integradoras de software.
04
ENE-FEB 2005
Eventos
7-10 Enero 2005
Enero-Marzo 2005
Taller software.net.mx Microsoft y ProSoft
SEPG LA
Universidad de Monterrey Monterrey, Nuevo Len Info: www.microsoft.com/spanish/msdn Tel: 01800-849-9959 e-mail: desarrollador@microsoft.com.mx 26-28 Enero 2005
XITO DE LA PRIMERA CONFERENCIA DEL SOFTWARE ENGINEERING PROCESS GROUP

La primera edicin del SEPG LA fue celebrada con xito del 8 al 10 de noviembre en Guadalajara, Jalisco. La conferencia atrajo ms de 240 profesionales de todo Latinoamrica, pertenecientes a los principales sectores industriales implicados en el desarrollo de sistemas de software. El notable resultado subraya que no es slo una conferencia necesaria y significativa entre los profesionales de software (98% de la evaluaciones dan un resultado de excelente); sino que el contenido es de gran importancia para el desarrollo de todos los sectores industriales de Latinoamrica que dependen de la calidad del software para sobrevivir y permanecer competitivos.
Introduction to CMMI por Giusseppe Magnani

Oficinas de Avantare Ciudad de Mxico Info: www.avantare.com Tel: 52 (55) 5544-3321 e-mail: informacion@avantare.com 8-11 Febrero 2005
Expo Comm Mxico 2005

Centro Banamex Ciudad de Mxico Info: www.expocomm.com.mx Tel: 1087-1664, 01800-000-2322 e-mail: conferencias@ejkrause.com 17 Febrero y 17 Marzo 2005
TI@mericas
Seminario Llegando Rpidamente al CMMI 2 y 3 a travs de RUP

Itera Cd. de Mxico Itera Monterrey 17 de Febrero, Cd. de Mxico 17 de Marzo, Monterrey Info: www.itera.com.mx Tel: 52 (55) 5281-7670 e-mail: contactsalescenter@itera.com.mx 2-3 Marzo 2005
Sun Tech Days

World Trade Center Ciudad de Mxico Info: www.suntechdays.com.mx e-mail: info@suntechdays.com.mx 7-10 Marzo 2005
CUMBRE INTERNACIONAL DE LA INDUSTRIA DEL SOFTWARE

Del 27 al 29 de octubre, la CANIETI llev a cabo la segunda edicin de su evento TI@mericas, en esta ocasin uniendo esfuerzos con la Secretara de Economa para apoyar a las empresas desarrolladoras de software. El objetivo fue promover el potencial de las empresas desarrolladoras de software en Mxico, creando nichos de oportunidad para los empresarios y generar credibilidad al mercado interno y de exportacin. El evento tuvo sede durante dos das en Tijuana, Baja California y el tercer da en San Diego, California, con la participacin de ms de 700 asistentes de 19 diferentes Estados de la Repblica.
SEPG 2005 - Deliver Winning Products Through Process Improvement

Washington State Convention & Trade Center Seattle, Washington Info: www.sei.cmu.edu/sepg e-mail: customer-relations@sei.cmu.edu 14-18 Marzo 2005
SD West 2005 Develop an Advantage

Santa Clara Convention Center Santa Clara, California Info: www.sdexpo.com e-mail: rrobles@cmp.com
ENE-FEB 2005
05
TEJIENDO NUESTRA RED
COLUMNA
Investigacin de Procesos
Primeros Temas Abiertos
n la entrega anterior de esta columna les platiqu sobre la creacin del International Process Research Consortium (IPRC), cuyo objetivo es denir la ruta para investigacin de procesos de software para los prximos 5-10 aos. En el primer taller se presentaron propuestas individuales y posteriormente se formaron cinco espacios de sesin abierta sobre los temas identicados de inters comn. Los participantes nos repartimos libremente entre estos espacios para generar ideas. A continuacin les presento un resumen sobre los temas abordados, el problema que intentan atacar y los posibles temas por investigar.
PyME o SME (Small & Middle Enterprise)

o Problemas Cmo se dene (desde 5 personas hasta cuantas?) Una persona lleva varios roles Un producto contiene varios productos de trabajo Tiene pocos recursos Ve a los procesos como su muerte Ve a las evaluaciones como exmenes o Temas por investigar: Entender qu signica la mejora de procesos para PyMEs Proporcionar un conjunto mnimo de procesos que sean fciles de utilizar y evolucionar Necesitan ser parcialmente subsidiadas por gobierno y/o integradoras de sistemas Creacin de clusters Casos de estudio especcos para PyMEs
Vericacin y Validacin de Procesos

o Problema: no queda claro qu signica la vericacin o validacin de procesos. o Temas por investigar: Cmo demostrar que un proceso se est siguiendo (process delity) Cmo demostrar que un proceso hace lo que queremos que haga (process suitability) Cules son los requerimientos de un proceso? Cul es la estructura de un proceso (componentes y elementos)? Ciclo de vida para el desarrollo de procesos
Factores Humanos
o Problema: no est sucientemente entendido el valor de los recursos humanos en el desarrollo de software. o Temas por investigar: Relacin de factores humanos con la productividad Disposicin de recursos humanos a cambiar Cmo afecta la distribucin geogrca, la educacin y la cultura (de pas, de la organizacin, del equipo) Cmo afecta la poltica pblica (reactiva o proactiva) Estos problemas y temas de investigacin no nos resultan ajenos y reejan el estado incipiente de esta rea a nivel mundial. Yo me un al grupo de Vericacin y Validacin de Procesos, coordinado por Terry Rout, un australiano responsable por la publicacin de la ISO/IEC 15504. En las propuestas de temas de investigacin que all se mencionaron, tenemos algo adelantado en MoProSoft con respecto a la estructura de procesos, sus componentes y elementos denidos a travs de un patrn. Como curiosidad les puedo contar que el desarrollo distribuido fue la mayor preocupacin de los alemanes, y los representantes de la India se concentraron en factores humanos. Los miembros del SEI fueron los ms interesados en las PyMEs. La razn es, como ellos mismos lo explicaron, que las grandes empresas subcontratan a las pequeas y, si el nico marco de procesos disponible es CMMi, estn en problemas. Esta preocupacin del SEI me dio an mayor conanza de que en Mxico vamos por buen camino con MoProSoft. Sin embargo, el tema que une a todos es el del repositorio de procesos de software, ya que ste podra tener un impacto inmediato en la industria de software mundial. Por qu no empezamos a hacer algo al respecto en Mxico? - Hanna Oktaba
La Dra. Hanna Oktaba es profesora en la Facultad de Ciencias de la UNAM. Es fundadora y vicepresidenta de la Asociacin Mexicana para la Calidad en la Ingeniera de Software. Actualmente dirige el proyecto para la creacin de una norma mexicana para la industria de software.
Repositorio de Procesos de Software

o Problema: falta de ejemplos y casos de xito para usar en la prctica, educacin e investigacin de Ingeniera de Software. o Temas por investigar: Desarrollar un repositorio global con diferente tipo de informacin que ayude a implementar prcticas y que resguarde evidencias de casos exitosos.
Desarrollo distribuido (outsourcing)

o Problema: no se conocen los criterios para la toma de decisin con respecto a outsourcing. No se sabe cmo coordinar el outsourcing con el negocio. o Temas por investigar: Identicar la variedad de tipos de desarrollos distribuidos Identicar y analizar las razones de outsourcing (competencia, costo, efectividad) Analizar qu partes de negocio conviene dejar en outsourcing Procesos comunes o no entre el negocio y la organizacin que proporciona outsourcing Mecanismos de coordinacin e integracin
06
ENE-FEB 2005
MEJORA CONTINUA
COLUMNA
El Proceso a Seguir
Y para qu Procesos?
ola!, y bienvenidos a este espacio en nuestra revista. Como saben, la industria de software est ms competida que nunca, nuevas compaas con nuevos productos y servicios surgen a diario, haciendo ms complejo el mercado. Adicionalmente la industria se encuentra saturada de teoras, modelos y herramientas que prometen aumentar la calidad y productividad de las empresas, pero que a la hora de implementar, generan resultados muy por debajo del costo de la inversin. Esta columna est enfocada a generar y compartir ideas prcticas para aplicar estos temas en las pequeas y medianas empresas. Abordaremos temas como CMM, CMMi, Six Sigma y otros de una forma prctica que nos ayude a entender qu hay detrs y cmo podemos, en forma sencilla, lograr los benecios prometidos. Para iniciar esta columna y durante las siguientes dos publicaciones, me gustara iniciar con el elemento ms bsico de toda teora de calidad y mejora: el proceso. El proceso es la base de todo modelo y metodologa de mejora, y aunque parece sencillo de entender y denir, la denicin incorrecta de los procesos de la organizacin es la principal causa de fracaso de las iniciativas de mejora.
Repetir xitos de la organizacin

La idea de tener procesos denidos viene del modelo de manufactura y las cadenas de produccin, donde las actividades se denen en procesos repetibles para ayudar a cada persona de la cadena productiva a volverse expertos en su trabajo especco. Este concepto se puede transportar a la cadena de servicio, y aunque existen fuertes diferencias en los niveles de detalle y tipos de proceso, el objetivo es el mismo: la repetibilidad, poder garantizar que los xitos de hoy se puedan repetir maana. Los procesos son la base para asegurar que exista un mtodo probado para continuamente proveer un producto o servicio en forma ecaz y eciente.
Facilitar la comunicacin
Una gran cantidad de problemas en los proyectos medianos de software se deben a fallas en la comunicacin. Desde el no denir claramente el alcance del proyecto con el cliente, hasta el hecho de que quienes estimaron el proyecto olvidaron pasar los supuestos que utilizaron a la persona que ahora lleva la problemtica de entregarlo a tiempo y en presupuesto. Contar con un proceso predenido nos ayuda a que todos los partcipes del proyecto conozcan su responsabilidad y sepan cul es la informacin mnima que deben comunicar. El proceso nos da las pautas que todos vamos a seguir durante el proyecto para trabajar como un equipo.
Luis R. Cuellar es Director de Calidad a nivel mundial de Softtek Information Services. Luis es reconocido por la American Society for Quality (ASQ) como Certied Quality Manager, Certied Software Engineer, y Six Sigma Black Belt. En los ltimos cinco aos ha estado a cargo de la denicin e implantacin de la estrategia para CMM5 y Six Sigma a travs de las diferentes reas del centro de desarrollo de Softtek.
Organizacin orientada a procesos

Comencemos por acordar algunas deniciones, por ejemplo, qu es un proceso? Segn el diccionario, conjunto de operaciones lgicas y aritmticas ordenadas, cuyo propsito es la obtencin de resultados determinados. En otras palabras, un proceso est compuesto por actividades con una secuencia de ejecucin, responsables para cada actividad, formatos, y procedimientos para llevar a cabo una tarea. Bajo esta denicin, se podra decir que las actividades que sigo para llegar a tiempo a mi trabajo por las maanas cumple con la denicin de proceso, que abarca desde las actividades y procedimiento que ocupo para levantarme a cierta hora, hasta las actividades que llevo acabo para transportarme al trabajo. Otra denicin necesaria para iniciar esta discusin es la efectividad, denida como la capacidad para producir el efecto deseado, lo que quiere decir que el proceso de llegar a mi trabajo en la maana es efectivo en la medida en la que realmente llegue a mi trabajo a la hora deseada. Finalmente, tenemos la eciencia, que es la capacidad para lograr un n empleando los mejores medios posibles. As que mi proceso es eciente en base a la consistencia con la cual se ejecuta en forma ecaz. Para que mi organizacin funcione correctamente, mis procesos deben estar denidos y deben llevarse acabo en forma efectiva y eciente. Esto con la nalidad de crear repetibilidad, facilitar la comunicacin y depositar el conocimiento de la organizacin.
Depositar el conocimiento de la organizacin

Finalmente, el proceso tambin nos sirve como repositorio o marco de referencia para guardar el conocimiento que la organizacin adquiere a travs del tiempo. Las teoras de administracin del conocimiento se basan en la idea de que la organizacin debe generar repositorios de consolidacin del conocimiento de todos los individuos, para que todos puedan aprender de los errores de todos. El proceso puede funcionar como un repositorio especco de ejemplos, checklists, templates y dems artefactos, que representan los logros, mejoras y lecciones aprendidas a travs de toda la organizacin. El proceso que sigue la organizacin es el marco perfecto para identicar qu es lo que la organizacin necesita aprender y cmo se referencia con respecto a otros aprendizajes antes mencionados. Esto nos da una base para la conversacin de la siguiente ocasin en donde profundizaremos en los problemas ms comunes para denir procesos y porqu pueden llevar al fracaso total de una estrategia de mejora. - Luis Cuellar
08
ENE-FEB 2005
PUBLIRREPORTAJE
La consolidacin de
MGE en Mxico
MGE es una empresa lder a nivel mundial, proveedora de soluciones de energa de calidad, diseadas para incrementar la disponibilidad y continuidad en procesos y aplicaciones de misin crtica, ya sea desde una computadora hasta los grandes centros de cmputo o plantas industriales. En aplicaciones especiales y en equipos de grandes capacidades MGE es el proveedor mundial nmero 1.
industrial, educativo, manufacturero, de gobierno y telecomunicaciones. Para MGE el mercado de UPSs ha crecido exponencialmente en concordancia con las necesidades de proteccin de informacin. Por ello, el involucramiento de los proveedores en los requerimientos de las empresas es fundamental, pues a travs de un anlisis previo se pueden elaborar estrategias de prevencin, mantenimiento y soporte adecuado a las zonas en las que se encuentran establecidas las compaas. De esta manera, es como ofrecemos soluciones adecuadas y adaptadas a las necesidades de nuestros clientes, nuestro servicio est enfocado a brindar calidad en cada uno de nuestros productos, comenta el Ing. Miguel Gutirrez, director comercial de MGE UPS Systems Mxico.
Trabajar sin interrupciones

Con ms de 40 aos de experiencia y una amplia gama de servicios y productos, se han distinguido siempre por brindar soluciones adaptadas a las necesidades de empresas que requieran de equipos tecnolgicamente probados para el cuidado y respaldo de sus computadoras y procesos productivos en lnea. Los UPSs son equipos de alto rendimiento para el ahorro de energa que permiten contar con soluciones de energa estable y permanente, que garantizan la continuidad operativa en procesos y aplicaciones de misin crtica. Los sistemas de MGE incluyen fuentes de energa continua, interruptores de transferencia esttica, unidades de distribucin de energa, ltros de armnicos, supresores de picos, inversores y acondicionadores de energa. MGE tiene programas de mantenimiento preventivo y correctivo de servicio para la gama de productos que comercializa, desarrollados por el Ing. David Rubio, director de servicio. Para ello cuentan con una plantilla de ingenieros de campo capacitados en estndares internacionales para ofrecer servicio los 365 das, las 24 horas, con un tiempo de respuesta inmediata.
De izquierda a derecha:
El futuro de los UPSs

Con sus 40 aos de experiencia a nivel mundial y tres en Mxico, MGE tiene un futuro prominente, pues segn arma Cristina Gamero, directora de administracin y nanzas, su perspectiva de crecimiento para este ao es de un 20% respecto a las ventas del ao anterior. Con la fortaleza y la ventaja competitiva que les da contar con un equipo de gente altamente capacitada y dispuestos a entender e involucrarse en los proyectos de sus clientes, MGE se ha planteado nuevas metas de consolidacin de sus productos. La alianza comercial que ha mantenido con Grupo Schneider les permitir penetrar estos mercados y consolidar su presencia de marca en los pases de la regin.
A pesar de las condiciones econmicas adversas que se han registrado en el mundo en los ltimos meses, MGE considera que el mercado de UPSs est en crecimiento, pues como explica la Lic. Gamero los UPS so indispensables para salvaguardar la informacin; el que su empresa se encuentre protegida contra cualquier eventualidad natural o humana, genera conanza en los inversionistas toda vez que el ncleo de su negocio sigue siendo productivo. Los empresarios consideran a los UPS como una inversin redituable en corto plazo y un factor importante en la reduccin de riesgos. Somos una empresa lder mundial, joven en Mxico pero con gran potencial de crecimiento, que refuerza da a da la conanza de nuestros clientes, distribuidores y accionistas.
Ing. Miguel ngel Gutirrez, Lic. Cristina Gamero, Ing. David Rubio
Consolidacin de MGE en Mxico

MGE tiene tres aos de operar con esta denominacin en Mxico y ha logrado alcanzar una cuota de mercado en el primer ao, por arriba del 7% de sus ms cercanos competidores, gracias a su estrategia de servicios, lo cual les ha permitido alcanzar cuentas corporativas importantes en los sectores mdico, nanciero,
MGE UPS Systems Mxico Av. Congreso de la Unin 524 Col. Santa Anita, Del. Iztacalco Mxico 08300 D.F. Tel 5538-9687 Fax 5530 7625
ENE-FEB 2005
09
LO QUE VIENE
Apache Beehive
VE LA LUZ
BEA Systems anunci durante el ApacheCon 2004 que ya est disponible la primera versin alfa de su proyecto de cdigo abierto Apache Beehive, un framework que pretende simplicar el desarrollo de aplicaciones empresariales y arquitecturas orientadas a servicios (SOA) a travs de un modelo de objetos sencillo que utiliza J2EE y Struts. Hasta el momento, Beehive est compuesto por tres elementos:
NetUI PageFlows Framework para aplicaciones web construido sobre Struts, que facilita la creacin de los archivos de conguracin de Struts a travs del uso de metadatos. Controls Framework de componentes que permite incorporar metadatos utilizando las nuevas capacidades de Java 5 para anotaciones (JSR-175). Web Services Una implementacin del JSR181, que es un modelo de programacin basado en anotaciones para desarrollar web services. El proyecto actualmente se encuentra en estatus de incubacin dentro de la fundacin de software Apache. El objetivo de esta versin, llamada v1Alpha, es permitir que los desarrolladores lo comiencen a utilizar para crear aplicaciones SOA que se puedan ejecutar en diferentes servidores de aplicaciones. Beehive actualmente soporta los servidores de aplicacin JOnAS y Apache Geronimo, as como el contenedor de web Tomcat. Al ser un proyecto de cdigo abierto, el objetivo es que pronto se genere soporte para una amplia gama de plataformas. Con el v1Alpha tambin se liberaron herramientas adicionales, como es el caso
PRODUCTOS
de controles para Hibernate, una herramienta para object-relational mapping (ORM). ORM es la capacidad de mapear clases en un lenguaje orientado a objetos en este caso Java hacia tablas de bases de datos relacionales para el manejo de persistencia de datos. Para desarrollar con Beehive se puede utilizar el BEA Weblogic Workshop 8.1, o herramientas de cdigo abierto como Pollinate, un plug-in de Eclipse creado para soportar esta tecnologa. Adems, Borland ya anunci que en el futuro prximo sus productos tambin soportarn este modelo de programacin.
Para mayor informacin: Beehive - Apache Software Foundation incubator.apache.org/beehive/ Pollinate Project www.eclipse.org/pollinate/ BEA Systems www.bea.com
PRODUCTOS
Amazon.com
LANZA SIMPLE QUEUE SERVICE

Amazon.com ha lanzado el beta del Amazon Simple Queue Service (SQS), un servicio de colas de mensajes entre aplicaciones distribuidas. Con este lanzamiento, la empresa anunci sus planes para vender un servicio que administre colas de mensajes entre componentes de aplicaciones distribuidas. Durante el beta, que es gratuito para usuarios registrados, Amazon SQS funcionar como almacenamiento transitorio de mensajes pequeos (menores a 4 KB) y que permanecern en la cola por un mximo de 30 das. Un mismo usuario podr tener almacenadas un mximo de 4,000 peticiones. Amazon ha comentado que cobrar por el servicio una vez que sea ocialmente liberado, pero hasta ahora no ha dado informacin de precios. Este es el primer producto que surge como resultado de la iniciativa de Amazon Web Services, lanzada en octubre de 2004. Esta iniciativa reeja una creciente tendencia entre las principales empresas del web para ofrecer su propia plataforma como infraestructura de TI para terceros. El servicio se puede acceder a travs de una interfaz de web service, que permite siete operaciones: crear colas, congurar colas, listar colas, eliminar colas, agregar mensajes, leer datos y eliminar mensajes. Este servicio ha sido especcamente diseado para ser usado en aplicaciones distribuidas, por lo tanto una misma cola pueda ser accedida de manera concurrente sin necesidad de que los componentes se coordinen entre s para acceder la cola. Microsoft, con MSMQ (Microsoft Message Queuing) e IBM con WebSphere MQ, ofrecen capacidades similares. Sin embargo, Amazon lo ofrece en un esquema de Application Service Provider (ASP), donde las empresas pagaran una cuota mensual para utilizar el sistema que reside en Amazon.com. Este esquema puede ser atractivo para empresas pequeas, ya que permite evitarse costos de instalacin y mantenimiento, aunque involucra el riesgo de no tener el control absoluto sobre la informacin manejada.
10
ENE-FEB 2005
PRODUCTOS
A FONDO
GXportal
ARTech
www.gxportal.com
GXportal 4
Valor y Sencillez
Calificacin: 4 de 5
Precio y Disponibilidad
Motor y 1 usuario: $750 a $2,800 USD. Usuarios adicionales: $140 a $350 USD. Contactar a la oficina de ARTech ms cercana para disponibilidad en tu regin.
Requerimientos de Sistema
Servidor Windows 2000+. SQL Server 2000+. Internet Information Server 5.0+. .NET Framework 1.1. Cliente Internet Explorer 5.5+ ,Netscape 6.0+, Mozilla 1.2+.
VEREDICTO
En general, consideramos que GXportal es una muy buena opcin cuando se requiera un CMS sencillo que pueda ser administrado por los usuarios finales sin necesidad de intervencin de personal tcnico. Pero no se queden con la curiosidad, los invitamos a que soliciten una evaluacin de este producto. PROS: 1. Fcil de usar por personal no tcnico. 2. Disponible en espaol. 3. Precio accesible. CONTRAS: 1. Restringido a plataforma Microsoft por el momento. 2. No existe un lugar dnde obtener componentes que extiendan la funcionalidad base.
Xportal es un motor para portales web cuyo objetivo es poder disear, administrar y mantener portales escalables sin necesidad de programar. ste es un producto de ARTech, empresa de origen uruguayo con oficinas en Mxico, Estados Unidos y Brasil. El producto insignia de ARTech es GeneXus, una plataforma para automatizacin de desarrollo de software. De hecho, GXportal forma parte de esta plataforma. A principios de siglo, este tipo de herramientas eran conocidas como portal engines (motores de portal). Sin embargo, conforme fueron evolucionando e integrando funcionalidad de flujos de trabajo (workflow) para contenido, su nombre tambin cambi y ahora son conocidos como Content Management Systems (CMS), o sistemas de gestin de contenido. La versin que evaluamos es la 4.0.1. Este producto se encuentra disponible en dos modalidades: Lite y Completa. La versin Lite
provee todas las funciones bsicas de un CMS, como el diseo basado en plantillas que permite manejar el diseo por separado del contenido, administracin de contenido con base en un workflow, bsqueda de contenido, personalizacin de pginas, conectores para contenido HTML, Flash y Javascript, componentes para foros de discusin, newsletters, FAQs y encuestas. Adems de esto, la versin completa ofrece: Interaccin con aplicaciones.- Con GXportal, un portal no slo es un sitio informativo, sino que las aplicaciones de negocio tambin se pueden habilitar para el web. Single Sign On.- Un objetivo comn de un portal es que sirva de punto de entrada para diferentes aplicaciones habilitadas en web. La capacidad de Single Sign On (firma nica), permite que un usuario se identifique una sola vez y pueda utilizar diferentes aplicaciones sin necesidad de estarse autentificando en cada una.
12
ENE-FEB 2005
El principal atractivo de este producto es la capacidad de que personal no tcnico pueda administrar un portal sin soporte del personal de sistemas.
An as, el principal atractivo de este producto es la capacidad de que personal no tcnico pueda administrar un portal por s mismo. Esto se logra a travs del uso de asistentes (wizards) y mens para todas las actividades de administracin de diseo y contenido. En pocas palabras, es posible crear un sitio completo sin necesidad de escribir una sola etiqueta de HTML. Tal vez esto parezca irrelevante a nuestros lectores, que seguramente conocen la especificacin de HTML y DOM al derecho y al revs, pero lo importante es que permite que los usuarios finales puedan manejar un portal entero sin necesidad de recurrir al personal de sistemas... imaginen la belleza.
Trabajar en base a grupos de trabajo permite controlar los privilegios de los usuarios.
Por otro lado, es cierto que existen CMS de cdigo abierto con disponibilidad gratuita, que brindan gran flexibilidad en cuanto a sus capacidades. El problema con ellos es que an no tienen la facilidad de uso de los productos comerciales, por lo que requieren mayor conocimiento tcnico y estn fuera del nicho en que se enfoca GXportal. La instalacin de este producto es bastante sencilla. Simplemente se ejecuta un instalable y se va siguiendo el asistente para configurar la conexin a la base de datos, el servidor web y el servidor FTP. Posteriormente se utiliza un mdulo de administracin de licencias para alimentar las licencias disponibles. Despus de esto ya estamos listos para crear y publicar un website. La documentacin incluida en GXportal es bastante completa, ya que incluye manual de instalacin, un tutorial para guiar al usuario en la funcionalidad bsica, y ayuda detallada en formato Microsoft Help. La versin 4.0.1 de GXportal solamente funciona sobre plataforma Microsoft, ya que requiere Internet Information Server como servidor web, y SQL Server como manejador de base de datos, adems de utilizar el .NET Framework 1.1. Sin embargo, Eugenio Garca, Project Manager de GXportal,
Otro atractivo de GXportal es su precio, el cual es bajo al compararlo con herramientas similares en el mercado. El esquema que maneja GXportal es que se adquiere una licencia que incluye el motor y un usuario administrativo, y por separado se puede adquirir licencia para usuarios administrativos adicionales. La licencia de la versin Lite tiene un precio de $750 dlares, mientras que la licencia de la versin completa cuesta $2,800. Los precios por usuario administrativo adicional dependen del volumen, pero van de $140 a $350 dlares por usuario. Todo esto es independiente de la cantidad de usuarios no administrativos, la cual es ilimitada. Estos precios son atractivos al compararlos con soluciones para portales como la de Bea u Oracle, que tpicamente superan los $80,000 dlares.
nos comenta que la versin 4.1 que estar disponible cuando ustedes estn leyendo esto ya se ejecuta sobre plataforma Java, pudiendo utilizar como DBMS tanto Oracle como DB2. Esto hace posible que GXportal sea instalado en ambientes Linux/Unix, utilizando cualquier motor de servlets (Websphere, Tomcat, Oracle IAS, JRun, etc.) y Apache como servidor web. Otra caracterstica importante para esta versin es el uso de cache en las sentencias a la base de datos, lo cual brinda una mejora considerable en el desempeo y escalabilidad. Algo que sentimos que le hace falta a GXportal es una comunidad de desarrolladores que contribuyan componentes para extender la funcionalidad base de este producto. Hemos visto que otros productos cuentan con esto, y es de gran ayuda. En este sentido, Eugenio nos comenta que en la versin 5.0 se podr extender GXportal a travs del estndar WSRP (Web Services for Remote Portlets). Esto nos permitir integrarnos a la comunidad que hoy en da existe en torno a esta especificacin, as como crear nuestra propia comunidad para que las empresas puedan intercambiar informacin mediante este mecanismo., agrega Eugenio.
ENE-FEB 2005
13
HERRAMIENTAS
PRODUCTOS
Por Isabell Chillopa
Gestin de Portafolio de Proyectos

Alineando las Tecnologas de Informacin con el Negocio
En los ltimos aos, el alineamiento entre las Tecnologas de la Informacin (TI) y la estrategia del negocio ha estado y se mantiene en el nivel ms alto de prioridad de las organizaciones. Este inters radica en la manera en que las inversiones en TI, recursos, oportunidades de negocio y el portafolio de aplicaciones pueden estar en armona con los objetivos estratgicos de la organizacin, de tal manera que permitan apoyar el proceso de toma de decisiones y mejorar el uso de recursos existentes para incrementar la productividad, haciendo as ms efectiva y eficiente a la organizacin.
e acuerdo con informacin reportada en diversos estudios, las organizaciones enfrentan una diversa problemtica al respecto. Pocas empresas seleccionan de manera exitosa un portafolio de proyectos que sea consistente con su estrategia de negocio. Un proyecto puede ser exitoso desde la perspectiva de tiempo, presupuesto y alcance, pero si falla en cumplir o satisfacer los objetivos de negocio, fracasa de manera completa.
que en realidad se est haciendo en la organizacin. El resultado de estas deficiencias se ve reflejado en la ejecucin de demasiados proyectos, una gran cantidad de complejidad y redundancia; as como fallas, retrasos y excesos en el presupuesto de los proyectos. Es evidente por lo tanto, que las organizaciones que no tienen control sobre sus portafolios de proyectos de TI estn condenadas al fracaso. Para solucionar esta problemtica, una de las estrategias de negocio que ms fuerza est tomando es la Gestin de Portafolio de Proyectos o Project Portfolio Management (PPM). PPM permite a las organizaciones alinear sus proyectos de TI y recursos con los objetivos de negocio corporativos. PPM brinda a las organizaciones una visin integral de su estrategia de TI, permite ganar control sobre sus proyectos y ayuda a generar valor al negocio.
Al igual que la seleccin de proyectos, la ejecucin de stos tambin acostumbra estar descentralizada y fragmentada. Las mejores prcticas de la industria y lecciones aprendidas derivadas de la ejecucin de los proyectos no se identifican y gestionan para ser aplicadas sistemticamente en la organizacin, desaprovechando la sinergia potencial entre proyectos. En otros casos, no se cuenta con procesos definidos para revisar propuestas de proyectos, ni un rastreo adecuado que permita identificar los proyectos que fracasan en el cumplimiento del valor de negocio prometido. Incluso, llega a suceder que los niveles directivos ni siquiera cuentan con una lista completa de los proyectos de TI en curso dentro de la organizacin. En resumen, no se cuenta con una visibilidad adecuada de lo
Con PPM se desarrollan y monitorean mediciones que tratan los activos de TI de igual manera como se trataran activos o portafolios de diversas inversiones financieras; por ejemplo, inversiones estratgicas ms riesgosas se balancean con inversiones ms conservadoras y la mezcla se monitorea constantemente para evaluar cules proyectos siguen su curso, cules necesitan ayuda y cules deben ser terminados. Al mantener un portafolio balanceado, se reduce el riesgo en cada proyecto, se obtiene un mayor entendimiento de los aspectos econmicos de cada uno y se genera una tasa ms alta de retorno de inversin general del portafolio. Asimismo, se tiene mayor visibilidad y un uso eficiente de los recursos entre los diferentes proyectos. PPM brinda claros y mltiples beneficios a las organizaciones. En esencia, los ejecutivos y gerentes pueden monitorear sus portafolios de proyectos facilitando la administracin integrada del alcance, tiempo, costo, recursos, habilidades, adquisiciones, comunicacin, reporte, predicciones y riesgos, y alineando estos proyectos a los objetivos de negocio para incrementar la productividad, apoyar la toma de decisiones oportuna e informada, y generar mayor valor al negocio.
Caractersticas y Beneficios de PPM

PPM involucra desde la identificacin y priorizacin de oportunidades de negocio (se examinan las propuestas de proyecto con respecto a los objetivos corporativos), hasta la ejecucin y cierre de proyectos, organizndolos en portafolios.
Isabel Chillopa es consultor y responsable de la Oficina de Proyectos en Itera. Anteriormente labor en el Instituto de Investigaciones Elctricas (IIE), donde particip en proyectos de desarrollo de software y coordin la certificacin del sistema de calidad conforme a la norma ISO 9001. Isabel es Licenciada en Informtica del Instituto Tecnolgico de Zacatepec, y Maestra en Administracin de Tecnologas de la Informacin del ITESM.
14
ENE-FEB 2005
Al mantener un portafolio balanceado, se reduce el riesgo en cada proyecto y se obtiene un mayor entendimiento de los aspectos econmicos de cada uno.
Cmo Iniciar PPM

No hay una manera nica de implantar PPM. Diferentes empresas manejan diferentes modelos y metodologas. Sin embargo, Todd Datz, Editor Ejecutivo de la revista CIO, establece ciertos pasos clave en la creacin y administracin de portafolios de proyectos de TI: Reunir.- Crear un inventario de proyectos es una tarea ardua pero bien vale la pena. En muchos casos, puede ser la primera vez que se tenga una vista completa de los proyectos de TI, y permite encontrar redundancias. Un buen inventario es la base para desarrollar proyectos alineados con los objetivos estratgicos del negocio. Evaluar.- Despus de inventariar los proyectos, se establece un portafolio de stos. Los lderes de las unidades de negocio, en conjunto con los lderes de TI, deben soportar los proyectos con casos de negocio que muestren estimacin de costos, ROI, anlisis de riesgos y beneficios esperados. Priorizar.- An despus de evaluar los proyectos, la mayora de las empresas tendrn ms proyectos de los que pueden realizar. El proceso de priorizacin permite asignar recursos a los proyectos que estn ms alineados con los objetivos estratgicos de la organizacin. Revisar.- Una vez que se tiene una lista de proyectos aprobados, es vital administrarlos activamente. Esto involucra monitorear los proyectos a intervalos frecuentes. Contar con la visin de portafolio tambin facilita la decisin de cancelar proyectos cuando sea necesario. Jeff Chasney, Vicepresidente de Planeacin Estratgica y CIO de CKE Restaurants, comenta: No requieres completar todos los proyectos simplemente porque los empezaste..
Herramientas de Apoyo a PPM

Existen diversas herramientas de software para asistir en la implantacin y automatizacin de esta prctica. Uno de los productos ms conocidos es Primavera (www.primavera. com). Se espera que en el 2005 el mercado de estas herramientas sea de $540 millones de dlares anuales. Seguramente esto es lo que motiv a IBM para entrar a este mercado con el reciente lanzamiento del Rational Portfolio Manager que, al integrarse con el resto de la plataforma de desarrollo de IBM, puede ofrecer grandes beneficios.
Las herramientas de software son vitales para implantar PPM. Imagen: Rational Portfolio Manager.
Como toda iniciativa nueva, la implementacin de PPM requiere tiempo y esfuerzo. Sin embargo, los retos que conlleva son mnimos en comparacin con el valor y beneficios que brinda a la organizacin.
Referencias: Datz, Todd. Portfolio Management, How To Do It Right. CIO Magazine, Mayo 2003 Reddy, Ashok. PPM: Aligning Business and IT. IBM developerWorks, Mayo 2004 Autores varios. Centralizing Management Of Project Portfolios. Meta Group. Enero 2002
TIPS
PRODUCTOS
Por Artemio Mendoza
El Sndrome
Los modeladores de datos son herramientas indispensables para el desarrollo de software. Es importante que conozcamos su funcionalidad, as como las limitaciones que pueden tener. En este artculo, Artemio Mendoza nos narra su experiencia con ERwin Data Modeler de Computer Associates.
Rwin es uno de los productos ms conocidos para modelado de datos. Su funcionalidad va ms all de simplemente dibujar diagramas, ya que tambin genera los scripts de creacin de la base de datos, permitiendo escoger entre diferentes DBMS destino como Oracle, DB2, Sybase, SQL Server y otros ms. Tambin es posible conectarse al DBMS de manera nativa en el caso de Oracle, utilizando SQL*Net o por ODBC para generar en lnea los objetos y sus relaciones o hacer ingeniera en reversa para obtener el diagrama Entidad Relacin (ER) de una base de datos existente. En n, si observamos el conjunto de servicios que ofrece, podemos entender porqu ERwin goza de tanta popularidad. Sin embargo, an con todas sus gracias, si dejamos demasiadas cosas en las manos de ERwin terminaremos con bases de datos altamente inecientes. Por qu esta armacin? Bueno, para justificarla voy a hablar acerca del RDBMS que conozco, el cual es Oracle. Sucede que he llegado a varios proyectos porque tienen problemas con la fragmentacin de los discos de la base de datos, tablas que no pueden crecer ms, problemas con integridad referencial no se pueden borrar datos de alguna tabla con Foreign Key, y algunos otros ms sutiles que no se ven a simple vista pero que afectan al desempeo global del DBMS como encadenamiento en bloques
ERwin
Las herramientas de modelado de datos son de gran utilidad
de datos, espacios ms grandes de lo necesario, niveles de concurrencia inadecuados. Por qu sucede esto? La respuesta es muy simple, resulta que en el caso de Oracle, la creacin de un objeto, como una tabla o un ndice, necesita parmetros de almacenamiento, tales como PCTFREE, PCTINCREASE, INITIAL, MAXEXTENTS y otros ms. Pero, si se realiza automticamente por un usuario que no conoce la existencia de estos, los valores se toman por omisin y rara vez resultan ser los adecuados. Un ejemplo tpico es el PCTINCREASE, que indica el porcentaje de espacio que se va a reservar para el objeto creado cuando se acabe el espacio (extent) actual. El valor por omisin es de 50. Qu signica esto? Bueno, que si tengo una tabla que de INITIAL tiene 10MB pero sigue creciendo y rebasa estos 10MB, la prxima extensin que se va a tomar ser 50% ms grande, es decir, de 15MB, y la siguientes de 22MB, 33.8 MB, 50.7MB y 76MB. As, en tan slo cinco iteraciones se increment en casi 800% el valor inicial. Resultado? Fragmentacin y espacio mal utilizado, adems de que no permite saber si el prximo extent va a caber en el tablespace. Otro ejemplo es el parmetro MAXEXTENTS que indica el nmero mximo
de extents que se permiten alojar para ese objeto. As, si se indica un valor demasiado bajo, puede ser que la tabla rebase estos valores y marque un error ORA-01631 max # of extents num reached in [table name]. Evidentemente, despus de que se corren los scripts y se crea toda la base de datos, no existen problemas y se procede al desarrollo de las aplicaciones. Sin embargo, no pasa mucho tiempo cuando empiezan a surgir las consecuencias. Todos sabemos que cuesta ms arreglar un problema que prevenirlo el costo de arreglar un problema durante el desarrollo debe de tomar en cuenta a los programadores que quedan parados sin poder trabajar. Y qu decir cuando estos sistemas se liberan a produccin con los parmetros por omisin mencionados? Siempre se termina por llamar a alguien que arregle los dimensionamientos. Entonces no debemos utilizar para nada ERwin y hacer nuestros diagramas y scripts a mano? Por supuesto que no! El planteamiento es que subordinemos esta excelente herramienta a los criterios de quien conoce los requerimientos especcos del DBMS para el que est generando, de tal forma que realize los clculos pertinentes e indique los valores ptimos. Si no hacemos esto, an cuando generemos nuestros objetos a mano, el riesgo ser el mismo. Toma en cuenta que Es mejor prevenir que remediar. Este es un consejo muy sabio y econmico. no lo creen?
Artemio Mendoza es Director de Operaciones de Towa Software, empresa de consultora en TI de la cual es socio fundador. Durante ms de once aos se ha desempeado como consultor, gerente y director en empresas de tecnologa en Mxico y Estados Unidos para clientes como GE Plastics, McKinsey & Company, Bancomer y Alestra. Artemio tiene el grado de Maestra en Administracin de TI, otorgado por el Tec de Monterrey.
16
ENE-FEB 2005
ENTREVISTA
Director de Tecnologa de Informacin en GNP

Por Jorge Palacios
Martn MndeZ
Desde sus inicios en la industria del software hace 24 aos, Martn ha tenido la gran inquietud de qu hacer para cumplir los proyectos a tiempo y con calidad. Esta mentalidad lo ha llevado a emprender importantes esfuerzos, como fue el caso de Tecnosys, empresa fundada por Martn que en 1999 se convirti en la primera de Amrica Latina en ser reconocida como SW-CMM3. Actualmente, Martn se desempea como Director de Tecnologa de Informacin en GNP, donde sigue tan cautivo como siempre del afn de mejorar a travs de los procesos.
Software Guru.- Cmo y cundo empiezas a dar cauce a esta inquietud? Martn Mndez.- En l991, mientras visitaba una biblioteca del MIT, me llam la atencin un libro titulado Managing The Software Process de Watts Humphrey. Al leerlo me di cuenta que el software no era algo artesanal, sino que era administrable. Cul es el valor de los procesos en las organizaciones? Soy un firme creyente de los procesos y
adems me ha tocado ver empresas muy exitosas alrededor de los procesos, en IBM es impresionante lo que han hecho. Actualmente se habla de que la competencia ya no va a estar alrededor de que tu producto sea mejor, sino de que generes las mejores experiencias a tus clientes. Esto slo se puede lograr con operaciones bien definidas, medidas y continuamente mejoradas, y eso slo te lo dan los procesos.
Qu importancia tiene la ingeniera de software para ayudar a los sistemlogos a escalar la pirmide organizacional? Un artista se hace solito, porque es una labor de l. En el momento en que te conviertes en ejecutivo, ya no eres artista, y tu misin no es un arte, sino una funcin en una organizacin. La ingeniera de software brinda un marco para que algo que estaba considerado como un arte, se pueda industrializar y administrar.
18
ENE-FEB 2005
Los dos obstculos mayores (para implantar CMM) son convencer al que pone el dinero y lograr que la gente se discipline.
Cuntanos tu experiencia encabezando un proyecto de implantacin CMM. Los dos obstculos mayores son convencer al que pone el dinero y lograr que la gente se discipline. En cuanto a esto ltimo, es importante generar un mensaje adecuado donde se explique el beneficio tanto para la organizacin como para las personas, hay diferentes cosas que se pueden hacer. Nos podras compartir alguna experiencia en este sentido? En mercadotecnia existe algo llamado el cruce del abismo. Esto se refiere a que entre los pioneros (early adopters) y la mayora, hay un abismo que tienes que ver cmo cruzar. En nuestro caso, un da hicimos una sesin donde presentamos los proyectos de estas personas para que el resto vieran los resultados, y al mejor proyecto le dimos un premio que consista en un cheque (simblico), los pusimos en frente de la empresa y les dimos un reconocimiento. El costo de esto no fue significativo y, en cambio, jal a la gente muchsimo. Con base a los early adopters tienes que jalar a la mayora. Cmo convenciste a IBM de invertir en un proyecto de mejora de Tecnosys? Les expliqu que haban comprado una empresa de la cual seguramente haban pedido referencias, y las cuales normalmente iban llenas de referencias personales, por ejemplo si t te traes a Martn Mndez y a este y a este otro, tu proyecto saldr bien. Pero nunca fueron referencias hacia la empresa ni al mtodo ni al proceso, y lo que yo quera cambiar era eso. Les coment que yo no poda clonar 50 personas en un mes, pero lo que s poda hacer era generar un programa de capacitacin e induccin para que conforme se incorporara personal nuevo, se fuera alineando a la manera de hacer las cosas.
La verdad es que al principio slo me dieron el dinero para ISO 9000, que era sustancialmente menor que el necesario para CMM, y medimos resultados. En un ao ya estbamos certificados en ISO 9000. Para los que ponen el dinero hay dos cosas importantes: la rentabilidad y la satisfaccin del cliente. La rentabilidad la medimos mes a mes, en los estados de resultados; y para medir la satisfaccin del cliente, generamos encuestas y demostramos que una vez implantado el sistema de calidad, dejando pasar el tiempo necesario, haba subido la satisfaccin del cliente. Entonces ya justificaba la inversin en CMM, con una visin de incursionar en el mercado de la exportacin. Es aplicable CMMI a las PyMEs desarrolladoras de software mexicanas? Yo creo que el (modelo) continuo es aplicable, y el ejemplo es Ultrasist, que habla del nivel en el que ya estamos en Mxico. No se necesita mucho capital financiero, s capital humano. Ellos tienen un capital intelectual y humano muy slido, de llamar la atencin. Ese tipo de empresas s lo van a poder hacer. La otra es el modelo flexible, al cual s le veo posibilidades en las PyMEs mexicanas. Tambin les recomiendo que vean la segunda versin del MoProSoft como una serie de recomendaciones para configurar el modelo continuo de CMMI. Para m el valor del MoProSoft es agarrar y decir: aqu est este modelo mexicano que es barato. ntrenle y adquieran la disciplina, y despus vayan un paso adelante. Eso fue lo que sucedi con el ISO 9000 en Tecnosys, el principal valor fue que empezamos
a entender lo que significaba trabajar en forma disciplinada, el otro fue demostrarle al consejo de administracin que s se poda hacer y que tena buenos resultados. Cmo te integras a GNP? GNP en m busca dos cosas: una experiencia en el mercado de desarrollo y la capacidad de generar un proceso disciplinado. Tengo a mi cargo la tarea de integrar los servicios al negocio, mas la tarea no formal de ir ordenando el proceso de desarrollo. Como dice Humphrey: Every business is a software business. Cmo va el proceso de generar disciplina en GNP? Tanto mi jefe como mis compaeros, creemos que podemos profundizar y obtener mejores resultados. Estamos buscando poner orden y luego reduccin del gasto, no solamente a travs de la eficiencia del desarrollo. Se estn obteniendo formas de hacer ms con lo mismo, o hacer ms con menos. Todo el mundo dice que le eches ganas y que se queden ms a trabajar, pero eso ya sabemos que no funciona. Mi rol consiste en mejorar la satisfaccin de mi cliente y un componente importante es entregar a tiempo y en costo lo que l necesita. La otra parte es entender el negocio y cmo solventar sus requerimientos. Mi rol pas de preocuparme por cmo mejorar el desarrollo del software a cmo generar las soluciones que mi cliente est buscando. Qu mensaje le dejas a nuestros lectores? Escojan algo en lo que quieren ser buenos y dedquense a eso por una temporada larga, el tiempo les dir si pudieron lograrlo o no.
ENE-FEB 2005
19
EN PORTADA
En un mundo de cambios constantes y competencia global, las organizaciones de desarrollo de software son presionadas a alcanzar mayor eficiencia con menores costos. Para poder lograr este objetivo, es necesario adoptar una forma de trabajo que permita entender, controlar, comunicar, mejorar, predecir y certificar el trabajo realizado. Actualmente existe una gran diversidad de opciones relacionadas con procesos de desarrollo. Constantemente se escuchan diferentes acrnimos como CMM, CMMI, RUP ISO, PSP TSP etc., que causan con, , , fusin, principalmente debido a la mala interpretacin de los mismos. Revisemos entonces los principales procesos de desarrollo y modelos ms utilizados al momento, as como los estndares relacionados.
GUA DEL
VIAJERO
Por Mara Ruvalcaba
Hasta hace poco tiempo, la produccin de software era realizada con un enfoque artstico, a diferencia de un enfoque industrial. Ante la constante presencia de proyectos fallidos, y con el objetivo de mejorar la calidad de los productos, en los ltimos aos las organizaciones introdujeron los mtodos de ingeniera de software. (Ver Fundamentos Desarrollar software es mucho ms que programar, pg. 42) A partir de estos, se formaliz el enfoque de ingeniera de producto para desarrollar software. Factores como la globalizacin han obligado a las organizaciones a contar con marcos de trabajo que las ayuden hacer las cosas de la manera ms eficiente. Fue entonces que se incorpor la ingeniera de procesos al desarrollo de software.
Por qu contar con un proceso de software?
20
ENE-FEB 2005
Antes de definir lo que es un proceso de desarrollo de software, entendamos lo que es un proceso. Una definicin sencilla de proceso es serie de acciones que conducen a un final. Esta definicin parece coincidir con las ideas generales de la gente sobre procesos, pero deja muchas preguntas abiertas. El proceso es la forma en que la organizacin opera desde mercadotecnia hasta recursos humanos o es la forma en que un desarrollador disea, produce cdigo, o prueba el software? El proceso se refiere a administracin, ingeniera, o ambas? El proceso implica demasiada documentacin y nos abstiene de desarrollar el producto objetivo? La respuesta a stas puede variar dependiendo de la perspectiva. Sin embargo, siempre que para alcanzar algn fin deseado necesitemos ejecutar una serie de acciones, y estas acciones tengan cierto orden, dependencias, roles responsables, resultados, tiempos de ejecucin y herramientas de apoyo, estaremos hablando de procesos, que pueden ser predefinidos y personalizados.
Proceso
Elementos Tpicos del Proceso de Software

Actividad Definen las acciones que se llevan a cabo en un momento dado del desarrollo de software. Coleccin estructurada de actividades y elementos asociados (artefactos y roles), que producen un resultado de valor. Son responsables por llevar a cabo las actividades del proceso, pueden ser personas o herramientas. Son las entradas y salidas de las actividades, pueden ser de diferentes tipos, como documentos, modelos, componentes, planes, reportes, etc. Conjunto integrado por actividades relativas a una rama particular de conocimiento. Ej. Anlisis y diseo.
Flujo de Trabajo
Rol
Producto o Artefacto
Proceso de software
Disciplina
La meta de la ingeniera de software es construir productos de software, o mejorar los existentes; en ingeniera de procesos, la meta es desarrollar o mejorar procesos. Un proceso de desarrollo de software es un conjunto de personas, estructuras de organizacin, reglas, polticas, actividades y sus procedimientos, componentes de software, metodologas, y herramientas utilizadas o creadas especficamente para definir, desarrollar, ofrecer un servicio, innovar y extender un producto de software. Un proceso de software efectivo habilita a la organizacin a incrementar su productividad al desarrollar software: Permite estandarizar esfuerzos, promover reuso, repeticin y consistencia entre proyectos. Provee la oportunidad de introducir mejores prcticas de la industria. Permite entender que las herramientas deben ser utilizadas para soportar un proceso. Establece la base para una mayor consistencia y mejoras futuras. Un proceso de software mejora los esfuerzos de mantenimiento y soporte: Define cmo manejar los cambios y liberaciones a sistemas de software existentes. Define cmo lograr la transicin del software a la operacin, y cmo ejecutar los esfuerzos de operacin y soporte. Necesitamos un proceso de software cuya funcionalidad est probada en la prctica, y personalizado para que cumpla con nuestras necesidades especficas.
Diversidad en Modelos
Actualmente existe una gran variedad de modelos para procesos de software. Podemos entenderlos ms fcilmente si los clasificamos en dos tipos: genricos y especficos.
Modelos Genricos
Abarcan todos los procesos relacionados con el desarrollo de software CMM modelo de madurez de capacidades estndar de facto CMMI modelo integrado ISO 9001-2000 sistema para administracin de la calidad - estndar ISO/IEC 15504 marco para evaluacin de procesos de software en vas de ser estndar, por ahora reporte tcnico MoProSoft modelo de procesos para la industria de software en Mxico en vas de ser norma mexicana Nos dicen qu debemos hacer Se deben usar como referencia para definir procesos en una organizacin y para autoevaluacin. Medio para evaluar que tan bien o mal esta la organizacin.
Modelos Especficos
Enfocados a la ingeniera de productos de software UP proceso de desarrollo RUP proceso de desarrollo PSP enfocado en individuos TSP enfocado en equipos (incluye PSP)
Nos dicen el cmo debemos hacer las cosas Se usan como gua para ejecutar proyectos
Proceso de Software
Revisemos estos modelos para entender mejor su objetivo y estructura.

Y las Metodologas giles?
Las metodologas giles son otro ejemplo de prcticas especficas para desarrollar software. Uno de los mtodos giles ms conocidos es Extreme Programming (XP), que se describe como una disciplina de desarrollo de software basada en valores de simplicidad, comunicacin, retroalimentacin, y coraje. XP funciona al poner a todo el equipo en presencia de prcticas sencillas, con suficiente retroalimentacin para habilitar al equipo para ver donde estn y afinar las prcticas para una situacin nica. No hemos listado XP como un modelo especfico, ya que no se considera un proceso formal y completo, sino que ms bien es un conjunto de prcticas que se pueden aplicar dentro de los modelos mencionados.
ENE-FEB 2005
21
Modelos Genricos
CMM (Capability Maturity Model) Modelo de Madurez de Capacidades
En el ao 2000, el SW-CMM fue reemplazado por CMMI. El SEI ya no mantiene el modelo SW-CMM, sus mtodos de evaluacin asociados, ni el material de entrenamiento.
Marco que describe elementos clave de procesos efectivos de software. Creado por el Software Engineering Institute (SEI) en conjunto con Carnegie Mellon University. La primera versin se public en 1994. CMM describe un camino evolutivo en 5 niveles de mejora de procesos para lograr su madurez. Cubre prcticas de planeacin, ingeniera y administracin del desarrollo y mantenimiento de software.
CMMI (Capability Maturity Model Integration) - Modelo de Madurez de Capacidades Integrado

El proyecto de CMMI fue concebido como una iniciativa para reunir los diferentes CMMs en un conjunto de modelos integrados, ms consistentes entre ellos. Los modelos fuente que sirvieron como bases incluyen: CMM Software, CMM Ingeniera de Sistemas, y CMM Desarrollo Integrado de Producto . CMMI proporciona una gua para desarrollar procesos, que adems ayuda a evaluar la madurez de la organizacin o capacidad de un rea de procesos. CMMI incluye los procesos de ingeniera de software e ingeniera de sistemas. El modelo est representado de forma continua y escalonada. Contiene 22 reas de procesos. Cada rea de proceso est formada por: Objetivos especficos, Prcticas especficas, Objetivos genricos, y Prcticas genricas. CMMI Modelo Continuo Esta formado por 5 niveles de capacidad del proceso: 0. Incompleto 1. Desempeado 2. Administrado 3. Definido 4. Administrado cuantitativamente 5. Optimizado Y por cuatro categoras de reas de procesos: Administracin de Procesos, Administracin de Proyectos, Ingeniera, Soporte. Estas categoras agrupan a las diferentes reas de proceso, dividindolos en procesos bsicos y avanzados. CMMI Modelo Escalonado El modelo escalonado, al igual que CMM, describe un camino evolutivo en 5 niveles de madurez de procesos, adems integra nuevas reas de proceso. La seleccin entre el modelo escalonado y el continuo depende del objetivo de la organizacin, adems de tener que considerar la situacin (si ya se tiene CMM, cultura en procesos, etc.). Por ejemplo, si el objetivo es llevar a la organizacin a cierto nivel de capacidad, deber seleccionarse la forma escalonada; en cambio si el objetivo es mejorar cierto proceso, ser mejor seguir la forma continua.
Niveles de Madurez Nivel

1 Inicial Proceso catico, impredecible. El xito depende del esfuerzo heroico de individuos. 2 Repetible Institucionalizar procesos efectivos de administracin de proyectos de software, que permiten a las organizaciones repetir prcticas exitosas desarrolladas en proyectos previos.
reas clave del proceso

Ninguna
Administracin de Requerimientos. Planeacin de Proyecto de Software. Seguimiento y Control del Proyecto de Software. Administracin de Subcontratos de Software. Aseguramiento de Calidad de Software. Administracin de Configuracin. de Software. Enfoque en Procesos de la Organizacin. Definicin de Procesos de la Organizacin. Programa de Capacitacin. Administracin Integral de Software. Ingeniera de Productos de Software. Coordinacin Intergrupal. Revisiones entre Colegas. Administracin cuantitativa de procesos. Administracin de la calidad del producto de software. Prevencin de defectos. Administracin de cambio de tecnologa. Administracin de cambio de procesos.
3 Definido El proceso estndar para desarrollar y mantener software en la organizacin esta documentado, incluyendo procesos de administracin e ingeniera de software, y estos procesos estn integrados.
4 Administrado Se establece un conjunto de metas cuantitativas para medir el nivel de calidad y desempeo de los proyectos y del proceso organizacional. 5 - Optimizado No es simplemente detectar y resolver defectos, sino prevenirlos y evitarlos al implementar actividades proactivas. Mejora continua de procesos.
ISO (International Standards Organization) en 1987 crea la norma ISO 9000, conjunto de estndares que establecen los requerimientos para la gestin de los sistemas de calidad. ISO 9000:2000 est formado por: ISO 9000 Fundamentos y Vocabulario. ISO 9001 Requisitos. ISO 9004 Recomendaciones. La parte de Requisitos - ISO 9001:2000, est estructurado en 8 secciones: 1. Alcance. 2. Normas para la Consulta. 3. Trminos y Definiciones. 4. Sistema de Gestin de la Calidad. 5. Responsabilidad de la Direccin. 6. Gestin de los Recursos. 7. Realizacin del Producto. 8. Medida, Anlisis y Mejora. Aunque ISO 9001:2000 no otorga un estndar especfico para sistemas de desarrollo de software, es decir, no abarca todos los procesos relacionados con el desarrollo de software, muchas organizaciones de software han optado por gestionar su sistema de calidad en base a este estndar, y obtener una certificacin reconocida de manera internacional.
ISO 9001-2000
Algunos Beneficios de CMMI vs. CMM
Algunos de los beneficios que han experimentado las organizaciones que pasan de CMM a CMMI son los siguientes: Mejor alineacin a objetivos de negocio. Mejor visibilidad hacia las actividades de ingeniera, con el objetivo de asegurar que el producto o servicio cumple las expectativas del cliente. Aprovechamiento de mejores prcticas adicionales (e.j., medicin, riesgo, administracin, y manejo de proveedores). Acoplamiento ms estrecho con estndares de ISO.
22
ENE-FEB 2005
Estndar internacional que ofrece un marco para la evaluacin de procesos. Fue iniciado en 1991 como el proyecto SPICE (Software Process Improvement and Capability dEtermination). La versin de Reporte Tcnico fue aceptada y publicada en 1998, enfocada nicamente en procesos de software. En el transcurso de su desarrollo ha evolucionado, de ser un modelo de referencia de buenas prcticas de software, para convertirse en un marco de trabajo para evaluacin de mltiples modelos (de software o no). Su direccin actual es poder aplicarse a mltiples disciplinas y permitir a las diferentes comunidades definir sus propios procesos especficos, modelos de referencia o buenas prcticas. ISO 15504 est en vas de convertirse en estndar internacional, y se espera que est completo para 2006. Esta versin esta compuesta de cinco documentos, a diferencia del reporte tcnico que consta de nueve partes (Ver grfica 1 - Estructura de documentos). La parte 2 de este estndar es de especial inters, ya que es la que define como se realiza una evaluacin. Establece requisitos tanto para modelos de procesos de referencia como para los mtodos de evaluacin sin establecer alguno en particular.
ISO/IEC 15504
* Partes publicadas
Grfica 1 - Estructura de Documentos 15504
Niveles de Capacidad (Ver grfica 2): 0. Incompleto.- Falta de cumplimiento del proceso. 1. Realizado.- Genera los productos de trabajo esperados. 2. Administrado.- Proceso y productos administrados y controlados. 3. Establecido.- Proceso definido para la organizacin y utilizado adecuadamente. 4. Predecible.- El proceso opera dentro de los lmites estadsticos establecidos. 5. Optimizado.- El proceso mejora continuamente. Las organizaciones de software no tienen que seleccionar entre 15504 y su modelo actual. El rol de 15504 es proveer un marco de trabajo en el que los modelos y mtodos de evaluacin puedan existir de una manera armnica. No esta diseado para ser utilizado solo. La seleccin radica en decidir si el ajustarse a 15504 es importante para el negocio (El negocio compite en el mercado global?, Provee software a algn cliente que requiera 15504?, Existen varios modelos de evaluacin en la organizacin?). De ser as, debern elegir modelos que se ajusten a 15504.
Grfica 2 - Modelo de Capacidades 15504-2
CMMI Modelo Escalonado

Nivel de Madurez
1 Inicial Madurez de un proceso caracterizada por resultados impredecibles. 2 Administrado Madurez del proceso caracterizada por el desempeo repetible del proyecto. El foco clave del proceso esta en actividades y prcticas a nivel proyecto. 3 Definido Madurez del proceso caracterizada por mejorar el desempeo del proceso dentro de una organizacin.
Compatibilidad entre Modelos

reas de proceso
Ninguna
Administracin de Requerimientos. Planeacin de Proyectos. Monitoreo y Control de Proyectos. Administracin del Acuerdo con el Proveedor. Administracin de Configuracin. Aseguramiento de Calidad de Proceso y Prod. Mediciones y Anlisis. Desarrollo de Requerimientos. Solucin Tcnica. Integracin de Producto. Verificacin, Validacin. Enfoque Organizacional en Proceso. Definicin de Procesos de la Organizacin. Capacitacin Organizacional. Administracin Integral de Proyectos. Administracin del Riesgo. Anlisis de Decisin y Resolucin. Desempeo de Procesos Organizacionales. Administracin Cuantitativa de Proyectos. Innovacin y Despliegue Organizacional. Anlisis Causal y Resolucin.
ISO/IEC 15504 Evaluacin de procesos de software. En vas de ser estndar. Direccin amplia. Niveles de capacidad. Evaluacin de capacidades por proceso individual. Gua para realizar la evaluacin. Toma como referencia ISO 9001 y CMMI. CMMI Modelo de madurez de procesos de software. Modelo estndar de facto. Direccin detallada. Pasos progresivos (niveles) - Escalonada. Categoras de procesos - Continua. Gua para institucionalizacin e implementacin. Modelo de evaluacin ser conforme al modelo de evaluacin de 15504. ISO 9001-2000 Sistema de Gestin de la Calidad. Estndar internacional. Direccin amplia. Un conjunto de requerimientos a ser cubierto. No hay lineamientos para su implementacin. Usado como referencia en actividades de gestin de calidad por CMMI y 15504.
ENE-FEB 2005
4 Administrado Cuantitativamente Caracterizada por mejorar el desempeo organizacional. 5 - Optimizado Madurez del proceso caracterizada por un desempeo organizacional rpido y configurable, Mejora continua y cuantitativa de procesos.
23
Modelos Especficos
Personal Software Process (PSP) es un proceso diseado para ayudar a los ingenieros de software a controlar, manejar y mejorar su trabajo. PSP est basado en una motivacin: La calidad de software depende del trabajo de cada uno de los ingenieros de software. Debido a que los costos de personal constituyen 70% del costo del desarrollo de software, las capacidades y hbitos de trabajo de los ingenieros determinan en gran manera los resultados del desarrollo de software. Basado en prcticas encontradas en CMM, el PSP puede ser usado por ingenieros para estructurar y disciplinar el desarrollo de software. El ingeniero de software podr planear mejor el trabajo, conocer con precisin el desempeo, medir la calidad de productos, y mejorar las tcnicas. PSP puede ser aplicado en: Desarrollo de programas. Definicin de requerimientos. Documentacin. Pruebas de sistemas. Mantenimiento de sistemas.
PSP Personal Software ProcessSM
El Rational Unified Process (RUP) es un proceso de software desarrollado y comercializado por Rational Software (ahora parte de IBM). RUP est diseado alrededor de seis mejores prcticas para el desarrollo de software: Desarrollar de manera iterativa. Administrar los requerimientos. Utilizar arquitecturas basadas en componentes. Modelar el software visualmente. Verificar la calidad de manera continua. Controlar los cambios. En s, RUP es una gua que define roles, actividades, flujos de trabajo y lineamientos para ejecutar proyectos de software de acuerdo a estas mejores prcticas. RUP organiza los proyectos de software en dos dimensiones: la del tiempo y la de las actividades. En base al tiempo, los proyectos se dividen en cuatro fases secuenciales: Concepcin Definicin de alcance, identificacin de riesgos. Elaboracin Resolucin de riesgos, establecimiento de arquitectura. Construccin Generacin del producto. Transicin Disponibilidad a la comunidad de usuarios finales. Las actividades se organizan en nueve diferentes disciplinas que son ejecutadas durante las diferentes fases.
RUP
Evolucin de PSP
TSP - Team Software ProcessSM
Team Software Process (TSP) es un marco para el desarrollo de software que pone igual nfasis en el proceso, producto y trabajo en equipo. Al igual que PSP, TSP fue propuesto por Watts Humphrey. TSP se basa en PSP, y se fundamenta en que el software, en su mayora, es desarrollado por equipos, por lo que los ingenieros de software deben primero saber controlar su trabajo, y despus saber trabajar en equipo. TSP le ensea a los ingenieros a construir equipos autodirigidos y desempearse como un miembro efectivo del equipo. Tambin muestra a los administradores como guiar y soportar estos equipos. Estrategia de TSP Proveer un proceso sencillo basado en PSP Desarrollar productos en varios ciclos. Ciclo de TSP: Lanzamiento, Estrategia, Plan, Requerimientos, Diseo, Implementacin, Pruebas, Postmortem Establecer medidas estndares para calidad y desempeo Proveer definiciones de roles, y evaluaciones de rol y de equipo Requiere disciplina de proceso Provee gua para manejo de problemas de trabajo en equipo
En realidad RUP es un framework (marco de trabajo) que pretende ser personalizado o configurado para organizaciones y proyectos especficos. RUP no se puede aplicar de la misma forma en todos los proyectos de una organizacin. Es por esto que pretender seguir RUP a travs de ir cumpliendo con la lista de artefactos que define, es una estrategia poco efectiva. Lo que las organizaciones deben hacer es entender la razn de ser de RUP las prcticas citadas anteriormente y en base a esto aplicar lo que decidan que es conveniente para cada rea o proyecto especfico. RUP es una instancia particular del Proceso Unificado, definido por Ivar Jacobson, Grady Booch y James Rumbaugh en el libro The Unified Software Development Process de 1998. Adicionalmente existen otras instancias de este proceso, tales como el Proceso Unificado Mejorado (Enhanced Unified Process), el cual agrega soporte multiproyectos y fases y disciplinas para el mantenimiento y retiro de sistemas de software.
Compatibilidad de PSP y TSP con CMMI
CMM y CMMI se enfocan en la mejora organizacional basada en modelos. TSP contiene prcticas operativas para el desarrollo de equipos. PSP se enfoca en la mejora a nivel individual.
24
ENE-FEB 2005
Qu hay para la Industria Mexicana?

Mxico quiere y puede darse a conocer con una fuerte industria de software. Las condiciones bsicas estn dadas: se generan recursos humanos capacitados, se tiene acceso a los equipos y herramientas de desarrollo, el mercado local tiene necesidades lejos de estar satisfechas, el mercado externo de habla hispana no est saturado y la cercana con los E.U. trae oportunidades de exportacin potenciales. MoProSoft, modelo de procesos para la industria de software mexicana, fue desarrollado pensando en facilitar a las organizaciones dedicadas al desarrollo y mantenimiento de software la adopcin de las mejores prcticas reconocidas internacionalmente a travs de modelos como SW-CMM, CMMI, TSP, PSP, ISO/IEC 15504, PMBOK y SWEBOK.
Caractersticas principales 1. Estructura adaptable - Los procesos estn organizados en 3 categoras, que corresponden a la estructura de cualquier organizacin. 2. Nmero reducido de procesos - Slo 6 procesos principales y 3 subprocesos. 3. Procesos integrados a travs de roles y productos. 4. Gestin de Negocio como proceso explcito. 5. Integracin de la gestin de recursos humanos, de infraestructura y conocimiento. 6. Verificaciones y validaciones explcitas. 7. Manejo de situaciones excepcionales. 8. Productos de trabajo con caractersticas mnimas explcitas. 9. Indicadores y propuestas de mediciones para evaluar el cumplimiento de los procesos. 10. Guas de ajuste para adecuar los procesos.
REFLEXIONES
El Desarrollo de Software
Por Francisco Lpez Lira
ARTE O INGENIERA?
La virtud est en el medio. Horacio Existen en la industria dos visiones aparentemente encontradas sobre lo que debera ser el desarrollo de software, aquella que lo considera una arte y la que plantea que es ingeniera. La primera considera al desarrollador como un artista, no sujeto a reglas ni mtodos, enfatizando la creatividad como la principal virtud. Rechaza los procesos considerando que estos restringen la creatividad. La segunda visualiza al desarrollador como un ingeniero, que debe utilizar procesos, mtodos y tcnicas probadas en un ambiente disciplinado y hace nfasis en establecer procesos definidos y controlados. Aunque ambos enfoques tienen algo de verdad, debemos tener en cuenta algunas consideraciones: Arte no equivale a Caos. La idea de Arte est estrechamente relacionada con un sistema de trabajo. Etimolgicamente Arte deriva del latn Ars que, a su vez, deriva del griego Tecn y que para Aristteles era el uso sistemtico del conocimiento para la accin humana inteligente. El arte requiere disciplina. Por ejemplo, a Miguel Angel le tomo cuatro aos terminar la Capilla Sixtina. Se dice tambin que Leonardo Da Vinci poda trabajar las 24 horas del da. Produccin artstica no es produccin comercial. Los grandes artistas del renacimiento tenan mecenas que les permitan vivir cmodamente hasta que creaban su obra maestra. Por otro lado, el desarrollo de software en el entorno actual implica cumplir con tiempos establecidos, lo cual a su vez requiere de procesos predecibles. La creatividad es muy importante, pero no es lo nico. Un proyecto de desarrollo de software requiere adems: planear, controlar, organizar personas, dirigir, comunicar, coordinar, negociar, interactuar, verificar y validar, por ejemplo. Todo esto requiere de un entorno organizado. Lo importante es la gente, lo secundario los procesos. Sin embargo, hay que considerar que la gente no puede funcionar adecuadamente en un sistema catico. El sistema siempre ganar dice Rummler . Por ello, es necesario contar con los procesos adecuados que posibiliten un sistema estable. Un mal proceso es peor que ninguno. Los procesos que se utilicen deben ser diseados a partir del conocimiento de los desarrolladores y de las condiciones de cada organizacin. Quiz la virtud yazca en el medio. Podemos utilizar procesos y modelos de procesos procurando crear un entorno organizado para potenciar el valor de las personas y de creatividad.
1 Geary A. Rummler, Serious performance consulting, International Society for Performance Improvement, 2004
Arquitectura de MoProSoft
Las organizaciones de desarrollo de software, adems de entender los principales modelos y procesos existentes, deben considerar varios factores para poder decidir que camino seguir, como: tamao de la organizacin, recursos, enfoque en mercado global o local, habilidades, etc. Las empresas grandes con miras a la exportacin, pueden considerar una certificacin en CMMI, principalmente niveles 2 y 3, con el objetivo de evaluarse y ganar ventaja competitiva. Las empresas pequeas y medianas con miras a mejorar los procesos y ser competitivos, pueden adoptar ISO 9001, ya que es un modelo ms barato y sencillo. Las PyMEs mexicanas tienen la opcin de seguir MoProsoft como camino inicial. Las reas internas de sistemas pueden adoptar algn proceso especfico, adems pueden requerir a sus proveedores algn nivel de madurez comparable con CMMI o ISO 15504, o bien, que adopten el mismo proceso especfico. Es recomendable considerar otros modelos que apoyen y complementen la correcta implantacin del proceso de software. Como ISO/IEC 9126:2001 enfocado en modelar la calidad de productos de software, o bien, modelos para implementar procesos de mejora como IDEAL. Otros modelos especializados, que pueden ser de gran utilidad son PMBOK (Project Management Body of Knowledge) y SWEBOK (SW Engineering Body of Knowledge). Para muchas de las organizaciones a nivel mundial, los 90s fueron la dcada de mejora de procesos. Aunque muchas aprendieron cmo implementar exitosos programas de mejora, otras lucharon sin lograr mejoras duraderas. Estas ltimas organizaciones pasarn la siguiente dcada tratando de ponerse al da, mientras que los lderes emprenden nuevos retos. Las metas relacionadas con procesos en esta dcada incluyen integracin de procesos, armonizacin, y aceleracin. Las organizaciones deben luchar por alcanzar un nivel de calidad que les permita ser competitivas en el mercado global. El punto de inicio es definir la meta, entendiendo la situacin actual y las diferentes opciones, para poder as emprender el viaje por el camino correcto.
Referencias: Proceso de Desarrollo de Software, Hanna Oktaba, Facultad de Ciencias UNAM Porqu usar MoProSoft como modelo de procesos de referencia?, Hanna Oktaba, www.amcis.org.mx Software Engineering Institute Carnegie Mellon University, www.sei.cmu.edu Diplomado en Calidad de Software, AMCIS 2002 www.amcis.org.mx Process Diversity in Software Development IEEE Software, julio-agosto 2000
Conclusin
El autor es fundador y actual presidente de la Asociacin Mexicana para la Calidad en Ingeniera de Software (AMCIS). flopezlira@amcis.org.mx
ENE-FEB 2005
25
CASO DE ESTUDIO
Aplicando
Por Ricardo Vidrio y Ricardo Domnguez
PSP y TSP
Una de las experiencias que QuarkSoft, S.C. ha tenido en el desarrollo de software utilizando metodologas como Personal Software ProcessSM (PSP) y Team Software ProcessSM (TSP), ha sido realizar un proyecto para generar un cambio a la nmina a nivel nacional de una dependencia de gobierno.
Quarksoft Comparte Su Experiencia
uando QuarkSoft tom el proyecto, ste ya llevaba un retraso de varias semanas con respecto a la fecha de inicio planeada, an no se realizaba la fase de anlisis de requerimientos y la fecha de terminacin, como en muchos otros casos, no era negociable, por lo que para terminar el proyecto en tiempo y forma, el equipo de desarrollo deba ser muy eficiente. Los problemas principales que enfrentamos fueron los siguientes: Falta de toma de requerimientos. Muy poca gente conoca la regla del negocio. El proyecto de inicio ya contaba con un retraso importante. No exista una planeacin del proyecto. Los participantes por parte del cliente no estaban familiarizados con PSP y TSP.
QuarkSoft decidi tomar esta oportunidad ya que era un claro ejemplo de falta de organizacin en la administracin de un proyecto y era un buen momento para probar si realmente los procesos funcionaban en tiempos de crisis. Nuestro principal reto era decidir cules seran los procesos mnimos a implementar para trabajar bajo esta metodologa, tomando en consideracin que la mayor parte del equipo no contaba con capacitacin en PSP y TSP, requerida para asegurar el control del proyecto.
26
ENE-FEB 2005
Toda la informacin que se genera durante el proceso de lanzamiento es necesaria para evaluar si el proyecto es factible en el tiempo que se requiere.
Se gener un reporte en el cual se inclua el nmero total de programas o componentes por mdulo, la etapa del ciclo de desarrollo en la que estaban cada uno de ellos y el porcentaje de avance de cada mdulo como se muestra en la siguiente tabla:
Estatus de Mdulos
Mdulo Altas Nmero de 10 Anlisis Pruebas 10 9 1 20 21 11 10 9 1 20 1 11 Porcentaje Nuevos 100.00 100.00 100.00 46.51 50.00 61.11 0 6 1 4 0 Faltantes 0 0 0 23 1 7 componentes y Codific. Terceros 9
El proyecto inici con un proceso de lanzamiento como lo plantea TSP. Este lanzamiento consiste de una serie de 9 juntas que se realizan en un periodo de 3 a 4 das con el equipo completo de desarrollo. Los objetivos de cada sesin son los siguientes: Sesin 1 Definir objetivos del cliente y del producto a construir. Sesin 2 Asignar roles y responsabilidades de cada miembro del equipo. Sesin 3 Obtener diseo conceptual del producto, estrategia de desarrollo y lista de principales componentes. Sesin 4 Identificar y estructurar actividades necesarias para la construccin. Sesin 5 Generar plan de calidad basado en mtricas cuantitativas para monitorear la calidad de los componentes creados. Sesin 6 Detallar plan de trabajo. Sesin 7 Analizar riesgos. Sesin 8 Preparar presentacin para el cliente con resultados del lanzamiento. Sesin 9 Presentar al cliente. Toda la informacin que se genera durante el proceso de lanzamiento es necesaria para evaluar si el proyecto es factible en el tiempo que se requiere, adems de tener todo un plan de accin detallado a seguir durante el desarrollo del proyecto con metas especficas y, sobre todo, verificables. Los mecanismos seleccionados para la administracin del proyecto fueron los siguientes: 1. Registro del tiempo real invertido por cada ingeniero en el proyecto para compararlo contra el tiempo planeado. 2. Juntas de comunicacin entre los integrantes del equipo. 3. Juntas de estatus semanales con el equipo y el cliente. 4. Control y seguimiento cuantitativo del avance de los componentes a nivel individual. El plan del proyecto contaba con actividades especficas y con tiempos planeados para realizarlas. Los tiempos que se registraron se dividieron en 3 tipos: tiempo real, que es el tiempo que se invirti al realizar una actividad del plan de trabajo; tiempo de espera, que es el tiempo muerto que un ingeniero tiene por dependencias con actividades de otros ingenieros o por esperar decisiones o actividades por parte del cliente; y, finalmente, el overhead, que se define como el tiempo que se tiene que invertir en actividades que no se planearon pero que se deben realizar para terminar el proyecto. Cada semana se convocaba a una junta de estatus con el objetivo de mantener informado al cliente del avance cuantitativo del proyecto.
Nmina 1 Admon. 43 Rep. 57 Nuevos 18
La tabla nos muestra de manera sencilla y puntual los mdulos a desarrollar dentro del proyecto, el nmero de componentes de los que consta y las diferentes fases por las que tiene que pasar cada componente, desde el anlisis hasta las pruebas necesarias para verificar que efectivamente se cumplen con los requerimientos solicitados por el cliente. PSP propone la realizacin de revisiones e inspecciones de los componentes al trmino de las fases de diseo detallado, codificacin y pruebas de unidad. El objetivo de las revisiones e inspecciones es que el ingeniero de software identifique mediante un checklist que contiene los puntos ms importantes a revisar, el mayor nmero de defectos posibles en cada componente. Posteriormente se genera una inspeccin por un ingeniero que es ajeno a la construccin de ese componente y, apoyado por un checklist de inspeccin, identifica el mayor nmero posible de defectos que no se detectaron en la revisin. Esto permite que el producto contenga la menor cantidad de defectos cuando se encuentre en la etapa de pruebas de integracin de componentes, con lo cual se pretende reducir los tiempos de las fases de pruebas de integracin y de sistema, que regularmente dentro de un proyecto de desarrollo de software son impredecibles y costosas. Adicionalmente, y con el objetivo de mantener un mayor control del proyecto, se incluy una grfica para conocer el porcentaje de avance real del equipo con respecto al plan. La grfica se genera mediante la consolidacin de datos que cada uno de los ingenieros de software registra. La informacin contenida en la grfica nos brinda la oportunidad de identificar el avance real del proyecto mediante el concepto de valor ganado. Cada una de las actividades planeadas en la construccin de los componentes tiene asignado un determinado valor ganado. El valor ganado del proyecto se obtiene considerando nicamente todas aquellas actividades que han sido concluidas satisfactoriamente y no se asignan valores parciales por actividades inconclusas. El valor ganado se define como el valor otorgado a cada una de las actividades del plan detallado como un porcentaje de su duracin con respecto al tiempo total del proyecto.
Ricardo Vidrio es director de operaciones de QuarkSoft. Es instructor de PSP autorizado por el SEI y coach de equipos TSP. Es egresado del ITESM y tiene una maestra en Ingeniera de Software en la Universidad Carnegie Mellon.
ENE-FEB 2005
27
CASO DE ESTUDIO
Valor Ganado
En la grfica se muestran tres diferentes lneas. La lnea azul (rombos) nos indica el valor ganado planeado del proyecto y representa el tiempo que llevarn las actividades incluidas en el plan original. Esta lnea se vuelve nuestro eje, ya que ah est indicado el inicio y fin del proyecto. La lnea rosa (cuadros) representa el valor ganado real que llevamos semana a semana y que refleja todas las actividades terminadas en el plan de cada ingeniero. Esta nos permite ver de forma cuantitativa el avance real del proyecto. Finalmente, la lnea verde (tringulos) nos indica una proyeccin del tiempo que requeriramos para terminar todas las actividades planeadas en un inicio si tomamos en cuenta el desempeo real del proyecto. La informacin de la lnea verde nos predice el posible retraso que se tendra si no se toman las medidas correctivas necesarias para evitarlo.
Valor ganado
Semanas
Esta informacin nos permiti saber en todo momento cul era el estatus real del proyecto, qu se haba realizado y lo que faltaba por ejecutar. En los proyectos normalmente no tenemos registros del tiempo que se pierde por falta de definicin o por cambios de requerimientos por parte del cliente. Cuando el cliente tuvo conocimiento de esta informacin, se empezaron a tomar acciones correctivas y posteriormente preventivas para evitar mayores retrasos en el proyecto. Finalmente, el proyecto se logr controlar y se concluy con dos semanas de retraso, lo cual fue considerado por el cliente como un xito rotundo. Los planes individuales son la clave para darle seguimiento al plan general original. Estos planes permiten informar el estatus de cada actividad, revisar constantemente los riesgos importantes del proyecto, reorganizar la carga de trabajo entre los ingenieros en caso de ser necesario, y producir los informes semanales del estatus del proyecto que se le entregan al cliente. Disciplinas como las planteadas en PSP y TSP nos ayudan a que el desempeo de cada uno de los ingenieros sea mayor, dando la oportunidad a cada uno de planificar y dirigir su propio plan de trabajo e interactuar dentro de equipos autodirigidos que se hacen responsables de sus propios planes. Adicionalmente, el uso de modelos como PSP y TSP no garantizan que el proyecto nunca entre en crisis, pero s nos proveen de informacin oportuna que nos permite tomar las decisiones adecuadas para mantener bajo control el proyecto. La implementacin de estos modelos depende del compromiso y disciplina de los ingenieros que intervienen en los proyectos, ya que son ellos los responsables de llevar a cabo todos los procesos necesarios para que la recoleccin de mtricas sea adecuada. Slo con
mtricas confiables se puede crear una base de datos histricos que nos ayude a mejorar las estimaciones de futuros proyectos que puedan ser entregados a tiempo, en costo y con calidad. PSP y TSP permiten que el proveedor de servicios se convierta en una organizacin cada vez ms madura, ya que el cliente tiene la visibilidad de cmo se desarrollan sus proyectos, se incrementa la confianza en las estimaciones basadas en datos histricos y, sobre todo, con la terminacin exitosa de los proyectos, se incrementa el nimo de los equipos de desarrollo. Para introducir correctamente estos modelos es necesario un apoyo total de los gerentes y directivos responsables de financiar estos proyectos. Es importante que la alta gerencia comprenda que las prcticas de ingeniera de software contenidas en estos modelos generarn mejoras en el proceso de desarrollo de software que se traducirn a mediano plazo en una mayor rentabilidad del negocio. Es vital para la continuidad de este proyecto que la alta gerencia est completamente convencida de los beneficios que se obtendrn para no cancelar el apoyo al proyecto en caso de un retraso no planeado. Actualmente QuarkSoft (www.quarksoft.net) est trabajando en el proceso para obtener la certificacin CMMI nivel 3 y basa toda su iniciativa del programa continuo de mejoramiento de procesos de software en los modelos PSP y TSP.
Team Software ProcessSM,TSPSM, Personal Software ProcessSM y PSPSM son Service Marks de la Universidad de Carnegie Mellon.
Ricardo Domnguez es lder de proyecto en QuarkSoft con ms de nueve aos de experiencia en desarrollo de software. Es ingeniero de software certificado en PSP con entrenamiento en TSP. Ricardo es egresado de la Universidad Popular Autnoma del Estado de Puebla (UPAEP).
28
ENE-FEB 2005
PRCTICAS
ADMINISTRACIN DE PROYECTOS
E
S
STIMACIN
DE PROYECTOS
ENTENDIENDO LAS BASES

Por Rodrigo Garca
egn Aberdeen Group, 90% de los proyectos de software se liberan tarde, mientras que Gartner comenta que 50% de los proyectos de software excede su presupuesto inicial. Existen muchas razones para esto, pero una de las ms comunes es que no se realiza una estimacin adecuada. La informacin que se espera obtener a travs de la estimacin en un proyecto de software es la siguiente: Tamao del producto Esfuerzo requerido Duracin del proyecto Recursos necesarios Calidad esperada Como ya mencionamos, las malas estimaciones o las no estimaciones son una de las principales causas de fracaso en los proyectos. Esto tpicamente sucede por no contar con un proceso estructurado para la estimacin, lo cual hace casi imposible definir equipos de trabajo de magnitud adecuada y plazos de cumplimiento razonables. La situacin empeora cuando no se cuenta con informacin de proyectos anteriores. Todo esto hace que la estimacin sea uno de los temas que ms preocupa a los administradores de proyectos de software. Un problema inherente a la estimacin es que conforme aumenta el tamao del proyecto, disminuye la precisin de los resultados obtenidos (ver grfica 1).
Precisin de la estimacin
Grca 1. Conforme aumenta el tamao del proyecto disminuye la precisin de la estimacin
Entonces, qu debemos hacer para que nuestra estimacin sea precisa, exitosa y cumpla los objetivos que buscamos? Comencemos por entender las dos caractersticas principales de cualquier estimacin: que sea explicable y que sea revisable. Explicable.- Es comn que al preguntar a las personas cmo llegaron al resultado de una estimacin, ellas mismas no lo puedan explicar. Una buena estimacin debe de tener suficiente claridad y modularidad para que sea entendible y cualquier persona pueda comprender los valores de todos sus componentes.
Rodrigo Garca es Technical Solutions Manager en Softtek Information Services en Monterrey, N.L., donde es responsable de la estimacin de propuestas para proyectos de desarrollo. Rodrigo es Ingeniero en Sistemas Computacionales del ITESM y actualmente cursa el MBA en Global e-Management en la misma institucin.
30
ENE-FEB 2005
Desviacin de la estimacin
Grca 2. La desviacin de la estimacin disminuye conforme avanza el proyecto.
Revisable.- A medida que el proyecto va avanzando, la cantidad de informacin que se tiene va siendo cada da mayor, y la misma nos ayuda a ir corrigiendo la estimacin. Es importante definir lmites superiores e inferiores para la estimacin, dependiendo de la etapa en la que se encuentre (ver grfica 2). Gracias a estos lmites, y con la ayuda de cierta informacin histrica, podremos ir revisando nuestro proyecto para saber si seguimos dentro del estimado. Tomemos como ejemplo un proyecto de 500 horas hombre. Nuestra informacin histrica nos indica que el levantamiento de requerimientos lleva cerca de 20% del tiempo, el diseo 30%, el desarrollo 25%, y las pruebas, junto con la puesta en produccin, 25% restante. Imaginemos que habamos planeado el levantamiento de requerimientos en 100 horas, pero en realidad se lleva 120. En este momento es cuando se tiene que revisar el estimado, ya que sera incorrecto asumir que solamente vamos con 20 horas de retraso, cuando en realidad llevamos un retraso de 20%. En este caso, tendramos que revisar el proyecto y agregar 20% al esfuerzo en todas las fases. Nuestro nuevo estimado sera de 600 horas. La duracin definida para un proyecto rara vez surge como resultado de una estimacin, sino que es negociada entre el cliente (ya sea interno o externo) y el equipo de desarrollo. Suele suceder que se busque acortar el tiempo en funcin de aumentar el nmero de recursos, pero sabemos que esta relacin no es del todo correcta. De aqu la existencia de frases como no porque una persona pinte una casa en diez das debemos concluir que diez personas lo harn en un da. Otro error comn es no tomar en cuenta las limitaciones de recursos disponibles. Debemos aprender a estimar en base a los recursos que se tienen, no a los que quisiramos tener.
Sentando estos antecedentes, expliquemos dos mtodos comunes para estimar de proyectos de software.
COCOMO
Desarrollado en la Universidad del Sur de California con Barry Boehm como principal autor. Su nombre significa Constructive Cost Model (modelo constructivo de costo). El modelo original data de 1981, pero en el 2000 se liber COCOMO II, una versin ajustada para el tipo de proyectos realizados actualmente. Este modelo se basa en la siguiente informacin para realizar una estimacin: Tamao del sistema.- Normalmente medido en KSLOCs o miles de lneas de cdigo la K representa un millar, y SLOC es el acrnimo de source lines of code. Esta informacin se puede obtener en base a sistemas existentes, aunque tambin existen mtodos para estimar el tamao de un sistema en base a su funcionalidad (ver puntos de funcin ms adelante). Factores de escala.- Contabilizan las economas o deseconomas de escala en el proyecto. Cuando un proyecto exhibe economas de escala, significa que si el tamao del producto se duplica, el esfuerzo necesario es menos del doble, mientras que cuando hay deseconomas de escala, el esfuerzo requerido aumenta a un ritmo mayor que el tamao del producto. Entre los factores que mejoran las economas de escala estn la cohesin del equipo y la madurez de procesos en la organizacin. Sin embargo, en general los proyectos de software exhiben deseconomas de escala. Multiplicadores de esfuerzo.- Caractersticas del proyecto que afectan el esfuerzo requerido para desarrollarlo. Algunos ejemplos son el nivel del personal disponible, las herramientas utilizadas o la complejidad del lenguaje.
PRCTICAS
ADMINISTRACIN DE PROYECTOS
No porque una persona pinte una casa en diez das debemos concluir que diez personas lo harn en un da.
La frmula para estimar esfuerzo es del tipo: pendiendo de la cantidad de datos que maneje; posteriormente, asignar una cantidad de puntos a cada elemento. Por ejemplo, una bsqueda de complejidad baja corresponde a 4 puntos, mientras que una salida de complejidad alta corresponde a 7. Existen tablas con los valores correspondientes a cada caso (ver las referencias). 3. Sumar los puntos asignados a cada elemento para generar un total conocido como puntos de funcin sin ajustar (UFP por sus siglas en ingls). 4. Determinar el factor de complejidad tcnica (TCF). Identificar las caractersticas tcnicas relevantes al proyecto, tales como requerimientos de desempeo, confiabilidad e interaccin con otros sistemas. Con esto se calcula un factor de ajuste cuyo valor va de .65 a 1.35. 5. Estimar los puntos de funcin ajustados. FP = UFP * TCF Con esto ya podemos determinar el tamao de un sistema. Pero ahora, cmo podemos obtener el esfuerzo y duracin del proyecto? Imaginemos que vamos a desarrollar un sistema de 100 FPs, y que usaremos un ciclo de vida tradicional en cascada con las siguientes etapas: anlisis de requerimientos, diseo, construccin, pruebas y liberacin a produccin. Basndonos en registros histricos, podemos determinar la relacin que hay entre la cantidad de FPs de un sistema y el esfuerzo requerido para cada etapa. Por ejemplo, podramos concluir que el anlisis requiere 2 horas-hombre por cada FP, y como nuestro sistema tiene 100 FPs entonces podemos esperar que el anlisis se lleve 200 horas-hombre. La tabla 1 muestra el ejemplo completo.
Modelo de estimacin de esfuerzo

Etapa Esfuerzo por FP 2 3 5 4 2 Esfuerzo Esperado 200 300 500 400 200 1600
Requerimientos Diseo Construccin Pruebas Liberacin Total

Tabla 1
Donde A es una constante, E es un indicador de economas de escala (calculado en base a los factores de escala), y ME es el promedio de valores de los multiplicadores de esfuerzo.
La frmula para estimar la duracin es del tipo:
Donde C es una constante y F es un valor derivado de los factores de escala.
Existen valores por defecto para las constantes, pero lo ideal es calibrarlas en base a la informacin histrica de proyectos en la organizacin. En general, COCOMO es una buena opcin para realizar estimaciones macro, con el objetivo de asignar presupuesto a un proyecto, o decidir si vale la pena desarrollar/ reemplazar un sistema.
Este ejemplo slo llega al nivel de detalle de etapas. Un modelo real debe contemplar todas las actividades a realizar dentro del proyecto, incluyendo juntas de revisin y otras tareas que rara vez se toman en cuenta en una estimacin. La idea de este mtodo es que sirva de base para la planeacin de actividades y asignacin de recursos en un plan de trabajo detallado.
Conclusin
Hemos delimitado la importancia y dificultades de la estimacin de proyectos de software. Mencionamos dos mtodos de estimacin: uno orientado a generar valores agregados para la toma de decisiones, y otro orientado a generar informacin detallada para la planeacin. En prximos artculos hablaremos ms a fondo sobre ellos. Es un hecho que ningn modelo va a dar una alta precisin en un inicio, poco a poco deben irse ajustando en base a la informacin obtenida cada que se realiza un proyecto.
Referencias: Gramajo, E. et al. Combinacin de Alternativas para la Estimacin de Proyectos de Software. CAPIS - Centro de Actualizacin Permanente en Ingeniera de Software. Boehm, Barry et al. Software Cost Estimation with COCOMO II. Prentice Hall, 2000. Longstreet, David. Fundamentals of Function Point Analysis. www.ifpug.com/fpafund.htm
Puntos de Funcin
Otra alternativa para dimensionar un sistema es utilizando function points (FPs) o puntos de funcin. Este mtodo fue creado por Allan Albrecht, y es una manera de cuantificar la capacidad funcional de un sistema de software. Los pasos para determinar los puntos de funcin en un sistema son: 1. Identificar los elementos generadores de funcionalidad. Estos pueden ser de cinco tipos: transacciones de entrada, transacciones de salida, transacciones de bsqueda, archivos lgicos internos y archivos de interfase externa. 2. Calificar cada elemento y asignarle un valor. Cada elemento se califica como simple, promedio o complejo, de-
32
ENE-FEB 2005
PRCTICAS
ASEGURAMIENTO DE CALIDAD
SQA?
E
Falta de planeacin Falta de administracin del proyecto Falta de soporte ejecutivo Cambios no controlados Expectativas poco realistas Altos costos Falta de recursos Requerimientos incompletos
SLVESE QUIEN PUEDA!

Aseguramiento de Calidad
Por Mariana Prez-Vargas y Elizabeth Almeraz
l desarrollo de software es una de las actividades ms complejas que se realizan hoy en da. Es considerado como algo abstracto ya que el producto que se construye no es algo fsico, es una caja negra. Podemos decir sin temor a equivocarnos, que los requisitos que pedimos para desarrollar software son mnimos y por lo tanto ste tiene un alto grado de incertidumbre, el cual aumenta si en el proyecto se presentan los siguientes problemas:
prcticas de aseguramiento de calidad en los proyectos de desarrollo de software.
Actualmente, muchas organizaciones de TI, as como reas internas de sistemas, sin la necesidad de establecer un programa de mejora o seguir todas las prcticas de un modelo o estndar de referencia, estn adoptando la prctica de aseguramiento de calidad de software para incrementar la calidad de sus productos, y lograr que el desarrollo de software sea ms predecible. Hasta aqu la historia parece ir muy bien, sin embargo, a pesar de que las organizaciones, desde el punto de vista competitivo, reconocen el valor del SQA (Software Quality Assurer / Advisor), en la prctica este rol es muchas veces subvalorado, incluso por aqullas donde se han establecido ciertas prcticas. Se cuestiona el valor agregado que puede aportar a los proyectos, siendo un recurso que no est involucrado al 100% en los mismos. En ocasiones, se visualiza al SQA ms como un enemigo y una barrera para realizar el trabajo asignado, que como el aliado que puede avisarnos sobre los peligros latentes que se encuentran en el proyecto al no seguir adecuadamente un proceso o al fijarnos expectativas que se encuentran fuera de lo humanamente alcanzable. Esta visin resta importancia y respeto al papel que este rol desempea, por lo cual es importante reivindicarlo para que pueda mostrar sus bondades al resto de la organizacin y una revisin de aseguramiento de calidad se convierta en algo que nos brinde un valor agregado ms que en una pesadilla que no nos deje conciliar el sueo en la noche.
La pregunta es, cmo se puede tener mayor certidumbre en el desarrollo de software y obtener productos con calidad, con el presupuesto planeado y en el plazo estimado? Los problemas que enfrentamos en el desarrollo de software tienen solucin a travs de la adopcin de procesos, lo cual consiste en que las organizaciones usen buenas prcticas que han demostrado ser efectivas y que definen de manera precisa cmo se construye el software. En el mercado existen diferentes modelos y estndares que pueden ser adoptados por la industria de TI: CMMI, ISO15504, MoProSoft, ISO9000, PMBoK, Trillium y Bootstrap, por mencionar algunos. Todos estos de alguna manera consideran y recalcan la importancia de establecer
Mariana Prez-Vargas es Directora General de Avantare y Lead Assessor Certificada y Autorizada por el SEI. Cuenta con amplia experiencia para proporcionar consultora estratgica a diferentes empresas desarrolladoras de software, reas de desarrollo de software y organismos gubernamentales. Pionera en el rea de calidad y procesos, entre sus principales logros est haber sido responsable de coordinar exitosamente el programa de mejora en la primer organizacin en Mxico que se evalu en CMM.
34
ENE-FEB 2005
Para lograr una reivindicacin adecuada del SQA, es necesario contestar las siguientes preguntas: qu es el aseguramiento de calidad?, quin es un SQA?, cules son las actividades que realiza?, y para qu las realiza? Contestando a las preguntas, iniciaremos diciendo que el aseguramiento de calidad es el conjunto de actividades desarrolladas dentro del proceso de produccin de software, necesarias para garantizar que una organizacin obtiene un determinado nivel de calidad en el producto o que cumple con los requisitos establecidos.
Haciendo Aliados
El secreto para que un SQA sea visualizado como un rol que aporta valor, es la creacin de sinergia entre los equipos de trabajo y l o ella. De esta manera se estarn logrando varios objetivos, como por ejemplo establecer un ambiente de confianza y cooperacin para realizar el trabajo de ambas partes, y as crear una visin compartida y objetivos comunes. El establecimiento de esta visin y objetivos comunes debe hacerse para cada nivel representado en la organizacin.
Una de las principales tareas del SQA es la de proporcionar gua y asesora a los miembros de los equipos sobre el uso y aplicacin de los procesos.
Un SQA es el rol en una organizacin que se encarga de revisar y auditar los productos y actividades para verificar que stos cumplen con los procesos aplicables al proyecto y los estndares establecidos. Proporciona a la gerencia la visibilidad del estado en que se encuentran los procesos y los productos de los diferentes proyectos. Las actividades del SQA no se limitan a realizar auditoras y revisiones; una de las principales tareas del SQA es la de proporcionar gua y asesora a los miembros de los equipos de trabajo sobre el uso y aplicacin de los procesos descritos en la organizacin, al nivel de sus proyectos. As pues, podemos decir que el SQA realiza principalmente las actividades de auditar/revisar los proyectos y asesorar sobre el uso o aplicabilidad de los procesos. Adicionalmente, brinda soporte para facilitar la adopcin de prcticas, monitorear la adecuada implantacin de las mismas, proporcionar entrenamiento especfico y facilitar la comunicacin intergrupal. Y para qu realiza todas estas actividades? Para evaluar la administracin y buen desarrollo del proyecto, previniendo posibles riesgos o incidentes que se pudieran presentar durante el ciclo de vida del proyecto.
De tal forma que la mejor manera encontrar aliados y mostrar el valor de los SQAs es buscando estrategias que puedan ayudar a los sectores seleccionados a reconocer el valor del SQA en sus tareas cotidianas y del da a da. Una estrategia para que los diferentes niveles de la organizacin vean al SQA como un aliado es establecer acciones que muestren cmo el papel del SQA, en su funcin de asesor, los ayuda a realizar su trabajo mediante la implantacin de prcticas y procesos, coadyuvando con ello a alinear el trabajo diario con los procesos definidos, sin que stos ltimos se perciban como una actividad extra. As se pueden empezar a identificar actividades sencillas y prcticas que ayudarn para mejorar las relaciones del grupo de SQA con los diferentes niveles de la organizacin, tales como: los ingenieros de software, los administradores de proyecto, la gerencia media y la gerencia alta. Este enfoque ayudar al SQA a crear un ambiente de sinergia que mejore su credibilidad, reivindique su funcin y coadyuve a mejorar la productividad de los equipos, la calidad de su trabajo y los productos generados.
PRCTICAS
ASEGURAMIENTO DE CALIDAD
Cuando la calidad es vital, son necesarias algunas revisiones independientes, no porque no confiemos en la gente, sino porque son humanos.
Watts S. Humphrey
Managing the Software Process. SEI Series in Software Engineering.
Estas son algunas sugerencias de lo que el SQA puede hacer para obtener el apoyo y la cooperacin de los diferentes grupos en la organizacin: Con el rea operativa: Asesorarlos en sus funciones con respecto a la calidad. Ser gua y mentor en prcticas de ingeniera de software y tcnicas de verificacin y validacin como revisiones entre colegas, pruebas, simulaciones, etc. Ayudar a los ingenieros de software a visualizar cmo sus actividades influyen en la calidad del producto final. Sensibilizarlos y mostrarles cmo los procesos les ayudan en la ejecucin de sus tareas diarias. Con la administracin del proyecto: Asesorarlos en aspectos relacionados con su proyecto. Recompensarlos por sus esfuerzos, dndoles visibilidad correspondiente. Sealando las desviaciones de los procesos y/o productos, pero aplaudiendo los logros. Capacitndolos en los procesos y procedimientos para mejorar la calidad en sus proyectos.
Escuchndolos y escalando sus sugerencias de mejora a los procesos. Con la gerencia media: Mantenerlos informados sobre estado de los proyectos a su cargo. Asesorarlos en las funciones que corresponden a su nivel y realizar las revisiones que les correspondan de acuerdo a los procesos definidos por la organizacin. Proporcionarles visibilidad sobre los problemas comunes de aseguramiento de calidad en sus reas y/o de otras reas de la organizacin. Sugiriendo mejoras a prcticas administrativas y de ingeniera de software en sus proyectos. Con la alta gerencia: Vigilando el apego a procesos, procedimientos, estndares y polticas definidos en la organizacin. Escalando problemas que deban ser atendidos a este nivel Reportando los resultados de las diferentes reas. Brindando visibilidad sobre la calidad de los productos. Mantenindolos informados sobre la operacin del negocio y el apego a los procesos.
En la actualidad, se cuentan con datos de la industria que pueden ayudar a las organizaciones a estimar el esfuerzo que se invierte en las actividades de aseguramiento de calidad, como por ejemplo: El esfuerzo total invertido en actividades de aseguramiento de calidad por los proyectos representa entre 3 y 5% del esfuerzo total invertido en el mismo. El nmero de proyectos que un SQA puede atender vara entre 5 y 10 proyectos, dependiendo de la madurez del SQA, la complejidad de los proyectos, el tiempo (parcial o completo) dedicado a actividades de SQA y la madurez de los procesos revisados en los proyectos. Finalmente, podemos concluir que si la organizacin pone en marcha esta prctica de aseguramiento de calidad, aunada con otras prcticas sencillas como verificacin y validacin, esto puede significar autnticos ahorros para todos los proyectos, eliminando defectos, previniendo riesgos, visualizando problemas en sus etapas tempranas y ayudando a los proyectos a potenciar los beneficios de los procesos.
Elizabeth Almeraz es pionera en Mxico en la realizacin de actividades de Aseguramiento de Calidad del Software (SQA), participando en el primer grupo de SQA que ayud a lograr una evaluacin CMM en Mxico. Actualmente es consultor de Avantare y especialista en las reas de tcnicas de verificacin de productos de software y mejora de procesos para la industria de TI.
36
ENE-FEB 2005
PRCTICAS
ARQUITECTURA
na realidad que no se puede ocultar es el hecho de que el desarrollo y la codicacin de software gozan de complejidad. A pesar de su relativa sencillez, resulta difcil entender todo este grupo de tecnologas convergentes que llamamos J2EE (Java 2 Enterprise Edition). Esta plataforma, que tiene como objeto codicar sistemas de software de nivel empresarial, goza de gran complejidad. EJBs de sesin, de entidad y de mensajes, JSPs, Servlets, Web Services, JDBC, HTML, cdigo SQL, etc., es complicado gurar en la mente todo un sistema software basado en J2EE. En ocasiones, no resulta muy claro el lugar que ocupa cada uno de estos elementos, y resulta an ms difcil explicarlo a un grupo de desarrolladores que est por introducirse en esta plataforma.
Las Capas Conceptuales

En este artculo les recomendamos cmo organizar sistemas basados en J2EE, utilizando una estrategia de organizacin en cinco capas conceptuales. Esta organizacin es un medio abstracto cuyo objetivo es el designar un orden lgico a cada elemento, agruparlo dentro de una capa y lidiar con la complejidad dentro de cada una. A n de cuentas el objetivo es hacer ms claro el desarrollo en J2EE. Las capas en cuestin son: Presentacin, Aplicacin, Servicios, Dominio y Persistencia. Algunas de estas capas pueden no estar presentes en un sistema. Dependiendo de las caractersticas particulares de ste (el dominio del problema), de los marcos de trabajo que se empleen y de la estrategia con que es abordado el desarrollo, alguna de estas capas no sern codicadas. Teniendo esto ltimo en mente, veremos cada una de ellas.
Presentacin.- Compuesta por todos los elementos relacionados con la interfaz de usuario, tales como botones, ventanas, campos de textos, etiquetas, etc., si hablamos de clientes Win32, AWT, SWT o Swing; HTML, JSP, JavaScript, aplicaciones Macromedia Flash si se tiene a un navegador Web por cliente; Xlets o Midlets, y sus correspondientes controles de interfaz de usuario si se trata de una aplicacin inalmbrica basada en J2ME (Java 2 Micro Edition). sta es la capa de interfaz de usuario, el rostro visible y, en cierta forma, esttico del sistema. Sin lugar a dudas, la parte ms importante para el usuario nal del sistema. Aplicacin.- Responsable del control del ujo de trabajo del lado del cliente y de componentes de IU reutilizables. stos se caracterizan por presentar un acoplamiento con la capa inmediata siguiente (servicios). Para el caso del control del ujo de trabajo, se puede emplear HTTPSession o el marco de trabajo Apache Struts. En el caso de componentes, por ejemplo, se puede tener un control heredado de un Combo Box que despliega los nombres de clientes que estn almacenados en la base de datos, y estos son obtenidos a travs de un mtodo de un EJB (capa de servicios) que es ejecutado en el constructor de dicho componente. Dependiendo del sistema que estemos construyendo, puede ser que no necesitemos administrar el ujo de control ni se empleen componentes, por tanto, esta capa no estara presente en tal situacin. Servicios.- Si la capa de presentacin es la ms importante para el usuario nal, la de servicios lo es para los desarrolladores. Sin lugar a dudas, la ms importante e indispensable de un software, el API (Application
J2EE
Por Rams Rodrguez
CAPAS CONCEPTUALES PARA SISTEMAS

A n de cuentas, el objetivo es hacer ms claro el desarrollo.
Rams Rodrguez es desarrollador de J2EE desde el 2002. Su especialidad es el empleo de software libre aplicado a Java y el diseo de arquitecturas orientadas a objetos. Actualmente se desempea como Arquitecto de Sistemas en la Universidad Loyola del Pacco.
38
ENE-FEB 2005
Programming Interface) del sistema. Es el punto de entrada a la lgica de negocios, la cual se encuentra encapsulada a travs de un conjunto de componentes de servicio. En el caso de J2EE, los componentes de esta capa tpicamente se implementan como EJBs de Sesin sin estado (stateless). La razn de que no tengan estado es que no guarden informacin de clientes particulares, y estn completamente desacoplados de stos, adems de que una instancia puede atender mltiples peticiones brindando un mayor desempeo. Estos Beans acostumbran servir como fachadas que proveen servicios utilizando informacin de las entidades de la capa de dominio. Esta capa requiere un gran esfuerzo para las pruebas unitarias, ya que es imperativo asegurarse de que estos componentes respondan adecuadamente a las diferentes condiciones posibles de ejecucin. De tenerlos, es aqu donde residiran los servicios web (web services) del sistema. Dominio.- Si se desean los benecios de un diseo orientado a objetos (el ser reutilizable y de fcil mantenimiento), esta capa debe estar presente dentro del sistema que se desee desarrollar. En ella est contenido nuestro modelo conceptual, mejor conocido como modelo de dominio de all el nombre de la capa. Este modelo consiste en todas aquellas entidades (facturas, productos, ordenes de compra, etc.) y actores (clientes, bancos, empleados, etc.) que componen y/o interactan en los procesos del negocio, y son creadas a raz de la abstraccin de sus atributos signicativos para el sistema. Este modelo tpicamente es ilustrado con diagramas de estructura, como el diagrama de clases de UML. Una caracterstica de estas entidades es su capacidad para asociarse con
otras entidades o, incluso con s mismas. Es posible que un sistema no cuente con capa de dominio; en estos casos la capa de servicios estara codicada de tal manera que dentro de los mismos mtodos de sus objetos se accederan directamente los datos en donde estos se almacenen, por ejemplo usando JDBC en el caso de una base de datos relacional. Esta opcin tiene la desventaja de que es de difcil mantenimiento y poco reutilizable, pero puede ser factible para sistemas de vida corta o para aquellos que no tendrn cambios signicativos a travs del tiempo, incluso para prototipos. Persistencia.- Al hablar de persistencia hablamos de almacenamiento de informacin en un medio no voltil (bases de datos, archivos de texto plano, etc). Los elementos de esta capa tpicamente funcionan como objetos de acceso a datos o DAOs (Data Access Objects), proveyendo mtodos para leer y almacenar los datos de los objetos de negocio. Es por esto que la existencia de esta capa tpicamente est condicionada a la existencia de la capa de dominio. Si no hay un modelo de dominio presente, no hay razn para hacerlo persistente. Incluso con la presencia de un modelo de dominio, podra no ser necesario codicar esta capa cuando se empleen marcos de trabajo tales como persistencia manejada por el contenedor (Beans de tipo CMP), JDO (Java Data Objects) o Hibernate. Al codicar las entidades en la capa de dominio, estos marcos de trabajo se encargarn de la persistencia de cada una de ellas, liberando a los programadores de esta responsabilidad. La persistencia manejada por el Bean (EJB de Entidad de tipo BMP) es un caso clsico de implementacin de
esta capa, ya que existe un modelo de dominio que debe ser persistente, y para ello los programadores codican clases con sentencias SQL cuyo objeto es crear, modicar, eliminar y consultar registros en una tabla.
Orden de Desarrollo
Ya describimos las cinco capas recomendadas. Ahora hablemos sobre cmo nos pueden ayudar para definir el orden en que se debera desarrollar un sistema. Cmo es eso? Sucede que estas capas presentan una caracterstica adicional: cada una de ellas depende de la capa inmediata inferior. Ya sea en tiempo de compilacin o de ejecucin, los tipos en las capas superiores dependern de los tipos de las capas inferiores. Por ejemplo, volviendo al ejemplo del componente que muestra los nombres de clientes, para que la capa de aplicacin, en donde se encuentra codificado el componente, muestre esta informacin, necesita invocar un mtodo que se encuentra en la capa de servicios. Es esta dependencia la que marca el orden de desarrollo. De acuerdo con Floyd Marinescu, autor del libro EJB Design Patterns, lo primero que debe ser codificado es la capa de dominio, seguida por las de persistencia, servicios y por las de interfaz de usuario (aplicacin y presentacin). La de dominio es la primera debido a que aqu residen las entidades que deben estar listas y compiladas para poder ser utilizadas por la que capa de servicios, que es la que contiene la lgica de negocio; adicionalmente, estas entidades tpicamente son sencillas de implementar. Una vez lista la capa de dominio, sta desencadena ordenadamente el desarrollo de las otras capas. Es recomendable tener en operacin la capa de servicios lo ms pronto posible para lograr el desarrollo de la interfaz de usuario en paralelo con las dems capas. Una importante observacin, asumiendo que se est creando un sistema bajo un proceso de desarrollo iterativo e incremental: no es necesario desarrollar totalmente y con lujo de detalle cada capa. Slo deben ser denidas aquellas piezas de cdigo directamente relacionadas con el o los casos de uso que se estn llevando a cabo en la iteracin actual.
ENE-FEB 2005
39
PRCTICAS
ARQUITECTURA
Aunque pareciera ser que esta estrategia es la nica forma posible de abordar el desarrollo, existe otra que he concebido a travs de mi experiencia. En los proyectos de J2EE en los que he estado involucrado, es una constante dividir el desarrollo en dos partes: el cliente y el servidor. Con el objeto de que el desarrollo del cliente se lleve en paralelo con el desarrollo del lado del servidor, primero se debe codicar la capa de servicios. Una vez concluida esta capa, los dos equipos de desarrollo (cliente y servidor) pueden iniciar su trabajo de manera independiente uno del otro. Qu es lo que se gana? El equipo de desarrollo del cliente no debe esperar a que se termine la programacin del lado del servidor (las capas de servicio, dominio y persistencia) para iniciar su trabajo, como sucede con la otra estrategia. En este punto surge una pregunta obvia: cmo se puede terminar la capa de servicios sin haber terminado la de dominio y las otras inferiores? La respuesta es sencilla: la capa de servicios slo tiene los esqueletos vacos de cada uno de sus mtodos, los cuales retornan datos de prueba; la capa de servicios
realmente no est terminada. Por ejemplo, empleando el componente de nombres de clientes citado anteriormente, suponiendo que estos datos son obtenidos a travs del mtodo getNombresDeClientes(), que devuelve un java.util.Collection de objetos de tipo String, entonces la implementacin de este mtodo crear una instancia de una clase que implemente la interfaz Collection - como un ArrayList - y le agregar nombres de clientes arbitrarios. La razn de ser del componente es desplegar un conjunto de nombres que se localizan en la base de datos. Sin embargo, para efectos de tener una capa de servicios funcional lo ms rpido posible, se omite el acceso a la base de datos (capa de persistencia), y en su lugar enviamos datos de prueba. Para que esto funcione se necesita cierto lujo de detalle al disear cada uno de los mtodos de la capa de servicios. Siendo ms especcos, si durante el ujo de trabajo de diseo de la iteracin actual, se especicaron cada uno de los mtodos que deben tener nuestras fachadas, entonces sern estos mtodos los primeros a codicar. Se necesita saber el nombre denitivo del mtodo, los
valores de retorno, el tipo y nmero de parmetros que recibe, y las excepciones que arroja. Estos datos son los que conforman el esqueleto de los mtodos.
Conclusiones
Esta prctica nos permite, por un lado, lidiar con la complejidad de J2EE a travs de un enfoque de organizacin y, por el otro, nos ofrece dos estrategias para iniciar el desarrollo de un Sistema J2EE. Empero, esta no es la nica forma en que puede ser organizado un sistema J2EE, ni tampoco son todos los enfoques para empezar a desarrollarlo. Sin lugar a dudas, la forma ms efectiva es aquella que comprendamos mejor y con la que nos sintamos cmodos. Pero si no se tiene un enfoque ni estrategia, entonces esto es un buen punto de partida.
Referencias: Marinescu, Floyd. EJB Design Patterns. Wiley, 2002.
CTEDRA Y MS
COLUMNA
Certicacin de Calidad para PyME

Qu Tan Necesaria Es?
l desarrollo de software con calidad es una necesidad de las empresas productoras de software del pas. La competencia de la industria extranjera, como India y China, as como las exigencias de algunos clientes estadounidenses, hacen que la calidad se haya convertido en algo ms que una palabra de moda o una urgencia por obtener certicaciones prestigiosas. Para tener ventaja competitiva, un desarrollador de software debe cuidar no slo la calidad de su producto, sino la calidad en su proceso de desarrollo. Por calidad del producto entendemos software que sea vlido y vericado, que sea resistente a fallas, y que tenga el desempeo requerido segn especicaciones. Por calidad del proceso entendemos aquellas prcticas que hacen que el tiempo de los desarrolladores sea utilizado de manera ptima, que aquellos procesos repetitivos sean debidamente documentados, y que en general hacen que el ciclo de desarrollo de un proyecto sea tan suave y sin incidentes como sea posible. Es esta bsqueda de calidad lo que ha llevado a la creacin y adopcin de modelos y metodologas de calidad, como CMM o SPICE. De hecho, los modelos de calidad se han vuelto tan importantes que una empresa desarrolladora de software de gran tamao no puede concebirse si no tiene algn tipo de certicacin o avalo de parte de algn organismo internacional. La capacidad de estas empresas Softtek, por ejemplo para exportar software hacia Estados Unidos est a menudo supeditada a poseer algn tipo de certicacin de calidad internacional. No queda ninguna duda de que estas empresas deben incluir y mantener en sus programas de aseguramiento de calidad de software una certicacin internacional, tanto para optimizar el uso de sus recursos como para poder competir en el mercado de exportacin. Cul, entonces, debe ser la postura de una pequea o mediana empresa productora de software con respecto a las certicaciones? Y, de qu manera deberan apoyar las comunidades y grupos de software del pas a estas empresas para la obtencin de certicaciones? Como ya es sabido, las PyMEs tienen recursos limitados. En particular, resulta difcil asignar roles para las actividades de un modelo como CMM entre los pocos miembros del personal de unos pequea empresa, que seguramente ya juegan distintos roles en el proceso de desarrollo. Pero esta aparente paradoja no signica que estas empresas no deban aspirar a la adopcin de prcticas y procedimientos que mejoren su ciclo de desarrollo de software. En el caso extremo en el que la empresa desee entrar al mercado de
exportacin, es probable que no haya opcin y se tenga que aspirar a una certicacin formal, con el costo que eso representa. Pero existen otras opciones. Se puede aspirar a implantar un modelo de calidad con el objetivo de optimizar procesos y adoptar mejores prcticas, sin optar por pagar el costo de hacer ocial la certicacin. O se puede implantar un modelo de calidad regional, adaptado a la realidad de la PyME. En estos casos, lo que se busca es la mejora de los procesos de desarrollo de software y un mejor producto nal, con el n de optimizar costos y tener un producto conable que consolide a la empresa en el mercado. Algo que es importante mencionar es la postura que se est permeando en la comunidad de software sobre el mercado potencial de las PyMEs desarrolladoras de software. Si bien es cierto que se desea que el pas compita contra las potencias productoras de software, como la India, tambin es cierto que existe un gran mercado nacional que, paradjicamente, consume software producido por empresas extranjeras. La visin presentada en varios foros de la industria es precisamente esa: la PyME debe empezar por abarcar este amplio mercado nacional antes de preocuparse por el mercado de exportacin. Es la opinin de varios miembros de la industria que ste enfoque al mercado nacional creara un crculo virtuoso en la economa del pas. Esto nos lleva de nuevo al tema de las certicaciones. Segn esta visin, no es una prioridad la certicacin de metodologas de calidad de software para las PyMEs. Lo verdaderamente importante es la adopcin cabal de estas metodologas en los procesos de desarrollo. En todo caso, es de suma importancia la elaboracin de estndares locales y, por qu no? de certicaciones nacionales que avalen estndares de calidad acordes a las necesidades de los consumidores locales y las caractersticas nicas de las pequeas y medianas empresas. Es por esta razn que los esfuerzos por crear estas certicaciones locales deben ser apoyados tanto por los grupos de ingeniera de software, as como por las instituciones acadmicas y la industria en general, y que es de suma importancia la adaptacin y creacin de modelos de calidad de software para la pequea y mediana empresa. Estos modelos sern, entonces, una antesala para optar, en su momento, por una certicacin de nivel internacional, y un paso necesario en el camino hacia un pas que sea competitivo en la industria del software mundial. - Ral A. Trejo
El Dr. Ral A. Trejo es profesor investigador de Sistemas de Informacin en el Tec de Monterrey, Campus Estado de Mxico. Sus reas de especialidad incluyen Ingeniera de Software y Algoritmos Computacionales. El Dr. Trejo gusta de participar en proyectos que involucren el trabajo cercano con estudiantes, como el Proyecto Principia de Integracin Curricular del Tec, o el Concurso FIRST de Robtica de la NASA. El Dr. Trejo ha participado en conferencias como el Americas Conference on Information Systems y publicado artculos en la revista Articial Intelligence.
ENE-FEB 2005
41
FUNDAMENTOS
Ingeniera de Software
Desarrollar Es Mucho Ms Que Programar
Qu conocimientos se necesitan para desarrollar software? Esta pregunta atormenta a muchos, desde jvenes estudiantes hasta personal de recursos humanos. Hay quienes piensan que basta con saber programar en algn lenguaje. Sin embargo, todos aquellos con experiencia en este medio reconocen que para desarrollar software de calidad, ms que de programadores se requiere de ingenieros de software.
entonces, qu conocimientos debe tener un ingeniero de software? Precisamente esto es lo que busca responder el Software Engineering Body of Knowledge (SWEBOK), un proyecto auspiciado por la IEEE para lograr un consenso mundial de lo que es esta disciplina y el lugar que tiene junto a otras ingenieras. El SWEBOK dene diez Knowledge Areas (KAs) o reas de conocimiento.
Pruebas de Software
Las pruebas de software consisten en la vericacin dinmica del comportamiento real de un programa comparado con su comportamiento esperado en un conjunto nito de casos de prueba seleccionados de un dominio de ejecuciones tpicamente innito. Las pruebas se realizan para evaluar la calidad de un producto a travs de la deteccin de fallas en ste. Sin embargo, las pruebas de software han evolucionado para dejar de ser consideradas como algo que comienza slo hasta que la programacin termina, con el limitado propsito de detectar fallas. Es aceptado que las pruebas deben abarcar el proceso completo de desarrollo, que su planeacin comienza durante las primeras etapas del proceso de requerimientos, y que los planes y procedimientos de prueba se deben desarrollar y renar durante el ciclo completo de desarrollo. Las pruebas pueden ser de diferentes tipos, ya sea por su alcance (unitarias, integrales, de sistema) o su objetivo (funcionalidad, conabilidad, desempeo, regresin, aceptacin, beta, etc.). Para esto se utilizan diferentes tcnicas como tablas de decisin, anlisis de fronteras, mquinas de estados, y la experiencia misma. Por ltimo, para cuanticar la calidad de un producto de software es necesario entender mtricas como la densidad de defectos y la evaluacin de conabilidad.
se generan modelos que sirven como planos para la construccin. Tpicamente se divide en dos tipos: Diseo arquitectnico - Describe la estructura y organizacin de alto nivel de un sistema. Identica los componentes e interfaces entre stos. Diseo detallado - Describe individualmente cada componente con suciente detalle para ser construido. Esta rea concentra una gran cantidad de conocimiento. Para empezar, el diseo de software requiere entender a fondo principios como la abstraccin, acoplamiento, cohesin, descomposicin y encapsulacin, ya que son la base para disear sistemas robustos. Tambin es necesario saber resolver aspectos prcticos como la persistencia de datos, sistemas distribuidos, peticiones concurrentes, manejo de eventos, recuperacin a fallas, etc. Por ltimo, un diseador que no quiera reinventar la rueda cada vez que se le presente un problema, debe estar familiarizado con patrones, soluciones documentadas a problemas comunes.
REAS DE CONOCIMIENTO (KAs) DE LA INGENIERA DE SOFTWARE Requerimientos Diseo Construccin Pruebas Calidad Mantenimiento Administracin de la Conguracin Administracin (de Proyectos) Proceso Herramientas y Mtodos
Requerimientos de Software
Los requerimientos de software expresan las necesidades y restricciones que debe satisfacer un producto para contribuir a la solucin de un problema real. Esta rea de conocimiento considera la obtencin, anlisis, especicacin y validacin de los requerimientos, as como el rol que juegan dentro del proceso de desarrollo de software. Un especialista en requerimientos tiene conocimiento y experiencia en tcnicas para obtener, cuanticar, negociar, clasicar, priorizar, modelar, documentar y validar los requerimientos de software. Adems debe saber administrar adecuadamente los cambios a stos.
Construccin de Software
Esta rea de conocimiento se reere a la creacin de software til a travs de la programacin, depuracin (debugging), pruebas unitarias e integracin de componentes. La construccin lidia con la creacin y aplicacin de algoritmos para la resolucin de problemas, as como su implementacin utilizando algn lenguaje de programacin. Todo esto se debe hacer buscando minimizar la complejidad y cumpliendo estndares para que el cdigo generado sea entendible y extensible por otros, adems de que est optimizado para consumir la menor cantidad de recursos posible.
Calidad del Software

El rea de conocimiento de calidad se enfoca en la aplicacin de tcnicas estticas para evaluar y mejorar la calidad del software. Esto diere del acercamiento utilizado en pruebas, donde las tcnicas utilizadas son dinmicas, ya que requieren la ejecucin del software. El rea de conocimiento de calidad involucra los subprocesos de aseguramiento de calidad, vericacin, validacin, revisin y auditoria. Adems considera
Diseo de Software
El diseo juega un rol clave en el desarrollo de software ya que es donde
42
ENE-FEB 2005
Los mtodos de ingeniera de software establecen una estructura para sistematizar las actividades con el objetivo de aumentar las posibilidades de xito.
tpicos como la clasicacin de defectos, control estadstico de calidad, modelos de prediccin y anlisis de tendencias.
Mantenimiento de Software
El mantenimiento se reere a las modicaciones a un producto de software previamente liberado para prevenir fallas (preventivo), corregirlas (correctivo), mejorar su desempeo (perfectivo) o adaptarlo a cambios en el ambiente (adaptativo). Histricamente no se le ha dado tanta atencin al mantenimiento como al desarrollo de software. Sin embargo, esto est cambiando debido a que las empresas buscan sacar el mayor jugo posible a sus productos existentes. Algunos temas clave en el mantenimiento son la reingeniera, anlisis de impacto, pruebas de regresin, y outsourcing del mantenimiento. Adems hay que tener en cuenta que el proceso a seguir en el mantenimiento es diferente al que se sigue para el desarrollo, por lo que involucra actividades y artefactos diferentes.
tos, estimacin de esfuerzo, asignacin de recursos, administracin de riesgo, manejo de proveedores, manejo de mtricas, evaluacin, y cierre de proyectos.
Proceso de Ingeniera de Software

Cada rea de conocimiento considera un proceso para las actividades tcnicas y administrativas que deben realizarse para adquirir, desarrollar, mantener y retirar software; ste es considerado como un primer nivel de procesos. Adicionalmente existe un segundo nivel, o meta-nivel, que se enfoca en la denicin, implantacin, evaluacin, mejora y administracin del cambio de los procesos de primer nivel. A ste es al que se reere el rea de conocimiento de proceso de ingeniera de software.
Herramientas y Mtodos de Ingeniera de Software

Las herramientas permiten la automatizacin de tareas repetitivas y bien denidas, habilitando al ingeniero de software para que se concentre en los aspectos creativos del proceso. Existen una gran cantidad de herramientas para asistir todas las reas de conocimiento, desde la administracin de requerimientos hasta las pruebas automatizadas. Los mtodos de ingeniera de software establecen una estructura para sistematizar las actividades con el objetivo de aumentar las posibilidades de xito. Esta rea de conocimiento se enfoca en los mtodos que abarcan mltiples KAs, ya que los que son relativos a una sola rea de conocimiento se incluyen en el rea correspondiente. Los mtodos pueden aplicar tcnicas heursticas (informales), formales, y basadas en prototipos.
Administracin de la Conguracin del Software (SCM)

La conguracin de un sistema se reere al conjunto de elementos de hardware y software que lo forman. SCM es la disciplina de identicar la conguracin en distintos puntos del tiempo con el propsito de controlar los cambios a sta, manteniendo su integridad y rastreabilidad durante el ciclo completo de vida del software. SCM va ms all del simple control de versiones, y requiere saber identicar los elementos de conguracin, denir un proceso de control de cambios, auditar y reportar el estatus de la conguracin, y administrar la integracin y liberacin del sistema completo.
Administracin de la Ingeniera del Software

Esta rea de conocimiento es lo que tpicamente llamamos Administracin de Proyectos o Project Management. Consiste en la aplicacin de actividades administrativas como la planeacin, coordinacin, medicin, monitoreo, control y reporte para asegurar que el desarrollo y mantenimiento de software se lleva a cabo de manera sistemtica, disciplinada y cuanticable. Entre los tpicos ms importantes de esta rea de conocimiento estn la planeacin de proyecwww.softwareguru.com.mx
Estas son las diferentes reas del conocimiento de la ingeniera de software. Si quieres conocer ms sobre estos temas, no te pierdas futuras ediciones de esta revista, ya que nuestros artculos ahondarn en cada uno de ellos. Ms informacin: Guide to the SWEBOK www.swebok.org
TECNOLOGA
SERVIDORES
HACER MS CON MENOS
Por Ariel Garca
BLADES
Son las seis de la tarde y llega nuestro lder de pruebas a comunicarnos que uno de los servidores que estn usando present una falla y necesitan reinstalar el sistema operativo. Adems, se requiere de un equipo extra para poder liberar la nueva versin del programa en cuestin, pues es necesario un equipo ms robusto.
l tiempo de respuesta por parte del administrador o lder de proyecto tiene un impacto directo en la entrega de soluciones. Esta situacin es muy comn en cualquier empresa, y como en todas, es necesario estar listos para tratar de solucionar estos problemas en tiempo y forma. Un sistema de servidores blades correctamente configurado y administrado, nos permite atacar de forma rpida y sencilla este tipo de problemas, y en base a estos beneficios, nos facilita justificar la inversin en nueva tecnologa. La mayor parte de las organizaciones de TI se encuentran en la problemtica de hacer ms con menos, pero, en qu consiste un sistema de servidores blade? Cmo saber si es una solucin que se adeca a las necesidades de cada empresa? Qu opciones existen en Mxico?
de red, unidad de disco floppy, CD-Rom, etc. Dependiendo de la configuracin de nuestro sistema de blades, podemos brindar acceso mediante una sola conexin de distintas tecnologas red local, red SAN a todos los servidores blades del chasis. Los beneficios de esta tecnologa son evidentes para cualquier persona encargada del mantenimiento y administracin de los equipos. El trabajo de cableado de red y/o fibra y el consumo de energa disminuyen. La densidad del espacio fsico usado se maximiza. Otro componente importante de un sistema de blades es la herramienta de administracin de los mismos. A travs de ella podemos llegar a configuraciones que realicen la instalacin y configuracin de los servidores de forma automtica, que nicamente requieran la insercin de los servidores en el chasis. Con el software de administracin podemos realizar copias o imgenes de los servidores de produccin, esto nos brinda flexibilidad y proteccin en las configuraciones de nuestros servidores, sobre todo en situaciones de liberacin de nuevas versiones o aplicacin de parches crticos a sistema operativo o aplicaciones. Esto incrementa la seguridad y disponibilidad de nuestros servicios. Dependiendo del fabricante, se pueden construir configuraciones avanzadas de sistemas de servidores blade. Estos pueden proporcionarnos soluciones de
alta disponibilidad y/o de procesamiento simtrico a gran escala que nos permiten migrar de sistemas propietarios RISC/SMP a tecnologa nueva de alta escalabilidad y bajo costo. Estos beneficios reducen de forma dramtica la administracin y los costos de pertenencia del equipo. La funcionalidad de esta tecnologa nos permite adaptarnos a las necesidades del negocio, incrementando la disponibilidad y los tiempos de respuesta en caso de fallas o nuevas necesidades de equipo cmputo.
Blades a la Medida
Existen escenarios muy claros en los cuales debemos evaluar la adquisicin de un sistema de servidores blades: Se renovar la planta de servidores actuales del centro de cmputo. Se tiene un proyecto nuevo que demanda la compra de equipo y requiere escalabilidad a futuro. Se tiene un problema de espacio fsico del centro de cmputo. Esto demanda la consolidacin de servidores, sin comprometer la disponibilidad de los servicios. Se construir un nuevo centro de cmputo que requerir de escalabilidad y alta disponibilidad en su infraestructura. En lo personal, considero que si tenemos planeada la adquisicin de cinco o ms servidores durante el ao en curso, debemos considerar esta tecnologa.
Sistema de Servidores Blade

Un sistema ideal de servidores blades se compone de servidores blades, almacenamiento compartido, red compartida y un sistema de administracin centralizada. Los equipos blades son servidores ultra compactos que contienen procesador, memoria y almacenamiento propio. Cada uno de estos servidores se inserta en un chasis, como libros en una estantera. A travs del chasis los servidores comparten ventiladores, energa elctrica, conexiones de fibra canal, conexiones
44
ENE-FEB 2005
TECNOLOGA
sto y ms en:
HP Pavilion
zd8000 Notebook PC
Esta lnea de computadoras porttiles de HP es la inversin ideal para trabajo en oficina y entretenimiento en casa. Viene preinstalada con Windows XP Professional y el Service Pack 2, para mayor proteccin en contra de ataques va red, los molestos pop-ups y virus recibidos por e-mail. Las opciones de personalizacin varan, pero se puede elegir un procesador Pentium 4 a 3.2GHz con Hyperthreading, escalar hasta 1GB de RAM, disco duro de 100GB y elegir una unidad DVD-RW/R + CD-RW con soporte para discos de doble capa, y una tarjeta de video ATI Radeon X600 con 265MB de memoria. Adems, tiene puertos ethernet, USB 2.O, Firewire, S-video y mdem de 56K. Por si fuera poco, las bocinas integradas son Harman-Kardon, y junto con la pantalla Brightwide de 17 pulgadas, son ideales para disfrutar de la versin 2005 del Windows Media Center, que da la posibilidad de sintonizar dos canales de televisin simultneos, adems de estaciones de radio de FM. Por si fuera poco, incluye software para edicin de video y traslacin a DVD, adems de un lector de tarjetas de memoria 6 en 1. Con una HP Pavilion zd8000, tanto diversin como productividad estn garantizadas.
Apple
Xserve G5
El servidor Xserve G5 de Apple monta dos procesadores PowerPC G5 a 2.0GHz, que entregan ms de 30 gigaflops de poder de procesamiento por sistema, 60% ms que el Xserve G4. El procesador G5 de 64-bit, ofrece un desempeo sin paralelo para aplicaciones basadas en UNIX. El Xserve G5 incluye un nuevo controlador de sistema con hasta 8GB de memoria PC3200 EEC, tres modulos seriales para unidades ATA que brindan hasta 750Gb de almacenamiento, hardware RAID interno opcional, dos puertos PCI-X y dos puertos Ethernet Gigabit para alto desempeo en trabajo en redes. El Xserve G5 es ideal para soluciones de impresin profesional, gestin de grupos de trabajo, stream de video, aplicaciones de bases de datos, aplicaciones grficas de alto desempeo y montaje de sitios web, as como gestin de servidores de correo electrnico. El sistema Mac OS X Server viene preinstalado, e integra software de cdigo abierto y sus estndares con herramientas fciles de usar, para ofrecer a sus usuarios lo mejor de dos mundos.
Iomega
Mini USB Drives

Los medios de almacenamiento porttil de Iomega no slo han elevado su capacidad hasta 1GB, sino que adems han crecido en funcionalidad. Ahora, estos verstiles cartuchos de memoria flash soportan conectores USB 2.0, que incrementan la velocidad de escritura hasta 7.0MBps, pero lo ms interesante de esta nueva generacin es la incorporacin de una tecnologa denominada Active Disk, que permite transferir aplicaciones al dispositivo para que corran desde el mismo, eliminando problemas en caso de que alguna computadora no tenga instalada determinada aplicacin. Esta caracterstica slo funciona en aplicaciones para PC, y respeta todos los copyrights de los desarrolladores, pues las aplicaciones no se pueden copiar desde el medio hacia otra mquina. La lnea tambin incluye los Micro USB drives, con capacidades desde 64MB y precios que van de los $64 hasta los $149 dlares.
ENE-FEB 2005
45
BIBLIOTECA
01
The Business of Software: What Every Manager, Programmer, and Entrepreneur Must Know to Thrive and Survive in Good Times and Bad
01
Michael A. Cusumano Free Press, Marzo 2004 Si el negocio del software fuera como los dems, ste libro no sera necesario. Con estas palabras comienza el libro The Business of Software ..., que fue uno de los ms sonados del 2004 en el rea de negocio/TI. A travs de esta obra, Michael Cusumano nos explica que hay varios aspectos de la industria de software que la hacen nica, y por lo tanto requieren estrategias y modelos de negocio nicos. El libro reexiona sobre diversos temas como diferentes modelos de negocio, mtricas nancieras, segmentacin de mercado, mejores prcticas y outsourcing. Cusumano tambin dene ocho factores que se deben tomar en cuenta para evaluar una empresa de software. Sin embargo, el tema central de The Business of Software ... es el de los modelos de negocio, donde el autor plantea tres opciones para esta industria: ser una empresa de productos, de servicios o un hbrido. Cusumano describe las caractersticas de cada uno, sus fortalezas, debilidades y cul puede ser el ms apropiado dependiendo de la etapa en que se encuentra una empresa, as como de la situacin econmica. Tambin se incluyen diversos casos de estudio con valiosas lecciones que aprender. En general, consideramos que esta es una excelente lectura para cualquier persona involucrada en la industria, principalmente los ejecutivos. Muy probablemente despus de leerlo lleguen a la conclusin de que, a diferencia de lo que muchos piensan, en esta industria es ms importante el modelo y estrategia de negocio que la tecnologa.
02
02 Development Ecosystems
Jim Highsmith Addison-Wesley, Marzo 2002 Y dado que hemos hablado bastante sobre procesos de desarrollo, creemos adecuado incluir un libro relacionado con este tema. Atendiendo al gran inters que hay en Amrica Latina y el mundo sobre el movimiento gil y sus diferentes mtodos, les recomendamos el libro Agile Software Development Ecosystems de Jim Highsmith. Ms que una receta para implementacin, este libro es un viaje a travs de la losofa y actitud de los principales impulsores de las metodologas giles. El autor hace uso de su experiencia y la de colegas como Kent Beck, Martin Fowler y Alistair Cockburn para
Agile Software
hablar sobre la agilidad en un sentido econmico y de negocios. Highsmith hace uso de la teora del caos para ilustrar la necesidad de balancear el orden y el desorden en un mundo de cambio constante, explicando porqu es mejor reemplazar el control por la libertad con disciplina. Todo esto se analiza bajo un nfasis recurrente en la gente y la manera en que piensan y se comportan. El mensaje central es que es la gente y no los procesos quin te salvar, pero necesitas darle la oportunidad. En el libro se explican principios como la necesidad de entregar valor al cliente, promover la colaboracin, conar en la gente, ser adaptable y hacer las cosas de la manera ms sencilla posible. Posteriormente se denen uno por uno los principales mtodos giles como Extreme Programming (XP),
SCRUM, Adaptive Software Development (ASD), Feature Driven Development (FDD), Lean Development y otros. Se incluye poca informacin detallada sobre los procesos, ya que es un libro de principios ms que de prcticas. El objetivo no es que despus de leer esta obra el lector ya pueda hacerse gil, sino que tenga la suciente informacin para decidir si hacerse gil es lo adecuado para su proyecto u organizacin. La implantacin se maneja en otros textos. Una queja que puede haber respecto a este libro es que resulta bastante repetitivo en cuanto a las ideas que maneja. Esto es comprensible, ya que es un esfuerzo para sumergir al lector en todo lo que es el movimiento gil. Adems, la narrativa tiene un ritmo adecuado para mantener la uidez y evitar hacerlo aburrido.
46
ENE-FEB 2005
INDEX
DIRECTORIO
TENEMOS UN ESPACIO RESERVADO PARA TI

Si deseas anunciarte contctanos en el (55) 5239 5502 o en ventas@softwareguru.com.mx
Anunciante Abits Software AMCIS ARTech Avantare Deintec EXPOCOMM IBM Imexsoft Intersoftware Itera Mayen PM MGE Microsoft Software Guru Sisoft Ssistemas
Pginas 47 17 40 31 29 F3 F4 35 33 07 43 09 F2-1 11 37 15
Sitio www.abits.com www.amcis.org.mx www.genexus.com/mx www.avantare.com www.deintec.com www.expocomm.com.mx www.ibm.com/mx www.imexsoft.com.mx www.intersoftware.com.mx www.itera.com.mx www.mayen-project.com.mx www.mgeups.com www.microsoft.com/mexico www.softwareguru.com.mx www.sisoft.com.mx www.ssistemas.com
ENE-FEB 2005
47
CARRERA
Desarrollador Cinco Estrellas

Busca Tu Estrella
i quieres formarte como desarrollador en la plataforma .NET, un excelente punto de partida es el programa de capacitacin Desarrollador Cinco Estrellas (DCE) ofrecido por Microsoft. Bajo esta iniciativa, Microsoft pretende brindar entrenamiento y capacitacin en los principales productos y servicios de esta plataforma. El programa DCE est diseado para permitir a los suscriptores incrementar sus conocimientos y habilidades de forma progresiva, en una serie escalonada de etapas. Las principales ventajas del programa son que es gratuito y que la mayora del material est disponible en espaol y portugus.
Este programa tiene ms de un ao de haber sido lanzado, y las estadsticas generadas hasta el momento de sta publicacin son las siguientes:
Pas
Argentina Per Mxico Espaa Colombia Ecuador Venezuela Chile Otros Uruguay Costa Rica Bolivia Repblica Dominicana Total por estrella
Total de 1a 2a 3a 4a 5a registrados Estrella Estrella Estrella Estrella Estrella 28.454 12.552 15.422 7.590 9.311 4.191 6.904 5.528 10.627 1.518 1.836 2.097 1.260 2.800 2.307 2.181 1.450 1.297 1.057 1.029 682 548 313 230 225 214 881 432 399 411 330 261 161 168 116 71 50 46 39 225 124 129 163 139 98 78 56 37 31 26 19 17 49 74 45 45 74 57 46 10 14 6 21 8 9 17 50 19 19 20 7 22 5 4 5 5
DCE est dirigido a: Desarrolladores profesionales que adopten .NET sin importar su experiencia previa y quieran actualizar sus conocimientos a este nuevo software. Estudiantes universitarios que deseen incorporar en su currculum los conocimientos necesarios para desarrollar aplicaciones con la nueva generacin de tecnologas .NET. Durante la participacin en este programa, los suscriptores realizan una serie de evaluaciones que les permiten ir avanzando de nivel, obteniendo las estrellas correspondientes hasta obtener la quinta, que los calica como desarrollador experto en .NET. El programa ofrece diversos benecios. Con slo registrarse se tiene acceso gratuito a las guas de estudio y software para entrenamiento. Los desarrolladores con al menos una estrella son listados en el directorio de desarrolladores de MSDN, el cual sirve como referencia curricular y para que las empresas que buscan personal puedan contactarlos. Posteriormente, conforme se van obteniendo estrellas, se van ganando ventajas adicionales, adems del conocimiento, claro est.
107.290
14.333
3.365
1.142
458
173
Para inscribirte o conocer ms sobre este programa, visita: www.microsoft.com/latam/msdn/comunidad/dce/
HUMOR
48
ENE-FEB 2005
Ao 01 No. 01
SOFTWARE GURU CONOCIMIENTO EN PRCTICA
Enero-Febrero 2005

Software Guru

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Software Guru

Загружено:

Авторское право:

Доступные форматы

Estimacin de proyectos Aseguramiento de calidad Capas en J2EE

SOFTWARE GURU CONOCIMIENTO EN PRCTICA

Aplicando PSP y TSP

Adems: Noticias Eventos Fundamentos Biblioteca Tecnologa Carrera

contenido ene-feb 2005

Procesos de Software: Gua para el Viajero

14 HERRAMIENTAS Gestin de Portafolio de Proyectos TIPS El Sndrome ERwin 16

ASEGURAMIENTO DE CALIDAD SQA? Slvese quien pueda!

ARQUITECTURA Capas Conceptuales para Sistemas J2EE

Taller software.net.mx Microsoft y ProSoft

XITO DE LA PRIMERA CONFERENCIA DEL SOFTWARE ENGINEERING PROCESS GROUP

Introduction to CMMI por Giusseppe Magnani

Expo Comm Mxico 2005

Seminario Llegando Rpidamente al CMMI 2 y 3 a travs de RUP

Sun Tech Days

CUMBRE INTERNACIONAL DE LA INDUSTRIA DEL SOFTWARE

SEPG 2005 - Deliver Winning Products Through Process Improvement

SD West 2005 Develop an Advantage

TEJIENDO NUESTRA RED

PyME o SME (Small & Middle Enterprise)

Vericacin y Validacin de Procesos

Repositorio de Procesos de Software

Desarrollo distribuido (outsourcing)

Repetir xitos de la organizacin

Organizacin orientada a procesos

Depositar el conocimiento de la organizacin

Trabajar sin interrupciones

El futuro de los UPSs

Consolidacin de MGE en Mxico

LANZA SIMPLE QUEUE SERVICE

Por Isabell Chillopa

Gestin de Portafolio de Proyectos

Caractersticas y Beneficios de PPM

Cmo Iniciar PPM

Herramientas de Apoyo a PPM

Por Artemio Mendoza

Las herramientas de modelado de datos son de gran utilidad

Director de Tecnologa de Informacin en GNP

Por qu contar con un proceso de software?

Elementos Tpicos del Proceso de Software

Revisemos estos modelos para entender mejor su objetivo y estructura.

CMMI (Capability Maturity Model Integration) - Modelo de Madurez de Capacidades Integrado

Niveles de Madurez Nivel

reas clave del proceso

Algunos Beneficios de CMMI vs. CMM

Grfica 1 - Estructura de Documentos 15504

Grfica 2 - Modelo de Capacidades 15504-2

CMMI Modelo Escalonado

Compatibilidad entre Modelos

PSP Personal Software ProcessSM

TSP - Team Software ProcessSM

Compatibilidad de PSP y TSP con CMMI

Qu hay para la Industria Mexicana?

Quarksoft Comparte Su Experiencia

Nmina 1 Admon. 43 Rep. 57 Nuevos 18

ENTENDIENDO LAS BASES

Grca 1. Conforme aumenta el tamao del proyecto disminuye la precisin de la estimacin

Grca 2. La desviacin de la estimacin disminuye conforme avanza el proyecto.

Modelo de estimacin de esfuerzo

Requerimientos Diseo Construccin Pruebas Liberacin Total

La frmula para estimar la duracin es del tipo:

Donde C es una constante y F es un valor derivado de los factores de escala.

SLVESE QUIEN PUEDA!

Por Mariana Prez-Vargas y Elizabeth Almeraz