1QU ES SAP?

SAP es un sistema de racionalizacin de operaciones para empresas. Es una

herramienta estndar, pero a la vez parametrizable, y una solucin modular, que aporta
un alto nivel de flexibilidad y posibilita su personalizacin y adecuacin a las
necesidades de cada empresa.1
Qus es SAP R/3?
El Sistema SAP R/3 consta, en la vista modular, de reas empresariales homogneas,
que soportan las operaciones empresariales y trabajan integradas en tiempo real. Las
siglas SAP (System, Applications and Products) identifican a una compaa de sistemas
informticos con sede en Alemania, que se introdujo en el mercado de los sistemas de
informacin con un producto denominado SAP R/2, antecesor al SAP R/3.
La integracin en SAP se logra a travs de la puesta en comn de la informacin de
cada uno de los mdulos y por la alimentacin de una base de datos comn. El sistema
SAP est compuesto de una serie de mdulos funcionales que responden de forma
completa a los procesos operativos de las compaas. 2

Utilizacin del sistema SAP R/3 [sitio en Internet], disponible en

http://www.tirant.com/libreria/detalle?articulo=8484681831 ltimo acceso: Noviembre 19 de 2007.

2

Mdulos De Sap R3 [sitio en Internet], disponible en

http://www.mundosap.com/foro/showthread.php?t=281 ltimo acceso: Noviembre 19 de 2007.

15

Ilustracin 1 Algunos mdulos de SAP

Desde un punto de vista funcional y de su arquitectura tcnica, SAP R/3 puede

definirse como un software abierto, basado en la tecnologa cliente/servidor, diseado
para manejar las necesidades de informacin de una empresa. SAP R/3 es el
software de estas caractersticas de mayor divulgacin en todo el mundo, contando con
ms de 18.000 instalaciones en ms de 100 pases. Es la versin mejorada de un
producto anterior (sistema R/2) que ha permitido a SAP AG convertirse en la empresa
lder de software empresarial, que es en lo que consiste bsicamente SAP R/3.
El sistema ECC es un sistema "On-line" y en tiempo real diseado para cubrir de forma
global las necesidades de gestin o informacin de corporaciones de tipo medio/grande.
Consta de un conjunto de mdulos totalmente integrados que cubren una amplia
variedad de funciones de negocio entre las que se incluyen: Gestin Econmico
Financiera (Contabilidad General, Contabilidad Analtica, Activos Fijos, Mdulo
Financiero, etc.), Logstica, Comercial y Distribucin, Produccin (Planificacin, Control,
Sistemas de Produccin en serie, lotes, JIT, etc.), Control de Calidad, Mantenimiento,
Gestin integrada de Proyectos, Recursos Humanos, Workflow, etc.
En definitiva, puede afirmarse que cubre todas las reas funcionales de la empresa.
Adems, se estn desarrollando y en su caso mejorando, las llamadas Soluciones
Industriales, lo que significa una mayor adecuacin del sistema SAP a las
particularidades de cada negocio sectorial: Petrleo, Automocin, Publishing,
Laboratorios Farmacuticos, Retail, Alimentacin, Sector Pblico, Telecomunicaciones,
etc.

1.1.1 Caractersticas del sistema R/3:

SAP R/3 ha tenido tanto xito debido a que combina unas caractersticas nicas que
son ideales a la hora de trabajar en gestin empresarial.
16

SAP es muy flexible. Permite agilizar las tareas diarias de cualquier empresa
independientemente del sector y del pas en que trabaje, de su tamao (si bien es cierto
que parece estar dirigido ms bien a grandes empresas) y de otros factores que pueden
suponer un problema con otro software.
Otro aspecto importante es que es altamente integrado: supera las limitaciones
jerrquicas y funcionales tpicas de la empresa. Todo est integrado en un mismo
software que coordina las distintas estructuras, procesos y eventos de todos los
departamentos y reas funcionales, permitiendo a cada empleado disponer de toda la
informacin necesaria en todo momento. As, no solo actualiza la informacin en tiempo
real (importantsima caracterstica de SAP que constituye una enorme ventaja), sino
que adems basta con introducir los datos una sola vez, puesto que es el sistema se
encarga de pasar y actualizar los datos en el resto de los mdulos o programas.
As la interconexin entre centrales, oficinas, centros de produccin, etc. queda
asegurada. Antes de los sistemas SAP, todas las operaciones podan hacerse, en cada
departamento, oficina, fbrica.... con sus programas especficos para cada una
(software para la gestin de materiales, software para controlar salarios, ventas,
compras, etc. y cada uno de ellos trabajando con sus propios protocolos, con su propia
informacin, adaptados para hardware distinto, sin conectar ni compartir informacin)
con lo que se trabajaba el doble: los datos que se repiten en diversas reas se manejan
varias veces (por ejemplo, en el almacn y en la administracin) y, al no estar
interconectados, (aunque exista una red interna, los diversos programas podran
trabajar con formatos, datos, mquinas incompatibles) es necesario que alguien se
dedique a pasar la informacin de unos a otros, perdiendo un tiempo que se podra
dedicar a mejorar la estrategia.
Imagine por ejemplo una fbrica de sillas metlicas, con su almacn de piezas,
maquinaria, oficinas, muelle de carga para los camiones, oficinas, salas de reuniones
etc. La empresa tendr personal de almacn, conductores, operarios de maquinaria,
encargados, jefe de personal, administrativos, comerciales, jefe de ventas, jefe de
administracin, gerente, y puede ser una pequea empresa (tendr mucho menos
personal e instalaciones) o una gran empresa (ms camiones, ms personal etc.), o no
ser un fbrica, sino un empresa de servicios, (en lugar de operarios podra tener
dependientes), para el caso es lo mismo. En la fbrica se genera y se necesita
informacin constantemente: entrada de mercancas y materias primas, necesidades de
barras metlicas y tornillos, presupuestos que piden los clientes, albaranes de venta,
notas de consumo de combustible, vencimientos de pedidos, pagars que nos entregan
los clientes, letras que firmamos a proveedores, facturas de acreedores, balances que
hay que presentar en el Registro Mercantil, etc. etc. SAP R/3 evita que se repita
innecesariamente la informacin (los datos que introduzca uno no hace falta que los
introduzca otro, aunque sea de otra seccin) y asegura que si en nuestra fbrica de
Berln se fabrica una silla, en ese mismo momento, nuestra sucursal en Albacete sabe
que tiene una silla ms que podra vender.
SAP es tambin abierto. Fue diseado como un producto integrado, pero existe la
posibilidad de instalar slo parte del software (los mdulos pueden utilizarse
individualmente) para luego ir ampliando paso a paso segn sus necesidades. Permite
17

adems la comunicacin con terceros (clientes o proveedores de su empresa que no

sean SAP AG y sus partners).
SAP est directamente conectado a Internet y preparado para el comercio electrnico.
As la World Wide Web (www) puede servir como una interfase de usuario alternativa
para las aplicaciones de empresa SAP R/3 , abriendo nuevas vas de negocio para los
clientes.
La universalidad de SAP ECC no consiste slo en la adaptabilidad a monedas,
lenguajes o leyes, sino que es capaz de satisfacer las necesidades tanto de empresas
pequeas y medianas (ms del 50% de las instalaciones, por ejemplo, HUMO COLPISA
S.A.) como de grandes multinacionales (Mercedes Benz o Microsoft) y empresas de
cualquier sector (aerospacial y defensa, automocin, banca y seguros, bienes de
consumo, gestin sanitaria, ingeniera y construccin, petrleo y gas...).
SAP ECC tiene adems otras ventajas. Ofrece algo ms que soluciones informticas.
Las aplicaciones tambin enlazan sus procesos empresariales con los de sus clientes y
proveedores, permitiendo integrar a los bancos y otras empresas colaboradoras dentro
de las comunicaciones internas (a nivel nacional e internacional).
Ofrece tambin la posibilidad de escoger entre ms de 100 escenarios y 1000 procesos
empresariales ya confeccionados en numerosos sectores industriales, permitiendo
beneficiarse de los modelos empresariales de las empresas lderes. SAP ha
desarrollado una amplia librera de procesos de negocio predefinidos que abarcan cada
requerimiento de software funcional. Nuevos procesos de negocio y tecnologas se
ponen a disposicin de los clientes regularmente, facilitndoles soluciones
empresariales al ltimo nivel tecnolgico, lo que les permite satisfacer la siempre
cambiante demanda del mercado.
Dispone asimismo de sistemas EIS y de alerta temprana como son EarlyWatch y
GoingLive Cheks que ayudan a detectar y corregir (incluye procesos de toma de
decisiones) los problemas (como valores umbrales crticos) antes de que afecten a las
operaciones.
SAP es infinitamente ampliable: es posible disear software especfico en varios
lenguajes de programacin.
Necesita breves periodos de implantacin. El tiempo que dure sta, la empresa no
podr rendir al 100%, pero actualmente el 90% de las instalaciones se hacen en menos
de un ao, permitiendo un rpido retorno de la inversin. La duracin no debe
parecernos excesiva si tenemos en cuenta que supone la adaptacin de maquinaria,
procesos, personal e incluso el diseo especfico de funcionalidades no cubiertas con el
software estndar.
Tiene un sistema de arquitectura abierta que facilita a las compaas el elegir los
equipos informticos y los sistemas operativos de tal manera que se pueda aprovechar
al mximo los avances en la tecnologa. Emplea estndares internacionales
reconocidos, lo que le permite a la empresa hacer distintas combinaciones (segn sus
18

preferencias) entre proveedores de hardware, bases de datos, sistemas operativos y

lenguajes de programacin.
La compatibilidad con HTML y JAVA permite disear programas especficos en estos
lenguajes, hacindose ms visual. As JAVA permite programacin de objetos para
trabajar con ventanas, ratn, botones, etc.., y, por tanto, ms fcil de manejar (ms
cmodo para el personal); mientras que el HTML est orientado a Internet (es el
lenguaje de las pginas web).
La combinacin de estructuras organizativas y funciones informticas "on-line" (ya sea a
travs de Internet o de intranets -redes internas-) conduce, si se desea, a un proceso de
datos descentralizado bajo una arquitectura cliente/servidor de tres niveles distintos:

Servidor de base de Datos:

El ordenador central (Host, miniordenadores, etc.) gestiona todas las funciones
de la base de datos tales como actualizacin, consulta y otros.
Servidor de aplicaciones:
Est conectado al servidor de Base de Datos, y para cada departamento de la
empresa, carga y ejecuta los programas y aplicaciones (ordenadores
departamentales).
Servidor de presentacin:
Estaciones de trabajo y ordenadores personales se conectan al nivel anterior de
aplicacin y presentan y hacen accesible la informacin y los procesos al usuario.
La flexibilidad de la arquitectura cliente/servidor le permite a las organizaciones obtener
un ptimo uso de los recursos informticos, pudiendo disfrutar de las ventajas que las
nuevas y ms avanzadas tecnologas de hardware van ofreciendo, as como la
posibilidad de adaptar los procedimientos de negocio a los nuevos requerimientos que
el mercado establece.3

SAP R/3 [sitio en Internet], disponible en

http://usuarios.lycos.es/cblsap/sisr3.html ltimo acceso: Noviembre 19 de 2007.

19

Qu es SAP NETWEAVER?
Como reemplazo de SAP R/3 y poder responder a las exigencias del mercado actual SAP AG ha
creado Sap Netweaver, la cual es una plataforma en la que se pueden alinear la infraestructura
de tecnologa con los requerimientos del negocio. SAP tiene una combinacin de tecnologas y
aplicaciones que reduce la complejidad e incrementa la flexibilidad del negocio. Con SAP
NetWeaver, se pueden crear aplicaciones usando servicios empresariales, orquestndolo con
procesos del negocio y eventos, administrando informacin empresarial que entregue
aplicaciones y contenido a los usuarios de una forma ms rpida y efectiva en costos.
Sap Netweaver es basado en web, posee una integracin abierta y es una plataforma que
provee una base de arquitectura orientada al servicio (SOA ServiceOriented Architecture) y
permite la integracin y alineamiento de las personas, informacin y los procesos de negocio.
Sap Netwaver estndares abiertos que permiten la integracin con la informacin y
aplicaciones.
SAP NetWeaver
Integracin de personas
Multi channel access
Portal

...

Collaboration

Integracin de informacin
Bus Intelligence

Knowledge Mgmt

Master Data Mgmt

Integracin de procesos
Integration
Broker

Business
Process Mgmt

Plataforma de aplicacin
J2EE

ABAP

Abstraccin DB y SO

Ilustracin 2 Arquitectura SapNetwaver

20

1.2.1 Arquitectura de SapNetweaver

Multi channel Access (Sap Mobile infrastructure):
Con una mquina virtual especial en los dispositivos mviles, permite desplegar e integrarse con
aplicaciones SAP.
Portals y collaboration:
Son un conjunto de herramientas web, que brindan un punto de acceso comn, maneja
perfiles y paquetes de aplicaciones.
Business Intelligent:
Componente de SAP relacionado con la minera de datos.
Knowledge Management:
Posibilita a los usuarios para ordenar la informacin externa e interna usando funciones
inteligentes de bsqueda.
Los usuarios pueden buscar , clasificar o manejar el contenido.
El Knowledge Management, est compuesto de:
Gestin de contenido: Soporta el ciclo completo de la vida de los documentos,
desde su creacin, hasta el archivamiento de un documento.
Bsqueda y clasificacin: Bsqueda a nivel de textos completos a travs de
toda clase de documentos y su clasificacin automtica.
Master Data Management:
Cuando se guarda la informacin en diferentes localizaciones y sistemas al mismo
tiempo usando la base tecnolgica de SAP Exchange infraestructure se puede obtener
la informacin de forma adecuada y garantizar la no duplicidad de estos.
Integracin de procesos(Integration Broker y Business Process Mgmt):
Bsicamente est cubierto por el SAP XI, el cual se encarga de la conexin de
sistemas no SAP que estn en diferentes plataformas y versiones con sistemas SAP.
XI est basado en una arquitectura abierta, usa principalmente estndares y ofrece
servicios que son esenciales en un sistema complejo y heterogneo.

21

Plataforma de aplicacin:
El web application server actualmente viene en 2 versiones, con soporte para ABAP o
Java, est el interpretador de la base de datos el cual nos permite tener un solo
lenguaje SQL sin importar su motor ni plataforma en la que est.

Qu es una personalizacin?
La plataforma SAP ofrece un nmero de programas altamente parametrizables, pero
por exigencias del negocio, se requiere un comportamiento de estos programas que no
cubre el estndar, existen reportes que varan de organizacin en organizacin
interfaces muy particulares que varan de empresa en empresa o programas que no
existen en la plataforma. SAP ofrece las herramientas suficientes para suplir todas
estas necesidades a la cuales se les llaman personalizaciones.

22

2 JUSTIFICACIN DEL PROYECTO

Hay muchos, aspectos por los cuales un proyecto no sale como se desea, ya sea por
excederse en el tiempo inicialmente proyectado, errores de diseo, errores de
codificacin, cambios del negocio en el transcurso del proyecto, una inadecuada
gestin de proyectos y en general son muchos los factores a controlar que hacen un
gran reto sacar adelante un proyecto de ndole tecnolgico.
Segn la envergadura del proyecto a enfrentar es directamente su complejidad y por
ende el nmero de entregables a manejar en cada fase del ciclo de vida del proyecto,
para poder tener un adecuado control sobre l. Muchas veces los entregables que se
definen en un proyecto surgen por la misma necesidad natural del proyecto, pero
debemos tener cuidado en no caer en los extremos de tener un exceso de
documentacin para todo o en tener una documentacin escasa.
Por experiencia propia, en muchos proyectos de implantacin del sistema SAP ECC,
con respecto a las personalizaciones se incurre en varios detalles que se deben mejorar
como son:
Inadecuada estimacin: La complejidad y duracin de una personalizacin, se llevan a
cabo por la experiencia y no se acompaa esto de alguna mtrica ms precisa como lo
puede ser los puntos de funcin. Cuando se lleva una mala estimacin de los
desarrollos a realizar en su totalidad, queda muy difcil hacer un cronograma de
actividades ajustado a un contexto ms real y a la vez se hace ms difcil estimar el
nmero adecuado de desarrolladores a utilizar en el proyecto.
Inadecuado manejo de riesgos: Todo proyecto a emprender tiene unos riesgos,
inherentes, si no se tiene un manejo adecuado de stos. Con sus debidos planes de
contingencia y mitigacin el proyecto se puede complicar.
Mtricas inadecuadas: Las mtricas son el indicador de cmo va el proyecto y si no
son llevadas de forma adecuada, no se pueden tomar las medidas correctivas a tiempo
o saber cmo est el proyecto realmente.
Falta de estndares: Es vital para el mantenimiento de las personalizaciones a futuro
que tengan un estndar en su codificacin, si no es as y cada desarrollador tiene su
propio estndar de programacin, las personas que a futuro le hagan mantenimiento a
estos programas se les dificultara mucho en tiempo el entendimiento de cada
desarrollo.
Falta de buenas prcticas de programacin: Muchos programas son ineficientes y
hacen lo que se menciona en su especificacin pero no de la manera ms adecuada, lo
cual hace que se desperdicie tiempo y recursos de cmputo.
Desconocimiento de la arquitectura: Teniendo en cuenta se deben crear programas
que hagan un uso adecuado del acceso a la base de datos, recursos del sistema,
23

consumo de red y tiempos de respuesta. Usualmente los desarrollos solo tienen en

cuenta la especificacin funcional, pero no la arquitectura de la plataforma.
Mala documentacin: Al tener una mala documentacin en las especificaciones de las
personalizaciones se pierde mucho tiempo en entender lo que el funcional y usuario
lder desean, as mismo se dificultara enviar estas especificaciones a terceros que
estn por fuera del proyecto dado el caso que se necesitaran. Por parte de la
documentacin tcnica, si esta no es llevada de forma adecuada a futuro se complicara
en forma muy notable el mantenimiento de las aplicaciones por parte de una persona
que no haya elaborado el programa y la gestin de cambios se dificultara en forma
extrema al no tener una trazabilidad del programa y poder medir el impacto real que
tiene un cambio sobre la aplicacin, adems que un cambio en un programa muchas
veces puede alterar un conjunto de programas y en estas ocasiones el impacto es
mayor sobre el proyecto.
Gestin inadecuada de transportes: En los proyectos, una forma de garantizar que
las versiones adecuadas de los programas van a pasar del ambiente de pruebas a
productivo, es transportar las ordenes en un orden especfico y las que son.
En algunos proyectos por decisiones gerenciales, se deben usar pocas ordenes de
transporte (se deben rehusar) lo cual inhabilita el manejo de versiones de las
aplicaciones.
En los grupos de funciones y en casos que deben intervenir varios desarrolladores se
deben poner de acuerdo las rdenes de transporte a usar para luego no daar el trabajo
de los dems.
Las rdenes de transporte deben estar debidamente documentadas, para poder medir
los impactos a la hora de hacer actualizaciones del sistema.

Si no se tienen en cuenta como mnimo estos aspectos en el manejo de las

personalizaciones, se tendrn muchos problemas en el proceso de desarrollo y un
cliente no muy contento con la situacin. Todo proyecto tiene atrasos y problemas, pero
estos deben ser debidamente manejados y llevados de la mejor manera y no que ellos
nos lleven y manejen.

24

3 MARCO TERICO
3.1 Metodologa de desarrollo de software
Las metodologas de desarrollo de software son un conjunto de procedimientos,
tcnicas y ayudas a la documentacin para el desarrollo de productos de este tipo.
Es como un libro de recetas de cocina, en el que se van indicando paso a paso todas
las actividades a realizar para lograr el producto informtico deseado, indicando
adems qu personas deben participar en el desarrollo de las actividades y qu papel
deben de tener. Adems detallan la informacin que se debe producir como resultado
de
una
actividad
y
la
informacin
necesaria
para
comenzarla.
Actualmente es imprescindible considerar los riesgos, aunque habitualmente las
empresas, no han sido concienciadas de los riesgos inherentes al procesamiento de la
informacin mediante ordenadores, a lo que han contribuido, a veces, los propios
responsables de informtica, que no han sabido explicar con la suficiente claridad las
consecuencias de una poltica de seguridad insuficiente o incluso inexistente. Por otro
lado, debido a una cierta deformacin profesional en la aplicacin de los criterios de
coste/beneficio, el directivo desconocedor de la informtica no acostumbra a autorizar
inversiones que no lleven implcito un beneficio demostrable, tangible y mensurable.
Las tcnicas indican cmo debe ser realizada una actividad tcnica determinada
identificada en la metodologa. Combina el empleo de unos modelos o representaciones
grficas junto con el empleo de unos procedimientos detallados. Se debe tener en
consideracin que una tcnica determinada puede ser utilizada en una o ms
actividades de la metodologa de desarrollo de software. Adems se debe tener mucho
cuidado cuando se quiere cambiar una tcnica por otra.4
En la industria se estn aplicando actualmente tres metodologas en los proyectos
informticos, dos de las metodologas pertenecen al mundo de las metodologas giles
son el SCRUM y el XP; por contraparte est una metodologa mas tradicional y probada
exitosamente en la industria y es el RUP.
La propuesta por parte de SAP AG en las implantaciones es una metodologa llamada
ASAP, la cual es muy propia de las implantaciones, esta se mostrar brevemente y se
explicar lo que hay que tener en cuenta para poderla llevar de una manera exitosa con
respecto a las personalizaciones.

Metodologa de desarrollo de software

[sitio en Internet], disponible en

http://www.um.es/docencia/barzana/IAGP/Iagp2.html ltimo acceso: Noviembre 19 de 2007.

25

3.1.1 Qu es el desarrollo gil de software?

En los aos 90, varias metodologas han llamado la atencin del pblico. Cada una de
ellas tiene una diferente combinacin de viejas ideas y nuevas ideas.
Todas estas metodologas se han enfatizado en una muy buena colaboracin entre el
equipo de programacin y los expertos del negocio; una comunicacin cara a cara
(mucho ms eficiente que la comunicacin escrita); haciendo frecuentemente entregas
de valor para el negocio, teniendo equipos que se auto organizan y un cdigo que se
puede adecuar a los cambios en los requerimientos sin traumatismos.5
En febrero de 2001, tras una reunin celebrada en Utah-EEUU, nace el trmino gil
aplicado al desarrollo de software. En esta reunin participan un grupo de 17 expertos
de la industria del software, incluyendo algunos de los creadores o impulsores de
metodologas de software. Su objetivo fue esbozar los valores y principios que deberan
permitir a los equipos desarrollar software rpidamente y respondiendo a los cambios
que puedan surgir a lo largo del proyecto.
Se pretenda ofrecer una alternativa a los procesos de desarrollo de software
tradicionales, caracterizados por ser rgidos y dirigidos por la documentacin que se
genera en cada una de las actividades desarrolladas.
Tras esta reunin se cre The Agile Alliance, una organizacin, sin nimo de lucro,
dedicada a promover los conceptos relacionados con el desarrollo gil de software y
ayudar a las organizaciones para que adopten dichos conceptos. El punto de partida es
fue el Manifiesto gil, un documento que resume la filosofa gil.

Segn el Manifiesto se valora:

Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las
herramientas. La gente es el principal factor de xito de un proyecto software. Es ms
importante construir un buen equipo que construir el entorno. Muchas veces se comete
el error de construir primero el entorno y esperar que el equipo se adapte
automticamente. Es mejor crear el equipo y que ste configure su propio entorno de
desarrollo en base a sus necesidades.
Desarrollar software que funciona ms que conseguir una buena documentacin. La
regla a seguir es .no producir documentos a menos que sean necesarios de forma
inmediata para tomar un decisin importante. Estos documentos deben ser cortos y
centrarse en lo fundamental.

What Is Agile Software Development? [sitio en Internet], disponible en

http://www.agilealliance.org/show/2 ltimo acceso: Noviembre 19 de 2007.

26

La colaboracin con el cliente ms que la negociacin de un contrato. Se propone que

exista una interaccin constante entre el cliente y el equipo de desarrollo. Esta
colaboracin entre ambos ser la que marque la marcha del proyecto y asegure su
xito.
Responder a los cambios ms que seguir estrictamente un plan. La habilidad de
responder a los cambios que puedan surgir a los largo del proyecto (cambios en los
requisitos, en la tecnologa, en el equipo, etc.) determina tambin el xito o fracaso del
mismo. Por lo tanto, la planificacin no debe ser estricta sino flexible y abierta.
Los valores anteriores inspiran los doce principios del manifiesto. Son caractersticas
que diferencian un proceso gil de uno tradicional. Los dos primeros principios son
generales y resumen gran parte del espritu gil. El resto tienen que ver con el proceso
a seguir y con el equipo de desarrollo, en cuanto metas a seguir y organizacin del
mismo. Los principios son:6

Nuestra mayor prioridad es satisfacer al cliente a travs de la entrega temprana

y continua de software con valor.
Aceptamos requisitos cambiantes, incluso en etapas avanzadas. Los procesos
giles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
Entregamos software frecuentemente, con una periodicidad desde un par de
semanas a un par de meses, con preferencia por los periodos ms cortos
posibles.
Los responsables de negocio y los desarrolladores deben trabajar juntos
diariamente a lo largo del proyecto.
Construimos proyectos con profesionales motivados. Dndoles el entorno y
soporte que necesitan, y confiando en ellos para que realicen el trabajo.
El mtodo ms eficiente y efectivo de comunicar la informacin a un equipo de
desarrollo y entre los miembros del mismo es la conversacin cara a cara.
Software que funciona es la principal medida de progreso.
Los procesos giles promueven el desarrollo sostenible. Patrocinadores,
desarrolladores y usuarios deben ser capaces de mantener un ritmo constante
de forma indefinida.
La atencin continua a la excelencia tcnica y los buenos diseos mejoran la
agilidad.
Simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial.
Las mejores arquitecturas, requisitos y diseos surgen de equipos que se autoorganizan.

Metodologas giles en el Desarrollo de Software [sitio en Internet], disponible en

www.willydev.net/descargas/prev/TodoAgil.Pdf ltimo acceso: Noviembre 19 de 2007.

27

A intervalos regulares el equipo reflexiona sobre cmo ser ms efectivo,

entonces mejora y ajusta su comportamiento de acuerdo a sus conclusiones.7

Algunas metodologas giles son:

Programacin Extrema (XP).

Scrum.
Crystal.
Evolutionary Project Management (Evo).
Feature Driven Development (FDD).
Adaptive Software Developmen(ASD).
Lean Development (LD) y Lean Software Development (LSD).

A continuacin se dar una breve introduccin a las metodologas de SCRUM y XP.

Principles behind the Agile Manifesto [sitio en Internet], disponible en

http://www.agilemanifesto.org/principles.html ltimo acceso: Noviembre 19 de 2007.

28

3.1.1.1 SCRUM8
3.1.1.1.1 Historia del SCRUM
El trmino Scrum viene de un estudio de 1986 de los japoneses Takeuchi y Nonaka.
En dicho estudio se documentaban una serie de proyectos muy exitosos los cuales
tenan en comn el uso equipos chicos y multidisciplinarios.
El estudio comparaba a esos equipos hiper-productivos con la formacin Scrum de
Rugby.
Jeff Sutherland cre el proceso Scrum para desarrollo de software en 1993 usando este
estudio como base y adopt la analoga con los equipos de Rugby. Posteriormente, Ken
Schwaber formaliz el proceso y lo abri a toda la industria del software en 1995.9
3.1.1.1.2 Qu es SCRUM?
Scrum es un proceso gil y liviano que sirve para administrar y controlar el desarrollo de
software. El desarrollo se realiza en forma iterativa e incremental (una iteracin es un
ciclo corto de construccin repetitivo). Cada ciclo o iteracin termina con una pieza de
software ejecutable que incorpora nueva funcionalidad. Las iteraciones en general
tienen una duracin entre 2 y 4 semanas. Scrum se utiliza como marco para otras
prcticas de ingeniera de software como RUP o Extreme Programming.
3.1.1.1.3 Porque SCRUM?

Scrum se focaliza en priorizar el trabajo en funcin del valor que tenga para el negocio,
maximizando la utilidad de lo que se construye y el retorno de inversin.
Est diseado especialmente para adaptarse a los cambios en los requerimientos, por
ejemplo en un mercado de alta competitividad. Los requerimientos y las prioridades se
revisan y ajustan durante el proyecto en intervalos muy cortos y regulares. De esta
forma se puede adaptar en tiempo real el producto que se est construyendo a las
necesidades del cliente. Se busca entregar software que realmente resuelva las
necesidades, aumentando la satisfaccin del cliente.

Fuente principal: Schwaber Ken Beedle Mike. Agile Software development with Srcum USA; Prentice Hall Hill, 2002.

Qu es Scrum? [sitio en Internet], disponible en

http://www.baufest.com/spanish/scrum/scrumconference2006/Que_es_scrum.pdf ltimo acceso: Noviembre 20 de 2007.

29

3.1.1.1.4 Roles 10
SCRUM Team
Son las personas conformantes del equipo a realizar el proyecto como tal. Este equipo
no debe ser muy numeroso, aproximadamente de 5 a 9 personas para que pueda
funcionar adecuadamente.
El equipo tiene mucha autonoma en el cumplimiento de sus labores y entre los propios
miembros del equipo se hace la asignacin de las tareas a realizar, dando sto como
resultado la posibilidad de estar en diferentes papeles durante el transcurso del
proyecto (analista, diseador, codificador, tester, etc.), segn las capacidades y
destrezas de cada miembro del equipo y las exigencias de las tareas a realizar.
Dueo del producto
Es la persona que representa los intereses de la empresa en el desarrollo del producto,
est encargada de velar porque el equipo SCRUM posea y cumpla la perspectiva del
negocio en lo desarrollado.
El dueo del producto debe estar altamente capacitado en el proceso de negocio que
se va desarrollar.
SCRUM Master
Persona encargada de facilitar todos los medios posibles para que el SCRUM team
pueda realizar sus labores efectiva y correctamente
Tambin debe hacer el rol de de Project manager al procurar que se tomen todas las
medidas necesarias para el cumplimiento del proyecto y maximizar el retorno de la
inversin por parte de la organizacin duea del desarrollo.

10

Scrum in five minutes [sitio en Internet], disponible en

http://www.softhouse.se/Uploades/Scrum_eng_webb.pdf ltimo acceso: Noviembre 20 de 2007.

30

3.1.1.1.5 Artefactos
Product backlog:
Es una lista en donde van las funcionalidades que requiere el sistema, esta lista va en
orden de prioridades y est a cargo del dueo del producto su elaboracin
Durante el transcurso del proyecto la lista de funcionalidades y sus prioridades pueden
ser cambiadas por el dueo del producto.

Tabla 1 Product Backlog

Haciendo una comparacin con las competiciones de atletismo, en SCRUM un SPRINT

es una entrega completamente funcional ( Codificada, verificada y documentada ) que
se hace cada dos o cuatro semanas.
La cantidad de funcionalidades en cada SPRINT es una negociacin entre el dueo del
producto, el SCRUM master y el SCRUM team.
Sprint backlog
Una vez se ha concertado un acuerdo entre el dueo del producto, el SCRUM master y
el SCRUM Team, se hace una lista detallada de las tareas especficas a realizar para
poder desarrollar las funcionalidades de determinado SPRINT, en la lista de tareas se
31

especifica el miembro del equipo que la realiza, el estado en que esta, y por cada da
del SPRINT se pone las horas faltantes
Sprint 1 backlog
Horas pendientes
Descripcin

Tarea 1
Tarea 2
Tarea 3
Tarea n

Originador

Carlos M

Responsable

Estatus

10

11

12

Sergio M
Ricardo P
Ricardo L
Pepito Mendez

Completado
Pendiente
En Progreso
Completado

30

15

20

20

20

20

20

20

20

20

20

20

20

20

15

50

40

30

20

10

Tabla 2 Sprint backlog

Burdown Chart
Grfica en forma descendente que muestra los resultados que se van presentando en el
proyecto.
La grfica como tal no es una sola y se pueden hacer varias segn las necesidades en
el proyecto.
Pueden representar varias cosas, entre ellas:
1. El trabajo pendiente de todo un Sprint Vs los das que quedan de un Sprint.
2. Horas pendientes de actividades Vs das pendientes de un Sprint ( por miembro
del equipo o el equipo)
3. El trabajo pendiente de todo del proyecto Vs cantidad de Sprints planeados para
todo el proyecto
Estos Burdown Charts son de gran utilidad para poder hacer el seguimiento al proyecto
a muchos niveles, desde el estado general del proyecto, hasta comparativas del
rendimiento real Vs El rendimiento esperado de un miembro del equipo

32

Ilustracin 3 Burn down chart

3.1.1.1.6 Metodologa de trabajo

Sprint Planning Meeting

Pre-requisitos:
El dueo del producto debe tener el product backlog ya elaborado.

Participantes:
El dueo del producto (son las personas que velan por los intereses de la empresa en el
proyecto), el Scrum Master , Scrum Team y personas requeridas con determinados
conocimientos en el negocio o en la tecnologa a emplear.

Dinmica:
El Sprint planning est constituida en 2 sesiones aproximadamente de 4 horas cada
una, la primera sesin es para seleccionar varias funcionalidades del Product Backlog y
la segunda es para preparar el Sprint Backlog.
En esta reunin deben participar el Scrum Master, el dueo del producto y el Scrum
team. Adicionalmente puede invitarse a gente que provea ms informacin acerca del
negocio o tecnologas necesarias, pero una vez que las personas adicionales hayan
hecho su aporte ya no es necesaria su participacin en la reunin.
El equipo sugiere los tems del product backlog que considera que puede dejar
completamente desarrollados, los cuales se mostrarn en el Sprint review, despus de
una concertacin con los miembros del equipo y el dueo del producto, la
33

responsabilidad de la eleccin de que tems irn exactamente en ese Sprint es del

dueo del producto.
En la segunda sesin el equipo se centra en todas las actividades necesarias para
llevar a cabo lo que se pacto con el dueo del producto para ese Sprint de esta reunin
sale el documento Sprint Backlog. Para esta segunda parte debe estar el dueo del
producto para resolver todas las inquietudes que posea el equipo.
Daily Scrum Meeting:
Es una reunin diaria donde se obtiene en general un balance de los avances de cada
miembro del equipo.
Participantes:
El Scrum master, el scrum team y personas que deseen ir aunque no deben ser
muchas.
Dinmica:
El scrum master y el scrum team se sientan en la mesa y las personas que vienen a ver
la reunin, se sientan atrs, esto con el fin de hacerlas caer en cuenta que van en
calidad de visitantes, ms no a participar en ella.
El Scrum Master le formula 3 preguntas a cada miembro del equipo.
Cmo ha avanzado desde la ltima reunin?
Qu vas hacer desde ahora hasta la prxima reunin?
Qu problemas ha tenido para trabajar exitosamente?
Estas tres preguntas sirven para que el Scrum Master pueda saber exactamente como
van las tareas a cumplir en el Sprint y solucionar los problemas que se presenten, as
mismo da la oportunidad de que todo el equipo tenga una nocin general del como va el
Sprint.
Despus de la reunin, si es necesario el Scrum Master toma las medidas
correspondientes para poder solucionar los problemas de los miembros del equipo, o si
est al alcance de los miembros del equipo entre ellos mismos se colaboran para poder
solucionarlos.
Es vital la reunin diaria, ya que de esta forma cada integrante del equipo asume una
responsabilidad ante l mismo y su equipo, dando como resultado que cada persona
del equipo procure dar lo mejor de si.

34

Sprint Review Meeting

Pre-requisitos:
Los desarrollos que se trazaron como meta en el sprint backlog, deben estar
completamente funcionales (codificados, verificados y documentados) en ambiente de
calidad. Lo que no cumpla esta condicin no se puede mostrar a menos que sea para
explicar algo que ya este completo.
Participantes:
El Scrum master, el scrum team, el dueo del producto y personas que tienen que ver
con el proyecto.
Dinmica:
Algn miembro del equipo presenta los objetivos que se pretendan alcanzar en el
Sprint que acabo de pasar y los tems que se cubrieron en el product backlog. Varios
miembros del equipo exponen en que les fue bien y en que puntos no, y el porqu de
ello.
En la mayora de estas reuniones los miembros del equipo presentan las
funcionalidades hechas y responden las preguntas de las personas que tienen que ver
en el proyecto a medida que se van presentado las funcionalidades.
La reunin es un espacio para el dueo del producto y los interesados en el proyecto
expresen sus ideas e impresiones de cmo ven el proyecto, que esta bien y que debe
corregirse, identificacin de nuevas o correcciones en el product backlog as como la
reorganizacin en prioridades del product backlog.
Al final de esta reunin el Scrum master da la fecha del prximo Sprint review meeting.
Sprint Retrospective Meeting
Participantes:
El dueo del producto (opcional), Scrum master y el Scrum Team.
Dinmica:
Cada miembro del equipo responde estas 2 preguntas:
En qu le fue bien en el pasado Sprint?
En qu se puede mejorar para el prximo Sprint?
A medida que cada miembro del equipo va respondiendo estas preguntas, el scrum
Master va tomando notas de ellas.
35

El equipo debe observar las anotaciones hechas por el Scrum master sobre los
aspectos a mejorar y hallar entre todos las mejores formas de solucionarlos, adems de
dar cabida a cambios y mejoras potenciales al prximo Sprint backlog.
El Scrum master debe hacer todo lo posible en esta reunin de retroalimentacin para
que el equipo en cada Sprint valla mejorando en sus labores.
3.1.1.1.6 Valores en el SCRUM.
Responsabilidad.
Uno de los pilares del Scrum, es la confianza que se deposita en cada uno de los
participantes al realizar sus labores. Es por ello que se les da la mayor autonoma y
libertad en el cumplimiento de sus actividades y como requisito para lograr esto, cada
integrante debe tener un sentido absoluto de la responsabilidad.

Concentracin.
En un proyecto, salen muchas actividades por hacer, pero para poder hacer las cosas
de la mejor forma posible, los miembros del equipo se deben centrar en hacer slo una
actividad al tiempo y de esta manera dar lo mejor de si en cada actividad que se est
haciendo.
Respeto.
Al trabajar en un grupo de personas, la gente se debe procurar de tratar a las dems de
la mejor forma posible. En esta clase de proyectos es de saberse que las presiones y el
tiempo es algo que juega en contra.
Coraje.
En esta metodologa, se trabajan tecnologas de alta complejidad, cambiantes o
simplemente el proyecto es muy cambiante en sus funcionalidades. Las personas
tienen mucha autonoma para realizar sus labores, pero a la vez asume mucha
responsabilidad y presin para llevarlas a cabo. Este tipo de proyectos no es para toda
clase de personas.

36

3.1.1.2 XP11
3.1.1.2.1Definiendo XP
XP es una Metodologa gil para equipos de desarrollo pequeos o medianos que
encaran un cambio rpido de requerimientos.
XP consiste en 4 partes: Valores, principios, actividades y prcticas, en la figura se
muestran como se componen unas de otras a travs de actividades que son ejecutadas
a travs del ciclo de vida del proyecto.
Actividades
Practicas
Principios
AATXT
Valores

Ilustracin 4 XP es basado en unos valores, que son soportados mediante actividades, prcticas y principios.

3.1.1.2.2 Valores:
XP maneja un conjunto de valores que es la esencia de la metodologa.
Simplicidad:
Simplicidad en XP es definido como has las cosas lo ms simples posibles y que
funcionen. Nosotros resolvemos problemas presentes simplemente y confiamos en que
los problemas a futuro tambin los podamos resolver. En la mayora de las
metodologas tradicionales se crean expectativas en la planeacin, donde el cliente
hace un esfuerzo por estimar la totalidad del sistema. Hay un entendimiento implcito
que este modelo cambiar en el futuro. Se debe implementar nicamente lo que el
usuario necesita ahora, Para qu poner caractersticas que probablemente no vas a
11

Fuente principal: Baird Stewart. Teach Yourself Extreme Programming in 24 Hours USA; Sams Publishing,

2002

37

necesitar?, esto ocurre mucho en las metodologas tradicionales porque el valor de un

cambio sera muy costoso, pero manteniendo el costo de los cambios constante se
remueve la necesidad de este tipo de prcticas.
El anlisis de un sistema de forma simple, lo hace ms fcil de comunicar, tiene menos
puntos de integracin y un escalamiento mayor.
Comunicacin:
Todas las metodologas tiene un proceso de comunicacin, pero en XP tiene un valor
muy importante poner hincapi en la comunicacin oral, no en documentos, reportes y
planes.
Sin una constante comunicacin entre todos los miembros del equipo para colaborarse,
el proyecto fracasara.

Retroalimentacin:
El valor de la retroalimentacin es vital para el xito de cualquier proyecto. Con XP las
constantes preguntas acerca del estado del sistema son respondidas constantemente.
Como se tienen varios periodos de desarrollo cortos, se debe analizar cada x tiempo
cmo se estn haciendo las cosas para mejorar o tomar mtodos correctivos a tiempo,
asegurando as un producto de alta calidad.
Coraje:
Es la tenacidad de trabajar rpido y volver a desarrollar si es necesario. Coraje en XP
debe ser pensado en el contexto de los otros 2 valores anteriores, sin el coraje se ira al
caos el proyecto. El valor del coraje en XP est basado en ser fuerte, y tener pruebas
automatizadas y no ser imprudentes en lo desconocido. Las personas que desarrollan
en XP cambian lo que son, tentativas de cambio de parecer en codificacin incierta, con
algo ms veraz.

3.1.1.2.3 Principios:
Basados en los valores del XP, que guan el desarrollo de software.
Rpida retroalimentacin:
Significa que los desarrolladores usan los cortos loops de desarrollo para verificar que
estn haciendo las cosas de forma adecuada para satisfacer las necesidades del
cliente.
38

Asuma simplicidad
Asuma la mayor simplicidad posible en cada problema que vaya a resolver, significa
que nicamente se hacen soluciones para la presente iteracin. No hay una bola de
cristal para saber a futuro lo que de pronto se necesitar.

Cambios incrementales:
Solucione los problemas con una serie de pequeos cambios. Esto aplica a la
planeacin, desarrollo y al diseo. En vez de hacer una sola entrega de todo, se van
haciendo pequeas entregas segn la necesidad del negocio.
Acoja el cambio:
Adopte la estrategia de preservar opciones cuando este resolviendo problemas difciles.
Trabajo con calidad:
La calidad del trabajo nunca puede estar comprometida. XP eleva la importancia del
cdigo y su chequeo con el criterio de hacer primero los test y luego el programa.

3.1.1.2.4 Actividades:
Teniendo en cuenta los valores y principios, lo que se hace a diario son las siguientes
actividades:
Escuchar:
XP est basado en la comunicacin y tiene prcticas que requieren escuchar
activamente. Al tener una comunicacin menos escrita, hay una necesidad sobre la
calidad de la comunicacin verbal. Ms all de decir que los desarrolladores deben
escuchar a los clientes, XP tiene prcticas que propenden a una mejor comunicacin,
sin necesidad de tanta documentacin.
Las personas de los proyectos XP deben aprender y madurar su forma de
comunicacin.

39

Haciendo chequeos (testing):

No es algo que se debe hacer justamente antes de entregar algo al cliente. Es algo
integral en el proceso, por lo que se requiere que los desarrolladores los hagan antes
de escribir el cdigo, no nicamente limitados la bsqueda de errores, si no de
funcionalidad y desempeo. Trayendo como ventaja un cdigo de alta calidad y no
tener que esperar a capturar errores posteriormente cuando los costos usualmente son
mucho ms altos.
Codificando:
El cdigo se debe ir refinando a travs de prcticas como la refactorizacin,
programacin en pares y la revisin de cdigo, con un pequeo diseo, los
desarrolladores de XP deben escribir un cdigo lo suficientemente claro para que con
slo leer el cdigo otros miembros del equipo puedan entender la lgica, vale la pena
clarificar que no slo estamos hablando de simples comentarios en el cdigo, el cdigo
como tal es una forma de comunicacin.
Recuerde que el cdigo es lo ms cercano que tenemos al producto final, despus de
esto el cdigo es compilado.

Diseando:
Una de las ideas radicales de XP es que el diseo debe ir creciendo y evolucionando a
travs del proyecto.
El diseo no es esttico o asignado a slo rol y debe estar en la dinmica del equipo y
en constante diseo en vez de limitarse a slo las actividades de diseo, XP acepta la
natural evolucin del sistema.
3.1.1.2.5 Practicas:
Haciendo ms especificas las actividades, en XP se expresan las actividades en 12
prcticas esenciales.
Estas actividades son las que el equipo XP usan cada da para desarrollar los
proyectos.
Planeamiento del juego:
Se debe generar un plan de alto nivel para la prxima iteracin

40

Pequeas entregas:
Los ciclos en XP consisten en constantes entregas que tengan valor al negocio
Metforas:
Es la visin comn, le da el sentido ms sencillo de lo que debe hacer el cdigo en XP.
Consiste en poner las descripciones con palabras entendibles tanto por parte del equipo
tcnico como para el cliente.
Diseo simple:
El diseo debe ser simple, en XP significa que el cdigo debe ser lo ms sencillo
posible para que funcione correctamente.
Chequeo:
El corazn de XP es el chequeo automtico, los test son escritos antes que el cdigo
para su posterior utilizacin.
Refactorizacin:
Es

mejorar

el

diseo

del

cdigo

existente

sin

cambiar

su

funcionalidad.

Programacin en parejas:
Una pareja de programadores se sientan en la misma estacin de trabajo y comparten
tareas de desarrollo.
Dueos colectivos:
Como se es dueo colectivo del cdigo se est en la posibilidad de mejorar cualquier
parte del cdigo en cualquier momento.
Contina integracin:
Los componentes del sistema son hechos e integrados varias veces cada da
40 horas de trabajo a la semana:
Para mantener la calidad y el rendimiento no se necesita tener horas extras al equipo.
Con un trabajo sostenido y regular se puede sostener la calidad.

41

El usuario en el mismo sitio de desarrollo:

El cliente como tal es parte del equipo.
Estndares de cdigo:
Son convenciones de codificacin que todo el equipo debe acatar.

3.1.1.2.6 Ciclo de vida de XP

En XP una de las premisas fundamentales es que el cliente y el desarrollador van a
trabajar en conjunto para producir un software que tenga un valor real, el cliente
direcciona al equipo de desarrolladores en cmo quiere hacer las entregas del producto
para que aporten valor al negocio a travs del ciclo de vida del proyecto XP.
Los proyectos XP consisten en dividir la visin que tiene el usuario acerca del producto
y segmentarlo en varias entregas e iteraciones.
Exploracin

Entrega
Iteracin n

Iteracin 1
Construccin

Construccin

Construccin

Construccin

Construccin

Construccin

Produccin

Mantenimiento

Ilustracin 5 Ciclo de vida de una aplicacin en XP

Durante cada iteracin, hay mltiples construcciones, las cuales ocurren regularmente
durante el da cuando el equipo integra nuevo cdigo. El nmero de construcciones es
dependiente del tipo de tecnologa usada por el equipo de desarrollo.
Las entregas son hitos que se planifican con el cliente, mientras que las iteraciones son
de tipo interno del equipo de desarrollo, que son usadas para lograr la elaboracin de
una entrega.
42

3.1.1.2.6.1 Etapas del ciclo de vida

Explorando los requerimientos del usuario:
Es donde se debe descubrir la visin y misin del sistema. Esta visin y misin se
deben ser sencillas y aproximadamente entre 20 a 30 palabras de longitud en forma de
metfora. El cliente y los desarrolladores trabajarn en esta fase explorando opciones
tcnicas, definiendo requerimientos y completando una lista de historias de usuario.
Estimando y descubriendo
La fase de exploracin incluye descubrimiento. Los clientes descubren lo que ellos
quieren y los desarrolladores descubren acercamientos de soluciones y sus
estimaciones.
Muchas veces el equipo de desarrollo debe indagar sobre nuevas tecnologas para
brindar las mejores soluciones. En la bsqueda de estas alternativas se deben estimar
cuanto tiempo se van a tardar y hacer su seguimiento, luego de esto contrastar el
tiempo real que se han demorado en hacerlo, esto se hace con el fin de que el equipo
vaya mejorando sus habilidades en las estimaciones ya que es vital cuando equipo
empiece a realizar sus planeaciones para cada iteracin.
El tamao de la exploracin depende de la naturaleza del proyecto y las tecnologas a
usar. El tiempo necesario para buscar alternativas es breve si el equipo de desarrollo
est familiarizado con las herramientas y la tecnologa. La longitud total de esta fase
puede ir entre unas pocas semanas o meses, dependiendo del tamao y alcance de los
requerimientos.
Una vez ha finalizado esta etapa, se documenta en forma de listas de usuario en forma
de metforas.
Creando el plan del proyecto
Es una fase corta en la cual el usuario y desarrolladores se pondrn de acuerdo para la
primera entrega. Las historias de usuario son priorizadas y puestas de una forma tal
que sean coherentes para el negocio y sean viables tcnicamente.
Reponsabilidad del cliente:

Definir las historias de usuario.

Definir qu valor para el negocio tienen las historias de usuario.
43

Definir que historias van a estar incluidas en una entrega.

Resposabilidad del desarrollador:

Estimar cuanto se va a demorar una historia de usuario en hacerse.

Avisar al usuario sobre los riesgos tecnolgicos en los cuales se est incurriendo.
Medir el avance del equipo.

En la etapa de planeamiento deben estar involucrados el equipo de desarrollo y el

cliente para crear un perfecto balance de los recursos tecnolgicos a usar y dar un real
aporte de valor para el negocio. Los desarrolladores deben crear unas historias de
usuario con cero valor al negocio para la parte de la infraestructura que va a soportar
el sistema. Un ejemplo de esto podra ser el establecimiento de los ambientes de
prueba y desarrollo. Haciendo esto se asegura que todo el trabajo del equipo va ha ser
estimado y va a tener su respectivo seguimiento.
Esta etapa en XP se llama el planeamiento del juego la cual es la principal
herramienta usada para la planeacin. Esta etapa involucra al cliente y programadores
a travs de historias de usuario, estimaciones y priorizando.
Una vez se tienen el total de las actividades estas se dividen en varias iteraciones.

Dividiendo las entregas en iteraciones.

Una entrega es dividida en varias iteraciones de longitud de 1 a 4 semanas. La iteracin
inicial est centrada en la arquitectura base del sistema. Esta iteracin es llamada de
cero valor para el negocio ya que estas historias de usuario cubren aspectos tcnicos
y no traen un beneficio directo al negocio del usuario.
Las otras iteraciones deben aportar valor al negocio. El usuario selecciona las historias
que desea y los desarrolladores procedern a desarrollarlas. En estas iteraciones el
usuario puede cambiar de parecer en las historias de usuario, pero una vez se
comienza una iteracin, se realizara la construccin de lo pactado en esas historias de
usuario. Lo que garantiza un costo bajo del cambio son los cortos tiempos de cada
iteracin.
El proceso de iteracin
Al principio de cada iteracin se hace una reunin de planeacin en donde se hace una
divisin de tareas de programacin. El usuario selecciona las historias de usuario que
se van a implementar. Los programas que hayan fallado en las pruebas de aceptacin
de la anterior iteracin se incluirn en la presente iteracin.

44

Ilustracin 6 Iteraciones y entrega en XP

Al tener las historias de usuario a implementar, stas se van desagregando en tareas

especficas a realizar, estas tareas se escriben a anexo a las historias de usuario
respectivas e idealmente deben ser de 3 das de extensin. Si excede esta cantidad de
das se recomienda subdividirlo en tareas. Como ejercicio y mejora de las estimaciones
las parejas de programadores deben dar a priori cuanto se demorarn en realizar las
tareas que se les haya asignado.

Medicin del rendimiento

En XP se mide el rendimiento (cantidad de trabajo que el equipo completa en el
tiempo). Para empezar a refinar las estimaciones se empieza a preparar el equipo
desde la iteracin cero para que se vaya familiarizando con este tipo de estimaciones y
se puedan hacer clculos ms refinados a futuro.
A medida que el proyecto va transcurriendo los resultados de los pares de
programadores se va mostrando pblicamente tanto los estimados de las tareas
asignadas como su duracin real. Esto con el fin de saber cada instante el estado real
del proyecto y poder afinar las futuras estimaciones.
Desarrollo y pruebas
Primero se desarrolla las pruebas
pruebas.

de la nueva tarea y se aade al framework de

El par de programadores hace el desarrollo.

A medida que se va construyendo componentes, estos se van aadiendo al ambiente
integrado Este tipo de integraciones se procura hacer con frameworks construidos para
este propsito.
Al final de cada iteracin, los usuarios corren sus pruebas de aceptacin y las tareas
que no pasen estas pruebas sern arregladas para la prxima iteracin.
45

Poniendo el software en produccin

Al final de la entrega, el producto es verificado y aprobado para ponerlo en ambiente
productivo. En este punto el experto de usabilidad crea pruebas de aceptacin en esta
ltima construccin de sistema, se pone a prueba con usuarios reales que aseguren
que el flujo del programa garantice el cumplimiento de sus labores. Si ocurre algn
percance o detalle, se procede a corregirlos.
Muchas veces estos correctivos involucran el sistema en que se ejecutan los programas
o en mejoramiento de los aplicativos, esto usualmente se prueba en ambientes espejo
al productivo, con el fin de garantizar una evolucin segura y estable.
En teora se puede poner parte del sistema desarrollado desde la primera iteracin, esto
depende de lo que contribuya valor al negocio y factores externos como migracin de
datos o sistemas integradores tipo legacy.
Dependiendo del tipo de estrategia utilizada para desplegar el sistema, se deben asumir
estrategias para reducir el riesgo que implica realizarlo.
Las formas tpicas de desplegar un sistema son:
Bing bang:
Se apaga el sistema antiguo y se inicia con el sistema nuevo. Esto se hace cuando
tener un manejo de transicin gradual entre sistemas es muy complejo o costoso.
Desplegar el nuevo sistema es sencillo, pero el riesgo es alto y las fallas en el nuevo
sistema pueden ser crticas.
Por fases:
El Nuevo sistema es desplegado en piezas discretas de funcionalidad, esto se puede
hacer cuando el sistema puede ser dividido en partes lgicas, se puede hacer y
desplegar el sistema con bajos riesgos, pero
puede
prolongar mucho el
posicionamiento del nuevo sistema en su totalidad.
En paralelo:
Esto requiere que tanto el nuevo sistema como el viejo estn corriendo durante un
periodo de tiempo. Este enfoque es costoso por el mltiple manejo de datos, pero el
riesgo manejado propende a disminuir ostensiblemente.

46

Bandera verde:
El sistema a desplegar en un ambiente nuevo, no tiene un sistema existente. Esto es
comn en un negocio que apenas est empezando. Es un ambiente ideal para
desplegar el nuevo sistema ya que los riesgos son bajos y los posibles problemas para
integrarse con otros sistemas en mnima.
Manteniendo el sistema despus de la entrega:
Despus de desplegar el sistema, este pasa al estatus de mantenimiento, en XP el
sistema constantemente est evolucionando, en refactorizacin y refinamiento del
sistema. La habilidad para parchar y actualizar el sistema es establecida y verificada por
las pruebas automticas del sistema.
Cuando estamos hablando del sistema productivo se debe tener mucho cuidado y se
deben crear estrategias para ello.

Exploracin

Planeacin
Multiples iteraciones
Iteracin
Refinar el plan

Produccin

Mantenimiento

Ilustracin 7 Ciclo de vida en XP

3.1.1.2.7 ROLES
Como trabajan juntos los roles en XP
Usualmente un negocio cubre demasiados aspectos que una sola persona no es capaz
de abarcar totalmente, o el negocio tendra que ser lo suficientemente pequeo para
que haya una persona experta en todo el proceso de negocio.

47

Ilustracin 8 Un solo cliente con el equipo tcnico

Las ventajas obvias de usar XP son el proceso de toma de decisiones simplificadas.

El problema al trabajar con 2 equipos es que son ms 2 roles (cliente y desarrollador),
existen ms roles como el diseador, pruebas, modeladores, arquitectos, etc.

Ilustracin 9 Equipo XP

Roles por parte del negocio:

Cliente:
El cliente define lo que el proyecto es, el valor del negocio y la direccin en que se debe
mover el proyecto. Nos referimos como cliente el conjunto de personas que:

Define el valor del negocio.

Escribe historias de usuario.
Escribe o especifica pruebas de aceptacin.
Debe ser el usuario final del sistema.

El cliente debe tener conocimientos muy slidos del proceso del negocio y debe tener
claridad de lo que el nuevo sistema est resolviendo. El nivel de sus conocimientos
tcnicos es menos crtico que el conocimiento que debe tener del negocio.
Administrador
Es la persona por parte del negocio, que lidera la comunidad de clientes, hacia el xito
del proyecto, esclarece y clarifica conceptos entre los usuarios y el grupo tcnico. En
48

general facilita y hace todo lo posible por parte de la organizacin para liberarla de
obstculos y facilitar los medios para el proyecto.
Entrenador:
El entrenador es el principal facilitador de comunicacin en el equipo.
El entrenador sabe que est haciendo el equipo, no 100%, pero si sabe en qu
direccin van.
El entrenador necesita tener excelentes habilidades tcnicas, porque dirige la
refactorizacin tanto en la parte de diseo como en su implementacin, en ocasiones
debe guiar y ayudar a los pares de programadores.
Algunas de las caractersticas del entrenador deben ser:

Alto entendimiento de XP
Un amplio conocimiento de los procesos de desarrollo
Confidente
Liderazgo
Sentido del humor
Habilidad para balancear las perspectivas de la visn a largo y los problemas que
se presentan presentes en el proyecto
Resolucin de problemas.
Saber ensear
Integral
Experiencia en tcnicas orientadas a objetos
Experiencia en lenguajes ( java, c++, etc.)

Desarrollador:

Hace una estimacin de las historias de usuario

Hace pruebas cuando es necesario
Escribe pruebas
Escribe cdigo
Participa en la reuniones de planificacin
Participa en las reuniones diarias.

Actividades diarias del desarrollador:

Los desarrolladores trabajan en parejas en una estacin de trabajo. Si se est
trabajando actualmente en una tarea ya asignada, se debe estar con una pareja, si se
va a comenzar una nueva tarea se debe conseguir un compaero de trabajo.
Disear a este nivel significa Cmo iremos a resolver esta tarea?

49

Se comienza la tarea de escribir las pruebas que chequean lo que podra fallar, antes
de escribir el cdigo. Expanda la prueba a todo lo que sea susceptible de fallos. En esta
fase si se requiere ms claridad se busca al usuario si es necesario.
Se codifica la tarea. El objetivo es completar nicamente lo que asegura que el
componente pase exitosamente las pruebas.
Revisando el cdigo, se miran las reas que son susceptibles de mejorarlas y
simplificarlas. Se para la refactorizacin una vez han sido satisfechas estas 2 premisas.
Se aade los componentes nuevos al escenario de integracin y se verifica que la
integracin pase las pruebas en el ambiente integrado.
Ejecutor de pruebas
Es el rol para completar las pruebas funcionales. Verifica que el sistema trabaja como
es esperado. Ms que trabajar desde un punto de aseguramiento de calidad externo, es
parte del equipo, probablemente escribir pruebas con el cliente.

Ejecutor de mtricas
Es la persona que junta las mtricas como las historias de usuario o tareas completas y
las disemina en el equipo, este rol debe decidir cual mtrica es ms significativa para el
equipo, cual mtrica es la que trae ms aportes significativos al estado actual del
proyecto.
En estas mtricas debe estar como mnimo como es el estado de los ltimos builds,
nmero de historias de usuario, velocidad de desarrollo y todo lo que se considere
necesario para hacer seguimiento.
Los resultados de las mtricas siempre deben ser pblicos y se pueden llevar en forma
electrnica como documentos ofimticas, pginas Web de intranet, etc.
3.1.1.2.7 Historias de usuario
Es una de las principales herramientas usadas en esta metodologa, puede estar en
medios impresos o digitales para su mejor manejo.

50

Un ejemplo de una historia de usuario en limpio podra ser:

Historia de Usuario
Nmero: 1

Nombre: Enviar artculo

Usuario: Autor
Modificacin de Historia Nmero:
Prioridad en Negocio: Alta
(Alta / Media / Baja)
Riesgo en Desarrollo:
(Alto / Medio / Bajo)

Iteracin Asignada:
Puntos Estimados:
Puntos Reales:

Descripcin:
Se introducen los datos del artculo (ttulo, fichero adjunto, resumen, tpicos) y de los
autores (nombre, e-mail, afiliacin). Uno de los autores debe indicarse como autor de
contacto. El sistema confirma la correcta recepcin del artculo enviando un e-mail al
autor de contacto con un userid y password para que el autor pueda posteriormente
acceder al artculo.
Observaciones:
Interfaz:

Tabla 3 Historia de usuario

51

3.1.2 RUP
3.1.2.1 Consideraciones
Cmo podemos comparar procesos?
Los procesos se caracterizan por dos dimensiones, nivel de ceremonia y son en
cascada o iterativos

Baja ceremonia/Alta ceremonia: En el eje horizontal, la baja ceremonia

produce un mnimo de documentacin de soporte y posee pequeos formalismos
en los procedimientos de trabajo; La alta ceremonia tiene una buena cantidad de
documentacin y una trasabilidad a travs de varios artefactos, control de
cambios y todo lo necesarios para proyectos que requieran ser muy rigurosos y
predecibles.

Cascada/Iterativos: Cascada es un ciclo de vida lineal con integracin y

pruebas tardas; El iterativo maneja riegos con una temprana implementacin de
la arquitectura, integracin y pruebas.

Mapa de procesos
Cascada
Pocos riesgos, secuencia,
integracin y testing tardos

Baja ceremonia
Poca documentacin
Procesos ligeros

Alta ceremonia
Bien documentado
trasabilidad

Iterativo
Manejo de riesgos
Continua intergacin y pruebas

Ilustracin 10 Mapa de procesos

Programacin gil: Baja ceremonia e iterativo

Los desarrollos giles como son XP y SCRUM, hacen un sacrificio en torno al nivel de
ceremonia y rigor en pro de tener una alta flexibilidad y adaptabilidad en el negocio. Se
le da una mayor prioridad en producir software y no en crear una extensa y detallada
documentacin. No se posee un plan rgido de desarrollo, se van haciendo cambios
durante el proceso, aunque esto no quiere decir que no exista y que no sea importante
52

la documentacin, esta es requerida para asegurar que el software se pueda hacer,

adaptar los planes a la realidad y necesidades que hayan de cambio.
CMM y CMMI: Alta ceremonia, se procura tener todo predecible.
Cuando las compaas tienen una inversin considerable en proyectos de software y no
pueden darse el lujo de resultados no predecibles que afecten la calidad, se debe tener
una cantidad considerable de documentacin que facilite y garantice un adecuado
funcionamiento de un proyecto de software.
Las caractersticas de un proyecto de este tipo son:

Los planes son muy detallados y hechos con cuidado.

Hay muchos artefactos relacionados con la administracin, requerimientos y
pruebas.
Se maneja control de versiones de artefactos de administracin, requerimientos y
pruebas.
Hay una creacin y mantenimiento de la trasabilidad entre los requerimientos,
elementos de diseo y artefactos de prueba.
Existe un mecanismo para manejar adecuadamente los controles de cambio.
Los resultados de las inspecciones poseen seguimiento.

El enfoque de alta ceremonia es apropiado para sistemas de desarrollo complejo,

equipos extensos y distribuidos. Este enfoque produce sistemas de calidad que son
fciles de mantener, pero el costo de producirlo es costoso y el tiempo para su
ejecucin es mayor que el enfoque de baja ceremonia.
CMM
En la bsqueda de tener mas predecibilidad y una alta calidad, las organizaciones
necesitaron primero entender sus procesos que tan buenos eran y mirar hacia el futuro
para tener unos procesos de alto nivel de madures. El modelo de capacidad y madurez
diseado por el instituto de ingeniera de software (SEI) , est diseado para hacer eso,
el CMM no es un proceso, es un framework de valoracin usado para saber en la
organizacin su nivel de los procesos en una escala de 1 a 5, CMM no dice como
desarrollar software como tal, para esto est RUP, XP, etc.
CMM provee una gua detallada de lo que puede ser parte de un desarrollo de software
o una adquisicin para una organizacin madura. Se debe tener mucho cuidado de no
tener un exceso de artefactos, lo cual hara los procesos pesados e ineficientes.
Teniendo un enfoque fuerte en las revisiones en pares, inspecciones, actividades
tradicionales para asegurar la calidad, CMM tiene un enfoque en cascada ya que no se
obliga ha realizar una temprana integracin y chequeo.
CMMI
El CMMI est ms adecuado a las nuevas y mejores prcticas como es el manejo de
riesgos y un desarrollo iterativo, ms que dedicarse a crear ms ceremonia, CMMI se
53

centra en enfocarse en reas individuales de mejoramiento que ayuden a los objetivos

de la organizacin en sus negocios y disminuya los riesgos.

Ilustracin 11 Mapa de rocesos CMM CMMI XP SCRUM

RUP: Un acercamiento iterativo con un nivel de ceremonia adaptable

Es un framework configurable que permite a los usuarios producir una gran variedad de
procesos, las configuraciones de RUP permite adaptarse si ningn problema desde
escalas de poca ceremonia hasta las que requieren alta ceremonia dependiendo de las
necesidades del proyecto. RUP promueve ser fuertemente iterativo y maneja riesgos en
el desarrollo haciendo frecuentemente integracin y pruebas. Hay tambin alguna
flexibilidad entre el eje de Cascada/iterativo y algunas compaas lo usan de la forma de
cascada
Mapa de procesos
Cascada
Pocos riesgos, secuencia,
integracin y testing tardos

Baja ceremonia
Poca documentacin
Procesos ligeros

RUP

Alta ceremonia
Bien documentado
trasabilidad

Iterativo
Manejo de riesgos
Continua intergacin y pruebas

Ilustracin 12 Mapa de procesos RUP

El framewok de RUP posee una vasta cantidad de guas, artefactos y roles, como no
todos los proyectos van a necesitar todos estos artefactos, se necesita especificar un
subjconjunto para usar en un proyecto. Esto es hecho configurando el RUP, el cual
constituye unos procesos completos desde una perspectiva particular de los
54

requerimientos. Tambin se pueden coger configuraciones pre-establecidas como punto

de inicio o arrancar de ceros.
Un componente de proceso en RUP: Es un mdulo del proceso que puede tener un
nombre, ser empacado, intercambiado y ensamblado con otros componente de de
proceso.
Una librera de RUP, es una coleccin de componentes, los cuales sus configuraciones
son tratadas con el RUP builder y se pueden poner ms procesos en la librera usando
el mecanismo de plug-ins.
El proceso de configuracin es realizado usando el RUP Builder. Este es comprado y
viene con un nmero predefinido de configuraciones. Tambin ofrece la posibilidad de
crear configuraciones que se necesiten. Se puede elegir el nivel de formalidad con la
que se puede trabajar, tambin se pueden usar plantillas que pueden ser muy
completas o ligeras dependiendo de las necesidades.
Una vez se halla definido que plug-ins, que componentes de proceso y base de RUP
se emplear el Rup Builder valida que todo este correcto y se hace una publicacin web
de la configuracin.
Al tener una configuracin del proceso RUP, partes de esta configuracin no son del
todo aplicables a administrador del proyecto, analista, arquitecto, desarrollador o tester,
por esta razn dependiendo del rol y las responsabilidades se crean vistas de procesos
las cuales sern usadas segn el rol y responsabilidades de la persona en el proyecto.
3.1.2.2 Definiciones de RUP
El RUP es un acercamiento al desarrollo de software que es iterativo, centrado
en la arquitectura y manejado con casos de uso. Rup describe una variedad de
documentacin y libros. La mayor informacin puede ser encontrada en el propio
producto el cual tiene guas detalladas, ejemplos y plantillas que cubren
completamente el ciclo de vida del software.

El RUP es un proceso de ingeniera de software bien definido y bien

estructurado, est claramente definido quien es responsable de que, como las
cosas son hechas y cuando deben hacerse. El RUP provee una buena definicin
de la estructura del ciclo de vida en un proyecto con RUP, se identifican hitos
importantes y puntos de decisin.

El proceso puede ser descrito en dos dimensiones o ejes:

Eje horizontal: Representa el tiempo y es considerado el eje de los aspectos dinmicos
del proceso. Indica las caractersticas del ciclo de vida del proceso expresado en
55

trminos de fases, iteraciones e hitos. Se puede observar en la Figura 8 que RUP

consta de cuatro fases: Inicio, Elaboracin, Construccin y Transicin. Como se
mencion anteriormente cada fase se subdivide a la vez en iteraciones.
Eje vertical: Representa los aspectos estticos del proceso. Describe el proceso en
trminos de componentes de proceso, disciplinas, flujos de trabajo, actividades,
artefactos y roles.

Ilustracin 13 Estructura de RUP

3.1.2.3 Estructura Dinmica del proceso. Fases e iteraciones

RUP se repite a lo largo de una serie de ciclos que constituyen la vida de un producto.
Cada ciclo concluye con una generacin del producto para los clientes. Cada ciclo
consta de cuatro fases: Inicio, Elaboracin, Construccin y Transicin. Cada fase se
subdivide a la vez en iteraciones, el nmero de iteraciones en cada fase es variable.

ciclo de desarrollo

release
(producto al final de
una iteracin)

ciclo de evolucin

base line

generacin

(release asociada
a un hito)

(release final de
un ciclo de desarrollo)

Ilustracin 14 Ciclos, releases, baseline

56

Cada fase se concluye con un hito bien definido, un punto en el tiempo en el cual se
deben tomar ciertas decisiones crticas y alcanzar las metas clave antes de pasar a la
siguiente fase, ese hito principal de cada fase se compone de hitos menores que
podran ser los criterios aplicables a cada iteracin. Los hitos para cada una de las
fases son: Inicio - Lifecycle Objectives, Elaboracin - Lifecycle Architecture,
Construccin - Initial Operational Capability, Transicin - Product Release. Las fases y
sus respectivos hitos se ilustran en la Figura siguiente.

Inception

Elaboration

Objetivos
(Vision)

Construction

Arquitectura

Transition

Capacidad
Operacional
Inicial

Release
del Producto

tiempo
Ilustracin 15 Fases e hitos en RUP

La duracin y esfuerzo dedicado en cada fase es variable dependiendo de las

caractersticas del proyecto. Sin embargo, la tabla 4 siguiente ilustra porcentajes
frecuentes al respecto. Consecuente con el esfuerzo sealado, la ilustracin 16 ilustra
una distribucin tpica de recursos humanos necesarios a lo largo del proyecto.

Inicio

Elaboracin

Construccin

Transicin

Esfuerzo

5%

20 %

65 %

10%

Tiempo
Dedicado

10 %

30 %

50 %

10%

Tabla 4 Distribucin tpica de esfuerzo y tiempo

57

Figura 1:
Ilustracin 16Distribucin tpica de recursos humanos

Inicio
Durante la fase de inicio se define el modelo del negocio y el alcance del proyecto. Se
identifican todos los actores y Casos de Uso, y se disean los Casos de Uso ms
esenciales (aproximadamente el 20% del modelo completo). Se desarrolla, un plan de
negocio para determinar que recursos deben ser asignados al proyecto.
Los objetivos de esta fase son:

Establecer el mbito del proyecto y sus lmites.

Encontrar los Casos de Uso crticos del sistema, los escenarios bsicos que
definen la funcionalidad.

Mostrar al menos una arquitectura candidata para los escenarios principales.

Estimar el coste en recursos y tiempo de todo el proyecto.

Estimar los riesgos, las fuentes de incertidumbre.

Los resultados de la fase de inicio deben ser :

Un documento de visin: Una visin general de los requerimientos del proyecto,

caractersticas clave y restricciones principales.

Modelo inicial de Casos de Uso (10-20% completado).

Un glosario inicial: Terminologa clave del dominio.

El caso de negocio.

Lista de riesgos y plan de contingencia.

Plan del proyecto, mostrando fases e iteraciones.

Modelo de negocio, si es necesario

Prototipos exploratorios para probar conceptos o la arquitectura candidata.

Al terminar la fase de inicio se deben comprobar los criterios de evaluacin para
continuar:

Todos los interesados en el proyecto coinciden en la definicin del mbito del

sistema y las estimaciones de agenda.

Entendimiento de los requisitos, como evidencia de la fidelidad de los Casos de

Uso principales.

Las estimaciones de tiempo, coste y riesgo son crebles.

Comprensin total de cualquier prototipo de la arquitectura desarrollado.

Los gastos hasta el momento se asemejan a los planeados.

58

Si el proyecto no pasa estos criterios hay que plantearse abandonarlo o repensarlo

profundamente.
Elaboracin
El propsito de la fase de elaboracin es analizar el dominio del problema, establecer
los cimientos de la arquitectura, desarrollar el plan del proyecto y eliminar los mayores
riesgos.
En esta fase se construye un prototipo de la arquitectura, que debe evolucionar en
iteraciones sucesivas hasta convertirse en el sistema final. Este prototipo debe contener
los Casos de Uso crticos identificados en la fase de inicio. Tambin debe demostrarse
que se han evitado los riesgos ms graves.
Los objetivos de esta fase son:

Definir, validar y cimentar la arquitectura.

Completar la visin.

Crear un plan fiable para la fase de construccin. Este plan puede evolucionar en
sucesivas iteraciones. Debe incluir los costes si procede.

Demostrar que la arquitectura propuesta soportar la visin con un coste

razonable y en un tiempo razonable.
Al terminar deben obtenerse los siguientes resultados :

Un modelo de Casos de Uso completa al menos hasta el 80%: todos los casos y
actores identificados, la mayora de los casos desarrollados.

Requisitos adicionales que capturan los requisitos no funcionales y cualquier

requisito no asociado con un Caso de Uso especfico.

Descripcin de la arquitectura software.

Un prototipo ejecutable de la arquitectura.

Lista de riesgos y caso de negocio revisados.

Plan de desarrollo para el proyecto.

Un caso de desarrollo actualizado que especifica el proceso a seguir.

Un manual de usuario preliminar (opcional).

En esta fase se debe tratar de abarcar todo el proyecto con la profundidad mnima.
Slo se profundiza en los puntos crticos de la arquitectura o riesgos importantes.
En la fase de elaboracin se actualizan todos los productos de la fase de inicio.
Los criterios de evaluacin de esta fase son los siguientes:

La visin del producto es estable.

La arquitectura es estable.

Se ha demostrado mediante la ejecucin del prototipo que los principales

elementos de riesgo han sido abordados y resueltos.

El plan para la fase de construccin es detallado y preciso. Las estimaciones son

crebles.

Todos los interesados coinciden en que la visin actual ser alcanzada si se

siguen los planes actuales en el contexto de la arquitectura actual.
59

Los gastos hasta ahora son aceptables, comparados con los previstos.

Si no se superan los criterios de evaluacin quiz sea necesario abandonar el proyecto

o replanterselo considerablemente.
Construccin
La finalidad principal de esta fase es alcanzar la capacidad operacional del producto de
forma incremental a travs de las sucesivas iteraciones. Durante esta fase todos los
componentes, caractersticas y requisitos deben ser implementados, integrados y
probados en su totalidad, obteniendo una versin aceptable del producto.
Los objetivos concretos segn incluyen:

Minimizar los costes de desarrollo mediante la optimizacin de recursos y

evitando el tener que rehacer un trabajo o incluso desecharlo.

Conseguir una calidad adecuada tan rpido como sea prctico.

Conseguir versiones funcionales (alfa, beta, y otras versiones de prueba) tan

rpido como sea prctico.
Los resultados de la fase de construccin deben ser :

Modelos Completos (Casos de Uso, Anlisis, Diseo,

Implementacin)

Arquitectura ntegra (mantenida y mnimamente actualizada)

Riesgos Presentados Mitigados

Plan del Proyecto para la fase de Transicin.

Manual Inicial de Usuario (con suficiente detalle)

Prototipo Operacional beta

Caso del Negocio Actualizado

Despliegue

Los criterios de evaluacin de esta fase son los siguientes:

El producto es estable y maduro como para ser entregado a la comunidad de

usuario para ser probado.

Todos los usuarios expertos estn listos para la transicin en la comunidad de

usuarios.

Son aceptables los gastos actuales versus los gastos planeados.

Transicin
La finalidad de la fase de transicin es poner el producto en manos de los usuarios
finales, para lo que se requiere desarrollar nuevas versiones actualizadas del producto,
completar la documentacin, entrenar al usuario en el manejo del producto, y en
general tareas relacionadas con el ajuste, configuracin, instalacin y facilidad de uso
del producto.
Algunas de las cosas que puede incluir esta fase:
Prueba de la versin Beta para validar el nuevo sistema frente a las expectativas
de los usuarios
Funcionamiento paralelo con los sistemas legados que estn siendo sustituidos
60

por nuestro proyecto.

Conversin de las bases de datos operacionales.
Entrenamiento de los usuarios y tcnicos de mantenimiento.
Traspaso del producto a los equipos de marketing, distribucin y venta.

Los principales objetivos de esta fase son:

Conseguir que el usuario se valga por si mismo.
Un producto final que cumpla los requisitos esperados, que funcione y satisfaga
suficientemente al usuario.
Los resultados de la fase de transicin son :
Prototipo Operacional
Documentos Legales
Caso del Negocio Completo
Lnea de Base del Producto completa y corregida que incluye todos los modelos
del sistema
Descripcin de la Arquitectura completa y corregida
Las iteraciones de esta fase irn dirigidas normalmente a conseguir una nueva
versin.
Los criterios de evaluacin de esta fase son los siguientes:
El usuario se encuentra satisfecho.
Son aceptables los gastos actuales versus los gastos planificados.
Estructura Esttica del proceso. Roles, actividades, artefactos y flujos de trabajo
Un proceso de desarrollo de software define quin hace qu, cmo y cundo. RUP
define cuatro elementos los roles, que responden a la pregunta Quin?, las
actividades que responden a la pregunta Cmo?, los productos, que responden a la
pregunta Qu? y los flujos de trabajo de las disciplinas que responde a la pregunta
Cundo? (ver Ilustracin 17 y 18) .

Ilustracin 17 Relacin entre roles, actividades, artefactos

61

Roles

Artefactos
Actividades

Ilustracin 18 Detalle de un workflow mediante roles, actividades y artefactos

3.1.2.4 Roles
Un rol define el comportamiento y responsabilidades de un individuo, o de un grupo de
individuos trabajando juntos como un equipo. Una persona puede desempear diversos
roles, as como un mismo rol puede ser representado por varias personas.
Las responsabilidades de un rol son tanto el llevar a cabo un conjunto de actividades
como el ser el dueo de un conjunto de artefactos.
RUP define grupos de roles, agrupados por participacin en actividades relacionadas.
Estos grupos son :
Analistas:
Analista de procesos de negocio.
Diseador del negocio.
Analista de sistema.
Especificador de requisitos.
Desarrolladores:
Arquitecto de software.
Diseador
Diseador de interfaz de usuario
Diseador de cpsulas.
Diseador de base de datos.
Implementador.
Integrador.
Gestores:
62

Jefe de proyecto
Jefe de control de cambios.
Jefe de configuracin.
Jefe de pruebas
Jefe de despliegue
Ingeniero de procesos
Revisor de gestin del proyecto
Gestor de pruebas.

Apoyo:
Documentador tcnico
Administrador de sistema
Especialista en herramientas
Desarrollador de cursos
Artista grfico
Especialista en pruebas:
Especialista en Pruebas (tester)
Analista de pruebas
Diseador de pruebas
Otros roles:
Stakeholders.
Revisor
Coordinacin de revisiones
Revisor tcnico
Cualquier rol

3.1.2.5 Actividades
Una actividad en concreto es una unidad de trabajo que una persona que desempee
un rol puede ser solicitado a que realice. Las actividades tienen un objetivo concreto,
normalmente expresado en trminos de crear o actualizar algn producto.
3.1.2.6 Artefactos
Un producto o artefacto es un trozo de informacin que es producido, modificado o
usado durante el proceso de desarrollo de software. Los productos son los resultados
tangibles del proyecto, las cosas que va creando y usando hasta obtener el producto
final.
Un artefacto puede ser cualquiera de los siguientes:

Un documento, como el documento de la arquitectura del software.

Un modelo, como el modelo de Casos de Uso o el modelo de diseo.
63

Un elemento del modelo, un elemento que pertenece a un modelo como una

clase, un Caso de Uso o un subsistema.

3.1.2.7 Flujos de trabajo

Con la enumeracin de roles, actividades y artefactos no se define un proceso.
Necesitamos contar con una secuencia de actividades realizadas por los diferentes
roles, as como la relacin entre los mismos. Un flujo de trabajo es una relacin de
actividades que nos producen unos resultados observables. A continuacin se dar
una explicacin de cada flujo de trabajo.
3.1.2.8 Modelado del negocio
Con este flujo de trabajo pretendemos llegar a un mejor entendimiento de la
organizacin donde se va a implantar el producto.
Los objetivos del modelado de negocio son:

Entender la estructura y la dinmica de la organizacin para la cual el sistema va

ser desarrollado (organizacin objetivo).
Entender el problema actual en la organizacin objetivo e identificar potenciales
mejoras.
Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento
comn de la organizacin objetivo.
Derivar los requisitos del sistema necesarios para apoyar a la organizacin
objetivo.

Para lograr estos objetivos, el modelo de negocio describe cmo desarrollar una visin
de la nueva organizacin. Basado en esta visin se definen procesos, roles y
responsabilidades de la organizacin por medio de un modelo de Casos de Uso del
negocio y un Modelo de Objetos del Negocio. Complementario a estos modelos, se
desarrollan otras especificaciones tales como un Glosario.
3.1.2.9 Requisitos
Este es uno de los flujos de trabajo ms importantes, porque en l se establece qu
tiene que hacer exactamente el sistema que construyamos. En esta lnea los requisitos
son el contrato que se debe cumplir, de modo que los usuarios finales tienen que
comprender y aceptar los requisitos que especifiquemos.
Los objetivos del flujo de datos Requisitos son:

Establecer y mantener un acuerdo entre clientes y otros stakeholders sobre lo que

el sistema podra hacer.
Proveer a los desarrolladores un mejor entendimiento de los requisitos del
sistema.
Definir el mbito del sistema.
64

Proveer una base para la planeacin de los contenidos tcnicos de las iteraciones.
Proveer una base para estimar costos y tiempo de desarrollo del sistema.
Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y
metas del usuario.

Los requisitos se dividen en dos grupos. Los requisitos funcionales representan la

funcionalidad del sistema. Se modelan mediante diagramas de Casos de Uso. Los
requisitos no funcionales representan aquellos atributos que debe exhibir el sistema,
pero que no son una funcionalidad especfica. Por ejemplo requisitos de facilidad de
uso, fiabilidad, eficiencia, portabilidad, etc.
Para capturar los requisitos es preciso entrevistar a todos los interesados en el
proyecto, no slo a los usuarios finales, y anotar todas sus peticiones. A partir de ellas
hay que descubrir lo que necesitan y expresarlo en forma de requisitos.
En este flujo de trabajo, y como parte de los requisitos de facilidad de uso, se disea la
interfaz grfica de usuario. Para ello habitualmente se construyen prototipos de la
interfaz grfica de usuario que se contrastan con el usuario final.
3.1.2.10 Anlisis y Diseo
El objetivo de este flujo de trabajo es traducir los requisitos a una especificacin que
describe cmo implementar el sistema.
Los objetivos del anlisis y diseo son :
Transformar los requisitos al diseo del futuro sistema.
Desarrollar una arquitectura para el sistema.
Adaptar el diseo para que sea consistente con el entorno de implementacin,
diseando para el rendimiento.
El anlisis consiste en obtener una visin del sistema que se preocupa de ver qu hace,
de modo que slo se interesa por los requisitos funcionales. Por otro lado el diseo es
un refinamiento del anlisis que tiene en cuenta los requisitos no funcionales, en
definitiva cmo cumple el sistema sus objetivos.
Al principio de la fase de elaboracin hay que definir una arquitectura candidata: crear
un esquema inicial de la arquitectura del sistema, identificar clases de anlisis y
actualizar las realizaciones de los Casos de Uso con las interacciones de las clases de
anlisis. Durante la fase de elaboracin se va refinando esta arquitectura hasta llegar a
su forma definitiva. En cada iteracin hay que analizar el comportamiento para disear
componentes. Adems si el sistema usar una base de datos, habr que disearla
tambin, obteniendo un modelo de datos.
El resultado final ms importante de este flujo de trabajo ser el modelo de diseo.
Consiste en colaboraciones de clases, que pueden ser agregadas en paquetes y
subsistemas.
65

Otro producto importante de este flujo es la documentacin de la arquitectura de

software, que captura varias vistas arquitectnicas del sistema.
3.1.2.11 Implementacin
En este flujo de trabajo se implementan las clases y objetos en ficheros fuente, binarios,
ejecutables y dems. Adems se deben hacer las pruebas de unidad: cada
implementador es responsable de probar las unidades que produzca. El resultado final
de este flujo de trabajo es un sistema ejecutable.
En cada iteracin habr que hacer lo siguiente:
Planificar qu subsistemas deben ser implementados y en que orden deben ser
integrados, formando el Plan de Integracin.
Cada implementador decide en que orden implementa los elementos del
subsistema.
Si encuentra errores de diseo, los notifica.
Se prueban los subsistemas individualmente.
Se integra el sistema siguiendo el plan.
La estructura de todos los elementos implementados forma el modelo de
implementacin. La integracin debe ser incremental, es decir, en cada momento slo
se aade un elemento. De este modo es ms fcil localizar fallos y los componentes se
prueban ms a fondo. En fases tempranas del proceso se pueden implementar
prototipos para reducir el riesgo. Su utilidad puede ir desde ver si el sistema es viable
desde el principio, probar tecnologas o disear la interfaz de usuario. Los prototipos
pueden ser exploratorios (desechables) o evolutivos. Estos ltimos llegan a
transformarse en el sistema final.
3.1.2.12 Pruebas
Este flujo de trabajo es el encargado de evaluar la calidad del producto que estamos
desarrollando, pero no para aceptar o rechazar el producto al final del proceso de
desarrollo, sino que debe ir integrado en todo el ciclo de vida.
Esta disciplina brinda soporte a las otras disciplinas. Sus objetivos son:
Encontrar y documentar defectos en la calidad del software.
Generalmente asesora sobre la calidad del software percibida.
Provee la validacin de los supuestos realizados en el diseo y especificacin de
requisitos por medio de demostraciones concretas.
Verificar las funciones del producto de software segn lo diseado.
Verificar que los requisitos tengan su apropiada implementacin.
Las actividades de este flujo comienzan pronto en el proyecto con el plan de prueba (el
cual contiene informacin sobre los objetivos generales y especficos de las prueba en
el proyecto, as como las estrategias y recursos con que se dotar a esta tarea), o
incluso antes con alguna evaluacin durante la fase de inicio, y continuar durante todo
el proyecto.
66

El desarrollo del flujo de trabajo consistir en planificar que es lo que hay que probar,
disear cmo se va a hacer, implementar lo necesario para llevarlos a cabo, ejecutarlos
en los niveles necesarios y obtener los resultados, de forma que la informacin obtenida
nos sirva para ir refinando el producto a desarrollar.
3.1.2.13 Despliegue
El objetivo de este flujo de trabajo es producir con xito distribuciones del producto y
distribuirlo a los usuarios. Las actividades implicadas incluyen:

Probar el producto en su entorno de ejecucin final.

Empaquetar el software para su distribucin.
Distribuir el software.
Instalar el software.
Proveer asistencia y ayuda a los usuarios.
Formar a los usuarios y al cuerpo de ventas.
Migrar el software existente o convertir bases de datos.

Este flujo de trabajo se desarrolla con mayor intensidad en la fase de transicin, ya que
el propsito del flujo es asegurar una aceptacin y adaptacin sin complicaciones del
software por parte de los usuarios. Su ejecucin inicia en fases anteriores, para
preparar el camino, sobre todo con actividades de planificacin, en la elaboracin del
manual de usuario y tutoriales.
3.1.2.14 Gestin del proyecto
La Gestin del proyecto es el arte de lograr un balance al gestionar objetivos, riesgos y
restricciones para desarrollar un producto que sea acorde a los requisitos de los clientes
y los usuarios.
Los objetivos de este flujo de trabajo son:
Proveer un marco de trabajo para la gestin de proyectos de software intensivos.
Proveer guas prcticas realizar planeacin, contratar personal, ejecutar y
monitorear el proyecto.
Proveer un marco de trabajo para gestionar riesgos.
La planeacin de un proyecto posee dos niveles de abstraccin: un plan para las fases
y un plan para cada iteracin.
3.1.2.15 Configuracin y control de cambios
La finalidad de este flujo de trabajo es mantener la integridad de todos los artefactos
que se crean en el proceso, as como de mantener informacin del proceso evolutivo
que han seguido.

67

3.1.2.16 Entorno
La finalidad de este flujo de trabajo es dar soporte al proyecto con las adecuadas
herramientas, procesos y mtodos. Brinda una especificacin de las herramientas que
se van a necesitar en cada momento, as como definir la instancia concreta del proceso
que se va a seguir.
En concreto las responsabilidades de este flujo de trabajo incluyen:
Seleccin y adquisicin de herramientas
Establecer y configurar las herramientas para que se ajusten a la organizacin.
Configuracin del proceso.
Mejora del proceso.
Servicios tcnicos.
El principal artefacto que se usa en este flujo de trabajo es el caso de desarrollo que
especifica para el proyecto actual en concreto, como se aplicar el proceso, que
productos se van a utilizar y como van a ser utilizados. Adems se tendrn que definir
las guas para los distintos aspectos del proceso, como pueden ser el modelado del
negocio y los Casos de Uso, para la interfaz de usuario, el diseo, la programacin, el
manual de usuario.12

12

Introduccin a RUP [sitio en Internet], disponible en

https://pid.dsic.upv.es/C1/Material/Documentos%20Disponibles/Introducci%C3%B3n%20a%20RUP.doc ltimo acceso: Noviembre
20 de 2007.

68

3.1.3 Consideraciones metodologa ASAP

La metodologa ASAP, al verla detenidamente nos da la impresin que sus procesos
van dirigidos estrictamente a un ciclo tradicional de cascada o lineal.
Para la mayora de gente que haya participado en proyectos tradicionales de software,
en donde se tiene que construir todo el sistema desde cero, claramente propondran un
esquema iterativo como lo proponen en la actualidad los paradigmas de la
programacin gil o RUP.
La plataforma SAP ECC, es un sistema altamente modular y configurable, en el cual
slo se programa la parte respectiva a las personalizaciones de la plataforma. Para
estas personalizaciones ya se tiene una plataforma tanto de hardware y software. SAP
ECC provee al programador una arquitectura y un modelo de datos suficientemente
completa como para llevar a cabo las tareas de personalizacin en el sistema y es por
esto que la metodologa ASAP se centra en la captura de los procesos del negocio y
trasladarlos a la plataforma SAP ECC con sus mdulos bsicamente.

3.1.3.1 Ciclo de vida cascada

En Ingeniera de software el desarrollo en cascada, tambin llamado modelo en
cascada, es el enfoque metodolgico que ordena rigurosamente las etapas del ciclo de
vida del software, de forma tal que el inicio de cada etapa debe esperar a la finalizacin
de la inmediatamente anterior.
Un ejemplo de una metodologa de desarrollo en cascada es:
1.
2.
3.
4.
5.
6.
7.

Anlisis de requisitos
Diseo del Sistema
Diseo del Programa
Codificacin
Pruebas
Implantacin
Mantenimiento

De esta forma, cualquier error de diseo detectado en la etapa de prueba conduce

necesariamente al rediseo y nueva programacin del cdigo afectado, aumentando los
costes del desarrollo. La palabra cascada sugiere, mediante la metfora de la fuerza de
la gravedad, el esfuerzo necesario para introducir un cambio en las fases ms
avanzadas de un proyecto.
Si bien ha sido ampliamente criticado desde el mbito acadmico y la industria, sigue
siendo el paradigma ms seguido al da de hoy.

69

Fases del modelo.

Anlisis de requisitos
Se analizan las necesidades de los usuarios finales del software para determinar qu
objetivos debe cubrir. De esta fase surge una memoria llamada SRD (documento de
especificacin de requisitos), que contiene la especificacin completa de lo que debe
hacer el sistema sin entrar en detalles internos.
Es importante sealar que en esta etapa se deben consensuar todo lo que se requiere
del sistema y ser aquello lo que seguir en las siguientes etapas, no pudindose
requerir nuevos resultados a mitad del proceso de elaboracin del software.
Diseo del Sistema
Se descompone y organiza el sistema en elementos que puedan elaborarse por
separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el
SDD (Documento de Diseo del Software), que contiene la descripcin de la estructura
relacional global del sistema y la especificacin de lo que debe hacer cada una de sus
partes, as como la manera en que se combinan unas con otras.

Diseo del Programa

Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los
requerimientos del usuario as como tambin los anlisis necesarios para saber que
herramientas usar en la etapa de Codificacin.

Codificacin
Es la fase de programacin propiamente dicha. Aqu se desarrolla el cdigo fuente,
haciendo uso de prototipos as como pruebas y ensayos para corregir errores.
Dependiendo del lenguaje de programacin y su versin se crean las libreras y
componentes reutilizables dentro del mismo proyecto para hacer que la programacin
sea un proceso mucho ms rpido.
Pruebas
Los elementos, ya programados, se ensamblan para componer el sistema y se
comprueba que funciona correctamente antes de ser puesto en explotacin.

70

Implantacin
El software obtenido se pone en produccin. Se implementan los niveles software y
hardware que componen el proyecto. La implantacin es la fase con ms duracin y con
ms cambios en el ciclo de elaboracin de un proyecto. Es una de las fases finales del
proyecto.
Durante la explotacin del sistema software pueden surgir cambios, bien para corregir
errores o bien para introducir mejoras. Todo ello se recoge en los Documentos de
Cambios.

Ilustracin 19 Ciclo de vida en cascada

3.1.3.2 La metodologa de implementacin Accelerated SAP (ASAP)13

La metodologa de implementacin ASAP fue diseada por SAP para ayudar a sus
Clientes y Partners a realizar una implementacin rpida y de bajo costo. La
metodologa ASAP permite:

Minimizar el tiempo requerido entre la instalacin y el arranque productivo.

Maximizar la utilizacin de los recursos de los clientes y de los partners.
Incorporar un esquema de entrenamiento orientado a los procesos.
Obtener resultados en un modelo de procedimientos que puede ser usado en
otras implantaciones en el cliente.
Involucrar y lograr una pronta aceptacin del sistema por parte de la comunidad
de usuarios.

La metodologa ASAP contempla las siguientes fases y entregables:

13 La metodologa de implementacin Accelerated SAP (ASAP) [sitio en Internet], disponible en

http://www.sap.com/argentina/partners/howtochoose/index.epx ltimo acceso: Noviembre 20 de 2007.
Fuente principal: Brand Hartwing. Implementacin tcnica mediamte ASAP Espaa; Gestin 2000, 2001.

71

Preparacin del Proyecto

Diseo del proyecto (equipo de trabajo, tareas, recursos, tiempo, metodologa)
Planos del Negocio
Definicin de Estructuras Organizativas
Definicin de Procesos Funcionales
Definicin de Datos Maestros
Migracin de datos
Recopilacin de informacin faltante
Documento Plano de Negocios
Realizacin
Parametrizacin del Sistema
Sistema configurado y probado
Preparacin Final
Usuarios entrenados y sistema productivo preparado
Arranque Productivo y Soporte
Ingreso en Productivo
Temas pendientes cerrados

Ilustracin 20 Fases del ASAP

FASE I: Preparacin del Proyecto

Durante esta fase, el equipo del proyecto se entrenar en los fundamentos de mySAP
ECC y en el mapa de procedimientos de ASAP, se completar el plan del proyecto de
alto nivel y se revisar el esquema del hardware necesario. El proyecto se iniciar
oficialmente con una reunin de lanzamiento. Esta reunin no es exclusiva del equipo
del proyecto y los consultores del implantador, sino que tambin para otros miembros
clave de la empresa. Este arranque preparar un escenario propicio para el proyecto
destacando la importancia de ste con los objetivos futuros de la compaa.
Debido a los grandes costos de estos proyectos en la reunin de lanzamiento debe
participar una empresa interventora que garantice los aspectos legales entre las partes
y garantice que el proyecto posee unos alcances coherentes y claros.
72

FASE II: Planos del Negocio (Business Blueprint)

El propsito de la fase de Planos del Negocio (Business Blueprint) es entender las
metas del cliente y determinar los procesos de negocio necesarios para cumplir las
mismas. En una reunin de Revisin Ejecutiva, se discutirn las metas del grupo, la
estructura organizacional y los procesos de negocio de alto nivel. Otros requerimientos
ms detallados sern discutidos durante reuniones de trabajo de revisin de cada uno
de los procesos de negocio. Las reuniones de Revisin Ejecutiva y de los procesos de
negocio sern conducidas por los consultores del implantador.
Las reuniones del levantamiento de procesos de la empresa son ejecutadas por los
funcionales respectivos del rea de proceso y los usuarios lderes que son los expertos
del negocio y conocen las singularidades del proceso, all tambin es de vital
importancia definir las interfaces con sistemas no SAP.
Para verificar que se entendieron apropiadamente los requerimientos del grupo y que se
incluy a todos los involucrados en el proyecto, se preparar un Plano del estado
futuro y ser presentado a sus ejecutivos para la aprobacin del mismo. Este Plano
consistir en un diagrama de la estructura de la empresa, adems del primer borrador
de la definicin de los procesos de negocio que se utilizar en su compaa; los dos se
presentarn en forma escrita y de diagrama. Con la elaboracin de los Planos se
finalizar el alcance detallado del proyecto.
FASE III: Realizacin
Durante esta fase, el equipo del proyecto de su empresa (usuarios lderes) y los
consultores del implantador se separarn para terminar las actividades asignadas. El
equipo del proyecto asistir al entrenamiento de SAP de nivel 2 y 314 El entrenamiento
de SAP se ha organizado alrededor de procesos de negocios. Durante el entrenamiento
de nivel 2, el equipo del proyecto se har ms competente, y comenzar a modelar al
sistema mySAP ERP con base en los requerimientos de una compaa caso. El
entrenamiento, tambin, proporcionar un entendimiento de las herramientas y ayudas
de referencia del sistema; de igual manera, se realizar la integracin de sus
componentes. El entrenamiento de nivel 3 ayudar al equipo del proyecto a adquirir
conocimientos en tpicos detallados dentro de los procesos de negocio.
Mientras que el equipo del proyecto est en entrenamiento, los consultores del
implantador configurarn los procesos de negocio definidos en los planos aprobados.
El sistema configurado reflejar la organizacin del cliente y los catlogos maestros; y
deber soportar un flujo totalmente integrado de los procesos del sistema. Una revisin
de los procesos de negocio de su empresa con el equipo del proyecto y con otros
usuarios clave de cada uno de los procesos de negocio permitir la retroalimentacin y
confirmacin de los planos aprobados.

14

Nivel 1: Cursos de uno a dos das para introducirse en la tecnologa de SAP ECC.
Nivel 2: Cursos de tres a cinco das como primera especializacin de un rea concreta.
Nivel 3: Cursos de tres a cinco das para profundizar en un rea de especialidad, a modo de ampliacin de un curso de nivel 2.

73

Un sistema que refleje los catlogos maestros y la organizacin de su empresa

proporcionar un beneficio adicional al equipo del proyecto en el refuerzo del
entrenamiento tomado.
La configuracin de cada proceso de negocio modular ser dividida en interacciones o
ciclos de flujos de procesos de negocios relacionados. Los flujos de procesos de
negocios son configurados conjuntamente con el desarrollo de reportes, formularios
(documentos legales de la empresa como son facturas, recibos de caja, retencin del
IVA, retencin en la fuente, ICA, etc), procedimientos de usuarios, escenarios de prueba
(pruebas unitarias e integrales), migracin de datos, interfaces (comunicacin sistemas
SAP no SAP) y perfiles de seguridad, basado en las necesidades globales de la
empresa y los requerimientos de los usuarios lderes. Los ciclos no slo proporcionan
indicadores para el equipo del proyecto, sino que tambin proveen puntos claves para
probar y simular partes especficas del proceso global de negocios. Este enfoque
proporciona retroalimentacin inmediata, as como el involucramiento de toda la
organizacin a lo largo del ciclo de vida del proyecto.
Durante los ciclos, los usuarios lderes del cliente estar trabajando estrechamente con
los consultores del implantador para definir los escenarios especficos de negocios y las
condiciones de excepcin. Este enfoque cuenta con la mxima transferencia de
conocimientos permitiendo al equipo de trabajo repetir la configuracin de los procesos
medulares del negocio mientras pone a punto el sistema para tomar en cuenta procesos
comunes de negocios. El equipo del proyecto del cliente completar el entrenamiento
detallado de Nivel 3 durante los ciclos.
Como una actividad paralela, son desarrollados y probados los programas de interface
y conversin, as como los reportes especiales.
FASE IV: Preparacin Final
El propsito bsico de la fase de Preparacin Final es terminar las pruebas finales del
sistema, entrenar a los usuarios finales y llevar los datos y el sistema a un ambiente
productivo. Las pruebas finales al sistema consisten en probar los procedimientos y
programas de conversin y reportes especiales para fines legales y fiscales, probar los
programas de interface a los sistemas actuales, llevar a cabo las pruebas de volumen y
estrs, as como las pruebas de aceptacin del usuario final.
Para entrenar a los usuarios finales, el equipo de proyecto entrenar usuarios clave
utilizando un mtodo de entrenar al entrenador. Este mtodo ayudar a ganar la
aceptacin de los usuarios finales, as como a la construccin de una base de
conocimiento para soporte propio de los reportes en lnea y futuras mejoras al sistema.
Otro propsito de esta fase es crear una estrategia para la Puesta en Marcha. Este plan
especficamente identifica la estrategia de conversin de datos, procedimientos iniciales
de auditora y una estructura de soporte al equipo del proyecto.
El ltimo paso en esta fase es aprobar el sistema y asegurar que el cliente est listo
para la puesta en marcha del Sistema mySAP ERP.
74

FASE V: Arranque Productivo y Soporte.

Inmediatamente despus de la puesta en marcha, el sistema deber ser revisado y
afinado para asegurar que el entorno del negocio est completamente soportado. Este
proceso involucra no solamente el verificar la precisin de las transacciones del
negocio, sino tambin, entrevistar informalmente a los usuarios para verificar que sus
necesidades hayan sido satisfechas.
El ltimo paso en el proceso involucra la medicin de los beneficios que brinda el nuevo
sistema al negocio.

75

4 CONSIDERACIONES PARA REALIZAR EXITOSAMENTE LAS

PERSONALIZACIONES
4.1 Roles
Desarrollador lder
Conocimientos y destrezas:
Alto nivel y destreza en ABAP (estructurado y orientado a objetos).
Conocimiento medio de los principales mdulos de SAP.
Conocimiento medio de la arquitectura SAP.
Nivel alto con metodologas y tcnicas de investigacin de alto nivel, para
planificar, ejecutar, administrar y evaluar proyectos informticos.
Habilidades para promulgar la comunicacin y resolucin de conflictos.
Ser capaz de trabajar en equipo.
Actividades:
En la fase 2 (Planos del negocio), trabajando en equipo, se debe planear con el
lder del proyecto de la empresa que esta montando la implantacin y con el
gerente del proyecto (persona por el lado de la empresa en la que estn
montando la implantacin), la estrategia de salida en vivo, segn tengan
previstas las necesidades de la organizacin y el riego que estn dispuesto a
correr.
En la fase 2 (Planos del negocio), cuando se hacen las especificaciones de las
personalizaciones, para poder hacer una aproximacin del tiempo de los
desarrollos, debe usar los punto de funcin.
En la fase 2 (Planos del negocio), Segn la estrategia de salida en vivo y
duracin de las actividades, se debe organizar un cronograma de los desarrollos,
para que estn acordes al proyecto en general y poder saber de una forma
coherente cuantos recursos ABAP se necesitan.
En todas las fases del proyecto, debe manejar junto con todas las personas
involucradas en el proyecto la parte de riesgos, tanto en su parte de
identificacin, probabilidad de ocurrencia, impacto, estrategia de mitigacin y
seguimiento.
En la fase 3 (realizacin), debe supervisar el adecuado desarrollo de las
personalizaciones, que vayan de acuerdo a lo planeado y en caso contrario
establecer las medidas adecuadas para que sea as.
En la fase 3, 4 y 5 debe supervisar el adecuado control de cambios a las
personalizaciones, si un desarrollador determina un impacto muy grande en una
personalizacin ya hecha, se deben tomar las medidas correspondientes para no
76

atrasar el cronograma en general, si la personalizacin de todos modos todava

no ha sido realizada se debe medir el impacto y como afecta el cronograma de
actividades.
En la fase 4(Preparacin Final), se supervisa que las entregas de los desarrollos
sean satisfactorias, habiendo aprobado las pruebas unitarias, integrales y estn
listas para pasar a productivo.
En la fase 5(Salida en vivo), se supervisa que los desarrollos estn ejecutando
correctamente.
Desarrollador
Conocimientos y destrezas:
Alto nivel y destreza en ABAP (estructurado y orientado a objetos).
Conocimiento medio de los principales mdulos de SAP.
Actitud de promulga la comunicacin.
Ser capaz de trabajar en equipo.
Actividades:

En la fase 2 (Planos del negocio), como la cantidad de personalizaciones

usualmente en un proyecto es considerable, 1 o 2 desarrolladores deben
colaborar en la tarea de estimacin por puntos de funcin al desarrollador lder.

En la fase 3 (Realizacin), deben desarrollar las personalizaciones, llenando los

informes respectivos a los avances de estos.

En la fase 3, 4 y 5, deben analizar el impacto que se reporte de los cambios

hechos a las personalizaciones y notificar esto al desarrollador lder, que es el
encargado de dar el aval o tomar las medidas indicadas con respecto a la
peticin de cambio.

Funcional:
Conocimientos y destrezas:

Alto conocimiento del rea de negocio a tratar.

Alto nivel de conocimiento del mdulo a configurar.
Actitud de promulga la comunicacin.
Ser capaz de trabajar en equipo

77

Actividades:

En la fase 2 junto con el usuario lder deben hacer un levantamiento de los

procesos de la organizacin respectivos al mdulo a tratar y sus relaciones con
los otros procesos de la empresa.

En la fase 2 debe hacer un mapeo de los proceso de la organizacin a

programas de SAP ECC que cubran estas necesidades y ver las interrelaciones
con los otros mdulos de SAP ECC. Estos mapeos deben supervisados y
abalados por el usuario lder.

En la fase 2 una vez mapeados los procesos de la empresa a diferentes

programas de SAP ECC, quedan detectados exactamente que funcionalidades
de estos programas son requeridos por reglas del negocio y la plataforma
estndar no los cubre, justamente estas funcionalidades deben ser especificadas
para que los desarrolladores las realicen.

En la fase 3 ya deben empezar a realizar las configuraciones, y pruebas unitarias

e integrales de las personalizaciones.

En la fase 4, se terminan las pruebas. se hacen pruebas de estrs para evaluar

el comportamiento y se entrenan a los usuarios que capacitarn al resto del
personal que vaya a usar el sistema.

En la fase 3, 4 y 5 pueden existir solicitudes de cambios, estas deben ser

manifestadas y comunicadas al desarrollador que haya realizado el desarrollo, o
se le notifican al desarrollador lder.

En la fase 5, se hace un seguimiento del sistema en produccin y se afina el

sistema.

Usuario lder:
Conocimientos y destrezas:

Alto conocimiento del rea de negocio a tratar.

Actitud de promulga la comunicacin.
Ser capaz de trabajar en equipo.
Ser un facilitador para promulgar las nuevas funcionalidades de las herramientas
desarrolladas.

78

Actividades:

En la fase 2 junto con el funcional respectivo deben hacer un levantamiento de

los procesos de la organizacin respectivos al mdulo a tratar y sus relaciones
con los otros procesos de la empresa.

En la fase 2 debe supervisar que el mapeo de los procesos de la organizacin a

programas de SAP ECC llevado por el funcional, sea adecuado y cubra tambin
las interrelaciones de estos procesos con otros de la organizacin.

En la fase 2 una vez mapeados los procesos de la empresa a diferentes

programas de SAP ECC, quedan detectados exactamente que funcionalidades
de estos programas son requeridos por reglas del negocio y la plataforma
estndar no los cubre, justamente estas funcionalidades entre el funcional y el
usuario lder deben ser especificadas para que los desarrolladores las realicen.

En la fase 3 ya se debe empezar a realizar las configuraciones efectuadas por el

funcional y supervisadas por el usuario lder.

En la fase 3 cuando el desarrollador entrega las personalizaciones, el usuario

lder debe realizar las pruebas unitarias e integrales para garantizar y constatar
que se realizo lo que se estaba solicitando.

En la fase 4, se terminan las pruebas, y determina con que datos se hacen

pruebas de estrs para evaluar el comportamiento.

En la fase 3, 4 y 5 pueden existir solicitudes de cambios, estas deben ser

manifestadas y comunicadas al desarrollador que haya realizado el desarrollo, o
se le notifican al desarrollador lder.

En la fase 5, se hace un seguimiento del sistema en produccin y supervisa el

afinamiento del sistema.

79

15

4.2 Manejo de riesgos

El SEI (Software Engineering Institute) define al riesgo como la posibilidad de sufrir una
prdida [SEI, 2004] y a la Administracin de Riesgos como el proceso formal en el
que los factores de riesgos son sistemticamente identificados, evaluados y mitigados
El anlisis y gestin del riesgo son una serie de pasos que ayudan a un equipo de
software a comprender y manejar la incertidumbre. El primer paso es reconocer que en
el proyecto algo puede salir mal. A esto se le denomina identificacin del riesgo,
segundo paso consiste en determinar la probabilidad de que ocurrir y el dao que
causar si en efecto ocurre, el tercer paso es desarrollar un plan para gestionar
aquellos riesgos con gran probabilidad y alto impacto. El cuarto paso consiste en revisar
la evolucin constante del riego y finalmente tomar las medidas de control necesarias
para evitarlo o mitigarlo. Este trabajo lo realizan todos los involucrados en el proceso de
software

Ilustracin 21 Modelo de Administracin de Riesgos

16

Identificacin de riesgos
Va encaminado a especificar las amenazas al plan del proyecto, este es un proceso
iterativo ya que se pueden ir descubriendo nuevos riesgos a medida que el proyecto
va avanzando.

15

Fuente Pincipal: Pressman Roger S. Ingeniera de software Un enfoque prctico Sexta edicin . Cap gestin del riego Mxico;Mc

Graw Hill, 2006

16

Tomada del anteproyecto: Identificacin de riesgos de proyectos de

software en base a taxonomias Proyecto de maestria de Lic. Sebastin D. Maniasi ITBA UPM

80

Es un criterio proactivo que busca identificar posibles factores de riesgo y tomar

medidas de aseguramiento o planes de contingencia para contrarrestarlos a ellos y a
sus efectos.
Existen mtodos para identificar riesgos uno de ellos es el de crear una lista de
verificacin de riesgos.
Con esta lista podemos identificar riesgos y enfocarnos en algn subconjunto de
riesgos sean conocidos y predecibles.
Ejemplo:
Tamao del producto
Impacto del negocio
Caractersticas del cliente
Definicin del proceso
Entorno de desarrollo
Tecnologa que construir
Tamao y experiencia de la plantilla de personal
El gestor de proyectos da un primer paso para evitarlos cuando es posible y a
controlarlos cuando es necesario.
Se ha identificado dos tipos de riesgos:
Riesgos genricos: Amenaza potencial para el proyecto de software.
Riesgos especficos: Se los puede identificar teniendo un claro conocimiento de la
tecnologa, el personal.
Componentes y controladores del riesgo
Es otro criterio, en la que se identifica cuatro componentes a tener en cuenta para la
estimacin del riesgo en desarrollo de software y son:
Riesgo de desempeo: es el que me permite medir el grado de incertidumbre de
que el producto satisfaga los requisitos.
Riesgo de costo: me permite medir el grado de incertidumbre del presupuesto del
proyecto.
Riesgo de soporte: mide el grado de incertidumbre de que el SW resulte fcil de
corregir, adaptar y mejorar.
81

Riesgo de calendarizacin: me permite tener un grado de incertidumbre de que el

producto se entregue a tiempo.
Anlisis del riesgo
Lo que se intenta con la proyeccin del riesgo es hacer una medicin de los riesgos
en funcin de la probabilidad o posibilidad de que el riesgo sea real o llegara a
ocurrir y as como tambin las consecuencias que causara al momento de que
ocurriese el imprevisto
Para la proyeccin del riesgo se realizan cuatro pasos:
Establecer una escala que refleje la posibilidad percibida de un riesgo.
Definir las consecuencias del riesgo
Estimar el impacto del riesgo en el proyecto y el producto
Tener una exactitud general en la proyeccin del riesgo para as evitar
confusiones
Estos pasos nos van a permitir establecer prioridades.
Desarrollo de una tabla de riesgos
Ofrece al gestor de un proyecto una tcnica simple para la proyeccin de riesgos.
Con el fin de facilitar un plan RSGR que es un Plan de Reduccin, Supervisin y
gestin de riesgo se explicar como ingresar la informacin en la plantilla
Evaluacin de riesgos.xls. Ver anexo 1.
Riesgo: La construccin de esta tabla se comienza listando todos los riesgos sin
importar cun remotos sean.
Probabilidad: Es la probabilidad de ocurrencia de este riesgo y se clasifica en: Muy
baja, Baja, Medio, Alto y Muy alta
Impacto: Es la clasificacin que se le da al riesgo si llegar a pasar, indicando el
nivel de dao o traumatizmo que puede causar en el proyecto y se clasifica en: Muy
bajo, Bajo, Medio, Alto y Muy alto.
Valor probabilidad: Como su nombre lo indica, es el peso que se la da al campo
probabilidad.

82

Probabilidad
1. Muy baja
2. Baja
3. Medio
4. Alto
5. Muy alta

Valor
probabilidad
0,1
0,3
0,5
0,7
0,9

Tabla 5 probabilidad valor probabilidad

Nota: Como son probabilidades no puede drsele el valor de 1, ya que no sera una
probabilidad, si no un hecho.
Valor impacto: Es el peso que se le da al campo impacto.
Impacto
1. Muy bajo
2. Bajo
3. Medio
4. Alto
5. Muy alto

Valor impacto
1,5
3,5
5,5
7,5
9,5

Tabla 6 Impacto valor impacto

Impacto por probabilidad: Operacin matemtica, que consiste en multiplicar el

valor de la probabilidad por el valor del impacto.
Calificacin del riesgo: Indicador visual del riesgo, se clasifica en 3 colores:
Verde: Bajo riesgo
Amarillo: Mediano riesgo
Rojo: Alto riesgo.
Requiere mitigacin: Indicador (si/no), si la calificacin del riesgo est en verde o
amarillo el indicador estar en No, si el indicador del riesgo est en rojo el
indicador estar en Si.
Estrategia de reduccin: Descripcin, de la estrategia para mitigar el riesgo.

83

Actividades: Indicar paso a paso de las actividades a realizar para evitar o mitigar
el riesgo.
Frecuencia: Cada cuanto tiempo, se debe revisar el estado de este riesgo para
saber su estado actual.
Responsable: Encargado de revisar y controlar este riesgo.
Revisiones: Notas y fechas de las revisiones que se la ha dado al riesgo.
Estado: Estado del riesgo (abierto/cerrado).
Enfoque de los riesgos en la primera etapa ASAP (Preparacin del Proyecto)
La primera fase o etapa de ASAP es en la que se deben tomar decisiones con
respecto al diseo del proyecto:

Equipo de trabajo.
Tareas.
Recursos.
tiempo.
metodologa.

Cada una de estas actividades conlleva riesgos que deben ser analizados en esta
etapa, con el fin de garantizar las otras etapas.

Enfoque de los riesgos en la segunda etapa ASAP (Planos del Negocio)

La segunda fase o etapa de ASAP es en la que se deben tomar decisiones con
respecto a:

Definicin de Estructuras Organizativas.

Definicin de Procesos Funcionales.

Definicin de Datos Maestros.

Documento Plano de Negocios.

Esta etapa es de vital importancia, ya que se plasman los procesos de negocio de la

empresa y el mapeo de estos procesos hacia la plataforma SAP.
84

Justamente en esta etapa es en donde se descubren cuales son las personalizaciones.

Los riesgos de esta etapa deben ir enfocadas en estos aspectos.
Enfoque de los riesgos en la tercera etapa ASAP (Realizacin)
La tercera fase o etapa de ASAP es en la que se deben tomar decisiones con respecto
a:

Configuracin de los mdulos.

Interfaces con otros sistemas.

Conversiones.

Desarrollos (personalizaciones).

Especificaciones.

Estimaciones.

Seguimientos.

Cambios.

Nivel del personal

Es muy importante en esta etapa del desarrollo, se tengan los procesos muy bien
definidos y revisados de la fase anterior, para poder asegurar una correcta claridad en
las especificaciones de las personalizaciones.
Algunos riesgos en los desarrollos son:
Las especificaciones son lo suficientemente claras?
Las especificaciones tienen su estimacin correcta?
Qu pasa si hay cambio en las aplicaciones?
El nivel del personal es el adecuado para el proyecto?
Qu pasa ante un cambio en el negocio con respecto a los desarrollos?
Las mtricas para los desarrollos es la adecuada, si est dando los resultados
esperados?

85

17

4.3 Mtricas

Las mtricas de procesos de software son algo ms que una simple medida de algn
atributo del proceso de software; una mtrica es informacin que sirve para planificar,
predecir y evaluar el estado de un proyecto.
Cuando puedes medir lo que estas diciendo y expresarlo en nmeros, sabes algo
sobre ello; pero cuando no puedes medirlo, cuando no puedes expresarlo con nmeros,
tu conocimiento es escaso e insatisfactorio: puede ser el comienzo del conocimiento
pero en tus pensamientos, apenas ests avanzando hacia el escenario de la ciencia.
Lord Kelvin
La medicin se aplica al proceso de software con la finalidad de mejorarlo de manera
continua. La medicin se utiliza a lo largo de un proyecto como apoyo en la estimacin,
el control de la calidad, la valoracin de la productividad y el control del proyecto.
4.3.1 Necesidades de medida
Las necesidades de medida pueden ser diversas, desde medir el rendimiento de los
proyectos de una empresa, evaluar las inspecciones de cdigo hasta evaluar las
actividades de mejora del proceso software
La medida es una parte esencial para comprender que afecta a la calidad, oportunidad,
utilidad y funcionalidad y en la mejora de los procesos y productos software.
Para comprender como aplicar las mtricas del software, debemos comprender primero
qu significan las medidas y por qu las necesitamos.
Las medidas nos permiten cuantificar conceptos o atributos en orden a manipularlos y
aprender ms sobre ellos
4.3.1.1 Cules son los costes de no medir
Incapacidad para:

estimar/planificar de forma realista

determinar el progreso
evaluar la calidad
reconocer las oportunidades de mejora
reconocer mejoras

17

Fuente Pincipal: Pressman Roger S. Ingeniera de software Un enfoque prctico Sexta edicin . Cap gestin del riego Mxico;Mc
Graw Hill, 2006

86

4.3.1.2 Precauciones y Limitaciones

Medicin implica varios usuarios en diversos niveles por toda la organizacin.

Medicin no deber ser utilizada para evaluar prestaciones individuales; ms
bien deber servir como base para resolucin interactiva de aspectos del
proceso.
Dos programas no son iguales: consecuentemente comparacin directa de datos
de programas deber evitarse.
Evaluaciones basadas en medicin son solo tan buenas como la oportunidad,
consistencia y precisin de los datos de entrada.

4.3.2 Beneficios de las mtricas

Medicin por si misma no mejora el proceso, pero la visibilidad permite

profundizar en la planificacin, control, gestin y mejora.
o Datos histricos ayudan a predecir y planear
o Datos actuales frente a los planificados ayudan a comunicar el progreso y
soportan la toma de decisiones.
Anlisis de tendencias ayuda a enfocar sobre reas problema.
La supervisin de las actividades de mejora del proceso ayuda a identificar lo
que funciona y lo que no funciona
Calidad del producto mejorada.
Productividad del equipo de desarrollo incrementada.
Estimacin y planificacin del proyecto mejor.
Mejor gestin del proyecto.
Cultura de calidad de la compaa mejorada.
Satisfaccin del cliente mejorada.
Visibilidad del proceso software incrementada.

4.3.3 Pasos para realizar usar una mtrica

Establecer los objetivos de la medicin

Especificar medidas
Especificar procedimientos de recogida y almacenamiento
Especificar procedimientos de anlisis
Comunicar los resultados

Una de las mtricas ms utilizadas para estimar la duracin de un proyecto segn su

complejidad y extensin son los puntos de funcin.

87

4.3.4 Punto de funcin

El Punto Funcin es una medida del tamao de un sistema de software y del proyecto
que lo construye. Es una unidad de medida as como la hora lo es para medir el tiempo
o el kilmetro para medir la distancia. El Anlisis de Punto Funcin se basa en la teora
de que las funciones de una aplicacin son la mejor medida del tamao de un sistema.
El Punto Funcin mide el software mediante la cuantificacin de la funcionalidad que el
sistema le brinda al usuario basado fundamentalmente en el diseo lgico. Es
independiente del lenguaje de computacin, de la metodologa de desarrollo, de la
tecnologa utilizada y de la capacidad del equipo de trabajo para desarrollar la
aplicacin.
El Anlisis del Punto Funcin es un mtodo estndar de medicin de desarrollo de
software desde el punto de vista del usuario. Su objetivo es medir el software
basndose en la cuantificacin de la funcionalidad brindada al usuario partiendo
fundamentalmente de diseos lgicos. La cuenta de Punto Funcin para proyectos de
desarrollo mide las funcionalidades que se le proporcionan al usuario conjuntamente
con la primera instalacin del software producido cuando el proyecto es terminado.
En el mundo del Punto Funcin los sistemas son divididos en componentes. Los
primeros tres componentes son: Entradas (EI = External Input), Salidas (EO = External
output ) y Consultas (EQ = External Queries).
Cada una de estas transacciones acta sobre ficheros agregando, modificando,
eliminando, obteniendo o procesando informacin. Los otros dos componentes son los
ficheros o entidades del sistema, denominados Ficheros Lgicos Internos (ILF = Internal
Logical File) y Ficheros Lgicos Externos (ELF = External Logical File).

Frontera de la aplicacin
La frontera de la aplicacin indica el lmite entre el software que est siendo medido.
Frecuentemente los sistemas computacionales interactan con otros sistemas
computacionales y con usuarios o dispositivos.
Es crucial tener bien identificada la frontera de la aplicacin a ser medida para luego
recin enfocarse en la descomposicin de sus componentes. La frontera de la
aplicacin debe ser dibujada en funcin del punto de vista del usuario.
En resumen, la frontera marca el borde entre el proyecto o aplicacin a ser medido y las
aplicaciones externas o el dominio del usuario. Una vez establecida la frontera, los
componentes pueden ser clasificados y contados.
Acta como una membrana a travs de la cual los datos procesados por transacciones
(EI, EO, EQ) cruzan la frontera hacia adentro y/o hacia fuera de la aplicacin.

88

Determina los datos lgicos mantenidos por la aplicacin (ILF) as como por
consiguiente facilita la identificacin de cules datos lgicos son referenciados por la
aplicacin pero mantenidos por otro sistema (ELF).
Las siguientes reglas deben aplicarse para el establecimiento de la frontera:
1. La frontera es determinada basndose en el punto de vista del usuario. Se
focaliza en qu el usuario puede entender o describir.
2. La frontera entre aplicaciones relacionadas est basada en reas funcionales
separadas siempre desde el punto de vista del usuario y no en consideraciones
tcnicas.
3. La frontera establecida por una aplicacin existente que est siendo modificada
no se influencia por el alcance de la cuenta.
La localizacin de la frontera de la aplicacin entre el software que est siendo medido
y otras aplicaciones de software suele ser algo subjetivo y difcil de determinar dnde
una aplicacin termina y la otra comienza.
Es importante que la frontera de la aplicacin sea dibujada con cuidado dado que todo
aquel dato que atraviesa la frontera puede potencialmente ser incluido en el alcance de
la cuenta.
Mecanismo
Para cada uno de los 5 tipos de elementos (EI, EO, EQ, ILF y ELF), identificar aquellos
que surgen de los requerimientos o funcionalidades que proveer el sistema. Luego
analizar la complejidad de cada uno, que puede ser Alta, Media o Baja. Con estos
datos, y utilizando los pesos correspondientes a cada uno de los elementos
identificados es posible calcular el total de Puntos Funcin.
Ficheros Lgicos Internos (ILF)
Un ILF es un grupo de datos relacionados lgicamente o informacin de control
reconocida por el usuario y mantenida dentro de la frontera de la aplicacin. El objetivo
fundamental de un ILF es manejar los datos mantenidos a travs de uno o ms
procesos elementales (o acciones) de la aplicacin que est siendo contada.
Reglas para identificarlos:
1. El grupo de datos o informacin de control es un grupo de datos lgico
identificable por el usuario que cubre de manera completa requisitos especficos
de este.
2. El grupo de datos es mantenido dentro de los lmites de la aplicacin.
3. El grupo de datos es mantenido o modificado por medio de un proceso elemental
de la aplicacin.
89

4. El grupo de datos identificado no se ha contado como ELF de la aplicacin.

Ficheros Lgicos Externos (ELF)
Un ELF es un grupo de datos relacionados lgicamente o informacin de control
reconocida por el usuario y referenciada pero mantenida dentro de la frontera de otra
aplicacin. El objetivo principal de un ELF es manejar los datos referenciados mediante
uno o ms procesos elementales (o acciones) dentro de la frontera de la aplicacin
contada.
La principal diferencia entre un archivo lgico interno ILF y una interfase de archivo
externa ELF es que el ILF es mantenido dentro de la frontera de la aplicacin mientras
que el ELF es mantenido por otra aplicacin. El ELF es referenciado por la aplicacin
que se est contando pero no mantenido por ella.
Reglas para identificarlos:
1. El grupo de datos o informacin de control es un grupo de datos lgico
identificable por el usuario que cubre de manera completa requisitos especficos
de este.
2. El grupo de datos es referenciado y es externo a la aplicacin que est siendo
contada.
3. El grupo de datos no es mantenido por la aplicacin que est siendo contada.
4. El grupo de datos se ha contado como ILF en al menos otra aplicacin.
5. El grupo de datos identificado no ha sido contado como un ILF para la aplicacin.
Nota:
No relacionar un ILF o ELF con un archivo fsico, sino como una entidad. Si por ejemplo
se identifica la entidad factura, la misma probablemente se registre en dos archivos o
tablas: cabecera y detalles, sin embargo, estos dos archivos corresponden a una misma
entidad lgica por lo que se cuenta nicamente un ILF o ELF.
Entradas (EI)
Un EI es un proceso elemental o una accin que procesa datos o informacin de control
que vienen desde afuera de la frontera de la aplicacin hacia adentro. Los datos pueden
venir desde otra aplicacin o desde una pantalla de ingreso de datos. El objetivo
fundamental es mantener uno o ms archivos lgicos internos (o ILF de Internal Logical
File) y/o alterar el comportamiento del sistema.
Se aplican las siguientes reglas:
90

1. Los datos se reciben desde fuera de los lmites de la aplicacin.

2. Los datos mantienen un ILF a travs de un proceso elemental de la aplicacin.
3. El proceso es la unidad ms pequea de actividad que es significativa para el
negocio del usuario final.
4. El proceso es auto contenido y deja la aplicacin que est siendo contada en un
estado consistente.
5. El proceso identificado debe verificar alguna de estas reglas:
a. Su lgica de proceso es nica respecto de otras entradas externas de la
aplicacin.
b. Los elementos de datos identificados son distintos a los de las otras EI de
la aplicacin.
c. Los ficheros lgicos referenciados son diferentes
Salidas (EO)
Un EO es un proceso elemental o una accin que enva datos o informacin de control
hacia fuera de la frontera de la aplicacin. El objetivo fundamental es presentar
informacin al usuario a travs del procesamiento lgico de los datos o de la
informacin de control obtenida. El procesamiento lgico debe contener al menos una
frmula o clculo matemtico o crear datos derivados de los obtenidos. Un EO podra
mantener uno o ms ILF y/o alterar el comportamiento del sistema.
Se aplican las siguientes reglas:
1. El proceso enva datos informacin de control.
2. Los datos o informacin de control se envan a travs de un proceso elemental
de la aplicacin.
3. El proceso es la unidad ms pequea de actividad que es significativa para el
negocio del usuario final.
4. El proceso es auto contenido y deja a la aplicacin en un estado consistente.
5. El proceso identificado debe verificar alguna de estas reglas:
Su lgica de proceso es nica respecto de otras salidas externas de la
aplicacin.
Los elementos de datos identificados son distintos a los de otras EOs de la
aplicacin.
Los ficheros lgicos referenciados son distintos.
6. Debe cumplirse al menos una de las siguientes condiciones:
91

El proceso elemental contiene al menos una frmula matemtica o clculo.

El proceso crea datos derivados
El proceso que genera la salida mantiene algn ILF
El proceso que genera la salida altera el comportamiento del sistema.
7. La transferencia de datos a otras aplicaciones se cuenta como salidas
8. Los informes escritos y online se cuentan como salidas independientes.
9. Los grficos se cuentan como una salida cada uno.
Consultas (EQ)
El EQ es un proceso elemental o una accin que enva datos o informacin de control
hacia fuera de la frontera de la aplicacin. El objetivo principal de un EQ es presentar
informacin al usuario a travs de la mera obtencin del dato o de la informacin de
control. A diferencia del EO, el procesamiento lgico no debe contener ninguna frmula
o clculo matemtico, ni tampoco debe crear datos derivados de los obtenidos.
Por otra parte ningn ILF es mantenido mientras se procesa la accin de un EQ ni
tampoco el comportamiento del sistema se ve alterado.
Es una combinacin de entrada/salida que se obtiene de una bsqueda de datos, no
actualiza ficheros lgicos y no contiene datos derivados (aquellos que requieren un
proceso distinto a bsqueda, edicin o clasificacin).
Se aplican las siguientes reglas:

Una peticin entra dentro del lmite de la aplicacin.

Un resultado sale del lmite de la aplicacin

Hay recuperacin de datos

Los datos recuperados no contienen datos derivados.

El proceso lgico no contiene frmulas matemticas o clculos

El proceso que genera la consulta no mantiene ningn ILF ni altera el

comportamiento del sistema

La peticin de entrada y el resultado de salida juntos, hacen del proceso la

unidad de actividad ms pequea que es significativa para el negocio del usuario
final.

El proceso es auto contenido y deja a la aplicacin que est siendo contada en

un estado consistente.
92

El proceso no actualiza ILFs.

El proceso verifica alguna de estas dos reglas:

La lgica del proceso sobre la entrada y la salida es nica respecto a otras
consultas de la aplicacin
Los elementos de datos que forman la entrada y la salida son distintos a los de
las otras consultas de la aplicacin.
Los ficheros lgicos referenciados son distintos.

El proceso no actualiza ILFs.

El proceso verifica alguna de estas dos reglas:

La lgica del proceso sobre la entrada y la salida es nica respecto a otras
consultas de la aplicacin.
Los elementos de datos que forman la entrada y la salida son distintos a los de
las otras consultas de la aplicacin.
Los ficheros lgicos referenciados son distintos.

Puntos De Funcin sin ajustar (PFSA)

Los Punto Funcin sin ajustar refleja las especficas funcionalidades contabilizadas que
se le proporcionan al usuario por el proyecto o la Aplicacin. Las funcionalidades de
usuario especficas son evaluadas en trminos del Qu es lo que proporcionan y no en
el Cmo es proporcionado.
Cada punto de funcin sin ajustar debe drsele un valor de 0 a 5.
Valor
0
1
2
3
4
5

Significado del valor

Sin influencia, factor no presente
Influencia insignificante, muy baja
Influencia moderada o baja
Influencia media, normal
Influencia alta, significativa
Influencia muy alta, esencial

Tabla 7valores escala puntos de funcin sin ajustar

Los puntos de funcin sin ajustar son:

El sistema requiere respaldo y recuperacin confiables?
Se requieren comunicaciones de datos especializadas para transferir informacin a la
aplicacin, u obtenerla de ella?
Hay funciones distribuidas de procesamiento?
El desempeo es crtico?
El sistema se ejecutar en un entorno existente que tiene un uso pesado de
operaciones?
El sistema requiere entrada de datos en lnea?
93

La entrada de datos en lnea requiere que la transaccin de entrada se construya en

varias pantallas u operaciones?
Los ILF se actualizan en lnea?
Las entradas, las salidas, los archivos o las consultas son complejos?
Es complejo el procesamiento interno?
El cdigo diseado ser reutilizable?
Se incluye la conversin e instalacin en el diseo?
Est diseado para instalaciones mltiples en diferentes organizaciones?
La aplicacin est diseada para el cambio y para que el usuario lo use fcilmente?
Pasos para totalizar los puntos de funcin
Se toman los cinco elementos EI, EO, EQ, ILF y ELF, se discriminan sus
funcionalidades por el nivel de complejidad, se suman y se multiplican por su
ponderacin
Parmetro Complejidad Cantidad Ponderacin
EI
EO
EQ
ILF
ELF

Baja
Media
Alta
Baja
Media
Alta
Baja
Media
Alta
Baja
Media
Alta
Baja
Media
Alta

Total = cantidad *
ponderacin

3
4
6
4
5
7
3
4
6
7
10
15
5
7
10

Total
Tabla 8 totales por EI ,EO, EQ, ILF y ELF

Luego de esto se totalizan los puntos de funcin sin ajustar (PFSA).

Finalmente la formula para los puntos de funcin quedara as
Puntos de funcin = Total * [0.65 + (0.01 * PFS)]18

18

Instructivo para la cuenta de puntos de funcin [sitio en Internet], disponible en

http://www.dinacyt.gub.uy/pdt/files/6.2.5%20-%20puntosFuncion.pdf ltimo acceso: Noviembre 20 de 2007.

94

4.3.5 Mtricas de proyecto

Permiten que un gestor de proyecto de software:

Valore el estado de un proyecto en curso.

Rastree los riesgos potenciales.
Descubra rea de problemas antes que se vuelvan crticas.
Ajuste el flujo de trabajo o las tareas.
Evale la habilidad del equipo del proyecto para controlar la calidad del equipo
del proyecto para controlar la calidad de los productos de trabajo de software.

Plantilla para las mtricas del proyecto

Con el fin de llevar las mtricas del proyecto de una manera sencilla se puede
alimentar la siguiente tabla:
ID
proyecto

Titulo

Modulo

Prioridad

Orden
ejecucin

Fase del
proyecto

Estado

%de
avance

Complejidad

T
desarrollo

T real
desarrollo

Tabla 9 Datos bsicos para las mtricas del proyecto

La tabla de las mtricas del proyecto se debe alimentar de la tabla de las mtricas
llevada por cada desarrollador.
Con esta sencilla tabla podemos saber el estado actual de las personalizaciones del
proyecto y tomar medidas al respecto si se llegaran a necesitar.
Plantilla para las mtricas del programador
Para saber el estado y las actividades de cada personalizacin se deben llenar las
siguientes tablas
ID proyecto
Titulo
Descripcin
Prioridad
Modulo
Orden ejecucin
Fase del proyecto
Estado
% avance
Funcional
Complejidad
T desarrollo
Tabla 10 datos bsicos mtricas programador

95

ID Proyecto
Fecha
Labor realizada
Tabla 11 Actividades del desarrollador en una personalizacin

Estas tablas o formatos, nos ayudan a medir el rendimiento de cada desarrollador y el

estado de sus personalizaciones, a la vez que son la fuente alimentadora de las
mtricas del proyecto en general.
Como recomendacin, estas mtricas se deben llevar en formato electrnico en un
portal web de manera tal que las mtricas del proyecto se vallan llenando
automticamente, cuando los desarrolladores ingresen la informacin de sus
actividades. Varias empresas para esto usan Sharepoint Server y si es posible se
debera integrar con Project Server para tener unas mtricas y cronogramas ms
afinados.

Plantilla propuesta especificaciones

Con el fin de asegurar una especificacin funcional y tcnica adecuada, que de pie a
contratar una fbrica de software si fuese necesario y un efectivo control de cambios sin
traumatismo, se hace la siguiente propuesta. Ver anexo 2.

96

4.4 Pruebas
Con el fin de asegurar la calidad en el desarrollo realizado, se deben hacer varios tipos
de pruebas.
4.4.1 Pruebas del programador
A medida que se va realizando el cdigo del desarrollo, el programador puede ir
chequeando los segmentos de programa que va desarrollando.
Estas pruebas son a nivel de:

Funciones.
Clases.
Formularios.
Reportes.
Consultas SQL.
Segmentos de cdigo.
Ampliaciones ( user exit, customer exit, badis y frameworkde ampliaciones).
Jobs.

Para verificar que los tems del listado anterior, cumplan con las especificaciones
funcionales podemos ejecutar el debugger del sistema.
Con la base de datos adems de usar el debugger para saber si est cumpliendo con lo
requerido se puede usar el la transaccin ST05 saber que consultas se estn
ejecutando, en que parte del cdigo y tiempo de ejecucin.
Adems de verificar que el cdigo s cumple con las especificaciones dadas, se debe
verificar el programa realizado con el Code inspector ->transaccin SCI para
garantizar que el cdigo sea seguro y posea buenas prcticas de programacin que
garantice que no se est desperdiciando recursos por la forma de programar.
Adems se debe mirar el rendimiento de la aplicacin con respecto a los recursos que
utiliza, esto se hace en el men Utilidades -> Ms utilidades->Run time analysis.

97

Ilustracin 22 ingreso run time analysis

Ilustracin 23 Resultados grficos del runtime analysis

Nota:
Como punto de enfoque El programador debe centrarse en las especificaciones dadas,
para disear su programa y hacer las pruebas de una forma organizada.
Pre-condiciones:
Se debe tener un mnimo de datos de prueba, lo suficientemente robusto para poder
hacer todas las pruebas que se consideren necesarias en la realizacin de las pruebas.

98

Post_condiciones:
El desarrollo se ha probado con los datos y ha funcionado con el resultado esperado, en
caso contrario se hacen las correcciones del caso.
4.4.2 Pruebas unitarias
Son las pruebas realizadas, usualmente por el usuario lder, funcional de ese mdulo o
por defecto alguien que est con la responsabilidad del desarrollo.
Estas pruebas deben estar previamente diligenciadas en el formato de pruebas y son
las encargadas de verificar que el programa funcione correctamente y coexista con los
dems programas del modulo para el que fue desarrollado.

Ilustracin 24 Flujo de datos en pruebas unitarias

En las pruebas unitarias, los desarrollos estn en un sistema que est compuesto de
varios aplicativos y estos pertenecen a uno o varios procesos del negocio y a un
mdulo. Hay un flujo de datos que debe funcionar de forma correcta.
Pre-condiciones:
Se debe tener un mnimo de datos de prueba, lo suficientemente robusto para poder
hacer todas las pruebas que se consideren necesarias en la realizacin de las pruebas.
Post_condiciones:
El desarrollo se ha probado con los datos y ha funcionado con el resultado esperado y
se firma que las pruebas se han cumplido satisfactoriamente.
En caso de existir errores se debe diligenciar el reporte de errores y notificarle esto al
desarrollador.

4.4.3 Pruebas integrales

Son las pruebas realizadas, usualmente por los usuarios lderes, funcionales de los
mdulos o por defecto varias personas que estn con la responsabilidad
de los
desarrollos.
99

Estas pruebas deben estar previamente diligenciadas en el formato de pruebas y son

las encargadas de verificar que los programas funcionen correctamente como en las
pruebas unitarias y coexista con los dems programas que pertenecen a otros mdulos
del sitema.

Ilustracin 25 Flujo de datos en pruebas integrales

En las pruebas integrales, los desarrollos estn en un sistema que est compuesto de
varios aplicativos y usualmente entre estos aplicativos que pertenecen a uno o varios
procesos del negocio (mdulos del sistema). Hay un flujo de datos que debe funcionar
de forma correcta.
Pre-condiciones:
Se debe tener un mnimo de datos de prueba, lo suficientemente robusto para poder
hacer todas las pruebas que se consideren necesarias en la realizacin de las pruebas.
Post_condiciones:
El desarrollo se ha probado con los datos y ha funcionado con el resultado esperado y
se firma que las pruebas se han cumplido satisfactoriamente.
En caso de existir errores se debe diligenciar el reporte de errores y notificarle esto al
desarrollador.
Ingreso informacin formato de pruebas
Es un archivo en Excel Formato de pruebas.xls y consta bsicamente de 2 hojas, la
primera hoja Casos de prueba (CP) y la segunda hoja es la Bug tracker. Ver Anexo
3.

Hoja Casos de prueba

Es la hoja donde se guarda detalladamente todo lo concerniente a los casos de prueba
y consta de los siguientes campos:

Desarrollo ID: Identificador nico de desarrollo

ID CP: Identificador nico caso de prueba para ese desarrollo
100

Titulo CP: Ttulo caso de prueba

Propsito: Que va hacer este caso de prueba
Datos de Prueba
Pasos: paso a paso de cmo se ejecuta el paso de prueba
Notas y Preguntas:
Estado CP: Pas, Fall, No se pudo ejecutar y Eliminado
# Bug: Identificador nico de Bug para ese desarrollo
Estado Bug: Abiertos, Asignados, Solucionados, Disponible para pruebas,
Verificados, No Aplica, Duplicado, No Se Puede solucionary Prxima Version.

Con fines control se lleva el nmero y porcentaje de:

Total CP Creados
Total CP Ejecutados
Casos de prueba Pasaron
Casos de prueba Fallaron
Total CP eliminados
Hoja Bug tracker
Si se han encontrado errores en los casos de prueba, estos se registran en la hoja bug
tracker y consta de los siguientes campos:

# Bug: Identificador nico del bug para ese caso de prueba.

ID CP: Identificador nico caso de prueba para ese desarrollo.
Titulo: Titulo del bug.
Descripcion Bug:
Pasos reproduccion Bug: Paso a paso y con que datos se dio el error.
Descripcin sln: Descripcin de la solucin, cuando el desarrollador la
implemente.
Estado: Abiertos, Asignados, Solucionados, Disponible para pruebas,
Verificados, No Aplica, Duplicado , No Se Puede solucionar y Prxima Version
Fecha de Registro: Fecha en que se detecto el error.
Asignado a: Quien hizo la prueba
Fecha de asignacin: Fecha de asignacin de correccin del error.
Fecha posible solucin: Fecha aproximada de la correccin del error
Fecha de solucin: Fecha real de la correccin.
Responsable de solucin.

Con fines control se lleva el nmero y porcentaje de:

Abiertos
Asignados
Solucionados
Disponible para pruebas
Verificados
No Aplica
Duplicado
101

No Se Puede solucionar
Prxima versin

Nota: El estado de un error en Prxima versin nicamente se podr poner cuando

haya un consenso entre el usuario lder, funcional y desarrollador.
Calidad en las pruebas unitarias e integrales
Cuando se ingresen los datos en las plantillas de las pruebas unitarias e integrales se
debe realizar una revisin por pares, esto quiere decir que se escoge a alguien que est
en la capacidad de entender el problema y sea capaz de entender las plantillas de cmo
se deben hacer las pruebas unitarias e integrales, en caso de duda o error se debe
poner de una forma ms clara las ideas en estas pruebas.

102

4.5 Gestin del cambio

La Gestin del Cambio es una disciplina que apoya directamente el desarrollo y
mantenimiento del software, mediante la conservacin de la integridad del producto
antes y despus de su puesta en produccin.
El cambio es inevitable cuando se construye software, aumenta el grado de
confusin entre los ingenieros de software que trabajan en un proyecto. La confusin
surge cuando los cambios:

No se analizan antes de realizarlos,

No se registran antes de implementarlos,
No se reportan a quienes deben saberlo,
No se controlan de forma que mejore la calidad y reduzca el error.

Las principales razones para la realizacin de cambios en la infraestructura TI son:

Solucin de errores conocidos.

Desarrollo de nuevos servicios.
Mejora de los servicios existentes.
Imperativo legal.

Los pasos al realizar un cambio son:

RFC (Request for change): Cuando se va a realizar un cambio, se debe realizar una
peticin de cambio, esta obedece a:

Correccin de errores.
Innovacin y mejora en los servicios.
Cumplimiento de nuevas normativas legales.

Registro: La RFC debe quedar correctamente registrada, para poder hacer un

seguimiento completo al proceso de cambio, el registro debe incluir:

Identificador nico de la RFC.

Descripcin detallada del cambio y sus objetivos.
Estatus ( Aprobado, Rechazado, Aplazado ).

Clasificacin: En caso de ser aprobado el cambio se debe tener en cuenta:

Prioridad: Importancia del RFC, esto determinar el calendario del cambio

Categora: Impacto y dificultad de cambio, determinar la asignacin de recursos
y plazos previstos.
103

Urgencia: En ocasiones que el cambio no puede esperar debido a interrupciones en el

sistema, el cambio se debe aprobar inmediatamente
Planificacin: Una vez aprobado el cambio se debe realizar lo siguiente

Elaboracin de calendarios realistas de cambio.

Cumplimiento de los objetivos indicados.
Minimizacin de incidencias secundarias derivadas del cambio.

Roll-out: Aunque en la gestin de cambios no es la responsable directa, deber

coordinar y garantizar el entorno de desarrollo, pruebas e implementacin
Back out: Los planes del back out son imprescindibles para evitar interrupciones
graves del servicio: sus objetivos principales son:

Volver en el menor tiempo posible a la ltima configuracin estable anterior al

cambio.
Impedir que se pierdan datos e informacin valiosa durante los procesos de
implantacin del cambio.

Cierre:
Tras la implementacin se debe evaluar el cambio
Se cumplieron los objetivos previstos?
Cual es la percepcin de los clientes y usuarios?
Si la valoracin es positiva se termina de documentar y cerrar el cambio, en caso
contrario se llevan a cabo los planes de back out.

Ilustracin 26 Flujograma de una peticin de cambio

Los principales beneficios derivados de una correcta gestin del cambio son:

Se reduce el nmero de incidentes y problemas potencialmente asociados a todo

cambio.
Se puede retornar a configuraciones estables de manera sencilla y rpida en
caso de que el cambio tenga un impacto negativo en la estructura TI.
Se reduce el nmero de "back-outs" necesarios.
104

Los cambios son mejor aceptados y se evitan "tendencias inmovilistas".

Se evalan los verdaderos costes asociados al cambio y por lo tanto es ms
sencillo valorar el retorno real a la inversin.
Se desarrollan procedimientos de cambio estndar que permiten la rpida
actualizacin de sistemas no crticos.

La implementacin de una adecuada poltica de gestin de cambios tambin se

encuentra con algunas serias dificultades:

Los diferentes departamentos deben aceptar la autoridad de la Gestin de

Cambios sobre todo en lo que respecta al cambio, independientemente de que
este se realice para solucionar un problema, mejorar un servicio o adaptarse a
requisitos legales.
Los encargados de la Gestin de Cambios no conocen a fondo las actividades,
servicios, necesidades y estructura TI de la organizacin incapacitndoles para
desarrollar correctamente su actividad.
Los Gestores del Cambio no disponen de las herramientas adecuadas de
software para monitorizar y documentar adecuadamente el proceso.
No existe el compromiso suficiente de la direccin por implementar
rigurosamente los procesos asociados.
Se adoptan procedimientos excesivamente restrictivos que dificultan la mejora o
por el contrario el proceso de cambio se trivializa provocando una falta de
estabilidad necesaria para la calidad del servicio.19

Formato sugerido control de cambios: Ver ANEXO 4

19

Gestin del cambio con ITIL [sitio en Internet], disponible en

http://itil.osiatis.es/Curso_ITIL/Gestion_Servicios_TI/gestion_de_cambios/vision_general_gestion_de_cambios/vision_general_gestio
n_de_cambios.php ltimo acceso: Noviembre 20 de 2007.

105

4.6 Biblioteca de software

Los procesos de negocio en cada empresa tienen sus particularidades, cada una es
como una persona que posee sus individualidades.
As como cada empresa tiene sus procesos en particular, existen procesos de negocio
que son sumamente parecidos.
Los procesos que son ms similares en una empresa, son los que son impuestos por
ley como lo son facturacin, procesos contables e impuestos como ICA, Retencin en la
fuente, etc.
Con el fin de agilizar las personalizaciones, se debe poseer un repositorio de software
con el propsito de usar objetos altamente parametrizables y recortar tiempo
sustancialmente a los desarrollos. Esta idea no es nueva y usualmente cada
desarrollador de forma individual a medida que va pasando el tiempo y enfrenta nuevos
desarrollos van formando un repositorio de sus programas realizados, pero esto no trae
grandes aportes de manera colectiva si no nicamente individual, lo que no trae un
aporte interesante al proyecto. Por otro lado si usamos los conceptos de fbrica de
software los cuales nos hablan de programacin por componentes altamente
parametrizables tendramos beneficios muy buenos para los proyectos, ya no de forma
individual si no colectiva, porque estos componentes estaran a disposicin de todos los
integrantes del equipo de desarrollo.
La constitucin de esta biblioteca de software para hacerla viable, debe hacerse de
forma gradual si la empresa que provee los desarrolladores no tiene montado una
fbrica de software debe hacer lo siguiente:

Detectar que programas y funcionalidades a travs de la experiencia son los ms

comunes e ir almacenando estos cdigos en un repositorio comn de pblico acceso
para los miembros del equipo de desarrollo.

Los programas y funcionalidades ms comunes, se deben reescribir de forma

genrica para futuras utilizaciones de forma ms efectiva.

Tener un manejo de versiones y documentacin de los cdigos.

Para proveer una plataforma que soporte manejo de versiones y documentacin del
cdigo se sugiere el manejo de un CVS o de Share Point

Se sugiere que el repositorio este organizado por mdulo al que pertenece el cdigo
y tipo de objeto (reporte, dympro, funcin, clase, sapscript, smarfrom, etc).

Al principio esto requerira un esfuerzo adicional con respecto a lo que estamos

familiarizados en las implantaciones actuales, pero nos brindara grandes ahorros de
tiempo a futuro.
106

A modo de consejo y hacer los componentes de software ms reutilizables se aconseja

concientizar a los desarrolladores en una mejor utilizacin de los objetos en la
plataforma SAP .

107

SAP SOLUTION MANAGER

El sap Solution Manager es una herramienta que da soporte a travs de todo el ciclo de
vida desde el blue print hasta la configuracin del sistema en produccin. Provee un
acceso central a las herramientas, mtodos y contenidos preconfigurados los cuales se
pueden usar durante la evaluacin, implementacin y procesamiento operacional del
sistema en productivo.

Algunas caractersticas
Implentacin y actualizaciones de soluciones SAP
Acceso central a todas las herramientas del proyecto
Administracin del proyecto
Blue print del negocio
Configuracin
Pruebas
Gestin central de toda informacin del proyecto
1 Ruta del proyecto
2 Estado del sistema
3 Documentacin del proyecto
Comparacin y sincronizacin de diferentes componentes SAP
Solucin de monitoreo
Administracin central del systema
Anisis del sistema con servicio de reportes
Monitoreo en tiempo real del sistema
Monitoreo del proceso del negocio.

Servicio de ayuda
Soporte de soluciones usando workflow para solucionar y procesar los mensajes de
problemas.
Gestin del cambio
Manejo de peticiones de cambio, usando workflow para poder tener un rastreo y auditar
los cambios y transportes en el sistema.

108

Ilustracin 27 Sap solution manager

El Sap Solution Manager es un set de herramientas, servicios y documentacin que

garantizan el desarrollo completo de una implementacin con SAP, si la organizacin
posee la infraestructura para montarlo, es lo ideal al no tener que instalar un conjunto
de componentes de software heterogneo que no necesariamente garantizan una
solucin integral que si nos da el Solution Manager.

109

4.7 Calidad
4.7.1 Que es la calidad del software?
La calidad del software es el conjunto de cualidades que lo caracterizan y que
determinan su utilidad y existencia. La calidad es sinnimo de eficiencia, flexibilidad,
correccin, confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e
integridad.
La calidad del software es medible y vara de un sistema a otro o de un programa a
otro. Un software elaborado para el control de naves espaciales debe ser confiable al
nivel de "cero fallas"; un software hecho para ejecutarse una sola vez no requiere el
mismo nivel de calidad; mientras que un producto de software para ser explotado
durante un largo perodo (10 aos o ms), necesita ser confiable, mantenible y flexible
para disminuir los costos de mantenimiento y perfeccionamiento durante el tiempo de
explotacin.
La calidad del software puede medirse despus de elaborado el producto. Pero esto
puede resultar muy costoso si se detectan problemas deriva dos de imperfecciones en
el diseo, por lo que es imprescindible tener en cuenta tanto la obtencin de la calidad
como su control durante todas las etapas del ciclo de vida del software.
4.7.2 Aseguramiento de la calidad
Para garantizar la calidad, en la metodologa ASAP, se deben verificar absolutamente
todos los entregables respectivos a cada etapa.
Bsicamente hay 6 actividades de mucha importancia y estas son:

Levantamiento de los procesos de negocio de la organizacin.

Mapeo de los procesos de la organizacin al mundo SAP (blue prints).
Especificaciones de las personalizaciones.
Manejo de riesgos.
Control de cambios.
Mtricas del proyecto.

Levantamiento de los procesos de negocio de la organizacin:

Dependiendo del tamao del proceso, intervienen un nmero de personas en este. Es
prcticamente imposible que una persona contenga todo el conocimiento del proceso
de un rea de la empresa, para evitar que se presenten visiones no completas, este
levantamiento se hace en conjunto y el documento (entregable) que sale de este
proceso es tambin revisado en conjunto.
110

Mapeo de los procesos de la organizacin al mundo SAP (blue prints):

Cuando est listo el mapa de procesos de la organizacin, el funcional del mdulo
correspondiente a esos procesos, procede a especificar los blue prints. Estos blue
prints, son revisados por el usuario lder para garantizar que si cubran todas las
funcionalidades expresado en el mapa de procesos de la organizacin.
Especificaciones de las personalizaciones:
Las especificaciones de las personalizaciones son realizadas, por el funcional y el
usuario lder. Una vez hechas las especificaciones estas deben ser revisadas por un
desarrollador, ya que deben ser los suficientemente claras para que cualquier
desarrollador las pueda realizar, en caso tal que se presenten inconsistencias el
desarrollador le indica al usuario lder y al funcional las partes por clarificar.
La claridad de las personalizaciones es muy importante, porque es una herramienta
para que a la hora de realizar el desarrollo se haga de una forma ms gil y en caso tal
que se requiriera contratar a personal externo o interno extra, los desarrollos se hagan
de mejor manera.
Control de cambios:
Se lleva a cabo, la misma gestin de calidad que en las personalizaciones.
Manejo de riesgos:
Peridicamente el desarrollador lder, revisar el estado del entregable de manejo de
riesgos, concerniente a la parte de las personalizaciones, quien es el responsable de
velar por determinado riego y su estado actual. Esto lo puede hacer a manera personal
mediante una entrevista a la persona encargada de determinado riesgo (siempre y
cuando en la organizacin exista una cultura de responsabilidad muy grande) o en su
defecto de manera escrita.
Si el riesgo no est siendo bien manejado, el desarrollador lder tomar las medidas
correspondientes segn el caso.

Mtricas del proyecto:

Peridicamente, el desarrollador lder mira el avance individual de su equipo de
desarrollo basndose en los reportes de avance del desarrollador, para saber en
general como va el proyecto en general y los ajustes que deben realizar para cumplir
los objetivos del cronograma. As mismo
el entregable del estado de las
personalizaciones en general es revisado por el gerente del proyecto y este segn ese
informe tomar las medicas correspondiente para que el proyecto siga segn lo
estipulado.
111

Estndares y buenas costumbres de programacin:

Con el fin de hacer programas altamente mantenibles en el tiempo, las
personalizaciones se deben regir por un estndar en el nombramiento de todos los
objetos necesarios para el desarrollo de las aplicaciones. Pero no basta con slo sto,
tambin se deben tener buenas prcticas de programacin para poder garantizar el
perfomance de las personalizaciones.
Para poder garantizar sto, se debe tener el compromiso del equipo desarrollador y
peridicamente se hara una verificacin por pares, para garantizar que se est
llevando a cabo efectivamente.

112

4.8 ESTNDARES DE DESARROLLO

Introduccin
Este documento define todos los estndares y guas necesitadas para el desarrollo de
programas en el ambiente SAP ECC. Contiene los lineamientos generales que permiten
manejar el mismo idioma entre los desarrolladores y entregar productos de buena
calidad.
4.8.1 Convenciones para Nombres de Objetos
Restricciones para modificacin de objetos estndar SAP ECC
Ampliaciones y Parametrizacin: antes de pensar en una modificacin al sistema
estndar, se debe pensar en la posibilidad de implementar una ampliacin, de igual
forma una ampliacin debe ser considerada nicamente cuando se comprueba que la
funcionalidad requerida no es posible hacerla por parametrizacin o por alguna
herramienta funcional.
Copias a objetos estndar SAP ECC: antes de pensar en una modificacin al sistema
estndar, se debe considerar la posibilidad de hacer una copia del programa estndar
en un programa Z o Y al cual se le puedan aplicar los cambios requeridos.
Modificaciones a objetos estndar SAP ECC: segn poltica SAP, ningn programa
estndar debe ser modificado. Esto solo es posible hacerlo cuando es recomendado en
una nota OSS o se llega a la conclusin de que el cambio no puede ser hecho usando
alguna herramienta que provea el sistema y adems sea crtico para el negocio. En este
caso se deber conseguir una aprobacin formal por parte de los gerentes de sistemas
de la compaa y documentar los cambios como sea pertinente.
Convenciones para Nombres de Objetos ABAP
SAP ha reservado rangos especiales para los nombres de los objetos no estndar.
Estos nombres aseguran que sus objetos no sern reemplazados o borrados cuando
SAP haga un mantenimiento o una actualizacin del sistema. Todos los objetos creados
en el sistema deben tener en su primer carcter la letra Z Y para pruebas.
El primer identificador que se debe definir para un programa ABAP es el Identificador
de Aplicacin (AA) que indica quien es el mdulo dueo del objeto. Algunos de los
valores son los siguientes:
CO
FI
MM
PP
SD

Control (Controlling)
Finanzas (Finance)
Materiales (Material Management)
Produccin (Production Planning)
Ventas (Sales and Distribution)
113

WM
BW
SE
CX
PS

Manejo de Bodegas (Warehouse Management)

Business Warehouse
SEM - Manejo Estratgico (Strategic Enterprise
Management)
Varias aplicaciones (Cross Application)
Sistema de proyectos
Tabla 12 Algunos mdulos de SAP ECC

No estn incluidos todos los identificadores posibles de mdulos o aplicaciones SAP

ECC, por lo tanto si se necesita un nuevo identificador ste debe ser incluido por el lder
de desarrollo o encargado de soporte del sistema
El segundo identificador es el Tipo de Desarrollo (TT) que indica la funcin tcnica del
objeto, es decir que hace el objeto dentro del sistema: es un reporte, una interface entre
dos sistemas, etc.:
RE
IE
IS
CO
ME
FS
FF
IN
GE

Reporte
Interface de Entrada
Interface de Salida
Conversin de Datos
Mejora o Enhancement
Formulario SapScript
Formulario SmartForm
Include
Propsito General
Tabla 13 Tipos de desarrollo en las personalizaciones

El tercer componente es un Nmero Consecutivo (nnnn) de 4 dgitos que se usa para

distinguir entre los objetos que tienen los primeros componenentes iguales. Este
consecutivo debe ser manejando por mdulo.

Nomenclatura para Programas (TT)

Los programas tipo report pueden usarse para el desarrollo de todo tipo de objetos
como interfaces, mejoras o reportes. El tipo Report / OnLine solo describe el tipo
programa desde el punto de vista del workbench
En el caso que un desarrollador haga una copia de un programa estndar de SAP ECC
para ser usado como base, se debe usar el estndar de nombre que se define en esta
seccin.
Formato de Nombre: el mximo permitido por SAP son 128 caracteres.
Para crear objetos nuevos, SAP requiere que estos comiencen con las letras Z o Y, y
en nuestro caso usaremos la letra Z para objetos formales. El formato de nombre se
define de la siguiente manera:
114

ZAATTnnnn
Para programas de prueba que no sern transportados al ambiente de produccin, se
usar el prefijo YP_xxxxxxxxx como nombre de programa. Estos programas debern
ser creados como objetos locales y no deben ser asociados a rdenes de transporte
(Change Request)
Ejemplos:
ZMMIE0001: interface de Entrada.
ZFICO0002: conversin de Datos del modulo de Finanzas
ZSDFS0001: formulario tipo SapScript del mdulo de Ventas
YP_EJEMPLO: programa de prueba
Restricciones: son las mismas especificadas en la seccin 2.1
Navegacin: Menu SAP Herramientas Workbench ABAP Desarrollo SE38 Editor ABAP

Nomenclatura para Includes (TT)

Los includes son tipos de programas que permiten la organizacin y modularizacin de
las lneas de cdigo dentro de los desarrollos. Se recomienda su uso nicamente si el
programa sobrepasa las 1000 lneas de cdigo. El tipo de include se identifica con la
letra I y puede tener las siguientes variaciones:
T
F
E
X

Variables y tipos de datos

Rutinas y subrutinas
Eventos
Otros
Tabla 14 Tipos de Include

Formato de Nombre: el mximo permitido por SAP son 128 caracteres, sin embargo
para tener una mejor armona entre los nombres usaremos solamente 11 caracteres.
Esta sintaxis aplica para programas propios, en el caso de las sustituciones, se deber
mantener el nombre del include original.
El formato de nombre se define de la siguiente manera:
ZAATTnnnnI
Ejemplos:
ZMMIEPKM0001T: variables para la interface de Entrada proveniente del sistema
PKMS
ZFICO0002F: rutinas para la conversin de Datos del modulo de Finanzas

115

Navegacin: Menu SAP Herramientas Workbench ABAP Desarrollo SE38 Editor ABAP
Los datos claves al momento de crear un programa son: ttulo, tipo (programa
ejecutable) y posteriormente asociar a una clase de desarrollo
Nomenclatura para Programas (Tipo Module Pool y Dynpros)
Un module pool es un tipo de programa ABAP revisa y procesa las entradas del usuario
durante una transaccin. Este tipo de programas estn compuestos por un conjunto de
INCLUDEs. La mayor parte de SAP ECC esta construido con este tipo de programas,
por ejemplo la creacin de un material usando la transaccin MM01 usa un programa
tipo module pool con un conjunto de pantallas y funcionalidades.
Formato de Nombre: el mximo permitido por SAP son 10 caracteres en el siguiente
formato:
SAPMZAAnnn
SAPMZ es un prefijo estndar definido por SAP y que es obligatorio.
Las pantallas en SAP son conocidas como DYNPROS (Dynamic Programs) y su
identificacin consta de un programa ABAP ms un nmero de 4 dgitos. El rango de
nmeros reservados para pantallas desarrolladas y que estn anexas a un programa
estndar de SAP va del 9500 al 9999 (con incremento de uno en uno). Para pantallas
anexas a programas desarrollados, el rango reservado es del 0001 al 0999 y del 9500
al 9999 (con incremento de 10 en 10). Por estandarizacin se manejaran la numeracin
de las pantallas comenzando desde la 0100.
Como fue dicho en el principio de esta seccin un programa module pool esta
compuesto por varios includes que cumplen diferentes funciones. El desarrollador no
tiene que preocuparse por los nombres de estos includes pues SAP los crea basados
en el nombre inicial dado al programa.
Ejemplos:
SAPMZCO001: programa principal creado por el usuario
MZCO001TOP: include creado por SAP para las declaraciones de datos
MZCO001O10: include creado por SAP para los mdulos PBO (se incrementa de 10 en
10)
MZCO001I10: include creado por SAP para los mdulos PAI (Se incrementa de 10 en
10)
MZCO001F10: include creado por SAP para las subrutinas (Se incrementa de 10 en 10)
MZCO001H10: include creado por SAP para los mdulos POH (Se incrementa de 10 en
10)
MZCO001V10: include creado por SAP para los mdulos POV (Se incrementa de 10 en
10)
116

Pantallas: 0100, 0110 y 0120

Restricciones: se debe tener en cuenta que la generacin automtica de los nombres
solo es exitosa si el programa principal fue creado siguiendo el estndar de nombre
previamente definido. Recuerde que otros objetos dependen del nombre de programa
que se crea: las pantallas o dynpros, los elementos de texto, la documentacin, los
mens y los ttulos entre otros.
Navegacin: Menu SAP Herramientas Workbench ABAP Resumen SE80 Object Navegator
Nomenclatura para Grupos de Funcin
Un grupo de funcin es un objeto que concentra uno o ms mdulos de funcin que
tiene algo en comn para compartir.
Formato de Nombre: la mxima longitud para un grupo de funciones es de 26
caracteres, sin embargo para propsitos de estandarizacin solo usaremos 6
caracteres. El formato es el siguiente:
ZAAnnn
Donde AA es el cdigo de la aplicacin y nnn es un nmero consecutivo. La creacin de
un grupo de funciones resulta en la generacin automtica de un programa llamado
SAPLZAAnnn, donde ZAAnnn es el nombre del grupo de funciones.
Ejemplos:
ZFI001: grupo de funciones para conversiones de Controlling (CO)
ZMM002: grupo de funciones para reportes de Materiales (MM)
Navegacin: Menu SAP Herramientas Workbench ABAP Desarrollo SE37 Biblioteca de Funciones

117

Ilustracin 28 Ingreso Biblioteca de funciones

Una vez en la pantalla de biblioteca de funciones, se busca la opcin de crear grupo por
el men principal: Pasar a Gestin gr. funciones Crear Grupo

Ilustracin 29 Creacin grupo de funciones

Nomenclatura para Mdulos de Funcin

Un mdulo de funcin es un programa escrito en ABAP que conforma una unidad lgica
y que permite ser usado para diferentes propsitos en diferentes programas. Son una
forma de modularizar la programacin que comnmente se conocen nicamente como
Funciones.
118

Formato de Nombre: la mxima longitud para un modulo de funciones es de 30

caracteres, de los cuales los primeros 5 Z_AA_ estn reservados, los restante 25
puedes ser usados libremente. El formato es el siguiente:
Z_AA_xxxxxxxxxxxxxxxxxxxxxxxxx
Donde AA es el cdigo de la aplicacin y xxxxxx est abierto para caracteres
alfanumricos y especiales
Ejemplos:
Z_SD_CONSULTAR_PROVEEDOR
Z_CX_CONVERTIR_FECHA_PROVEEDOR
Restricciones: los mdulos de funcin son programas que adems de poder ser
llamados desde los programas ABAP, pueden ser llamados desde otras aplicaciones a
travs del sistema operativo usando remote function calls (RFC). Un modulo de
funcin solo puede pertenecer a un grupo de funciones, pero un grupo de funciones
puede tener n mdulos de funcin.
Navegacin: Menu SAP Herramientas Workbench ABAP Desarrollo SE37 Biblioteca de Funciones
Nota: Debe documentarse el mdulo de funcin ya que es un componente reutilizable y
otros desarrolladores podran utilizarlo. Tambin deben documentarse los parmetros
de la funcin.
Nomenclatura para Cdigos de Transaccin
Las transacciones son el objeto ms comn dentro de la lgica SAP ECC. Todas las
funcionalidades del sistema poseen una transaccin para lograr ejecutar los programas
de una manera ms gil (MM01, F-02, etc.). La transaccin llama el programa
especificado para que el usuario pueda interactuar con la aplicacin. Existen 5 tipos de
transacciones que pueden ser creadas dependiendo de la necesidad:
Programa y Dynpro (transaccin de dilogo): usadas para programas tipo dynpro
o module pool
Programa e imagen de seleccin (transaccin de report): para objetos tipo report
Mtodo de una clase: para programacin orientada a objetos
Transaccin con variantes (transaccin de variante)
Transaccin con parmetros (transaccin de parmetros)
Formato de Nombre: la mxima longitud para transacciones es de 20 caracteres, para
el caso del proyecto solo usaremos 6. El formato es el siguiente:
119

ZAAnnn
Donde AA es el cdigo de la aplicacin y nnn es el nmero concecutivo para esa
aplicacin. La asignacin del concecutivo se hace revisando desde la transaccin SE93,
el concecutivo actual y sumando uno (1).
Ejemplos:
ZFI001: transaccin para un programa de finanzas
ZSD010: transaccin para un programa de ventas
Navegacin: Menu SAP Herramientas Workbench ABAP Desarrollo Otras
Herramientas SE93 - Transacciones

Ilustracin 30 Creacin de transacciones

120

Nomenclatura para Paquetes

Un paquete es un objeto utilizado para colocar juntos objetos de desarrollo que tienen
algo en comn y que son mutuamente dependientes uno del otro. El paquete es usada
para corregir y transportar estos objetos de desarrollo juntos como una unidad, por
ejemplo un programa que tiene tablas Z, transacciones y un modulo de funcin debe ser
condensado en una sola clase de desarrollo.
Formato de Nombre: se debe definir con un mximo de 3 caracteres de la siguiente
manera:
ZAA
Un ejemplo de los paquetes sera:
ZCO
ZFI
ZMM
ZPP
ZBW
ZSD

Control (Controlling)
Finanzas (Finance)
Materiales (Material Management)
Produccin (Production Planning)
Business Warehouse
Ventas (Sales and Distribution)
Manejo de Bodegas (Warehouse
ZWM
Management)
ZCX
Varias aplicaciones (Cross Application)
$TMP Para objetos locales (no transportables)
Tabla 15 Ejemplos de paquetes

Restricciones: los paquetes son previamente creadas por el coordinador de Basis y

ABAP, los desarrolladores NO tienen que crear nuevos paquetes. Los objetos que no
sern transportados a ambientes de calidad y produccin deben ser creados como
locales bajo la clase $TMP.

Nomenclatura para Variantes

Una variante es un conjunto de valores usados para la ejecucin de un programa. Estos
valores son colocados en los parmetros y posteriormente grabados como variante. Las
variantes tienen mltiples usos, sin embargo son comnmente usadas para ejecutar
programas ms rpidamente y para trabajar con los Jobs.

121

Formato de Nombre: se debe definir con un mximo de 10 caracteres de la siguiente

manera:
ZAAVSS_nnnn
Donde SS es el tipo de programa al que se le crea la variante:
IE
IS
RE
PE

Interface de Entrada
Interface de Salida
Reporte
Programa Estndar

Tabla 16 Tipo de programa al que se le crea la variante

Las variantes pueden ser transportadas como cualquier objeto del Workbench.
Ejemplos:
ZSDVR_0001, variante de reporte de SD
ZMMVP_0001, variante de programa estndar de MM
Navegacin: las variantes son creadas directamente en la ejecucin del programa o en
el editor de ABAP (SE38).
Nota: Los usuarios lderes y usuarios del sistema en productivo, son los que deben
conocer el estndar de nombramiento de las variantes, ya que son los que finalmente
las van a usar.
Nomenclatura para Jobs (Trabajos de Fondo)
Los trabajos de fondo o jobs permiten la ejecucin en fondo de programas (internos
SAP ECC o externos) ya sea por una vez o de manera repetitiva. Para crear un Job es
necesario definir los siguientes datos:

>
>
>
>

Descripcin del Job

>
>
>

Definir si el programa es externo o interno

Prioridad del Job (Job Class)

Servidor en el cual ser ejecutado el Job (en el caso de existir mas de uno)
Numero de pasos que tendr el Job. Un paso significa un programa a ejecutar.
o Nombre del programa
o Nombre de la variante
o Usuario autorizado
Cuando y que tan seguido se debe ejecutar el Job
Tambin se pueden definir dependencias entre Jobs

122

Formato de Nombre: se debe definir con un mximo de 9 caracteres de la siguiente

manera:
ZAASSFnnnn
Donde SS es el tipo de programa que se ejecutar con el Job.
Donde F es la frecuencia con que se debe ejecutar el Job:
H
D
S
M
C
A
N
Z

Cada Hora
Cada Da
Cada Semana
Cada Mes
Cada Trimestre (3 meses)
Cada Ao
Cuando se necesite
Otros

Tabla 17 Frecuencia de ejecucin de un JOB

Ejemplos:
ZFIRED0001, reporte de FI con ejecucin diaria
ZMMISM0001, interface de salida de MM con ejecucin mensual
Navegacin: Sistema Servicios Job Definicin Job (SM36)

Ilustracin 31 Ingreso definicin de Job

Nomenclatura para Clases e Interfaces/ Clases Proxy

Las clases son declaraciones o abstracciones de objetos, lo que significa, que una clase
es la definicin de un objeto. Cuando se programa un objeto y se definen sus
caractersticas y funcionalidades, realmente se programa una clase.

123

Formato de Nombre: la mxima longitud para una clase es de 30 caracteres, de los

cuales los primeros 5 ZCL_ estn reservados, los restantes pueden ser usados
libremente. El formato es el siguiente:
ZCL_AA_xxxxxxxxxxxxxxxxxxxxxxx
Donde AA es el cdigo de la aplicacin y xxxxxx est abierto para caracteres
alfanumricos y especiales.
Para clases de excepcin, se deber cambiar el prefijo ZCL por ZCX:
Ejemplos:
ZCL_SD_CALCULO_PRECIOS
ZCX_MM_MVTO_INVENTARIO
Para interfaces, se deber cambiar el prefijo ZCL por ZIF:
Ejemplos:
ZIF_SD_PRECIOS
ZIF_ INVENTARIO
Nomenclatura para Grupos de Puntos de Verificacin
Para simplificar el debugging y el anlisis de programas complejos, se pueden
implementar breakpoints y aserciones en programas que estn inactivos por defecto.
Para ello, los breakpoints y las aserciones se asignan a un grupo de puntos de
verificacin mediante el cual pueden ser activados en caso necesario. Las
parametrizaciones de activacin del grupo de puntos de verificacin se transfieren al
comando BREAK-POINT o ASSERT.
El nombre del grupo de puntos de verificacin deber comenzar con Z o Y, ya que debe
estar en el espacio de nombres del cliente.

Formato de Nombre: la mxima longitud para un grupo es de 30 caracteres. El formato

es el siguiente:
NOMBRE_PGM_BRKnn
Donde:
NOMBRE_PGM: Nombre del programa ABAP, o funcin que contiene los puntos de
verificacin.
BRK: Constante para indicar que es un grupo de Breakpoints.
124

nn: consecutivo
Ejemplo:
ZMMIE0001_BRK01: Grupo de Breakpoints 01 para el programa Interface de Entrada,
del modulo Materiales
ZFICO0002_BRK02: Grupo de Breakpoints 02 del programa de Conversin de Datos
del modulo de Finanzas

Nomenclatura para Vistas de Actualizacin y Cluster de Vistas

Al crearse vistas de actualizacin o mantenimiento para tablas o vistas del diccionario
de ABAP, el sistema nos solicita un grupo de funcin en donde se crearn los
programas, funciones y dynpros necesarias para el mantenimiento de dicha tabla.
Las vistas de actualizacin son programas que el sistema crea en el grupo de funcin
que le definamos al momento de su creacin. Debe indicarse mantenimiento en
pantalla sencilla en la mayora de los casos. Solo para casos en que el registro tiene
demasiados columnas (mas de 10), se puede realizar un mantenimiento en dos
dynpros.
Debe crearse un grupo de funcin para cada vista de actualizacin, es decir, en el
mismo grupo de funcin no pueden existir ms de una vista de actualizacin, esto con
el fin de minimizar los esfuerzos e inconvenientes durante el mantenimiento de las
aplicaciones.
Formato de Nombre: El nombre del grupo de funcin para la vista de actualizacin de
una tabla o vista, debe ser el mismo nombre de la tabla o vista:
NombreTabla o NombreVista
Ejemplos:
ZTFI0001: grupo de funciones para la vista de actualizacion de la tabla ZTFI0001
ZVMM0002: grupo de funciones para la vista de actualizacin de la vista ZVMM0002
Los cluster de vistas son la agrupacin de dos o ms vistas de mantenimiento con el fin
de centralizar el mantenimiento de tablas muy relacionadas (en lo posible relacionadas
con Foreign Key). Estos objetos son creados por la transaccin SE54.
Formato de Nombre: El nombre de las vistas cluster es el siguiente:
ZCVnnnn
125

Ejemplos:
ZCV0001: Cluster vista para tablas de la solucion de etiquetas
ZCV0002: Cluster vista para tablas de bancos
Nomenclatura para Proyectos de Ampliacin y Productos BTE
Para implementar ampliaciones al estndar de mySAP usando Customer Exit o User
exit , es necesario crear un proyecto de Ampliacin ( transaccin CMOD) que contenga
la ampliacin correspondiente de mySAP, la nomenclatura para este tipo de objeto es la
siguiente.

Formato de Nombre:
ZAAPnnnn
Donde AA es el cdigo de la aplicacin, P constante para indicar que es un Proyecto de
ampliacin, y nnnn es un nmero consecutivo para Proyectos de Ampliacin y otro
consecutivo para Productos BTE.
Ejemplos:
ZFIP01: Proyecto de ampliacin nmero uno del mdulo FI
ZMMP02: Proyecto de ampliacin nmero dos del mdulo MM
Para implementar ampliaciones por medio de BTE (Business Transaction Events), se
debe crear un Producto por la transaccin FIBF asocindole la o las BTEs que
requerimos implementar. La nomenclatura de nombre para el producto BTE es la
misma de Proyectos de ampliacin.

Nomenclatura para Proyectos LSMW

Como norma en el proyecto, todas las conversiones se realizarn por la herramienta
LSMW (Legacy System Migration Workbench), los objetos creados en esta herramienta
estn organizados jerrquicamente en proyecto, subproyecto y objeto de migracin.
Esta estructura permite la organizacin de las conversiones, agrupando los objetos por
mdulo, funcionalidad o proceso.
Los nombres definidos para cada uno de los item de la estructura del LSMW son los
siguientes:

126

Proyecto LSMW

Agrupa a todas las migraciones y conversiones del proyecto

Nombre: Nombre del proyecto
Descripcin: Migracin de Datos Nombre del proyecto
Este proyecto ser utilizado para las cargas por LSMW creadas por el equipo de
Desarrollo.

Subproyectos LSMW

Agrupa todas las conversiones de cada mdulo. Los subproyectos creados son los
siguientes:
CO
FI
MM
PP
SD
WM

Conversiones Mdulo CO
Conversiones Mdulo FI
Conversiones Mdulo MM
Conversiones Mdulo PP
Conversiones Mdulo SD
Conversiones Mdulo WM

Objetos LSMW

El objeto de conversin, el identificador de ese objeto es el mismo ID del requerimiento.

Y en la descripcin debe ir el titulo del requerimiento.
Formato de Nombre:
IDRequerimiento

NOTA: Generacin de Juego de Datos

Como regla, las conversiones de cualquier tipo (LSMW, Report, etc), debern generar
Juegos de Datos (Batch Input Session) para su ejecucin por la transaccin SM35. El
Juego de datos deber ser creado como hold, es decir, que no se elimine cuando sea
ejecutado, sino que permanezca para verificar su log y su informacin de carga,
adems el juego de datos deber tener el mismo nombre del objeto LSMW.
Nomenclatura para Implementacin de BADI
Si el desarrollo demanda la ampliacin de la funcionalidad estndar de mySAP por
medio de una BADI, se deber crear la implementacin de la BADI.
127

El nombre de la BADI implementada deber corresponder con la siguiente

nomenclatura:
Formato de Nombre:
ZAA_BADI_nn
Donde AA es el cdigo de la aplicacin, BADI es el nombre de la badi que se est
implementado, y nn es un nmero consecutivo. El mximo tamao para el nombre de
implementacin de una BADI es 20 caracteres, si el nombre da mayor de 20, se deber
recortar al nombre de la BADI.
Ejemplos:
ZFI_ACEPS_BAPIPRE_01: Implementacin 01 de la BADI
ACEPS_BAPIPREDOC_MOD, del mdulo FI
ZSD_BADI_SD_CM_02: Implementacin 02 de la BADI_SD_CM del mdulo SD

Nomenclatura para Formularios (SAPScript y SmartForms)

Los formularios son un tipo de desarrollo utilizado para la impresin de documentos
empresariales especiales (diferentes a reporte) y que en la mayora de los casos son
invocados automticamente desde programas estndar cuando se presenta una salida
de un tipo de mensaje especfico.
Los formularios pueden ser implementados usando dos herramientas: SAPScript y
SmartForms. Smartforms es una herramienta ms nueva y ms completa que
SAPScript y los nuevos formularios diseados por SAP estn siendo diseados con
base en esta herramienta; sin embargo, en el estndar de SAP todava existen muchos
formularios estndar implementados en SAPScript y que deben seguir siendo
soportados.

Formato de Nombre: el mximo permitido por SAP son 128 caracteres, sin embargo
para tener una mejor armona entre los nombres usaremos solamente 10 caracteres.
Para crear objetos nuevos, SAP requiere que estos comiencen con las letras Z o Y, y
en nuestro caso usaremos la letra Z para objetos formales. El formato de nombre se
define de la siguiente manera:
Para los SapScript
ZAAFSnnn
Para los SmartForms
128

ZAAFFnnn

Ejemplos:
ZMMFS001 Formulario de Orden de Compra del modulo MM
Nota: Se hace una diferenciacin en los nombres de los SapScripts y los Smartforms,
para evitar malos entendidos ante la posibilidad de poner el mismo nombre a un
formulario hecho en SapScript y otro en Smartform.

129

4.8.2 Convenciones para Objetos de Diccionario de Datos

Tablas
Se recomienda que todas las tablas sean definidas como tablas transparentes, sin
embargo dependiendo de la problemtica que se tenga se debe analizar la posibilidad
de definir tablas pool o cluster. Se deben tener en cuenta las recomendaciones SAP
sobre el tipo de tabla a usar, tamao, si soporta memoria intermedia, entre otros.
Adems se deben usar en lo posible dominios y elementos de datos estndar SAP
ECC. Sino estos deben ser definidos segn los estndares que se vern en esta
seccin.
Formato de Nombre:
ZTAAnnnn
Donde AA es el cdigo de la aplicacin y T es una constante que indica que el objeto es
una Tabla. Los 4 caracteres nnnn son el identificador numrico consecutivo.
Ejemplos:
ZTFI0001: tabla transparente de FI
ZTCO0001: tabla transparente de CO
Navegacin: Menu SAP Herramientas Workbench ABAP Desarrollo SE11
Dictionary ABAP

Ilustracin 32 Ingreso Diccionario

Algunas tablas Z podrn tener Vista de Mantenimiento, de acuerdo al requerimiento de

la Especificacin funcional.
Vistas
Vistas son tablas transparentes que contienen datos de mltiples tablas, tal y como
trabaja el concepto de join.
130

Formato de Nombre:
ZVAAnnnn
Donde AA es el cdigo de la aplicacin y V es una constante que indica que el objeto es
una Vista. Los 4 caracteres nnnn son el identificador numrico consecutivo.

Ejemplos:
ZVMM0001: vista de MM
ZVSD0001: vista de SD
Navegacin: Menu SAP Herramientas Workbench ABAP Desarrollo SE11
Dictionary ABAP

Estructuras
Una estructura se define para ser usado como tipo de datos. No contiene datos y no se
define fsicamente en la base de datos. Sin embargo su construccin es muy similar a la
de una tabla, exceptuando los datos tcnicos e llaves. En lo posible se deben usar
dominios y elementos de datos estndar SAP ECC. Sino estos deben ser definidos
segn los estndares que se vern en esta seccin.
Formato de Nombre:
ZEAAnnnn
Donde AA es el cdigo de la aplicacin y E es una constante que indica que el objeto es
una Estructura. Los 4 caracteres nnnn son el identificador numrico consecutivo.
Ejemplos:
ZEFI0001: estructura de FI
ZESD0001: estructura de SD
Navegacin: Menu SAP Herramientas Workbench ABAP Desarrollo SE11
Dictionary ABAP

131

Dominios
Un dominio puede ser definido como los datos tcnicos de un campo en una tabla.
Contiene los datos que pueden ser asignados a ese valor, por ejemplo tipo carcter de
1. Tambin se pueden definir valores para ese campo, como X, Y y Z. Un dominio
puede ser usado en mltiples tablas y campos.
Formato de Nombre:
ZZxxxxxxxxxx
Donde xxxxxxxxxx es abierto y puede contener hasta 10 caracteres.

Ejemplos:
ZZTIPOTRANS: dominio para un campo tipo transporte (Carcter de 4)
ZZCOLOR: dominio para un campo cdigo de color (Carcter de 2)
Navegacin: Menu SAP Herramientas Workbench ABAP Desarrollo SE11
Dictionary ABAP
Elementos de Dato
Un elemento de dato o dominio semntico describe el papel que juega un dominio en
una tabla, llevando la informacin semntica o simplemente la descripcin
Formato de Nombre:
ZZxxxxxxxxxx
Donde xxxxxxxxxx es abierto y puede contener hasta 10 caracteres.
Ejemplos:
ZZTIPOTRANS: elemento de datos con descripcin Tipo de Transporte
ZZCOLOR: elemento de datos con descripcin Color de Producto
Restricciones: son las mismas especificadas en la seccin 2.1
Navegacin: Menu SAP Herramientas Workbench ABAP Desarrollo SE11
Dictionary ABAP
132

Nota: Todos los elementos de datos Z que se creen, debern tener etiquetas o labels y
documentacin que ser usada para la funcionalidad de F1.

Campos
Elemento principal de una tabla. Deben ser descriptivos y no exceder los 10 caracteres,
es formato abierto.
Formato de Nombre:
xxxxxxxxxx
Si son campos de append structure, deben tener el formato especial:

Formato de Nombre:
ZZxxxxxxxxxx
Debe coincidir con los nombres definidos para Elemento de Datos y Dominio.
Ejemplos:
Elemento de Dato: ZZTIPOTRANS
Campo: TIPOTRANS
Restricciones: no aplican restricciones especiales
Navegacin: Menu SAP Herramientas Workbench ABAP Desarrollo SE11
Dictionary ABAP
ndices
Los ndices son un elemento que acelera la bsqueda de informacin ya sea en una
tabla estndar o una tabla Z.
Formato de Nombre:
Znn
Donde nn es un nmero consecutivo dependiente de la tabla.
Ejemplos:
Tabla LIPS
133

Z01, para campo MATNR

Z02, para campo VGBEL
Restricciones: los ndices no son recomendados en todos los casos, un anlisis
detallado debe ser hecho previamente. La ayuda del equipo de Basis puede ser
requerida.
Navegacin: Menu SAP Herramientas Workbench ABAP Desarrollo SE11
Dictionary ABAP (Botn de ndices)

Ayudas o Search Help

Antiguamente conocidos como match codes los search help son objetos que proveen
una ayuda al momento de introducir un dato en un campo. Presionando F4 o el
triangulo al final del campo, el sistema muestra un grupo de opciones que limitan el
valor que puede ser digitado en el campo. El usuario se limita a dar doble click o Enter
en valor deseado.
Existen dos tipos de objetos de ayuda, elementales y colectivos. El elemental es el
concepto bsico del objeto, el cual provee informacin de ayuda para ser introducida en
un campo. Un search help se define con: mtodo de seleccin (como el objeto obtendr
el valor (de una tabla, una vista, etc.), la interface, es decir los parmetros que le darn
entrada de datos a la bsqueda y por ltimo el comportamiento en lnea del objeto. El
tipo colectivo se define como un conjunto de search help elementales donde el usuario
puede escoger varias alternativas que le ayuden a encontrar la informacin deseada.
Formato de Nombre:
ZHAAxxxxxx
Donde xxxxxxxxxx es abierto y puede contener hasta 26 caracteres. Generalmente
tiene correspondencia con el nombre de la tabla base de la cual extrae los datos.
Ejemplos:
ZHMMTIPOTRANS
Navegacin: Menu SAP Herramientas Workbench ABAP Desarrollo SE11
Dictionary ABAP
Table Types
Los tipos de tabla globales son utilizados para definir tipos globales de tabla interna, con
el fin de declarar data objects de tipo tabla interna en los programas ABAP. En el Tipo
134

Tabla se especifica internamente la llave y su tipo asi como la cantidad inicial y el tipo
de tabla interna (STANDARD, SORTED o HASHED).
Formato de Nombre:
ZTTAAnnnn
Donde AA es el cdigo de la aplicacin y TT es una constante que indica que el objeto
es un Tipo Tabla. Los 4 caracteres nnnn son el identificador numrico consecutivo.
Ejemplos:
ZTTMM0001: Tipo tabla interna para datos de MM
ZTTSD0001: Tipo tabla interna con datos de SD
Navegacin: Menu SAP Herramientas Workbench ABAP Desarrollo SE11
Dictionary ABAP
Objeto de Bloqueo
Los objetos de bloqueos son necesarios para realizar bloqueos lgicos a registros de
tablas de la base de datos. Estos bloqueos no realizan un bloqueo fsico a los registros,
por lo tanto se deber consultar si un registro o conjunto de registros estn siendo
bloqueados por otro usuario y otra aplicacin antes de intentar trabajar con l.
Para esto se generan dos mdulos de funcin automticamente al momento de activar
el objeto de bloqueo.
Formato de Nombre:
EZ_AAnn
Donde AA es el cdigo de la aplicacin y nn 2 dgitos para el consecutivo.

135

4.8.3 Convenciones Generales para Programacin en ABAP

El propsito de esta seccin es definir las guas generales y nomenclatura que se
usaran como lineamientos dentro del lenguaje de programacin ABAP, especialmente
para desarrollos tipo online o report. Ms adelante se definirn los lineamientos para
programacin en module pool (dynpros).

Atributos del Programa

Al crear un programa se deben definir los atributos generales para dicho programa.
Estos atributos son obligatorios y dan direccin al programa en funcin de su objetivo:
Tipo:
L: Reporte (ejecutable)
I: Include (no ejecutable)
M: Module Pool
V: Update report
Status:
Siempre usar K (Programa Cliente Productivo)
Aplicacin:
F: Finanzas
C: Costos
L: Logstica
S: Ventas
B: Basis
Aritmtica de Punto Fijo:
Se debe activar esta opcin a menos que solo se trabaje con nmeros enteros
Documentacin:
Todos los programas debern tener documentacin explicita a nivel del objeto, con el fin
que la descripcin, proposito, prerequisitos, etc, aparezcan cuando el usuario de clic
cuando ejecute el programa. Esta documentacin deber copiarse
sobre el icono
de la especificacin funcional y/o tcnica.

136

Variables y Tablas Internas

Las variables se definen principalmente con la sentencia Data, sin embargo tambin
pueden ser definidas como parmetros con la sentencia Parameters o Select Options.
Los siguientes tipos de variables sern diseccionados en esta seccin: constantes,
variables de trabajo, parmetros, select-options y rangos.
Se debe tener cuidado con el uso de los caracteres _ (guin bajo) y - (guin), el
guin bajo se usa para separar palabras de una misma variable, el guin se usa para
separar una tabla de sus campos y hacer referencia a ellos.
Variable
Tabla Interna
Estructura

Ambito + _ + Tipo +
_ + libre
Ej: G_E_CANTIDAD
G_TI_ + Libre
L_TI_ + Libre
G_ES_ + libre
L_ES_ + libre

Parmetro

PA_ + libre

Select-Option

SO_ + libre

Tipo Local

<G_FS_ + libre + >

<L_FS_ + libre + >
G_CTE_ + libre
L_CTE_ + libre
G_R_ + libre
L_R_ + libre
G_TP_ + libre
L_TP_ + libre

Ranges

RA_+ libre

Field Symbol
Constante
Variable de
referencia

Variables de propsito general. Ver los

tipos y mbito en el siguiente cuadro
Tablas Internas para guardar grupos de
datos (tipo registro)
Estructura para almacenar un solo registro
de datos
Variables para entrar datos antes de la
ejecucin programa. Permiten mximo 8
caracteres
Variables (tipo tabla interna) para entrar
datos de rango antes de la ejecucin del
programa. Permite mximo 8 caracteres
Variables tipo constante no pueden cambiar
durante la ejecucin de los programas
Variable de referencia a objetos de clases.
Tipo de datos global
Tipo de datos local
Variables (tipo tabla interna) para entrar
datos de. Permite mximo 8 caracteres

Tabla 18 Estandar en las definiciones

Los Tipos son los siguientes:

C
F
U
E
N
P

Carcter
Fecha
Punto Flotante
Entero
Texto Numrico
Nmero empaquetado
137

H
X
R

Hora
Byte (Hexa)
Rango
Tabla 19 tipo de datos

Los Ambitos son los siguientes:

L
G
I
A

Local
Global
Instancia
Argumento
Tabla 20 Ambito de los datos

Ejemplos:
Variable tipo fecha y mbito global:
G_F_FECHA_CREACION
Variable tipo carcter y mbito local:
L_C_PLANTA
Tipo de Datos Global:
G_TP_ORDEN
Parmetro:
PA_ARCHIVO
Select-Option:
SO_FECHA_COMPRA
Field Symbol local:
<L_FS_DOCUMENTO>
Constante local:
L_CTE_AE10
Tabla Interna global:
G_TI_CLIENTES_KNA1

138

Module Pool (Dynpros)

A continuacin se definen los estndares de nombres para los objetos propios de la
programacin en Module Pool y Dynpros:
Text Field
Group Box
Radio Button
Button
Sub-Screen
TabStrip
Table Control
GUI Status
GUI Title

TF_ + libre
GB_ + libre
RB_ + libre
BT_ + libre
SS_ + libre
TS_ + libre
TC_ + libre
GS_ + Numero consecutivo (4)
GT_ + Numero consecutivo (4)
Tabla 21 Estandares elementos Modul Pool y Dynpros

Parmetros en Rutinas y Funciones

Cuando se use modularizacin de cdigo con rutinas / subrutinas y mdulos de funcin,
los parmetros que se pasados deben tener una nomenclatura especial:
Rutinas Internas

Funciones

USING P + Tipo + _ + libre

CHANGING P + Tipo + _ + libre
TABLES P + Tipo + _ + libre
IMPORT I_ + libre
EXPORT E_ + libre
CHANGING C_ + libre
TABLES T_ + libre
Tabla 22 Paso de parametros

Ejemplos:
PERFORM calculo_precio USING g_e_cantidad
g_c_nombre

FORM calculo_precio USING p_e_cant type i

p_c_descrip type c.

ENDFORM.
El nombre de las rutinas y las funciones no tiene una nomenclatura especial. Solo
deben ser nombres explcitos que informen la funcin del objeto.
139

NOTA: Es requerido y obligatorio tipificar todos los parmetros de las subrutinas y los
mdulos de funcin.

Clases de Mensajes
Todos los mensajes utilizados en las aplicaciones del cliente, debern ser creados en
clases de mensajes Z, deber crearse una clase de mensaje por cada mdulo o
aplicacin del sistema. Los mensajes creados debern reutilizarse lo mximo posible
entre los diferentes desarrollos.
Formato de Nombre:
ZAAnn
Ejemplos:
ZMM01: Clase de Mensaje 01 para el mdulo MM
ZCO02: Clase de Mensaje 02 para el mdulo CO
Los tipos de mensaje son definidos en el apndice de Mensajes. La numeracin para
los mensajes tiene 3 caracteres numricos nicos por cada clase de mensaje nnn (del
000 al 999).
De ser necesario, se deber extender el texto del mensaje con una explicacin ms
completa, quitando la marca de Autoexplicable e ingresando la descripcin
correspondiente al mensaje.
Anexos:
Ver anexos del 5 al 8

4.8.4 Gua de Programacin ABAP

En esta seccin se definen las guas y reglas de programacin en cuanto a orden,
estructura, manejo de includes, entre otros.

Estructura del Programa

Todos los programas deben tener una estructura determinada (esqueleto) para guardar
la uniformidad y el orden.
140

Orden del Cdigo

Las principales reglas acerca del ordenamiento por secciones en un programa son las
siguientes:

>

El orden general del programa es el siguiente:

o Encabezado General del Programa
o Declaracin de Variables
Constantes
Tipos locales
Estructuras Tables
Estructuras
Tablas
Variables
Parmetros y Select-Options
Ranges.
o Eventos
o Subrutinas

>

Los eventos usados deben ser resaltados para que puedan ser fcilmente
identificables (START-OF-SELECTION, END-OF-SELECTION, etc.). Los
eventos no usados deben ser eliminados del programa.

>

Todas las subrutinas creadas (FORMs), deben ser ubicadas al final del programa
despus del evento END-OF-SELECTION, en la seccin SUBRUTINAS.

Comentarios
Los comentarios hacen parte de la documentacin de un programa haciendo ms fcil
la lectura e interpretacin de las lneas de cdigo que lo componen.
Los comentarios deben ser usados en las siguientes condiciones:

>
>
>
>

Antes de cada seccin de cdigo, ya sea grande o pequea

>

Al principio de cada subrutina o modulo de funcin para explicar el su propsito

Para clarificar lgica que sea compleja o confusa

Para modificar cdigo ya existente
Al principio de programa como encabezado general para explicar aspectos como
desarrollador, fecha, identificador, propsito, etc.

Formateo de Sentencias
El editor del lenguaje de programacin ABAP da la opcin de hacer un formateo de
sentencias automtico conocido como Pretty Printer (Shift-F1). Este hace cambios de
maysculas a minsculas y viceversa segn el caso, adems de organizar la
identificacin de las lneas de cdigo.
141

Manejo de Includes
Los includes son tipos de programas que permiten la organizacin y modularizacin de
las lneas de cdigo dentro de los desarrollos. Se recomienda su uso nicamente si el
programa sobrepasa las 1000 lneas de cdigo.
Mensajes
Todos los mensajes que arroja un programa deben ser manejados a travs de clases
de mensajes ya sea estndar o creadas por el programador. Para mayor informacin
ver el apndice E.
Formateo de Reportes
Las lneas en blanco dentro de un reporte deben ser creadas usando la sentencia SKIP
en lugar de usar la sentencia WRITE /. Los textos fijos deben ser creados usando
numeracin que hace que dichos textos sean lenguaje independiente, ejemplo:
WRITE: Nombre del Cliente (001).
El texto 001 debe ser definido como Nombre del Cliente (dando doble clic sobre el
nmero) y puede ser traducido a diferentes lenguajes segn sea la necesidad.
El formateo de reportes se reduce sustancialmente si se usa ALV (Abap List Viewer),
sin embargo esto depende del perfil de los desarrolladores, de su conocimiento de esta
herramienta, y del tipo de layout del reporte.
SQL Nativo
El lenguaje de programacin nos da la posibilidad de trabaja con SQL nativo, sin
embargo esto solo es recomendado bajo condiciones especiales. Contacte a su
coordinador del equipo de desarrollo antes de usar este tipo de instrucciones.
Subrutinas y Mdulos de Funcin
Cuando un programa usa una funcin, carga en memoria el grupo de funciones a la que
pertenece ocupando memoria del sistema en proporcin al tamao del grupo de
funciones. Por tal razn cuando se creen funciones nuevas se debe analizar si esta
debe o no incluirse en un grupo de funciones existente. Tambin se debe considerar la
creacin de includes.
142

El uso de variables locales en subrutinas es recomendado para evitar la creacin de

estas variables en la memoria global del programa y para que esta memoria se libere
cuando se finalice la ejecucin de la subrutina.
Como regla general, todas las subrutinas deben tener una declaracin de parmetros
de entrada y salida (interface) usando las instrucciones USING y CHANGING que
permiten el paso de parmetros desde y hacia la subrutina, asi como tipificarlos
completamente. Tambin debe especificarse si los parmetros son pasados por valor,
por referencia o por valor y resultado.
Objetos de Autorizacin
El uso de autorizaciones depende en su totalidad del programa que se est
desarrollando. La autorizacin ms comn es la que esta inherente a la ejecucin del
programa. Por ejemplo un reporte que muestra informacin no necesita autorizaciones
internas en el programa sino que se controla con el perfil asignado a nivel de
transaccin.
Frecuentemente los programas que necesitan manejo interno de autorizaciones son las
mejoras que pueden tener funcionalidades diferentes como Visualizar y Modificar, o
para restringir visualizacin de informacin. Para estos casos Authorization Check
deber ser implementado segn la necesidad.
El desarrollador deber ser el responsable de crear el objeto de autorizacin
correspondiente, con su definicin y campos de autorizacin si fueran requeridos; y
realizar el chequeo respectivo en el programa utilizando para ello la sentencia
AUTHORITY-CHECK.
El desarrollador deber informar el nuevo objeto de autorizacin para que los
administradores del sistema y seguridad creen las autorizaciones respectivas y las
asignen a los perfiles.
Objetos de Bloqueo
Los objetos de bloqueo deben ser usados cuando se requiera, especialmente cuando
se trata de tablas Z y objetos que no pueden ser compartidos por varios usuarios.
Tambin deber utilizarse los objetos de bloqueo del estndar en los casos que se
desee manipular objetos de negocio y se requiera de manera exclusiva.
Siempre el bloqueo debe ser usado a travs de las funciones Enqueue y Dequeue.
Seguimiento (Debugging)

143

Existen dos formas de detener los programas usando sentencias desde los mismos
programas, una de ellas es BREAK-POINT que detiene el programa sin importar que
usuario lo est ejecutando y activa el modo debugging. El segundo es BREAK
<usuario> que detiene el programa nicamente para el usuario <usuario>. En los dos
casos estas sentencias deben ser usadas temporalmente y se deben remover ANTES
de promover el programa a otros ambientes como calidad y produccin.
Otra posibilidad es crear grupos de puntos de verificacin BREAK-POINT ID XXXX, con
el fin de poder activar o desactivar los grupos en conjunto y de servir como herramienta
de pruebas. Estos tipos de puntos de verificacin no se necesitan remover del cdigo
fuente del programa, y podran pasarse a otros ambientes.
Con la transaccin SAAB se pueden activar los grupos de puntos de verificacin.
Usando la variable SY-SUBRC
La variable SY-SUBRC es un cdigo de retorno que permite saber si el proceso fue
exitoso o no. Siempre se debe leer y analizar esta variable (con un CASE o con un IF)
despus de sentencias como SELECT, OPEN, READ, TRANSFER, MODIFY, INSERT
o CALL TRANSACTION. Ejemplo:
SELECT * FROM BKPF
INTO TABLE t_bkpf.
IF sy-subrc <> 0.
WRITE No hay registros en la Base de Datos.
ENDIF.
Nota: en general hay muchas variables del sistema que pueden ser usadas.
Ver ANEXO 9.

Sentencia DATA
DATA nos permite definir espacios de memoria (variables), el complemento LIKE da la
posibilidad de definir variables usando variables ya existentes en la aplicacin. Esta
prctica es muy recomendada pues ahorra tiempo en el mantenimiento.

144

4.8.5 Gua de Eficiencia y Rendimiento

Existen algunas prcticas de programacin que hacen ms eficientes los programas y
mejoran el rendimiento de los mismos.
Acceso a la Base de Datos

Minimizar el trfico de la red

Se debe proveer el mximo nmero de criterios disponibles en el momento de hacer
una lectura a la base de datos, para esto se puede forzar al usuario a dar la mayor
cantidad de parmetros de entrada y select-options (obligatorios) en el programa que
ayuden a restringir las bsquedas y por consiguiente los valores de salida.
Se debe tratar de traer los datos en un solo bloque desde la base de datos y no hacer
accesos independientes cada vez que se necesite informacin.
Uso del NOT en WHERE
Evite el uso del NOT en la clusula SELECT WHERE. Es menos eficiente que usar una
lgica positiva.
Evitar el SELECT ENDSELECT
Este tipo de sentencia debe ser solo utilizada si el conjunto de registros a obtener de la
base de datos, debo procesarlos en un solo recorrido y no se necesitan posteriormente
en la aplicacin. Si esta es la situacin, el uso de SELECT-ENDSELECT es ms
recomendado que el uso Array fetch (uso de tabla interna), ya que evita consumo de
memoria interna del work process que est ejecutando el programa.
Recuerde que dentro de este bloque loop no se permiten las siguientes sentencias:
COMMIT WORK
ROLLBACK WORK
MESSAGE
Si requiere realizar este tipo de sentencias, deber realizar una carga de los registros a
una tabla interna y posteriormente recorrerla con un LOOP ENDLOOP.
Nota: Cuando se va a procesar un gran volumen de datos, se puede usar esta
sentencia ya que de otra forma el sistema cancela el proceso.

145

Order by vs SORT
Los datos que se traen de la base de datos pueden venir en cualquier orden, existe la
posibilidad de ordenarlos durante la ejecucin de la lectura usando el complemento
ORDER BY, sin embargo esto no es recomendado porque puede intensificar el
esfuerzo de la lectura. Se recomienda ordenar el contenido de la tabla interna despus
de la lectura usando un SORT.
Evitar el SELECT *
Usar el SELECT * significa que se traern a memoria todos los campos de la tabla por
lo tanto siempre se deben seleccionar las columnas que se necesitan de la(s) tabla(s)
en el mismo orden en que se encuentran definidas. Si una lectura trae el doble de
campos que son necesarios, la lectura demorar el doble de tiempo.
Uso del SELECT SINGLE
Al usar la sentencia SELECT intente proveer la mayor cantidad de campos clave a la
lectura. Si tiene todos los campos clave en su instruccin o si solo est interesado en un
solo registro de la tabla use un SELECT SINGLE.
Evitar SELECT anidados
El uso de instrucciones SELECT dentro de SELECT no es una prctica recomendable
en la lectura de tablas. Para suplir esto se tienen varias alternativas que mejoran el
rendimiento:
1. Buscar una vista en la base de datos que contenga la relacin de tablas que
se necesita
2. Usar un SELECT con el complemento JOIN o OUTER JOIN
3. Subir la informacin en instrucciones SELECT independientes a tablas
internas y despus hacer LOOPs anidados.
4. Se deben seleccionar las tablas o vistas por los campos claves.
Tablas Internas
Proceso registro a registro
Se debe usar la sentencia LOOP AT en lugar de DO. Esto porque el LOOP AT da la
posibilidad de colocar una clusula restrictiva WHERE Usar un CLEAR despus de
cada sentencia APPEND es recomendado para evitar inconsistencias.
Clusula OCCURS
La clusula OCCURS <n> debera apuntar cercanamente al nmero de registros que
contendr la tabla interna durante su utilizacin. Esto porque SAP ECC reserva el
espacio en memoria (roll area) en funcin del <n> nmero de filas. Si el nmero de
registros se incrementa, SAP ECC reservar un espacio igual en otro espacio de
146

memoria lo cual degradar el acceso durante la manipulacin de la tabla. Si usted no

est seguro de la cantidad de registros que contendr la tabla, use OCCURS 0 y SAP
ECC asignar dinmicamente el valor incrementando el espacio de 8k en 8k.
NOTA: Usar la nueva sintaxis de declaracin de tablas internas en vez de occurs.
Leyendo un registro sencillo
Al leer un registro sencillo de la tabla interna estndar, use la instruccin SORT para
ordenarla y posteriormente use la READ TABLE WITH KEY BINARY SEARCH. Si la
tabla tiene n entradas la bsqueda lineal toma O(n), mientras que la bsqueda binaria
toma O(log2(n)).
Ordenamiento
Siempre que se ordene una tabla interna se debe proveer el campo o los campos por
los cuales se quiere hacer el ordenamiento. SORT <tabla> <campo 1> <campo 2> es
ms eficiente que usar simplemente SORT <tabla>.
Nmero de Entradas
Para conocer el nmero de entradas de una tabla no es necesario hacer un recorrido de
la misma con un LOOP e incrementar una variable. Para esto se debe usar la sentencia
DESCRIBE TABLE <tabla> LINES <var>, la funcin LINES( ti ), o simplemente la
variable del sistema SY-TFILL.
Eliminado Entradas
Para eliminar entradas de una tabla, se debe usar la sentencia DELETE <tabla>
WHERE campo = <valor>. Como en el caso anterior, no es necesario el uso de
sentencias cclicas como el LOOP.
Copiando Tablas Internas
La forma ms eficiente de copiar el contenido de una tabla interna en otra tabla interna
es usando una asignacin directa [] de la siguiente manera tabla1[] = tabla2[]. No es
necesario usar LOOPs para recorrer las tablas.
LOOP WHERE vs LOOP CHECK
Se recomienda usar el WHERE en que es un complemento de LOOP en lugar de la
sentencia CHECK que debe ir dentro del LOOP. Esto evita una sentencia extra en la
lgica.
Se debe usar:
LOOP AT tabla WHERE campo = valor.

ENDLOOP
147

No se debe usar:
LOOP AT tabla.
CHECK campo = valor.

ENDLOOP.
Clusula INTO TABLE
1. Se debe usar la clusula INTO TABLE cuando se carga una tabla interna desde la
base de datos. Esto es ms eficiente que mover uno a uno los registros e insertarlos
usando APPEND:
Se debe usar:
SELECT * FROM LFA1 INTO TABLE T_LFA1.
No se debe usar:
SELECT * FROM LFA1.
MOVE LFA1 TO T_LFA1.
APPEND T_LFA1.
ENDSELECT.
2. Recuerde evitar el uso del SELECT / ENDSELECT, cuando sea posible use un INTO
TABLE para guardar la informacin:
Se debe usar:
SELECT * FROM LFA1 INTO TABLE T_LFA1.
LOOP AT T_LFA1.
WRITE: / T_LFA1-LIFNR.
ENDLOOP.
No se debe usar:
SELECT * FROM LFA1.
WRITE: / LFA1-LIFNR.
ENDSELECT.
Clusula Appending Table
En el caso de tener una segunda o ms consultas y retornar los mismos campos, se
puede usar esta instruccin y reducir el nmero de tablas internas a utilizar.

148

Ej:
SELECT campo1 campo2 campo 3
FROM TABLE1 APPENDING TABLE itab1
WHERE fld1 = AA.

Lgica
Uso de CHECK, STOP, EXIT y REJECT
Usar estas sentencias cuando se necesite suspender un proceso o saltar procesos
innecesarios. Esto mejora el rendimiento al no tener que ejecutar ciertas instrucciones.
Uso de CHECK
Cuando sea posible use la instruccin CHECK en lugar de tener IF anidados.
CASE vs IFs
El uso de CASE en ciertos casos es mejor y ms claro que los mismos IFs. Cuando se
tienen ms de 5 instrucciones IF anidadas, se recomienda el uso del CASE que es ms
rpido y legible.
Manipulacin de Textos y Cadenas
Operadores de Cadenas
Se deben usar los operadores estndar CO, CA, CS en lugar de crear lgicas propias.
Ejemplos:
x CA y (contiene alguno), x contiene al menos un carcter de Y
x CO y (contiene nicamente), x contiene un nico carcter de Y
x CS y (contiene string), x contiene una cadena de carcter de Y
Manipulacin de Cadenas
En versiones anteriores la manipulacin de cadenas se hacia a travs de mdulos de
funcin, ahora existen instrucciones que mejora el rendimiento de estas operaciones:
CONCATENATE, para concatenar dos cadenas
SPLIT, para separar dos cadenas
STRLEN(), para conocer la longitud de una cadena
149

SHIFT
Para eliminar caracteres de una cadena, se debe usar la sentencia SHIFT LEFT/RIGHT
en lugar de crear lgicas propias.
Recomendaciones Varias
Limpiar cdigo
Evite dejar cdigo muerto dentro de los programas, remueva todos los objetos
(variables, constantes, tipos, rutinas, tablas internas) que no son usados. Se
recomienda hacer un chequeo extensivo para revisar el programa:
Transaccin SE38 Editor ABAP y por el men principal: Programa Verificar
Verificacin de programas ampliada
Escoger las mejores tablas
Siempre se debe intentar usar la mejor tabla disponible para recuperar datos. Existen
tablas que tienen los mismos datos pero son menos pesadas, por ejemplo se deben
encontrar alternativas para tablas como VBAP y BSEG
Sentencia AT
Es ms eficiente usar la sentencia AT (AT NEW, AT END, etc.) para hacer sumas y
rompimientos, que usar sentencias como ON CHANGE OF por que estas se basan en
la jerarqua de la tabla interna y permiten operaciones automticas. Sin embargo se
debe tener en cuenta que las sentencias AT no permiten ver el contenido de los campos
individuales.
Tipos de Datos y Conversiones
Trate de eliminar conversiones de datos. Definir las variables de origen y de destino con
el mismo tipo es la mejor solucin para este problema. Para conocer la forma como se
estn ejecutando sus conversiones puede ejecutar la transaccin SE30 (Runtime
Analisys).
Sentencia WRITE
Se deben usar la menor cantidad de WRITEs como sea posible, pues cada uno es un
llamado a una sentencia diferente:
Se debe usar:
WRITE: / esta es una prueba, MATNR,
150

/ nueva lnea, 20 comienza en posicin 20.

No se debe usar:
WRITE: / esta es una prueba, MATNR.
WRITE: / nueva lnea, 20 comienza en posicin 20.

151