Comentarios acerca de la calidad de software Estimado Nerón, 

En el tiempo que llevo trabajando he visto ya tres sistemas: Mall Advertising, Max Center, 

Grupo BGD. Todos estos sistemas tienen el mismo estilo de programación, pero tengo entendido 

que no  los ha realizado  la misma persona por  lo que asumo que es una especie de normativa o 

estandarización en la empresa.  

En los años que tengo de experiencia siempre ha sido una constante realizar mi trabajo lo 

más profesional posible, siempre he preferido demorarme un poco más a entregar un trabajo mal 

hecho, medianamente bueno o  susceptible de errores. Ha  sido esa  característica  la que me ha 

dado cierta reputación, reputación que pretendo mantener y esta es  la principal motivación que 

me lleva a escribir este documento. 

Antes de continuar quisiera que este documento se entienda como una crítica constructiva 

que busca mejorar  la  calidad  de  los  trabajos  de  la  empresa,  ya  que  es  de mi  entender  que  la 

calidad del trabajo que se entrega es el prestigio que la empresa debe asegurar a sus clientes y es 

lo que hace que todos ganemos.  

La crítica que hago lo hago desde el punto de vista de una auditoría de software. Por favor 

leer este documento como si un consultor de Control de Calidad estuviera dando un informe de la 

calidad del trabajo de esos tres sistemas. El resumen de lo que encontré es: 

Los tres sistemas revisados tienen la misma característica y es que cada uno es un sistema 

monolítico y salta a la vista que no ha existido un trabajo de diseño de software previo. No 

sigue ninguna arquitectura de software que pueda asegurar que sean escalables, al menos 

no de forma fácil y segura.  

Cada uno de  los sistemas  tienen el código de  la  lógica del negocio  (en este caso código 

php) mezclado de  forma desordenada, o al menos no de  forma  clara o definida,  con el 

código de la presentación (código html, css, javascript).  

El flujo del código no presenta un orden, siquiera procedural, que pueda asegurar que el 

sistema pueda ser rápidamente adaptable a los cambios en la lógica que el negocio pueda 

requerir.  

En  ninguna  parte  del  código  se  ve  reflejado  una  estandarización  en  los  estilos  de 

programación, por ejemplo: no existe una clara definición de formación de nombres para 

las variables, no existe una forma estándar de ejecutar las consultas y mucho menos existe 

una  correcta  identación  en  el  código  que  permita  leer  con  facilidad  el  código  allí 

expresado.  

No existe documentación de ninguna índole, ni dentro del código siquiera. 

La  base  de  datos  no  está  correctamente  normalizada,  teniendo  datos  (tales  como  la 

dirección o proveedores) mal normalizados. No se ha definido un conjunto de caracteres 

estándar  (he  visto  usar  sueco,  binario,  general).  Tampoco  se  utilizan  motores  de 

almacenamiento  que  proporcionen  transacciones  lo  que  hace  peligrar  los  datos  para 

sistemas e‐commerce. 

No existen mecanismos claros de filtro de los Request HTTP, y se utilizan directamente las 

variables  siendo esto un grave hueco de  seguridad al  ser posible  inyectar  código en  los 

request, comúnmente conocidos como ataques XSS. 

Las características anteriormente descritas hacen que cualquier cambio que exija el cliente sea 

un paso algo  tortuoso, mucho más para alguien que no conoce el sistema ya que debe hacer el 

trabajo  de  un  hacker  para  poder  ir  desenmarañando  el  código,  ir  descubriendo  su  lógica  y 

sobretodo  lidiar con  las prácticas de programación que en el caso de  los sistemas analizados es 

más bien un obstáculo.  

Por otra parte hay que considerar que realizar un cambio en el código en estas circunstancias 

puede  ser  inclusive  contraproducente debido al desorden y es muy probable que al añadir una 

característica o cambio también se incluya un bug en el sistema.  

Hay que deducir que esto implica que se demore más tiempo del necesario para realizar algo 

nuevo en el sistema, en una empresa en  la que exista un control de  calidad del  software estos 

cambios serían mucho más fáciles, rápidos, seguros y confiables haciéndolas más competitivas. 

¿Por qué esta crítica?  

Definir una arquitectura de software para realizar un sistema, sentarse a establecer un diseño, 

permitiría  que  se  realice  un  software  de  calidad;  una  empresa  que  piense  tan  sólo  en  “sin 

embargo funciona y eso es suficiente” hace que sea una empresa que se condena a sí misma al 

fracaso puesto que no podrá eventualmente afrontar  los cambios con  la velocidad que exige el 

mercado,  y  el mercado  de  software  es  un mercado muy  exigente  y  sobretodo  que  sufre  de 

amnesia muy rápidamente. 

Una arquitectura de software consiste en un conjunto de patrones y abstracciones coherentes 

que proporcionan el marco de referencia necesario para guiar la construcción del software para un 

sistema  de  información.  Establece  los  fundamentos  para  que  analistas,  diseñadores  y 

programadores  trabajen en una  línea  común que permita alcanzar  los objetivos del  sistema de 

información. 

Me han dicho en más de una vez: “lo de GSM Manía es fácil, es copiar y pegar lo hecho para 

Max Center”, bueno, eso no es enteramente cierto. En un sistema monolítico como el que está 

realizado para Max Center, donde  las  consultas  están mezcladas de  forma desordenada  con  el 

código html es más bien realizar la tarea de un cirujano el adaptar ese código. Por otro lado, eso 

significa que se están copiando los mismos errores, malas prácticas de programación, los mismos 

vicios en el otro sistema, entregándole al cliente el mismo mal trabajo, aunque “funciona”, de  la 

misma forma como funcionó Frankenstein para su creador. 

Para graficar esto puedo presentar esta parte del código que presenta el detalle de un pedido: 

 

En parte del archivo detallepedido.php podemos ver que se mezcla el código HTML con código 

PHP para realizar el detalle, e inclusive en el mismo código PHP se vuelca código HTML haciéndolo 

más complicado aún. Realizar una pequeña modificación aquí requiere el trabajo de un cirujano y 

no es una simple cosa de “pegar y copiar” sólo “porque funciona”. 

Una  razón personal por  la que efectúo esta crítica es por el hecho que yo no soy un simple 

programador,  soy  ingeniero,  aunque me  gusta mucho  la  programación;  pero,  soy más  que  un 

programador. Un programador hace  lo que  se  le pide  sin más puesto que  ese es  su  trabajo,  y 

ciertamente yo también puedo hacer eso mismo (como lo he venido haciendo); pero, mi búsqueda 

de la profesionalización de mi trabajo me exige que no me contente con realizar un trabajo poco 

profesionalizado, lo que a la larga me lleva a ensuciarme con malas prácticas y vicios en mi forma 

de trabajo, que mucho esfuerzo y sacrificio  (personal y de mis padres) me ha costado  llevarlo al 

nivel  en  el  que  está  y  que  se me  ha  reconocido  en  diversas  oportunidades. Ni  siquiera  en mi 

primer proyecto web, en Enero del 2001 que hice el sistema de  inscripción, gestión operativa y 

pago en  línea para un congreso de sistemas de mi universidad, realicé un trabajo sin considerar 

muy  bien  la  ingeniería  y  calidad  de  software,  cosa  que  no  encontré  en  los  trabajos  que  he 

revisado. Para mi estos trabajos no son profesionales y a casi más de 8 años de experiencia en la 

rama no estoy dispuesto a rebajar mi trabajo a algo así. 

HTML 

PHP

HTML 

Es  justamente  en  virtud  de  esta  profesionalización  que  no  sólo me  quedo  en  criticar  sino 

también en plantear soluciones, tal como siempre me decía un profesor, amigo  íntimo y mentor: 

“Un ingeniero no sólo describe los problemas, da soluciones”.  

Planteamiento  

  Lo  que  planteo  para  este  sistema  de  GSM  Manía,  es  iniciarlo  usando  un  modelo  de 

Arquitectura de Tres Capas aunque reutilizando el código SQL y el DDL ya utilizados en el sistema 

de Max Center. Primero quisiera explicar de manera  rápida  el modelo de Arquitectura de  Tres 

Capas para que se me entienda. 

Arquitectura de Tres Capas  

  Según wikipedia1:  Es  una  especialización  de  la  arquitectura  Cliente  –  Servidor  donde  la 

carga se divide en tres partes o capas con un reparto claro de funciones:  

1. Capa de presentación: Es lo que ve el usuario, presenta el sistema al usuario, le comunica 

la  información  y  captura  la  información  en  un mínimo  de  proceso  (realiza  un  filtrado 

previo  para  comprobar  que  no  hay  errores  de  formato).  Esta  capa  se  comunica 

únicamente  con  la  capa de negocio. También es  conocida  como  interfaz  grafica  y debe 

tener la característica de ser "amigable" (entendible y fácil de usar) para el usuario. 

2. Capa  de  negocio:  Es  donde  residen  los  programas  que  se  ejecutan,  se  reciben  las 

peticiones del usuario  y  se envían  las  respuestas  tras el proceso.  Se denomina  capa de 

negocio  (e  incluso de  lógica del negocio) porque es aquí donde  se establecen  todas  las 

reglas  que  deben  cumplirse.  Esta  capa  se  comunica  con  la  capa  de  presentación,  para 

recibir  las solicitudes y presentar  los  resultados, y con  la capa de datos, para solicitar al 

gestor de base de datos para almacenar o recuperar datos de él. También se consideran 

aquí los programas de aplicación. 

3. Capa de datos: Es donde residen los datos y es la encargada de acceder a los mismos. Está 

formada por uno o más gestores de bases de datos que realizan todo el almacenamiento 

de datos, reciben solicitudes de almacenamiento o recuperación de información desde la 

capa  de  negocio.  Por  lo  general  implementada  como  una  base  de  datos  dentro  de  un 

Sistema de Administración de Bases de Datos Relacionales. Contiene, además de los datos 

en  sí,  código  escrito  en  procedimientos  almacenados,  disparadores  (triggers),  reglas  y 

funciones. 

Las principales ventajas de este modelo son las siguientes: 

                                                            1 http://es.wikipedia.org/wiki/Arquitectura_de_tres_niveles  

1. Separación de  funciones: todo  lo relacionado con  la  interfaz del usuario va en una capa, 

las reglas de negocio en otra y el manejo de datos en una tercera capa. No se mezcla en 

una capa código correspondiente a otra. 

2. Reutilización:  el  código  correspondiente  a  una  capa  puede  ser  reutilizado  desde  varias 

partes de la capa inmediatamente superior. 

3. Escalabilidad:  sabiendo  dónde  está  el  código  correspondiente  a  cada  capa,  pueden 

realizarse modificaciones  dentro  de  una  capa  para mejorar  o  aumentar  el  tamaño  del 

sistema de software, con un mínimo impacto en las capas restantes. 

4. Facilidad  de  mantenimiento:  mediante  esta  división,  es  mucho  más  sencillo  localizar 

errores en el código o efectuar mejoras. 

Para los sistemas web existen frameworks ya creados, mucho más para php y java, que permiten 

implementar el modelo de tres capas con mucha facilidad. Los frameworks más utilizados en PHP 

son: Smarty2 para la capa de presentación y ADODB3 para la capa de datos. 

El uso de Smarty yo  lo considero  indispensable en  los sistemas web que he  revisado y  también 

para  el  sistema  de  GSM Manía.  El  uso  de  ADODB  se  hace  útil  si  el  sistema  a  desarrollar  es 

susceptible de  tener cambios en el motor de base de datos,  si se  tiene  la  seguridad que nunca 

cambiará el uso de MySQL se puede restringir su utilización, aunque tampoco está demás ni le da 

complejidad al desarrollo, por el contrario es muy aconsejable su uso (uno nunca sabe qué puede 

deparar el futuro y es mejor estar preparado ante él y los cambios que pueden exigir). 

Smarty  es  un  framework  motor  de  templates,  que  permite  separar  la  capa  lógica  de  la 

presentación, dado que en la capa de presentación se le declaran variables que son reemplazadas 

en  los templates y así el mismo template puede entregarse a cualquier diagramador o diseñador 

para que lo modifique a su gusto sin impacto en la capa lógica. 

ADODB es un framework que permite la abstracción del motor de base de datos, proporciona una 

API única para el  trabajo con  las conexiones y consultas, de  tal  forma que un cambio  futuro de 

DBMS no requiere más que el cambio de una sola línea de código en un sistema realizado con este 

paquete. 

La capa de la lógica del negocio es la capa a ser diseñada ad‐hoc para cada sistema. Si se tuviese el 

tiempo suficiente se podría pensar en crear un framework propio para la generación de sistemas 

de e‐commerce lo que facilitaría su reutilización en otros sistemas futuros de la misma rama (algo 

que me parece es muy recurrente en el giro del negocio de “Meiler Interactive Creations”), por lo 

que es altamente recomendable. 

                                                            2 Smarty: http://www.smarty.net   3 ADODB: http://adodb.sourceforge.net  

Así la primera aproximación del sistema para GSM Manía podría ser la siguiente: 

   

Capa de Lógica del N

egocio

Lógica de GS

M M

ania

AD

OD

BA

CL

Capa de Base de Datos

Servidor MyS

QL

DD

LTriggersV

iewsFunctions

Capa P

resentación

PresentaciónH

TML

CSS

JavascriptX

mlHttpR

equestFlash

Sm

arty

Capa de Lógica del Negocio  

Según requerimientos expresados a mi por Danny Herrán, la interfaz del sitio de GSM Manía debe 

generarse “de cero” dado que hay que hacer el diseño completamente usando CSS para que así 

pueda ajustarse a cualquier plataforma móvil. Yo veo aquí una oportunidad estupenda para poder 

realizar un cambio en las directrices del trabajo y realizar uno bien planteado, correctamente 

definido y documentado, un trabajo realmente de calidad. 

He hecho  el  trabajo de  hacker  con  el  sistema de Max Center  y  le  logrado deducir  el  siguiente 

diagrama de clases (capa de lógica del negocio): 

   

 

   

Pedido

- pedi_id : Integer- cliente : Cliente- direccion : Direccion

Cliente

- clie_id : Integer- clie_nom

bre_razon : String- clie_rif_ci : Integer- direccion : Direccion

Pago

- pago_id : Integer- pedido : Pedido- banco : Banco- form

a_pago : Integer- status : Integer

CategoriaProducto

- cat_orden : Integer- cat_nom

bre : String- cat_id : Integer- cat_nivel : Integer- cat_padre_id : Integer

Direccion

- entidad_id : Integer- tipo_entidad_id : Integer- dire_id : Integer- dire_pais : Integer- dire_estado : Integer- dire_ciudad : String- dire_avenida : String- dire_urbanizacion : String- dire_casa_apt : String- dire_codigo_postal : String

Proveedor

- prov_id : Integer

interfaceIEntidad

+GetCodigoEntidad

+GetTipoEntidad

PedidoDetalle

- pedd_id : Integer- pedi_id : Integer- producto : Producto- pedd_cantidad : Integer- pedd_precio : float- pedd_iva : Integer- pedd_subtotal : float

Opi

- opin_public- opin_rankin- cliente : Clie- producto : P- opin_id : Int- opin_fecha - opin_texto

Banco

- banc_beneficiario : String- banc_nom

bre : String- banc_id : Integer- banc_num

erocuenta : String- banc_rif : String

No me queda claro que

relación tiene con Costo, Zona o qué son estos conceptos

 

Variables

Tienda

- tien_imagen : String

- tien_nombre : S

tring- tien_id : Integer

Marca

- marc_nom

bre : String

- marc_id : Integer

- marc_publica : Integer

- marc_logo : S

tring

Variable

- var_id : Integer- nom

bre : String

- valor : Integer- fecha_registro : D

ate- ultim

a_modificacion : Date

- modificable : Integer

Producto

- prod_imagen : S

tring- prod_publica : Integer- prod_nom

bre : String- prod_ranking : float- prod_id : Integer- m

arca : Marca

- categoria : CategoriaProducto

interfaceIPublicable

+EsPublica

pinion

ca : Integerng : floatienteP

roductontegera : D

ate: S

tring

interfaceIVisualizable

+GetIm

agen

Banner

- bann_publica : Integer- bann_im

agen : String

- bann_id : Integer

interfaceINombrable

+GetNom

bre

En  el  diagrama  de  clases  presentado  anteriormente  se  han  omitido  unas  clases  que  tienen  su 

correspondiente  a  cada  clase presentada en el diagrama  y que  tienen  como  función  realizar  la 

conexión  y  consultas  con  la  base  de  datos  sobre  la  lógica  de  la  clase  que  representa,  así  por 

ejemplo: para  la  clase Producto debe existir una  clase BdProducto que  se  conecta a  la base de 

datos y debe encargarse de  la persistencia de  los datos de Producto así como de su  lectura del 

motor  de  base  de  datos.  Estas  clases  de  conexión  con  la  base  de  datos  deberían  utilizar  el 

framework ADODB antes mencionado. 

Lógicamente  es  un modelo  que  debería  afinarse  dado  que  yo  no  he  tenido  acceso  a  ninguna 

documentación del sistema, y sospecho que no existe tal documentación. 

Capa de Presentación  

Para la capa de presentación propongo el siguiente diagrama de clases: 

 

La  clase página  se  encarga de manejar  los  flujos Http  y  comunicarse  con  la  capa de  lógica del 

negocio. Utiliza el motor de templates Smarty para la generación de las interfaces gráficas. 

Capa de Datos  

Para  la capa de datos podríamos  reutilizar el 80% del DDL ya existente para Max Center, allí yo 

tengo consultas acerca de, por ejemplo, el porqué no se normalizó  la dirección entre entidades 

tales  como  cliente,  pedido  y  proveedor.  Además  tampoco  está  normalizado  el  tipo  de  pago, 

teniendo una tabla extra que no da ganancia en el sistema. Tampoco está normalizada la forma de 

pago, ni los estados ni las ciudades. Falta hacer una normalización de varios datos los cuales están 

hard‐coding y eso es una práctica que hace que el sistema no sea escalable o lo dificulta.  

Conclusiones  

El presente  informe ha presentado el  resultado de un análisis de  la calidad del software de tres 

sistemas a  los que he tenido acceso, no es un análisis hecho a  la profundidad que merece y tan 

solo presento un resumen de lo encontrado. 

smarty

Pagina

Los sistemas evaluados son sistemas que carecen de una arquitectura definida o de un diseño de 

software que permita que ellos sean flexibles, coherentes y de fácil mantenimiento en el tiempo. 

Son sistemas monolíticos con código desordenado y mezclado entre interfaz, conexiones y lógica. 

Se  hace  ver  la  necesidad  de  corregir  esta  forma  de  trabajo  mediante  la  utilización  de  una 

arquitectura de  tres  capas, que por  lo demás es  la arquitectura más utilizada para  los  sistemas 

web. Al utilizar esta arquitectura  se asegura un buen  código, un  sistema  flexible, escalable que  

permite la reutilización y hace entrega de un trabajo de calidad al cliente. 

Se han planteado los diagramas de clases base producto de un hackeo del sistema de Max Center 

para guiar en  la migración de paradigma de trabajo,  los diagramas requieren un afinamiento con 

las personas que conocen a la perfección la lógica del sistema dado que se han generado después 

de deducir el sistema debido a la nula documentación del mismo. 

El  espíritu  de  este  informe  es  intentar  mejorar  la  forma  de  trabajo  de  la  empresa,  se  han 

expresado duras críticas pero ninguna se ha  realizado sin sustento en  la realidad. Creo que está 

demás  aclarar  que  este  informe  no  tiene  carácter  personal  ni  busca menoscabar  a  nadie  en 

especial,  yo  soy  nuevo  en  la  empresa  y  simplemente  he  intentado  dar  mi  punto  de  vista 

profesional que es para lo que, eventualmente y si no hay ningún cambio, se me paga. En última 

instancia he emitido este informe en la búsqueda de salvaguardar la reputación y profesionalismo 

de mi trabajo que ha adquirido con el tiempo buenas prácticas y he intentado siempre de subir mi 

nivel, y no pretendo disminuirlo. 

Tiempos Contestando a la pregunta que en final de cuentas importa (aparentemente lo único que importa) 

es mi deber plantear dos plazos: 

‐ Si se toma en cuenta el modelo propuesto podría dar la siguiente aproximación: 

o Capa Presentación: 1 semana. 

o Capa Lógica: 1 semana y 3 días. 

‐ Si se obvia  lo propuesto y se continúa con un sistema monolítico podría dar  la siguiente 

aproximación: 

o 2 semanas y algunos días  

 

Los tiempos están definidos pensando en un trabajo a tiempo completo, con toda la información 

clara y oportunamente definida (cosa que no existe en el primer caso). 

 

 

Grover Campos Ancajima 

Ingeniero de Sistemas