ITECH Blog

Entrañas Sistemáticas

Calidad de Servicio (Orientacion al Desarrollador)

leave a comment »

Seria muy fluido y desastroso si con cada proyecto bien sea aplicacion Desktop o Web nos sentasemos frente al computador y conforme tengamos a la mano la informacion proporcionada por el cliente, fuesemos armando cada parte de todo el sistema. Tanto en su proceso como luego de su culminacio tendriamos que estar parchando los defectos de un mal diseno.  Si las bases no son solidas, todo el proyecto tiene el alto riesgo de irse abajo o funcionar muy deficientemente quitandole la credibilidad del trabajo entre contratista y cliente.

Este podria ser un borrador o una idea del patron que podria seguirse para poner en marcha un proyecto:

1. Levantamiento de la informacion
1.1. Flujograma Corporativo de la Empresa (inicio-proceso-culminacion por cada dpto).
1.2. Entrega de Planillas, Formularios y Formatos en general (ingreso, proceso, salida/facturacion).
2. Evaluacion y diseno de esquema de proyecto en base a la informacion levantada
2.1. Actual o Rediseno de procesos de la organizacion.
3. Repaso de la informacion, re-evaluacion.
4. Preparacion de la Presentacion del esquema del proyecto.
5. Presentacion del esquema del proyecto

POSIBLE CLAUSULA DE CONTRATO (Ejemplo):
cc1.- Una vez evaluado el costo del proyecto, el programa tendra el costo establecido a como actualmente este estipulado en el contrato y se haya aprobado.
cc2.- Nuevos agregados o ajustes perteneceran a un nuevo costo del proyecto, que debera de establecerse en futuras reuniones con el cliente, en base a nuevos anexos al mismo.
cc3.- Se prohibe el rediseno de modulos ya culminados por peticion del cliente. De presentarse la necesidad de redisenar un modulo ya culminado, las partes, cliente y contratista deben entablar un nuevo costo en base a duplicar el tiempo de trabajo de dicho modulo.
cc4.- Se prohibe el uso de Software Pirata. Debe tenerse las licencias de los Software Propietario en caso de requerirse su uso como herramienta de trabajo.
cc5.- Debe cancelarse la inicial del 30% del costo total del proyecto, el 50% al culminarse el 50% del proyecto y un 20% final al culminar el proyecto.
cc6.- Todo Proyecto de Software personalizado a Empresas, se le hara entrega de Esquemas y Disenos del proyecto.
cc7.- COSTOS:
cc7.1.- Pago por horas trabajadas
cc7.2.- Pago por modulo
cc7.3.- Pago por Redisenos
cc7.4.- Pago por Perfil del Proyecto: local o Cliente/Servidor.

INICIO DEL PROYECTO
1. Investigacion previa para el desarrollo
2. Elaboracion de Diagramas ER, DF. (Entidad Relacion – Diagrama de Flujo).
3. Diseno en papel de la Base de Datos (BBDD ER: Entidad Relacion de la Base de Datos).
4. Diseno de la BBDD y sus Relaciones
5. Diseno en papel de las interfaz de usuario (GUI).
6. Presentacion y entrega de la interfaz de usuario al cliente.
7. Desarrollo de la Interfaz de Usuario (GUI) por modulo. (una vez aprobado)
8. Pruebas y Depuracion.
9. Manual del Usuario.
10. Instalacion y Configuracion.
11. Adiestramiento y Soporte al Usuario.

Esto es una idea con la que puede empezarse para armar una planificacion y un verdadero Contrato con sus Clausulas, no se indica en ningun momento que esta estructura de recopilar la informacion sea exacta, es un rapido borrador de como podria perfilarse el proyecto. Se necesitaria de alguna planificacion como Project (bajo Windows) o alguna equivalente para Linux e igual para MAC, para indicar el tiempo que se llevaria cada punto y hacerle entrega de ello al cliente.

Las cosas que pueden vivirse en la marcha del proyecto:

1. El cliente cambia de opinion sobre el comportamiento de uno o varios de los modulos del proyecto, deseando cambiar algunos procesos o anexarle mas cosas (recordemos que ya se establecio un precio, por lo que se evalua que tanto se debe de redisenar y en base a ello determinamos si es necesario o no un reajuste del precio).

2. A veces no nos tomamos mas del tiempo que deberia ser necesario para probar realmente cada modulo del proyecto, y cada modulo con su integracion a otros, y en resumen todo el proyecto completo. Es importante recordarle al cliente que pueden existir algun mal funcionamiento que inmediatamente se presta a correccion, hacerle saber que los primeros dias el sistema estara bajo “prueba” y no ser tomado inmediatamente para produccion. Normalmente un desarrollador no deberia cobrar por fallos del sistema, solo por mantenimiento preventivo, anexos y rediseno por peticion del cliente. Sabemos que en esta area de trabajo, si un sistema no funciona bien, pierde su valor e incluso, podria considerarse que no vale nada, sobre todo en Sistemas ERP, de hecho, todo este articulo esta orientada a sistemas ERP, por ser sistemas grandes y mas complejos donde todo se integra y en donde al fallar algo, los otros modulos no caminan (no producen) puesto que dependen de la salida de un modulo previo, asi que si un punto se estanca, el resto tambien.

3. Si el cliente solicita en repetidos momentos, el resideno de uno o varios modulos, esto es un problema que debe entablarse nuevamente con otra reunion (esto es lo que todos tratamos de evitar, retrabajar demas en lo mismo, en cosas en marcha o ya culminadas).

4. Es bueno anotar todo refrente a cosas nuevas que hacemos y aprendemos (buscando e investigando) para satisfacer una o varias necesidades del cliente, ya que de no conservar apuntes, en el futuro al presentarse nuevamente la misma solicitud, es posible que no recordemos como solventamos ese punto (creeme que si pasa). Tomando en consideracion que los respaldos de proyectos para un programador son el Todo, no solo por ser proyectos en funcionamiento, sino porque en ellos existe la codificacion que podriamos volver a necesitar en futuros proyectos.

5. Un consejo, si indicas como PrimaryKey un campo Cedula o Rif, es mejor que el campo ID sea un campo numerico, en las tablas Maestras Autoincrementable, en las tablas hijas o detalles de esta, un campo numerico que estara asociado al Id de la tabla maestra conformando lo que uno llamaria (maestro-detalle). Se puede presentar (se ha presentado y creem que es asi) el que incluso el mismo dato que es el Id de referencia de los registros en la BD fue mal ingresado (mala transcripcion) y esto hace que el programador termine creando un script o pequeno modulo que corrija el cambio de la viejta cedula por la nueva en todas las tablas. Si el Id es realmente otro campo (como se indica) cuando estos malos ingresos (error humano) sucedan, solo se corrige el campo cedula primordial y el sistema seguira funcionando igual, puesto que a partir de la cedula es que el sistema sabe que Id es de este dato y en la estructura de todas las tablas de la BD siempre seguira siendo el mismo Id, campo que el sistema le asigno al campo cedula. Si esto no se hace, cuando un cliente con esa cedula ingrese al sistema, el sistema indicara que ya existe, el usuario transcriptor terminara haciendo dos cosas, o reporta el fallo (y el progamador correra el script que lo cambie en todas las tablas, un proceso lento y tedioso) o el usuario transcriptor editara el registro borrando los datos previos por los del nuevo usuario, ocasionandose todo un desastre (en el caso de que el sistema permite la edicion del registro a dicho usuario), o borre el registro y lo vuelva a hacer que es lo mismo. Una mala transcripcion no es culpa nuestra, pero igual, son platos rotos que nos toca recoger, asi que es mejor prevenirlo que corregirlo, siempre hemos sabido que los sistemas que hagamos debemos hacerlo a prueba de tontos y de tercos. Incluso es nuestra labor en las pruebas tratar de hacerlo fallar, reventarlo y ver cual es su limite.

6. Es bueno tener ayuda (no solo por contar con un buen grupo de programadores) sino por personas que ayuden a probar y ver lo que posiblemente se le ha pasado por alto al desarrollador, tanto en pruebas ficticias como reales.

Finalmente termino indicando lo siguiente…

No uses lenguajes viejos (herramientas viejas), gracias a dios existen programadores que si se dedican a aprender lo nuevo, porque si existe y se da a conocer por algo existe, la gente no usa algo porque otros lo usen, es porque es la herramienta mejor adaptada a dichas necesidades. Conozco gente que aun desarrolla en lenguajes viejos lo cual trae sus problemas, el soporte decae, necesidad de hacer algo que en la version nueva o en otros lenguajes si se puede, pero en el viejo no. Conozco un sistema ERP que fue desarrollado en un lenguaje llamado Dexterity y fue una de las peores estrategias de trabajo y la peor decision para una empresa, aceptar este sistema, debido a que el soporte depende netamente de un solo individuo, no existen libros, ni informacion em internet sobre un lenguaje aislado y decaido como este, toda una mala estrategia de negocio, lo cual lo estan pagando ahora, y algo caro.

Conoce muy bien la herramienta de trabajo, puesto que conocer a nivel basico o incluso medio, produce trabajar demas, mas codigo y este en base al analisis de estructura del proyecto, como fue enmarcado su diseno. La persona que conoce muy bien la herramienta no deberia estar preguntando tanto en foros, grupos de correo, o en alguna otra parte de internet buscando como hacer algo, ya que los momentos de investigacion por la necesidad de hacer algo, quita tiempo, aprendes en el proceso pero te retrasa. El que conozca bien la herramienta(s) conoce que tanto pueda hacer con ella, conoce sus limites. Que te detenga unicamente el limite de la herramienta, mas no tu limite en usarla, trata de ser usuario avanzado en lo que uses para trabajar, esa debe ser tu principal meta. Solo las personas apasionadas por algo logran llegar a este nivel, y tu puedes ser una de ellas, porque no? solo tu mismo te puedes dar resistencia, porque todavia no se han levantado las barreras que le digan al genio… de aqui no pasaras.

Existen dos excelentes articulos sobre la Planificacion de proyectos que indico a continuacion y considero fomentarlo a ser un estilo de trabajo a seguir:

Orientacion a Calidad de los Programadores en Desarrollo de Sistemas Web

Gerencia de Proyectos Web

enjoy!

Anuncios

Written by jocdz

septiembre 26, 2009 a 4:32 pm

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: