Bienvenidos a Iseries Venezuela

Las mejores prácticas, recursos, tips, enlaces, videos y artículos para informáticos relacionados con el Iseries y el As/400 lenguajes de programación RPG, ILE RPG y SQL.

The best practices, resources, tips, links, videoes and articles for computer related to the Iseries and the As/400 languages of programming RPG, ILE RPG and SQL.

sábado, 19 de junio de 2010

Calculando Tiempos de Desarrollo













Tradicionalmente, calcular el tiempo de desarrollo de un sistema consiste en realizar un inventario de todos los programas que hay que desarrollar para luego clasificar los programas según su nivel de complejidad.

En algunas organizaciones se establecía y se establece una “Guía” que sirve como referencia para calcular los tiempos de desarrollo.

Nivel de complejidad del programa.___________Duración en Horas/Hombre

Extremadamente Complejo...........................120 horas   (15 días hábiles)
Muy Complejo..............................................80 horas   (10 días hábiles)
Complejo…………………………………..........................40 horas   (5 días hábiles)
Medianamente Complejo………………....................24 horas   (3 días hábiles)
Standard………………………………………….....................16 horas   (2 días hábiles)
Sencillo…………………………………………….....................08 horas   (1 día hábil)
Muy sencillo………………………………………...................04 horas   (medio día)

Según el criterio del Líder de Proyecto, a estos tiempos se le podía sumar un incremento de 30% para considerar una holgura en caso de que algún evento imprevisto pudiese alterar el tiempo estimado de desarrollo.

Actualmente hay una tendencia a dividir los programas, procesos y tareas en actividades que no excedan un máximo de cinco (5) días hábiles. Se definen los diagramas de Gantt en “Project” con actividades que tengan una persona asignada y que esa persona demore un máximo de 5 días en cada actividad.

He notado que en muy  pocas ocasiones se toma en cuenta la experticia de la persona a quien se le asigna el programa a desarrollar. Si la persona asignada a desarrollar la tarea tiene poca experiencia en desarrollo en RPG o en la actividad que le ha sido asignada, un programa que puede ser medianamente complejo para alguien experto podría ser complejo o muy complejo para alguien que no posee la experiencia o el entrenamiento adecuado. La premura por definir una fecha de entrega, hace que se calculen tiempos de desarrollo y de procesos sin conocer el recurso encargado de la actividad. Es mas, en innumerables ocasiones ni siquiera se ha contratado el recurso a quien le será encomendado el desarrollo del programa. En diversas ocasiones el líder de proyecto o el gerente de sistemas calculan los tiempos de desarrollo como si fuese él (o ella) quien va a realizar el trabajo. Por otra parte, tampoco se considera el tiempo que la persona que ingresa necesita para adaptarse tanto a la organización como al conocimiento funcional y técnico del proceso en el cual está participando.

La planificación de un proyecto va mas allá de conocer las herramientas, dominar “Project”, tener la información analizada, conocer el AS/400 y tener la experticia técnica en ILE o RPG. La planificación es un proceso de integración donde cada participante tiene un sello personal que debe ser respetado  y tomado en cuenta para que todos los  involucrados sean capaces de integrarse al equipo de trabajo y a la actividad en su conjunto.

El proceso de planificación, en mi criterio, es parecido al proceso de integración de una orquesta donde cada instrumento tiene un timbre, tono, altura y registros que le son propios. 
En  la medida en que el director de la orquesta conozca el alcance y efecto de cada instrumento y asigne inteligentemente  un rol a cada uno acorde con sus habilidades, en esa misma medida, es mucho más probable garantizar una culminación exitosa del proyecto.


Autor: Ing. Liliana Suárez.


Si te pareció interesante el artículo reenvíalo a un amigo, haciendo click en el sobrecito que está al final del artículo. El conocimiento es valioso, compártelo.

   

domingo, 13 de junio de 2010

Desarrollando un Sistema de Múltiples módulos.












En esta oportunidad voy a referirme no a la programación modular sino al desarrollo de sistemas integrados que tiene múltiples módulos que se comunican entre si. Por ejemplo, los sistemas ERP, que tienen en sus módulos Cuentas por Cobrar, Ventas, Contabilidad, Inventarios y otros. En la Banca también hay sistemas integrados como IBS, por ejemplo.

La clave para un piso tecnológico sólido es la arquitectura de la base de datos. Es importante diseñar simultáneamente la base de datos de cada módulo y la base de datos que guardará la información de las interfases así como los mecanismos de recuperación del proceso en caso de caída del sistema. Suele ocurrir que luego de diseñar la base de datos de cada módulo, caemos en cuenta que se necesita agregar campos o ampliar las longitudes y cambiar los tipos porque no tomamos en cuenta las interfases intermódulos y la data que estas interfases requieren para ser desarrolladas. Sucede esta misma omisión con los mecanismos de recuperación de la información. Una vez que el sistema se desarrolla caemos en cuenta que, se requieren bien sea archivos temporales o controles de compromisos COMMIMENT que no fueron contemplados.

La compilación de programas SQL-RPG puede requerir las especificaciones de journals (registros de diario) de los archivos involucrados en el proceso.

Las interfases entre módulos y sobretodo las interfases de cada uno de ellos con la contabilidad son vitales para asegurar la integridad y la consistencia de la data a través de todo el sistema. Al diseñar sistemas muti-modulares tomemos las interfases como módulos que deben ser definidos con total claridad durante del desarrollo del sistema y no al final del mismo. Además considerémoslos no como simples programas de traslado de data de un archivo a otro, sino como agentes de integración de la data que tienen bajo su responsabilidad mantener la consistencia e integridad de la información del sistema en su conjunto. Una caída del As400 justo en un momento de una interfase puede representar muchos días y horas-hombre de trabajo para restaurar la data y los archivos involucrados.

Los procesos de migración hacia otros sistemas o plataformas y los procesos de auditoría se facilitarán enormemente cuando tenemos en consideración los aspectos de diseño mencionados en este artículo.



Autor: Ing. Liliana Suárez.




Si te pareció interesante el artículo reenvíalo a un amigo, haciendo click en el sobrecito que está al final del artículo. El conocimiento es valioso, compártelo.