I.-INTRODUCCION
El desarrollo e implementación de un Banco de Proyectos (BP) se orienta a complementar el tratamiento tradicional de la inversión pública a través de un enfoque integral y dinámico. Permite normalizar el tratamiento de la misma vinculando el nivel de proyectos específicos con el presupuesto del Estado y los Objetivos y Metas de Desarrollo Social y Económico.
A través de la implementación del BP se conforma un instrumento operativo que permite complementar el análisis a nivel de proyectos específicos, con un tratamiento sistematizado e integral del proceso de inversión pública.
Los principales objetivos del Banco de Proyectos son los siguientes:
El Banco de Proyectos tiene como principal objetivo proporcionar información para mejorar la toma de decisiones de asignación de recursos para preinversión e inversión. Por lo tanto, la demanda de información vinculada con este propósito específico define el universo dentro del cual deben establecerse las variables pertinentes.
Concebir a la inversión pública como un proceso continuo y poner de manifiesto que el nivel, la estructura y la compatibilidad entre las políticas del Gobierno y la futura inversión, dependerá de la capacidad actual de programar adecuadamente el proceso de inversión desde sus inicios y en todas sus etapas.
Concebir cada proyecto como una unidad del sistema de información. El diseño y operación del sistema requiere mantener individualizado al proyecto durante su ciclo de vida, a fin de garantizar un eficiente manejo de la inversión.
Permitir mantener un registro de la historia de cada proyecto individual (aún de los más pequeños) y de este modo efectuar análisis ex-post de proyectos que retroalimentan al sistema de planificación y posibiliten un mejoramiento paulatino del proceso.
Normar en detalle el ciclo de vida de los proyectos y estandarizar tanto el léxico como el contenido conceptual de la terminología utilizada, para todas las instituciones públicas en este campo.
Para lograr una adecuada organización del proceso de inversión pública, es necesario que las normas, procedimientos, metodologías, capacitación de recursos humanos e información sean homogéneos, coherentes y de aplicación uniforme en todas las instituciones del sector público.
En la asignación de recursos para preinversión/inversión, la demanda de información proviene de todas las instituciones, estando la misma determinada por sus funciones (decisión, asesoramiento o ejecución) y por el marco legal que fija su competencia.
El BP abarca el ciclo completo de todos y cada uno de los PROYECTOS de inversión pública, pero sólo se almacena y procesa información sistematizada y resumida a ser utilizada por los niveles de Gobierno (decisión), Planificación (asesoramiento) y Administración (ejecución). Cabe hacer notar que se entiende por "Proyectos", los programas o estudios básicos o proyectos específicos indistintamente.
II.-ARQUITECTURA LOGICA DE UN BANCO DE PROYECTOS
En este marco lógico se identifican claramente las entidades, procesos y funciones correspondientes a cada etapa de un proyecto para lograr financiamiento y su posterior ejecución.
EL Modelo Conceptual es la consecuencia del trabajo grupal llevado a cabo por un equipo multidiciplinario liderado por el experto en informática, el cual debe sintetizar y concretar todo el conocimiento de los expertos de cada área en el Modelo, el cual posteriormente será la base para generar el Modelo Físico del sistema.
En general para abordar el desarrollo de sistema de la embergadura de un BP, es necesario subdividir la aplicación en módulos, ello permite concentrarse con mayor facilidad en el análisis y posterior desarrollo al estudiar los requerimientos de cada módulo en forma separada.
Podemos distinguir claramente en un primer análisis dos grandes módulos:
PREINVERSIÓN
INVERSIÓN
Dependiendo de las necesidades y requerimientos de las instituciones y usuarios del sistema a implementar, se podría detectar otros módulos y/o subdividir los anteriores.
PREINVERSION:
Las funciones básicas de la etapa de PREINVERSION son :
. REGISTRO DE PROYECTOS.
. VERIFICACION DE INFORMACION BASICA.
. RECOPILACION ANTECEDENTES EVALUACION DE PROYECTOS.
. SELECCION PROYECTOS A FINANCIAR.
Para registrar la información asociada a cada una de estas funciones, se diseña formularios apropiados, los cuales deben ser completados a medida que el proyecto avanza por las distintas etapas.
El proceso comienza con la confección por parte del sector interesado, de la ficha de registro de proyecto. Esta ficha es completada con los datos básicos del proyecto que postula al financiamiento, siendo condición absolutamente necesaria para iniciar el proceso de preinversión. Completada la ficha, es enviada al Departamento de Planeación, donde se verifica que la información contenida en la ficha sea consistente y se pide que se realice la evaluación del proyecto.
El BP debe registrar las diferentes etapas por las que pasa un proyecto, siendo las más relevantes las siguientes:
INGRESO FICHA
RECOMENDACIÓN TECNICO ECONOMICA
PRIORIDADES DE INVERSION
APROBACION
OBTENSION FINANCIAMIENTO
PROYECTOS APROBADOS CON FINANCIAMIENTO
PROGRAMACION FISICO-FINANCIERA
Las instituciones reciben los proyectos que requieren financiamiento y estudian su viabilidad e información técnica que los acompaña. Producto de este análisis puede que se requiera completar información, la que debe ser provista por las distintas instituciones que participan en el proceso.
La nómina de proyectos aprobados con sus respectivos montos asignados, es enviada al Ministerio de Hacienda y/o Economía y Departamento de Planeación, siendo este último el encargado de informar a los sectores regionales de aquellos proyectos que fueron aprobados, con lo cual finaliza la etapa de Preinversión.
INVERSION:
Las funciones básicas de esta etapa son :
. SEGUIMIENTO PROGRAMACION FISICA-FINANCIERA
. CONTROL AVANCE FISICO-FINANCIERO PROYECTOS
. CONSOLIDACION DE INFORMACION DE AVANCE FISICO-FINANCIERO
El proceso de inversión comienza cuando ya se han asignado los fondos y los sectores conocen las resoluciones correspondientes, luego, corresponde realizar la licitación y llamado a propuesta para cada proyecto. Los sectores regionales son los encargados de llevar acabo esta tarea y paralelamente deben informar a la agencia financiera del resultado de las licitaciones de acuerdo a la normativa de éstas.
Con los montos asignados y los contratos firmados, se procede a confeccionar el calendario de desembolsos. En este calendario se estipula claramente el monto a desembolsar por proyecto trimestralmente, el cual es enviado a la agencia financiera correspondiente.
La programación física-financiera es confeccionada por las instituciones responsables de la ejecución del proyecto, en conjunto con las empresas externas que se harán cargo de su ejecución. Esta programación se confecciona una vez que han sido analizadas y definidas las actividades más relevante del proyecto, y se envía al Ministerio de Hacienda y/o Economía para su análisis y comentarios.
Cada sector, en base a las actividades que debe controlar confecciona un programa trimestral de avances físico-financiero, que se registra en un formulario especialmente confeccionado para tal efecto y que serán registrados en el BP. Este programa servirá de base para comparar los avances reales con los proyectados.
Finalmente en forma simultánea, se proporcionan los antecedentes de reprogramaciones trimestrales de la ejecución físico-financiera de los proyectos, las que deben practicarse cuando se verifiquen desviaciones significativas en el avance de los mismos. El registro de esta información en el Banco de Proyecto será de capital importancia ya que será utilizada más tarde para preparar informes agregados trimestrales sobre el resultado de la ejecución física-financiera de los proyectos de inversión.
Este conocimiento es llevado a un diagrama, el cual se construye utilizando herramientas que permiten "modelar" el sistema, este diagrama esta constituído por entidades, atributos y relaciones entre ellas, a este diagrama se le llama Modelo Conceptual y refleja fielmente las reglas del negocio y dominios de cada atributo que componen el BP. Es en el Modelo Conceptual donde se concentra todo el conocimiento y la problemática del sistema, es absolutamente necesario documentar profusamente cada entidad y atributo, así como también definir las validaciones lógicas para cada una de ellas.
Un buen Modelo Conceptual evita la dependencia de las personas que participaron en la generación del sistema, permite una generación del Modelo Físico fluída, ahorra una cantidad de tiempo razonable al generar automáticamente las tablas del sistema una vez construído el Modelo Físico y finalmente permite una programación "limpia".
III.-ARQUITECTURA FISICA DE UN BANCO DE PROYECTOS
Una vez elaborado el Modelo Conceptual existen herramientas que permiten generar automáticamente el Modelo Físico, generando tablas, campos, relaciones, validaciones, trigger, procedimientos e índices. Una vez generado el Modelo Físico es necesario revisar y evaluar el impacto de la implementación de este modelo en la plataforma de hardware a seleccionar.
Una de las grandes dudas que se plantean al momento de definir el tipo de arquitectura física en la cual se implementará el BP, es la distribución de las bases de datos, en general ello implica un análisis detallado de las necesidades de las unidades ejecutoras y la realidad de país en términos de infraestructura de comunicaciones.
Al utilizar una arquitectura distribuída inevitablemente se generan procesos adicionales para la integración de los datos, centralización de información mediante medios magnéticos y/ó vía electrónica, ello en general presenta problemas prácticos, tales como el envío de información a la unidad centralizadora, falla en los medios magnéticos que se utilizan para el traslado de la información, falla en las lineas de comunicación, validación de la información a centralizar, la cual debe ser validada nuevamente al momento de ser centralizada.
La ventaja de una arquitectura distribuída se centra en la economía de las estaciones de trabajo y la seguridad de la información al residir en equipos locales, claramente resulta más económico utilizar PC con bases de datos distribuídas y enviar esta información a través de diskette para su centralización, ello evita la instalación y configuración de complejos sistemas de comunicaciones, los cuales son difíciles de controlar y complejos de mantener, dependen de las compañías telefónicas locales y de la infraestructura que estas tenga para cubrir el área de interés.
La arquitectura centralizada tiene la enorme ventaja de evitar procesos de centralización de datos, pero requiere de una fuerte estructura de seguridad y comunicaciones. En lo que respecta a la seguridad es necesario armar complejos perfiles de usuario de manera de evitar la manipulación de información por parte de usuarios no autorizados, por otro lado el tema de las comunicaciones tampoco resulta trivial, es necesario controlar usuarios remotos, conmutados y dedicados, los cuales estan modificando permanentemente las bases de datos.
Felizmente con el abvenimiento de la arquitectura Cliente/Servidor, la tendencia a la utilización de modelos relacionales a sido la tónica en los últimos años, en general los primeros BP utilizaban modelos jerárquicos, los cuales eran muy rígidos en lo respecta a las relaciones entre las distintas entidades del modelo, siendo muy seguros respecto de las validaciones de consistencia.
La evolución de los PC permitió implementar BP complejos en redes de area local utilizando sistemas operativos simples pero inseguros, en general con lenguajes como Clipper, FoxPro, Basic, etc., claramente estos BP adolecian de varios problemas tales como, fragilidad de las bases de datos, inseguridad en las transacciones, niveles de seguridad usuaria pobre. En la medida que la tecnología de programación fue en avance, se implementó BP en plataforma más sólidas, utilizando motores de bases de datos, los cuales permiten un manejo y control sobre el modelo físico más eficiente.
Una vez terminado el Modelo Físico comienza el modelamiento de objetos y la programación de la aplicación, algunas herramientas permiten generar las pantallas básicas automáticamente, como paso posterior a la generación de las tablas del sistema, pero en general es necesario modificarlas para adecuarlas al estilo y a la presentación del sistema, no siendo recomendable utilizar esta opción, al final puede consumir demasiado tiempo de programación que construirlas desde cero de una vez.
En lo respecta al modelamiento de objetos, en esta actividad se identifican los objetos base y se determina cuales de ellos serán construídos por el programador y cuales serán adquiridos y/o construídos en forma externa. Los lenguajes de arquitectura abierta permiten la inclusión de objetos del tipo OCX, ActiveX y DLL, ellos le da una potencialidad insospechada, en la actualidad existe una cantidad importante de empresas desarrollando objetos de distintas característica, los cuales ahorran muchísimo tiempo de programación.
IV.-IMPLEMENTACIONES
Evidentemente él éxito en la implementación de un BP parte de un buen análisis del marco conceptual y las políticas y normas vigentes, en general podemos visualizar las siguientes etapas en el desarrollo de un BP:
Generación Modelo Conceptual
Generación Modelo Físico
Elaboración de Diccionario de Datos
Modelamiento de Objetos
Generación de Bases de Datos
Programación
Pruebas y Depuración
Marcha Blanca
Implementación
La planificación del desarrollo de un BP parte por asignación de responsables para cada una de las etapas anteriormente descritas, siendo necesario crear un grupo de desarrollo constituído por al menos los siguientes profesionales:
Experto en Sistema de Inversión Públicas
Analista de Sistema
Programador de Aplicaciones
Contraparte Técnica para implementación y pruebas
La cantidad de profesionales responsables para cada etapa pudiere variar dependiendo de la magnitud del BP, por ejemplo, de implementar una arquitectura distribuída como módulos operador directamente por unidades ejecutoras, será necesario mantener más de un programador y al menos dos profesionales a cargo del soporte para los usuarios externos y administración de las bases de datos.
Existen en el mercado herramienta más económicas para construir los modelos lógico y físico, pero en general es recomendable utilizar aquellas que permitan manejar diversos motores de bases de datos.
Respecto de los plazos tenemos la siguiente tabla:
Actividad Semanas
Generación Modelo Conceptual 8
Generación Modelo Físico 4
Elaboración de Diccionario de Datos 4
Modelamiento de Objetos 6
Generación de Bases de Datos 2
Programación 12
Pruebas y Depuración 4
Marcha Blanca 2
Implementación 2
TOTAL 44
Evidentemente los plazos pueden variar dependiendo de la magnitud y el grado de complejidad del BP a construir, lo cual influirá directamente sobre los costos de desarrollo en lo que respecta a los profesionales contratados.
Se trata de ambiente frágiles respecto de su seguridad y consistencia de datos, los cuales hacen necesarios generar procesos de verificación de datos. Las bases de datos que utilizan tienen relaciones y atributos que no contemplan su existencia , es decir, no es posible validar si un campo quedo vacío, a no ser de que se programe, lo mismo sucede con las relaciones, aquellas que son necesarias, como por ejemplo la existencia de un proyecto con su respectivo plan de financiamiento, es necesario programarlo.
Al utilizar este ambiente se pone demasiado esfuerzo en la programación para solventar deficiencias de las bases de datos y los lenguajes de aplicación, invirtiendo mucho tiempo y esfuerzo en ello. Todos lo que tenemos experiencia en el desarrollo de software, sabemos que el esfuerzo se debe focalizar en el Modelo Conceptual y Físico, de manera de optimizar la programación y evitar la ocurrencia de errores obvios.
En implementaciones más ambiciosas o con más recursos nos encontramos con arquitecturas del tipo MainFrame, donde la aplicación reside en un gran computador central el cual esta conectado a una serie de terminales "tontos" que reciben imágenes de los datos, los procesos y las bases de datos residen en el MainFrame, el cual asigna recurso y administra procesos.
El alto costo de mantención y la rigidez para realizar cambio, han sido razón para que este tipo de ambiente vaya en franca disminución, siendo rápidamente desplazados por arquitecturas del tipo Cliente/Servidor.
Es en esta arquitectura Cliente/Servidor donde encontramos más facilidades para la implementación de aplicaciones como los BP.
En esta arquitectura es posible determinar que procesos residirán en el Servidor y cuales serán de responsabilidad de los clientes, en general se trata de instalaciones donde nos encontramos con redes de PC, soportadas por uno o varios servidores de archivos, trabajando sobre Windows NT, Netware Novell, Unix, Solaris, etc..
Al utilizar este tipo de arquitectura es posible descansar sobre motores de bases de datos que provean atributos y relaciones estables y solidas sobre las tablas de datos, ello también permite utilizar programación orientada al objeto, la cual entrega enormes beneficios a la programación, tales como objetos reutilizables, utilización de servicios del sistema operativo (API), empaquetamiento de objetos comunes, etc…
Sin duda que en el futuro tendremos muchas aplicaciones corriendo sobre esta arquitectura, sobre todo porque ello permite la distribución eficiente de procesos, lo cual descongestiona las redes LAN y WAN.
En lo que se llama el "Front-End" para estas aplicaciones nos encontramos con lenguajes tales como; Visual Basic, PowerBuilder, Delphi, SQL Windows y otros nativos para algunos motores de datos. En general todos estos lenguajes permiten una buena conectividad con los motores de datos, siendo destacables la ductibilidad y la rapidez para el desarrollo de aplicaciones, Delphi 3.0 y Visual Basic 5.0, ambos cumplen sobradamente con los estándares de programación, pero además proveen al programador de una serie de herramientas, librerías OCX, PVCS que resuelven la mayoría de problemas de cualquier aplicación compleja y proveen de una arquitectura de programación abierta, lo que se traduce en la liberación de aplicaciones solidas y con bajo peso en cuanto a código contenido en la aplicación.
V.- EXPERIENCIAS
El consultor ha tenido una basta experiencia en el desarrollo e implementación de BP bajo distintas arquitecturas durante los últimos 15 años, participando en el desarrollo e implementación de los siguientes BP:
Chile
Honduras
Colombia
Aruba
El Salvador
Venezuela
Bolivia
Todos estos BP se encuentran en funcionamiento, es probable que varios de ellos hayan sido migrados a arquitectura Clientes/Servidor, generando versiones mejoradas, acorde con la realidad del país y el avance de la tecnología.
Para lograr éxito en la implementación de un BP es necesario considerar los siguientes puntos:
Apoyo Institucional y Unidades Ejecutoras
Análisis detallado de problemática de inversión pública
Arquitectura abierta
Utilización de herramientas y plataformas probadas
Programación orientada al objeto documentada
Implementación con compromiso
Soporte técnico orientado al cliente
Mucha paciencia
miércoles, julio 13, 2005
viernes, mayo 06, 2005
INTEGRACIÓN
1.-Introducción
La mayoría de las empresas medianas y grandes tienen sistemas computacionales funcionando que resuelven las aspectos más básicos de la problemática contable-administrativa. Partieron desarrollando sobre plataformas aún inmaduras, hasta los últimos sistemas liberados utilizando potentes motores de base datos e interfaces Web, estos sistemas funcionan en forma centralizada y satisfacen las necesidades más básicas de la mayoría de los procesos operacionales, dejando espacios enormes por cubrir en lo que respecta a gestión y las consultas externas, entiéndase clientes, proveedores y ejecutivos en terreno, además estas aplicaciones no logran "cruzar" horizantalmente la organización, lo cual impide la integración de la información al interior de la empresa.
Las empresas en general han desarrollado aplicaciones computacionales en casa, las cuales buscan suplir las deficiencias de los "ERP's", automatizando procesos propios que no están cubiertos por los ERP's, así como también desarrollando funcionalidades que permiten satisfacer requerimientos de clientes y proveedores. Aún no visualizan la importancia de integrar horizontalmente la organización, la información sigue fluyendo por voz y papeles.
Las empresas en CHILE al igual que en el resto del mundo ha invertido tiempo y esfuerzo en desarrollo de software, pero siempre los problemas para continuar y consolidar los desarrollos propios se deben básicamente a, una falta de claridad respecto de futuro informático de la empresa, desconocimiento de algunos procesos incrustados que existen en todas las empresas y no son considerados por parte de los "ERP's", falta de definición sobre el marco tecnológico donde estos sistemas deberían ser desarrollados y por último, la excesiva centralización de las aplicaciones corporativas.
La idea entonces, consiste en abordar el problema sin perder la visión general y con sistemas corporativos incluidos, con una visión de procesos y no de sistemas computacionales, analizar procesos previamente para posteriormente evaluar si es necesario construir. Considerar los sistemas corporativos como un dato, convivir con ellos en forma armónica, mantener la misma plataforma y en base a ello, trabajar en interfaces y/o pequeñas piezas de software que permitan eliminar la duplicidad de datos y procesos que tornan ineficiente el sistema en general.
Evidentemente el proyecto es complejo e implica un estudio acabado de la realidad actual, la modificación de algunos procesos que se verán afectados con la implementación de un sistema integrado, además implica el desarrollo de varias interfaces y soluciones anexas para el buen éxito del proyecto.
2.-Estrategia
Los principales sistemas computacionales en las empresas son los construidos en torno a una base de datos (Oracle, SQLServer, Sybase, DB2, etc..), estos sistemas que cumplen en gran medida con los requerimientos básicos y mas bien operativos de una oficina, funcionan en un ambiente excesivamente centralizado, lo que obliga mantener costosas líneas de conexión dedicadas para mantener actualizados los datos.
En un levantamiento preliminar en cualquier empresa podemos identificar los siguientes problemas:
1.-Sistemas computacionales centralizados con altos costos de operación
2.-Carencia de herramientas de gestión (corporativas y locales)
3.-Ausencia de aplicaciones horizontales
4.-Subexplotación de recursos informáticos
5.-Ausencia de documentación de algunas aplicaciones computacionales (en especial las desarrolladas localmente)
6.-Ausencia de aplicaciones de corran sobre una Intranet Local
7.-Desconocimiento de la estructura física de los sistemas computacionales en funcionamiento.
8.-Excesivos requerimientos al "encargado" de informática.
9.-Concentración de funciones y procesos en un mismo rol.
Para resolver esta problemática es aconsejable la conformación de un equipo de trabajo multidiciplinario que lidere un proyecto tecnológico y defina actividades y estrategia a seguir llevando un control estricto sobre todo el ámbito de acción. Este grupo (Grupo de Tecnología de la Información GTI) debe ser liderado por la gerencia de la empresa y definirá el Plan Informático, así como también coordinará el análisis de procesos, previo a la definición de que construir y/o modificar, determinando el impacto de los procesos sobre sistemas computacionales en funcionamiento y por supuesto sobre las personas que "soportan" estos procesos, ello los llevará a un modelamiento sólido y seguro.
En general como estrategia de desarrollo se propone desarrollar cada una de las aplicaciones bajo un ambiente integrado, dado las premuras de tiempo y la necesidad de implementar algunas aplicaciones rápidamente, no es posible construir un Modelo de Datos Corporativo, que seria el ideal, una suerte de mapa informático, en cual se pueda visualizar la totalidad de las entidades y procesos involucrados, sin embargo es posible llegar a ello mediante una estratégica de mejoramiento continuo, desarrollando modelos aislados para cada uno de los sistemas, considerando que en el futuro formaran parte del Modelo Corporativo de la empresa.
Cabe destacar que el valor agregado inmediato de esta estrategia, será la documentación de cada uno de los procesos y sistemas a construir y/o modificar, cosa que generalmente no se considera o simplemente no se hace en este tipo de desarrollos, de hecho, es muy extraño que las aplicaciones en funcionamiento están documentadas, sobre todo aquellas construídas por profesionales externos, a los cuales normalmente no se sabe que pedir.
Como tarea prioritaria es necesario revisar y modificar la arquitectura de directorio y perfiles de grupos de usuarios en los servidores que soportan las aplicaciones coorporativas, se consume demasiado tiempo en instalar y probar una aplicación debido a la poca claridad que hay respecto a los atributos que tiene un determinado directorio y los perfiles de los grupos asociados al directorio en cuestión. En este mismo sentido, es absolutamente necesario analizar y resolver un ordenamiento de los distintos directorios donde residen las aplicaciones en explotación. Ubicar una base de datos y/o tablas puede llegar a ser una tarea compleja, implica navegar varios minutos para encontrarla, no hay un conocimiento cabal del contenido de cada servidor y directorios residentes en él, simplemente se copia información sobre ellos sin discriminación, generando desorden y caos generalizado.
También es absolutamente necesario desarrollar una interfaz de usuario común para todas las aplicaciones que se construyan, ello genera seguridad al usuario y evita la capacitación inicial cada vez que se libera una nueva aplicación. Normalmente existen en las aplicaciones empresariales una serie de interfaces de usuario, llegándose al extremo de que cada aplicación tiene su propia interfaz, ello confunde y complica al usuario final.
En lo que respecta a las Intranet's, estas redes interna deberían contener aplicaciones que permitan integrar y relacionar a los funcionarios mediante la información. Aparentemente parece sencillo "armar" una Intranet con este contenido, pero precisamente la definición y estructuración de los contenidos son los elementos claves al interior de una Intranet, asi como también la mantención de la información que alli resida. Técnicamente es sencillo configurarlas y ponerlas en operación, pero el tema de los contenidos es complejo y debe ser analizado en profundidad, de manera que finalmente se cumpla con los objetivos de integrar horizontalmente la organización.
En la medida que se vayan liberando aplicaciones será necesario crear la función de Administrador de Base de Datos (DBA), el cual será responsable por el buen funcionamiento de los motores de bases de datos, perfiles de usuario, configuración de aplicaciones cliente/servidor, actualización de versiones, respaldos y por la consistencia de los datos que allí residan. Para cumplir esta función se necesita una persona con conocimientos del o los motores de datos que utilizan las aplicaciones empresariales, también un buen manejo de los software de respaldo y los paquetes de administración de datos.
Esto último resulta ser extremadamente importante, básicamente por que las empresas medianas (e incluso las grandes) tienden -erroneamente- a concentrar una serie de funciones/procesos en una misma persona, con una visión netamente económica, lo cual normalmente genera que todas o la mayoría de las funciones asignadas al profesional no se ejecuten eficientemente, o lo que es aún mas grave que simplemente no se ejecutan.
Lo anterior es gran importancia si se esta pensado en compartir y distribuir aplicaciones con terceros, en general al tener en explotación varias aplicaciones, las dudas y/o problemas que se presentan aumentan, siendo necesario asignar una persona exclusivamente para resolver estos problemas, lo cual generalmente no se cumple, pues exite la tendencia de centralizar todos los temas infomáticos en una sóla persona, por ende el tema de atención a usuario queda total y absolutamente colapsada.
Finalmente entonces la idea es analizar, construir, integrar y asignar funciones y procesos de acuerdo a un criterio de sistemas/procesos, considerando el valor agregado que ello producira a la organización.
La mayoría de las empresas medianas y grandes tienen sistemas computacionales funcionando que resuelven las aspectos más básicos de la problemática contable-administrativa. Partieron desarrollando sobre plataformas aún inmaduras, hasta los últimos sistemas liberados utilizando potentes motores de base datos e interfaces Web, estos sistemas funcionan en forma centralizada y satisfacen las necesidades más básicas de la mayoría de los procesos operacionales, dejando espacios enormes por cubrir en lo que respecta a gestión y las consultas externas, entiéndase clientes, proveedores y ejecutivos en terreno, además estas aplicaciones no logran "cruzar" horizantalmente la organización, lo cual impide la integración de la información al interior de la empresa.
Las empresas en general han desarrollado aplicaciones computacionales en casa, las cuales buscan suplir las deficiencias de los "ERP's", automatizando procesos propios que no están cubiertos por los ERP's, así como también desarrollando funcionalidades que permiten satisfacer requerimientos de clientes y proveedores. Aún no visualizan la importancia de integrar horizontalmente la organización, la información sigue fluyendo por voz y papeles.
Las empresas en CHILE al igual que en el resto del mundo ha invertido tiempo y esfuerzo en desarrollo de software, pero siempre los problemas para continuar y consolidar los desarrollos propios se deben básicamente a, una falta de claridad respecto de futuro informático de la empresa, desconocimiento de algunos procesos incrustados que existen en todas las empresas y no son considerados por parte de los "ERP's", falta de definición sobre el marco tecnológico donde estos sistemas deberían ser desarrollados y por último, la excesiva centralización de las aplicaciones corporativas.
La idea entonces, consiste en abordar el problema sin perder la visión general y con sistemas corporativos incluidos, con una visión de procesos y no de sistemas computacionales, analizar procesos previamente para posteriormente evaluar si es necesario construir. Considerar los sistemas corporativos como un dato, convivir con ellos en forma armónica, mantener la misma plataforma y en base a ello, trabajar en interfaces y/o pequeñas piezas de software que permitan eliminar la duplicidad de datos y procesos que tornan ineficiente el sistema en general.
Evidentemente el proyecto es complejo e implica un estudio acabado de la realidad actual, la modificación de algunos procesos que se verán afectados con la implementación de un sistema integrado, además implica el desarrollo de varias interfaces y soluciones anexas para el buen éxito del proyecto.
2.-Estrategia
Los principales sistemas computacionales en las empresas son los construidos en torno a una base de datos (Oracle, SQLServer, Sybase, DB2, etc..), estos sistemas que cumplen en gran medida con los requerimientos básicos y mas bien operativos de una oficina, funcionan en un ambiente excesivamente centralizado, lo que obliga mantener costosas líneas de conexión dedicadas para mantener actualizados los datos.
En un levantamiento preliminar en cualquier empresa podemos identificar los siguientes problemas:
1.-Sistemas computacionales centralizados con altos costos de operación
2.-Carencia de herramientas de gestión (corporativas y locales)
3.-Ausencia de aplicaciones horizontales
4.-Subexplotación de recursos informáticos
5.-Ausencia de documentación de algunas aplicaciones computacionales (en especial las desarrolladas localmente)
6.-Ausencia de aplicaciones de corran sobre una Intranet Local
7.-Desconocimiento de la estructura física de los sistemas computacionales en funcionamiento.
8.-Excesivos requerimientos al "encargado" de informática.
9.-Concentración de funciones y procesos en un mismo rol.
Para resolver esta problemática es aconsejable la conformación de un equipo de trabajo multidiciplinario que lidere un proyecto tecnológico y defina actividades y estrategia a seguir llevando un control estricto sobre todo el ámbito de acción. Este grupo (Grupo de Tecnología de la Información GTI) debe ser liderado por la gerencia de la empresa y definirá el Plan Informático, así como también coordinará el análisis de procesos, previo a la definición de que construir y/o modificar, determinando el impacto de los procesos sobre sistemas computacionales en funcionamiento y por supuesto sobre las personas que "soportan" estos procesos, ello los llevará a un modelamiento sólido y seguro.
En general como estrategia de desarrollo se propone desarrollar cada una de las aplicaciones bajo un ambiente integrado, dado las premuras de tiempo y la necesidad de implementar algunas aplicaciones rápidamente, no es posible construir un Modelo de Datos Corporativo, que seria el ideal, una suerte de mapa informático, en cual se pueda visualizar la totalidad de las entidades y procesos involucrados, sin embargo es posible llegar a ello mediante una estratégica de mejoramiento continuo, desarrollando modelos aislados para cada uno de los sistemas, considerando que en el futuro formaran parte del Modelo Corporativo de la empresa.
Cabe destacar que el valor agregado inmediato de esta estrategia, será la documentación de cada uno de los procesos y sistemas a construir y/o modificar, cosa que generalmente no se considera o simplemente no se hace en este tipo de desarrollos, de hecho, es muy extraño que las aplicaciones en funcionamiento están documentadas, sobre todo aquellas construídas por profesionales externos, a los cuales normalmente no se sabe que pedir.
Como tarea prioritaria es necesario revisar y modificar la arquitectura de directorio y perfiles de grupos de usuarios en los servidores que soportan las aplicaciones coorporativas, se consume demasiado tiempo en instalar y probar una aplicación debido a la poca claridad que hay respecto a los atributos que tiene un determinado directorio y los perfiles de los grupos asociados al directorio en cuestión. En este mismo sentido, es absolutamente necesario analizar y resolver un ordenamiento de los distintos directorios donde residen las aplicaciones en explotación. Ubicar una base de datos y/o tablas puede llegar a ser una tarea compleja, implica navegar varios minutos para encontrarla, no hay un conocimiento cabal del contenido de cada servidor y directorios residentes en él, simplemente se copia información sobre ellos sin discriminación, generando desorden y caos generalizado.
También es absolutamente necesario desarrollar una interfaz de usuario común para todas las aplicaciones que se construyan, ello genera seguridad al usuario y evita la capacitación inicial cada vez que se libera una nueva aplicación. Normalmente existen en las aplicaciones empresariales una serie de interfaces de usuario, llegándose al extremo de que cada aplicación tiene su propia interfaz, ello confunde y complica al usuario final.
En lo que respecta a las Intranet's, estas redes interna deberían contener aplicaciones que permitan integrar y relacionar a los funcionarios mediante la información. Aparentemente parece sencillo "armar" una Intranet con este contenido, pero precisamente la definición y estructuración de los contenidos son los elementos claves al interior de una Intranet, asi como también la mantención de la información que alli resida. Técnicamente es sencillo configurarlas y ponerlas en operación, pero el tema de los contenidos es complejo y debe ser analizado en profundidad, de manera que finalmente se cumpla con los objetivos de integrar horizontalmente la organización.
En la medida que se vayan liberando aplicaciones será necesario crear la función de Administrador de Base de Datos (DBA), el cual será responsable por el buen funcionamiento de los motores de bases de datos, perfiles de usuario, configuración de aplicaciones cliente/servidor, actualización de versiones, respaldos y por la consistencia de los datos que allí residan. Para cumplir esta función se necesita una persona con conocimientos del o los motores de datos que utilizan las aplicaciones empresariales, también un buen manejo de los software de respaldo y los paquetes de administración de datos.
Esto último resulta ser extremadamente importante, básicamente por que las empresas medianas (e incluso las grandes) tienden -erroneamente- a concentrar una serie de funciones/procesos en una misma persona, con una visión netamente económica, lo cual normalmente genera que todas o la mayoría de las funciones asignadas al profesional no se ejecuten eficientemente, o lo que es aún mas grave que simplemente no se ejecutan.
Lo anterior es gran importancia si se esta pensado en compartir y distribuir aplicaciones con terceros, en general al tener en explotación varias aplicaciones, las dudas y/o problemas que se presentan aumentan, siendo necesario asignar una persona exclusivamente para resolver estos problemas, lo cual generalmente no se cumple, pues exite la tendencia de centralizar todos los temas infomáticos en una sóla persona, por ende el tema de atención a usuario queda total y absolutamente colapsada.
Finalmente entonces la idea es analizar, construir, integrar y asignar funciones y procesos de acuerdo a un criterio de sistemas/procesos, considerando el valor agregado que ello producira a la organización.
jueves, abril 28, 2005
Reglas del Negocio
Las reglas de negocios fueron desconocidas por muchos años para el común de la gente, es más, ni siquiera los profesionales de la informática las habían identificado ni menos definido y estipulado en la construcción de sistemas.
En la medida que fueron evolucionando las herramientas de diseño y modelamiento de sistemas, las reglas de negocios surgieron como una forma de definir aquellos limites y condiciones de borde tan comunes en cualquier modelo de negocio.
Finalmente se definió claramente de que se trata una regla de negocio, este documento pretende definir los conceptos generales en torno a las reglas de negocios y sus alcances en la arquitectura de los sistemas informáticos y procesos asociados, esta metodología puede aplicarse a cualquier modelo de procesos y por ende de negocios.
Una regla de negocio es un conjunto de instrucciones que aportan el conocimiento al modelo del sistema y permiten definir eventos y procedimientos al interior del proceso, configurando “él cómo y cuando” se deben hacer las cosas.
En el nivel conceptual
Una regla de negocio en el modelo conceptual es una guía y documentación del sistema, la cual queda inserta dentro del modelo permitiendo que otras personas, ajenas a los generadores del modelo, tengan acceso a este conocimiento.
En el nivel físico
Durante la generación del modelo físico desde el modelo conceptual, se transfieran todas las reglas del negocio al modelo físico, las cuales serán aplicadas a cada objeto y dependerán del motor de base de datos a utilizar.
Tipos de Reglas de Negocio
Definición: Característica o propiedad de un objeto dentro del sistema.
Ejemplo : Un cliente es una persona que se identifica por Rol Unico Tributario y tiene un nombre y domicilio conocido.
Tácita : Define la existencia y dimensión de la información dentro del sistema.
Ejemplo : Un cliente puede tener una o varias direcciones.
Formula : Define un determinado calculo que debe emplear el sistema
Ejemplo: El total de una factura esta dado por la suma de su detalle.
Validación: Define los posibles valores válidos para un determinado proceso o variable dentro del sistema
Ejemplo : La suma total de las facturas emitidas a un cliente no puede ser mayor que el crédito otorgado al mismo.
En modelo conceptual predominan las reglas de negocio tipo Definición y Tácitas en forma de texto, allí se deben describir claramente cuales son los procesos asociados a cada evento y como deben funcionar.
En modelo físico las reglas de negocio se transforman de “triggers”, “store procedures”, rutinas de calculo y rutinas de validación, las cuales más tarde serán traspasadas al motor de base de datos y al código, dependiendo del criterio a utilizar en la implementación del modelo, pudiendo definirse como reglas a manejar por el Server o Cliente.
Dominios
Los dominios ayudar a identificar los tipos de información dentro del modelo, definen las validaciones y los posibles estados de una determinada variable.
Los dominios son aplicados a los campos y tablas del sistema en el modelo físico, ello permite estandarizar las validaciones y los tipos de campos. Resulta conveniente definir a nivel conceptual dominios genéricos, de manera de agrupar varios atributos que son homogéneos bajo un mismo dominio, ello permite disminuir la generación de código para solventar algunas validaciones.
Ejemplos:
Fecha
Tipo : fecha
Valor mínimo : 1990
Valor máximo : 2099
Formato : 99/99/9999
Sexo
Tipo : Carácter largo 1
Valores válidos : “M”, “F”
Formato : X
Sucursales
Tipo : Numérico de 4
Valores válidos : sobre tabla de códigos
Formato : ####
En la medida que fueron evolucionando las herramientas de diseño y modelamiento de sistemas, las reglas de negocios surgieron como una forma de definir aquellos limites y condiciones de borde tan comunes en cualquier modelo de negocio.
Finalmente se definió claramente de que se trata una regla de negocio, este documento pretende definir los conceptos generales en torno a las reglas de negocios y sus alcances en la arquitectura de los sistemas informáticos y procesos asociados, esta metodología puede aplicarse a cualquier modelo de procesos y por ende de negocios.
Una regla de negocio es un conjunto de instrucciones que aportan el conocimiento al modelo del sistema y permiten definir eventos y procedimientos al interior del proceso, configurando “él cómo y cuando” se deben hacer las cosas.
En el nivel conceptual
Una regla de negocio en el modelo conceptual es una guía y documentación del sistema, la cual queda inserta dentro del modelo permitiendo que otras personas, ajenas a los generadores del modelo, tengan acceso a este conocimiento.
En el nivel físico
Durante la generación del modelo físico desde el modelo conceptual, se transfieran todas las reglas del negocio al modelo físico, las cuales serán aplicadas a cada objeto y dependerán del motor de base de datos a utilizar.
Tipos de Reglas de Negocio
Definición: Característica o propiedad de un objeto dentro del sistema.
Ejemplo : Un cliente es una persona que se identifica por Rol Unico Tributario y tiene un nombre y domicilio conocido.
Tácita : Define la existencia y dimensión de la información dentro del sistema.
Ejemplo : Un cliente puede tener una o varias direcciones.
Formula : Define un determinado calculo que debe emplear el sistema
Ejemplo: El total de una factura esta dado por la suma de su detalle.
Validación: Define los posibles valores válidos para un determinado proceso o variable dentro del sistema
Ejemplo : La suma total de las facturas emitidas a un cliente no puede ser mayor que el crédito otorgado al mismo.
En modelo conceptual predominan las reglas de negocio tipo Definición y Tácitas en forma de texto, allí se deben describir claramente cuales son los procesos asociados a cada evento y como deben funcionar.
En modelo físico las reglas de negocio se transforman de “triggers”, “store procedures”, rutinas de calculo y rutinas de validación, las cuales más tarde serán traspasadas al motor de base de datos y al código, dependiendo del criterio a utilizar en la implementación del modelo, pudiendo definirse como reglas a manejar por el Server o Cliente.
Dominios
Los dominios ayudar a identificar los tipos de información dentro del modelo, definen las validaciones y los posibles estados de una determinada variable.
Los dominios son aplicados a los campos y tablas del sistema en el modelo físico, ello permite estandarizar las validaciones y los tipos de campos. Resulta conveniente definir a nivel conceptual dominios genéricos, de manera de agrupar varios atributos que son homogéneos bajo un mismo dominio, ello permite disminuir la generación de código para solventar algunas validaciones.
Ejemplos:
Fecha
Tipo : fecha
Valor mínimo : 1990
Valor máximo : 2099
Formato : 99/99/9999
Sexo
Tipo : Carácter largo 1
Valores válidos : “M”, “F”
Formato : X
Sucursales
Tipo : Numérico de 4
Valores válidos : sobre tabla de códigos
Formato : ####
viernes, abril 22, 2005
Transferencia de Archivos Multimediales
En la industria publicitaria, asi como otras industrias (Cine, Audio, etc...), existe la necesidad de enviar y recibir archivos digitales de gran tamaño, normalmente se utilizan los servidores de correos para ello, lo cual torna lento e insegura la transferencia, en muchos casos los servidores de correos simplemente rechazan archivos que exceden los 5Mb. La solución "Transferencia de Archivos Multimediales" (TAM) es una herramienta para la transmisión de archivos "pesados" a alta velocidad sobre TCP/IP de arquitectura "punto a punto" y cliente-servidor, la cual consta de dos componente, el servidor de datos, software que corre en una maquina la cual contiene la o las carpetas a compartir con otros usuarios, y el cliente que se carga en la maquina que accede a los archivos compartidos. La aplicación permite que los usuarios se conecten directamente con el servidor de datos de la empresa, sin pasar por ningún servidor adicional, ello optimiza la velocidad de transferencia y seguridad de la aplicación, evitando la transferencia de archivos por los servidores de correos, siempre complicados con el tráfico y tamaño de los archivos atachados. Una empresa puede tener varios servidores TAM funcionando, ubicados físicamente en distintas partes, los usuarios que acceden a ellos son autenticados por los proveedores de la solución (http://www.infotecnologia.com/), pero generados y mantenidos por la empresa que recibe el servicio. Cada empresas tiene sus propios servidores y grupos de usuarios, los cuales NO pueden ver las carpetas entre sí al menos que el administrador le asigne los privilegios adecuados. Se trata de una arquitectura totalmente abierta donde un usuario puede acceder a los archivos desde cualquier estación de trabajo corriendo plataforma Windows y conectado a la Internet, la velocidad de transferencia dependera de la velocidad del cliente y el tráfico que en ese momento tenga el servidor de datos (Host). El cliente accede a la dirección http://pttk.dnsalias.com:8080/discovirtual/dv.htm por medio del Browser (IE, NetScape, Opera) y carga un componente ActiveX la primera vez, luego ingresa su Nombre Usuario y Clave. La carga del ActiveX demora entre 10 y 15 minutos dependiendo de la velocidad de conexión del cliente, para ello es necesario que la seguridad del explorador permita la instalación componentes ActiveX sin firmar (ver apendice), ello es posible configurar mediante la opción "Herramientas" y luego "Seguridad" del Browser (IE6 por ejemplo)
lunes, abril 18, 2005
Venta Proyectos Tecnologicos
El éxito económico en el desarrollo de aplicaciones consiste en replicar la venta de los productos ya desarrollados y/o variaciones de los mismos, en este sentido los esfuerzos de las empresas desarrolladoras deben ir orientados a ofrecer y/o recomendar productos que estén en su línea de producción.
Proyectos de desarrollo completos, en los cuales se requiere analizar y entender la funcionalidad y procesos a automatizar, o proyectos "para arreglar" y/o en plataforma en los cuales no se tenga la experiencia necesaria deben ser desechados. Estos proyectos implican un gran consumo de recursos y tiempo, normalmente el cliente no esta dispuesto a pagar por ello.
Los procesos involucrados en la venta de proyectos tecnológicos son los siguientes:
1. Entrevista con el cliente
Se lleva a cabo una reunión con el cliente, la cual debe ser concreta precisa, escuchar al cliente, jamás ofrecer soluciones antes de escuchar.
En esta reunión(es) debe definirse los alcances del sistema a desarrollar, para posteriormente realizar un levantamiento técnico de requerimientos. Todo aquello si el cliente manifiesta interés en continuar la relación comercial.
2. Levantamiento Requerimientos
Ya sea se trate de proyectos en los cuales el cliente ya tiene confeccionado el “Informe de Requerimientos” y/o sea necesario elaborar el documento, el desarrollador debe validar dichos requerimientos y en conjunto con el cliente, revisar y aprobar la funcionalidad a desarrollar y el diseño de frame's asociados.
3. Cotización y Propuesta
Sobre la base del "Informe de Requerimientos" se construye la propuesta comercial donde se estipulan plazos y costos, adjuntando dicho informe el cual se transformará en el único documento de referencia para el desarrollo del proyecto.
En la cotización se deben definir “hitos” y no fechas, esto se debe a que en el proceso de desarrollo existen una serie de actividades que no depende del desarrollador, como por ejemplo las pruebas de las versiones “Beta” a realizar por el cliente, comprometerse a fecha de entrega puede ser extremadamente riesgoso y se transforma rapidamente en una fuente de conflictos.
Entiendase como “Hito” aquella instancia en la cual se finaliza una determinada actividad y/o proceso definido con anterioridad. Por ejemplo, los Hitos normales en un desarrollo son los siguientes:
1. Entrega funcionalidad/frame al cliente
2. Aprobación funcionalidad y diseño frame por cliente
3. Término programación aplicación I
4. Entrega BETA cliente
5. Termino pruebas BETA cliente, con las observaciones pertinentes
6. Aprobación BETA cliente
7. Termino programación aplicación II
8. Inicio pruebas versión definitiva
9. Entrega aplicación
Las actividades 4 y 5 puedes repetirse varias veces hasta que el cliente apruebe el BETA.
4. Orden de Compra
Con la recepción de la Orden de Compra del cliente, se procede a FACTURAR inmediatamente de acuerdo a lo estipulado en la cotización previa.
Con el cumplimiento de este "Hito" comienza el desarrollo de la aplicación.
5. Cobrar
En base a lo estipulado en la cotización se procede a cobrar de acuerdo al avance del proyecto.
6. Seguimiento
Semanalmente se deberá informar sobre el estado del avance de cada proyecto en curso.
7. Termino de la etapa de desarrollo y pruebas
Una vez que el desarrollaodor informe el término de las pruebas "Beta" se coordina una reunión para dar por terminado formalmente el proyecto.
No esta considerado dentro de estos procesos la confección de contrato de desarrollo de software, no se esta abordando la problemática de desarrollo específicos, los que necesariamente requieren de un contrato de por medio, sólo nos concentraremos en esta oportunidad, en la “personalización” de productos ya desarrollados.
Cabe destacar que todos estos procesos están cubiertos y controlados por la herramienta “Contactos Comerciales”, la cual mantiene una historia de las acciones (reuniones, llamadas, email) realizadas con los clientes, así como también los vínculos con los doctos enviados y recibidos que tiene relación con el proyecto.
Proyectos de desarrollo completos, en los cuales se requiere analizar y entender la funcionalidad y procesos a automatizar, o proyectos "para arreglar" y/o en plataforma en los cuales no se tenga la experiencia necesaria deben ser desechados. Estos proyectos implican un gran consumo de recursos y tiempo, normalmente el cliente no esta dispuesto a pagar por ello.
Los procesos involucrados en la venta de proyectos tecnológicos son los siguientes:
1. Entrevista con el cliente
Se lleva a cabo una reunión con el cliente, la cual debe ser concreta precisa, escuchar al cliente, jamás ofrecer soluciones antes de escuchar.
En esta reunión(es) debe definirse los alcances del sistema a desarrollar, para posteriormente realizar un levantamiento técnico de requerimientos. Todo aquello si el cliente manifiesta interés en continuar la relación comercial.
2. Levantamiento Requerimientos
Ya sea se trate de proyectos en los cuales el cliente ya tiene confeccionado el “Informe de Requerimientos” y/o sea necesario elaborar el documento, el desarrollador debe validar dichos requerimientos y en conjunto con el cliente, revisar y aprobar la funcionalidad a desarrollar y el diseño de frame's asociados.
3. Cotización y Propuesta
Sobre la base del "Informe de Requerimientos" se construye la propuesta comercial donde se estipulan plazos y costos, adjuntando dicho informe el cual se transformará en el único documento de referencia para el desarrollo del proyecto.
En la cotización se deben definir “hitos” y no fechas, esto se debe a que en el proceso de desarrollo existen una serie de actividades que no depende del desarrollador, como por ejemplo las pruebas de las versiones “Beta” a realizar por el cliente, comprometerse a fecha de entrega puede ser extremadamente riesgoso y se transforma rapidamente en una fuente de conflictos.
Entiendase como “Hito” aquella instancia en la cual se finaliza una determinada actividad y/o proceso definido con anterioridad. Por ejemplo, los Hitos normales en un desarrollo son los siguientes:
1. Entrega funcionalidad/frame al cliente
2. Aprobación funcionalidad y diseño frame por cliente
3. Término programación aplicación I
4. Entrega BETA cliente
5. Termino pruebas BETA cliente, con las observaciones pertinentes
6. Aprobación BETA cliente
7. Termino programación aplicación II
8. Inicio pruebas versión definitiva
9. Entrega aplicación
Las actividades 4 y 5 puedes repetirse varias veces hasta que el cliente apruebe el BETA.
4. Orden de Compra
Con la recepción de la Orden de Compra del cliente, se procede a FACTURAR inmediatamente de acuerdo a lo estipulado en la cotización previa.
Con el cumplimiento de este "Hito" comienza el desarrollo de la aplicación.
5. Cobrar
En base a lo estipulado en la cotización se procede a cobrar de acuerdo al avance del proyecto.
6. Seguimiento
Semanalmente se deberá informar sobre el estado del avance de cada proyecto en curso.
7. Termino de la etapa de desarrollo y pruebas
Una vez que el desarrollaodor informe el término de las pruebas "Beta" se coordina una reunión para dar por terminado formalmente el proyecto.
No esta considerado dentro de estos procesos la confección de contrato de desarrollo de software, no se esta abordando la problemática de desarrollo específicos, los que necesariamente requieren de un contrato de por medio, sólo nos concentraremos en esta oportunidad, en la “personalización” de productos ya desarrollados.
Cabe destacar que todos estos procesos están cubiertos y controlados por la herramienta “Contactos Comerciales”, la cual mantiene una historia de las acciones (reuniones, llamadas, email) realizadas con los clientes, así como también los vínculos con los doctos enviados y recibidos que tiene relación con el proyecto.
Generación DVD
En la generación de DVD's por medio de un computador en la plataforma Intel-Pentium, se deben procesar distintos archivos y por ende ejecutar un serie de procesos, los cuales son complejos y dependen en su gran mayoría del hardware que los soporte.
Existe una infinidad de programas y/o aplicaciones para generar DVD's (Nero ,Studio 7), todas estas aplicaciones contienen o resuelven algunos y/o la totalidad de los procesos aqui identificados.
Sean identificados los siguientes procesos básicos:
1.-Obtensión de medios gráficos, fotos, peliculas, diapositivas digitalizadas, etc...
2.-Selección y clasificación de elementos gráficos.
3.-Procesamiento de imagenes, mejoramiento de calidad
4.-Selección banda de musica asociada a la presentación y/o película
5.-Grabación de banda de audio, relato y/o descripción personalizada para una o varias secuencias de la pelicula.
6.-Selección de elementos de transición y titulos a utilizar al comienzo y fin de cada capitulo, los capitulos se muestran como opciones en el menu de las maquinas reproductoras de DVD.
7.-Generación de la secuencia completa, se inserta los elementos graficos y de audio, esto es lo que llamamos el "proceso creativo", donde realmente esta lo importante y el contenido del DVD.
8.-Proceso de composición ("renderización"), proceso que en una maquina Pentium III de 750Mhz, para 1 minuto de pelicula toma 5 minutos de proceso.
9.-Generación de capitulos y menu a desplegar en el reproductor de DVD, la pelicula y/o secuncia de imagenes se puede dividir en capitulos y/o secciones de manera de facilitar la navegación.
10.-Grabación DVD, normalmente 1 minuto de pelicula toma 5 minutos, obviamente esto depende de la velocidad de grabación del lector-grabador de DVD.
Claramente los procesos de "renderización" y generación de archivos ".Mpg" son los que consumen mas tiempo. Tomando como referencia una pelicula de 1 minuto de duración, el proceso completo puede llegar tomar 14 min., generando un archivo de 24Mb.
Evidentemente que utilizando equipos con mayor velocidad de proceso los tiempos pueden variar significativamente, ahora bien, el procesamiento completo de una secuencia de imagenes en la plataforma Pentium III puede llegar a tomar 14hr para 1 hr de pelicula, lo cual claramente imposibilita el procesamiento y generación masivo de DVD
Existe una infinidad de programas y/o aplicaciones para generar DVD's (Nero ,Studio 7), todas estas aplicaciones contienen o resuelven algunos y/o la totalidad de los procesos aqui identificados.
Sean identificados los siguientes procesos básicos:
1.-Obtensión de medios gráficos, fotos, peliculas, diapositivas digitalizadas, etc...
2.-Selección y clasificación de elementos gráficos.
3.-Procesamiento de imagenes, mejoramiento de calidad
4.-Selección banda de musica asociada a la presentación y/o película
5.-Grabación de banda de audio, relato y/o descripción personalizada para una o varias secuencias de la pelicula.
6.-Selección de elementos de transición y titulos a utilizar al comienzo y fin de cada capitulo, los capitulos se muestran como opciones en el menu de las maquinas reproductoras de DVD.
7.-Generación de la secuencia completa, se inserta los elementos graficos y de audio, esto es lo que llamamos el "proceso creativo", donde realmente esta lo importante y el contenido del DVD.
8.-Proceso de composición ("renderización"), proceso que en una maquina Pentium III de 750Mhz, para 1 minuto de pelicula toma 5 minutos de proceso.
9.-Generación de capitulos y menu a desplegar en el reproductor de DVD, la pelicula y/o secuncia de imagenes se puede dividir en capitulos y/o secciones de manera de facilitar la navegación.
10.-Grabación DVD, normalmente 1 minuto de pelicula toma 5 minutos, obviamente esto depende de la velocidad de grabación del lector-grabador de DVD.
Claramente los procesos de "renderización" y generación de archivos ".Mpg" son los que consumen mas tiempo. Tomando como referencia una pelicula de 1 minuto de duración, el proceso completo puede llegar tomar 14 min., generando un archivo de 24Mb.
Evidentemente que utilizando equipos con mayor velocidad de proceso los tiempos pueden variar significativamente, ahora bien, el procesamiento completo de una secuencia de imagenes en la plataforma Pentium III puede llegar a tomar 14hr para 1 hr de pelicula, lo cual claramente imposibilita el procesamiento y generación masivo de DVD
Pruebas Software
En el ciclo de desarrollo de software una de las etapas mas importantes son las pruebas a las piezas de software desarrolladas y luego a los sistemas construídos en base a estas piezas y/o componentes de software.
Un proceso de pruebas de software requiere habitualmente de mucho tiempo y esfuerzo que el desarrollo propiamente tal (alrededor de un 60% del tiempo de desarrollo lo consumen las pruebas), se necesitan metodologías, herramientas y conocimientos adecuados.
Básicamente en este documento se analizaran los siguientes tipos de pruebas:
Las pruebas de caja negra son aquellas que se enfocan directamente en el exterior del módulo, sin importar el código, son pruebas funcionales en las que se trata de encontrar fallas generales y que no estan en el ámbito de su especificación, como ser interfaz con el usuario, apariencia de los menús, control de las teclas, etcétera. Este tipo de pruebas no es aplicable a los módulos que trabajan en forma transparente al usuario, entíendase rutinas y/o procedimientos internos.
Para realizar estas pruebas existe una técnica algebraica llamada "clases de equivalencia", consiste en tratar a todos las posibles entradas y parámetros como un modelo algebraico, y utilizar las clases de este modelo para probar un amplio rango de posibilidades.
Para la generación de estas clases no se puede armar un modelo, pero se pueden seguir las siguientes pautas como guía utilizable para la creación de cada clase. Por ejemplo: Cuando una entrada es booleana, existen solo dos clases, verdadero o falso. Para una entrada que está comprendida dentro de un rango, existen tres clases, por debajo, dentro, y por encima del rango.Utilizando este ejemplo se pueden generar las distintas clases aplicables al módulo en cuestión, luego, se procede a ingresarle al módulo un valor de cada clase.
Las pruebas de caja blanca son mucho mas amplias, normalmente se denominan pruebas de cobertura o pruebas de caja transparente, al total de pruebas se caja blanca se le llama cobertura, la cobertura es un número porcentual que indica cuanto código del programa se ha probado.
Básicamente la idea de pruebas de cobertura consiste en diseñar un plan de pruebas en las cuales se vaya ejecutando sistemáticamente el código hasta que haya corrido todo o la gran mayoría de él, esto que parece complicado, es mas aún cuando el programa contiene código de difícil alcance, como por ejemplo manejadores de errores o "código muerto".
Entiéndase por código muerto a aquellas funciones y/o procedimientos que hemos incluido por encontrarse en librerias pero que no son ejecutadas por el programa directamente. Para los módulos que no poseen condiciones basta con ejecutar una vez el programa para asegurar una cobertura total.Es importante que el diseño de cobertura sea eficiente y lo menos redundante posible, por ejemplo, en el siguiente código:
If Variable_Booleana..Do Modulo_XEndIf
Como no hay un "else", a simple vista con ejecutar una vez con éxito la condición bastaría, en términos de cobertura es así, pero entendiendo que el "Modulo_X" podría modificar variables o valores que afecten a la ejecución del resto del código habría que ejecutar 2 veces la condición, una satisfaciendo y otra no.
Respecto al siguiente ejemplo:
If Variable_Booleana1 .Or. Variable_Booleana2..Do Modulo_XEnd
O este otro:
If Variable_Booleana1 .And. Variable_Booleana2..Do Modulo_XEnd
A simple vista y considerando que ambas variables pueden tener 2 valores se precisarían 4 pruebas para realizar la cobertura, pero esto no es así, solo es necesario 2 pruebas en el caso que el Modulo_X pueda interferir de alguna manera en el programa o una sola satisfaciendo la condición si el Modulo_X no alterara de ninguna manera con el resto de los procedimientos y condiciones a ejecutarse.Probado las 4 posibilidades solo estaríamos probando que funcione el comando "IF" en sí, lo cual ya fue probado por el desarrollador del lenguaje de programación.
Con respecto a la cobertura en bucles (for, while) el tema es un poco mas delicado, a simple vista un bucle no es mas que un salto condicional que se repite hasta que se cumpla o deje de cumplirse una o mas condiciones, en teoría esto es simple, pero en la práctica son una fuente inagotable de versátiles errores, que en su gran mayoría suelen ser catastróficos.
En primer lugar, la cantidad de veces que se ejecute un bucle debe ser precisa, y todos los programadores saben que no es difícil equivocarse y programar un bucle que se ejecute una vez de mas o una vez de menos, siempre que esto suceda los resultados serán indeseables, y muchas veces cuando se trate de manejos de datos complicados de calcular no será fácil advertir el error, el cual será caro cuando se trate de valores que se utilizan para tomar determinaciones a nivel empresarial.
Para realizar la cobertura total de un bucle se necesitan 3 pruebas, cero ejecuciones, una ejecución y mas de una ejecución.
Los bucles de tipo "for", parecerían ser mas sencillos, ya que la cantidad de ejecuciones es definida por su cabecera y controlada por el compilador, con una ejecución bastaría para una cobertura total, siempre y cuando no contengan código que altere el valor de la variable de control o comandos de salida (Exit), en este caso requiere un examen un poco mas detallado ya que el bucle deja de ser responsabilidad del lenguaje compilador y pasa a ser del programador.Particularmente no es aconsejable que se utilicen bucles "for" modificando su variable de control o incluyendo en ellos comandos de salida.
En pocas palabras es muy importante diseñar lo mas precisamente posible las pruebas de cobertura, para que quede en lo posible la mayor parte del código probado con la mínima cantidad de pruebas realizadas.
Hay que tener en cuenta dos puntos importantes, en primer lugar las pruebas de caja blanca no reemplazan, solo complementan a las de caja negra y de aceptación, y en segundo lugar, las pruebas de cobertura deben ser realizadas una ves terminado el software y no deben ser confundidas con las pruebas informales y/o básicas que realiza el programador en momentos de desarrollo, dado que si bien estas van cubriendo distintos fragmentos de cada módulo, nunca son eficaces por no tener un diseño apropiado.
El valor porcentual de pruebas de cobertura de un sistema terminado nunca deberá ser inferior al 51%, y elevándose en función al costo que podría ocasionar las fallas posibles, ascendiendo a un 99% cuando estén involucradas vidas humanas o cuando la falla no da una segunda oportunidad.
El uso de un depurador es muy útil en las pruebas de cobertura, ya que se pueden ir viendo todas las líneas y ejecuciones paso a paso, esto no muy práctico y es bastante tedioso, pero es considerablemente efectivo.
Pruebas de aceptación, son las que hará el cliente, en esta fase de pruebas se determina que el sistema cumple con el objetivo deseado, determina la conformidad del cliente antes de que el programa le sea entregado como una versión final.
Las pruebas conocidas con el nombre de pruebas de rendimiento son aquellas que determinan los tiempos de respuesta, el espacio que ocupa el módulo en disco o en memoria, el flujo de datos que genera a través de un canal de comunicaciones, etc..
Pruebas de transformación, este método curioso y caro aún se pone en funcionamiento por diversas empresas, consiste en dividir el equipo de desarrollo en dos partes una vez realizadas todas las pruebas y corregidos todos los errores, luego una de las dos partes introduce pequeños errores en el sistema y la otra parte debe encontrarlos con los mismos procedimientos que se usaron para buscar los errores nativos. Esto es muy costoso y consume grandes cantidades de tiempo.
Pruebas de robustez, comúnmente denominadas "robustness test" son las encargadas de verificar la capacidad del programa para soportar entradas incorrectas, por ejemplo en un sistema de facturación donde el usuario debe ingresar códigos de productos y luego cantidades es mas que factible que en algún momento ingrese un código en el campo de cantidad, si el programa fue sometido a pruebas de robustez este valor sería rechazado o grabado como una cantidad inmensa pero que no daría error por desbordamiento de datos.
Las denominadas pruebas de resistencia se utilizan para saber hasta donde puede soportar el programa condiciones extremas, por ejemplo los tiempos de respuesta con el procesador a un 95% de su utilidad o con muy poco espacio en disco.
Esta metodología es utilizada por InfoTecnologia en el desarrollo de aplicaciones cliente-servidor y móviles, donde las pruebas resultan ser extremadamente críticas debido a la dinámica que posee la tecnología móvil.
Un proceso de pruebas de software requiere habitualmente de mucho tiempo y esfuerzo que el desarrollo propiamente tal (alrededor de un 60% del tiempo de desarrollo lo consumen las pruebas), se necesitan metodologías, herramientas y conocimientos adecuados.
Básicamente en este documento se analizaran los siguientes tipos de pruebas:
Caja negra
Cobertura (Caja Blanca)
Aceptación
Rendimiento
Robustez
Cuando se considera terminado un módulo o pieza de software, se realizan las pruebas sistemáticas, inicialmente por los programadores que participaron en el desarrollo, los cuales harán pruebas básicas, para luego entregar el código al equipo de pruebas, el objetivo de estas pruebas es buscar fallas através de un criterio específico, estos criterios se denominan "pruebas de caja negra y de caja blanca".
Las pruebas de caja negra son aquellas que se enfocan directamente en el exterior del módulo, sin importar el código, son pruebas funcionales en las que se trata de encontrar fallas generales y que no estan en el ámbito de su especificación, como ser interfaz con el usuario, apariencia de los menús, control de las teclas, etcétera. Este tipo de pruebas no es aplicable a los módulos que trabajan en forma transparente al usuario, entíendase rutinas y/o procedimientos internos.
Para realizar estas pruebas existe una técnica algebraica llamada "clases de equivalencia", consiste en tratar a todos las posibles entradas y parámetros como un modelo algebraico, y utilizar las clases de este modelo para probar un amplio rango de posibilidades.
Para la generación de estas clases no se puede armar un modelo, pero se pueden seguir las siguientes pautas como guía utilizable para la creación de cada clase. Por ejemplo: Cuando una entrada es booleana, existen solo dos clases, verdadero o falso. Para una entrada que está comprendida dentro de un rango, existen tres clases, por debajo, dentro, y por encima del rango.Utilizando este ejemplo se pueden generar las distintas clases aplicables al módulo en cuestión, luego, se procede a ingresarle al módulo un valor de cada clase.
Las pruebas de caja blanca son mucho mas amplias, normalmente se denominan pruebas de cobertura o pruebas de caja transparente, al total de pruebas se caja blanca se le llama cobertura, la cobertura es un número porcentual que indica cuanto código del programa se ha probado.
Básicamente la idea de pruebas de cobertura consiste en diseñar un plan de pruebas en las cuales se vaya ejecutando sistemáticamente el código hasta que haya corrido todo o la gran mayoría de él, esto que parece complicado, es mas aún cuando el programa contiene código de difícil alcance, como por ejemplo manejadores de errores o "código muerto".
Entiéndase por código muerto a aquellas funciones y/o procedimientos que hemos incluido por encontrarse en librerias pero que no son ejecutadas por el programa directamente. Para los módulos que no poseen condiciones basta con ejecutar una vez el programa para asegurar una cobertura total.Es importante que el diseño de cobertura sea eficiente y lo menos redundante posible, por ejemplo, en el siguiente código:
If Variable_Booleana..Do Modulo_XEndIf
Como no hay un "else", a simple vista con ejecutar una vez con éxito la condición bastaría, en términos de cobertura es así, pero entendiendo que el "Modulo_X" podría modificar variables o valores que afecten a la ejecución del resto del código habría que ejecutar 2 veces la condición, una satisfaciendo y otra no.
Respecto al siguiente ejemplo:
If Variable_Booleana1 .Or. Variable_Booleana2..Do Modulo_XEnd
O este otro:
If Variable_Booleana1 .And. Variable_Booleana2..Do Modulo_XEnd
A simple vista y considerando que ambas variables pueden tener 2 valores se precisarían 4 pruebas para realizar la cobertura, pero esto no es así, solo es necesario 2 pruebas en el caso que el Modulo_X pueda interferir de alguna manera en el programa o una sola satisfaciendo la condición si el Modulo_X no alterara de ninguna manera con el resto de los procedimientos y condiciones a ejecutarse.Probado las 4 posibilidades solo estaríamos probando que funcione el comando "IF" en sí, lo cual ya fue probado por el desarrollador del lenguaje de programación.
Con respecto a la cobertura en bucles (for, while) el tema es un poco mas delicado, a simple vista un bucle no es mas que un salto condicional que se repite hasta que se cumpla o deje de cumplirse una o mas condiciones, en teoría esto es simple, pero en la práctica son una fuente inagotable de versátiles errores, que en su gran mayoría suelen ser catastróficos.
En primer lugar, la cantidad de veces que se ejecute un bucle debe ser precisa, y todos los programadores saben que no es difícil equivocarse y programar un bucle que se ejecute una vez de mas o una vez de menos, siempre que esto suceda los resultados serán indeseables, y muchas veces cuando se trate de manejos de datos complicados de calcular no será fácil advertir el error, el cual será caro cuando se trate de valores que se utilizan para tomar determinaciones a nivel empresarial.
Para realizar la cobertura total de un bucle se necesitan 3 pruebas, cero ejecuciones, una ejecución y mas de una ejecución.
Los bucles de tipo "for", parecerían ser mas sencillos, ya que la cantidad de ejecuciones es definida por su cabecera y controlada por el compilador, con una ejecución bastaría para una cobertura total, siempre y cuando no contengan código que altere el valor de la variable de control o comandos de salida (Exit), en este caso requiere un examen un poco mas detallado ya que el bucle deja de ser responsabilidad del lenguaje compilador y pasa a ser del programador.Particularmente no es aconsejable que se utilicen bucles "for" modificando su variable de control o incluyendo en ellos comandos de salida.
En pocas palabras es muy importante diseñar lo mas precisamente posible las pruebas de cobertura, para que quede en lo posible la mayor parte del código probado con la mínima cantidad de pruebas realizadas.
Hay que tener en cuenta dos puntos importantes, en primer lugar las pruebas de caja blanca no reemplazan, solo complementan a las de caja negra y de aceptación, y en segundo lugar, las pruebas de cobertura deben ser realizadas una ves terminado el software y no deben ser confundidas con las pruebas informales y/o básicas que realiza el programador en momentos de desarrollo, dado que si bien estas van cubriendo distintos fragmentos de cada módulo, nunca son eficaces por no tener un diseño apropiado.
El valor porcentual de pruebas de cobertura de un sistema terminado nunca deberá ser inferior al 51%, y elevándose en función al costo que podría ocasionar las fallas posibles, ascendiendo a un 99% cuando estén involucradas vidas humanas o cuando la falla no da una segunda oportunidad.
El uso de un depurador es muy útil en las pruebas de cobertura, ya que se pueden ir viendo todas las líneas y ejecuciones paso a paso, esto no muy práctico y es bastante tedioso, pero es considerablemente efectivo.
Pruebas de aceptación, son las que hará el cliente, en esta fase de pruebas se determina que el sistema cumple con el objetivo deseado, determina la conformidad del cliente antes de que el programa le sea entregado como una versión final.
Las pruebas conocidas con el nombre de pruebas de rendimiento son aquellas que determinan los tiempos de respuesta, el espacio que ocupa el módulo en disco o en memoria, el flujo de datos que genera a través de un canal de comunicaciones, etc..
Pruebas de transformación, este método curioso y caro aún se pone en funcionamiento por diversas empresas, consiste en dividir el equipo de desarrollo en dos partes una vez realizadas todas las pruebas y corregidos todos los errores, luego una de las dos partes introduce pequeños errores en el sistema y la otra parte debe encontrarlos con los mismos procedimientos que se usaron para buscar los errores nativos. Esto es muy costoso y consume grandes cantidades de tiempo.
Pruebas de robustez, comúnmente denominadas "robustness test" son las encargadas de verificar la capacidad del programa para soportar entradas incorrectas, por ejemplo en un sistema de facturación donde el usuario debe ingresar códigos de productos y luego cantidades es mas que factible que en algún momento ingrese un código en el campo de cantidad, si el programa fue sometido a pruebas de robustez este valor sería rechazado o grabado como una cantidad inmensa pero que no daría error por desbordamiento de datos.
Las denominadas pruebas de resistencia se utilizan para saber hasta donde puede soportar el programa condiciones extremas, por ejemplo los tiempos de respuesta con el procesador a un 95% de su utilidad o con muy poco espacio en disco.
Esta metodología es utilizada por InfoTecnologia en el desarrollo de aplicaciones cliente-servidor y móviles, donde las pruebas resultan ser extremadamente críticas debido a la dinámica que posee la tecnología móvil.
miércoles, abril 06, 2005
Banco Proyectos Exitosos (BPE)
El presente texto describe el diseño de un sistema computacional bajo el ambiente de Internet de un Banco de Proyectos Exitosos (BPE), se abordará sólo la problemática que dice relación con el diseño conceptual, físico y la programación de la aplicación, desde un punto de vista netamente técnico. Los procesos asociados y la forma de recopilar y mantener la información que en el banco se registre será descrita a nivel de requerimientos para el sistema, las responsabilidad y el personal necesario para registrar y mantener la información debe ser definido con posterioridad a las pruebas y puesta en marcha del sistema.
Un Banco de Proyectos Exitoso es un sistema de información que acopia, documenta, clasifica y sistematiza, información relevante de los proyectos en explotación en cual parte del mundo, que han tenido algún nivel de éxito. El objetivo principal de este Banco será pues la difusión de todas estas experiencias, de manera que esta información este a disposición de gobiernos, entidades y/o personas naturales.
La explotación de una aplicación de este tipo en INTERNET permite unir horizontalmente organizaciones, gobiernos y en general cualquier entidad que tiene la necesidad de generar y evaluar continuamente proyectos de distinta índole y especie.
Esta red de cooperación técnica tiene un efecto multiplicador muy positivo y potenciador que permite básicamente obtener los siguientes beneficios inmediatos:
Conectar la oferta con la demanda alrededor de las experiencias exisitosas
Estimular la cooperación horizontal entre las distintas entidades que acceden al sistema
Difundir experiencias en base al concepto problema-solución probada
Apoyar actividades de capacitación y asistencia técnica, en base al estudio de las experiencias exitosas.
Agente de trasferencia tecnológica, mediante la entrega de información técnica sustantiva activación de mercados y estimulan el intercambio de experiencias obteniendo un valor agregado incalculable.
La calidad y vigencia de la información que resida en la base de datos del sistema debe ser continuamente revisada y actualizada, de esta forma se estará manteniendo un sistema "vivo" el cual ira cubriendo paulatinamente las distintas áreas de interés de los usuarios, ello implica un dinamismo y un flujo de información que debe ser normado y controlado regularmente.
Para mas información visite Publicaciones
Utilización Banda Ancha
La utilización de la Internet como elemento integrador al interior de las empresas así como también con clientes y proveedores, trae indudables ventajas en lo que respecta a la eficiencia y optimización de procesos de negocios. Chile posee ventajas comparativas importante en esta área, la infraestructura de comunicaciones es sólida y estable.
Conexiones del tipo “Banda Ancha” son absolutamente necesaria en las empresas para alcanzar niveles de crecimiento y desarrollo similares a países desarrollados, en este sentido el cambio cultural tecnológico viene con fuerza, las generaciones jóvenes vienen “configuradas” para la utilización de estas tecnologías, ya no se asocia la Internet con juegos y navegación sobre páginas sin vida, sino con aplicaciones distribuidas y servicios relacionados de alto valor agregado y bajo costo.
Debido a lo anterior hay un gran espacio en lo que respecta a la venta y distribución de conexiones del tipo Banda Ancha, a la fecha el crecimiento de este tipo de conexión a crecido cerca de un 182% en el último año, mientras que las “conmutadas” hay bajado en un –9,8%. Las PYMES que juntos a los hogares son el principal grupo objetivo para este tipo de servicios, están viendo con mayor claridad los beneficios de poseer una conexión a la Internet rápida y eficiente.
La conectividad entre redes de área local y redes de área amplia es un hecho real, un problema a resolver entre empresas y organizaciones que por su gestión comercial están distribuidas. Nuestra experiencia al respecto nos ha permitido participar en proyectos de desarrollo e implementación de este tipo de tecnologías. Generando especificaciones para adquisición de equipos y la supervisión e instalación de redes y sus componentes.
Todos nos hemos visto enfrentados a los problemas que genera a implementación de soluciones informáticas en las empresas, sobre todo en aquellas empresas de tamaño pequeño y/o mediano (PYMES), conocemos en profundidad la problemática que conlleva la utilización de tecnología de punta.
En general las PYMES no cuentan con profesionales idóneos para realizar labores y tareas como las siguientes:
Instalación de Software
Actualización de Software y Licencias asociadas
Configuración de redes de área local/amplia y estaciones de trabajo
Mantención de Respaldos
Detección de problemas Hard-Soft
Capacitación
Mantención de sitios Internet
Mantención de cuentas de correo
Antivirus
Consistencia de datos
Este tipo de empresas claramente debe orientarse utilizar soluciones en arriendo sobre la Internet, de esta forma la administración y toda la problemática técnica (Hardware y Software) queda en manos de profesionales afines, ello permite que cada empresa con su problemática particular sea resuelta en forma individual a bajo costo y máxima eficiencia, Internet lo permite, para ello es necesario una conexión de banda ancha y un buen proveedor de aplicaciones (ASP).
Conexiones del tipo “Banda Ancha” son absolutamente necesaria en las empresas para alcanzar niveles de crecimiento y desarrollo similares a países desarrollados, en este sentido el cambio cultural tecnológico viene con fuerza, las generaciones jóvenes vienen “configuradas” para la utilización de estas tecnologías, ya no se asocia la Internet con juegos y navegación sobre páginas sin vida, sino con aplicaciones distribuidas y servicios relacionados de alto valor agregado y bajo costo.
Debido a lo anterior hay un gran espacio en lo que respecta a la venta y distribución de conexiones del tipo Banda Ancha, a la fecha el crecimiento de este tipo de conexión a crecido cerca de un 182% en el último año, mientras que las “conmutadas” hay bajado en un –9,8%. Las PYMES que juntos a los hogares son el principal grupo objetivo para este tipo de servicios, están viendo con mayor claridad los beneficios de poseer una conexión a la Internet rápida y eficiente.
La conectividad entre redes de área local y redes de área amplia es un hecho real, un problema a resolver entre empresas y organizaciones que por su gestión comercial están distribuidas. Nuestra experiencia al respecto nos ha permitido participar en proyectos de desarrollo e implementación de este tipo de tecnologías. Generando especificaciones para adquisición de equipos y la supervisión e instalación de redes y sus componentes.
Todos nos hemos visto enfrentados a los problemas que genera a implementación de soluciones informáticas en las empresas, sobre todo en aquellas empresas de tamaño pequeño y/o mediano (PYMES), conocemos en profundidad la problemática que conlleva la utilización de tecnología de punta.
En general las PYMES no cuentan con profesionales idóneos para realizar labores y tareas como las siguientes:
Instalación de Software
Actualización de Software y Licencias asociadas
Configuración de redes de área local/amplia y estaciones de trabajo
Mantención de Respaldos
Detección de problemas Hard-Soft
Capacitación
Mantención de sitios Internet
Mantención de cuentas de correo
Antivirus
Consistencia de datos
Este tipo de empresas claramente debe orientarse utilizar soluciones en arriendo sobre la Internet, de esta forma la administración y toda la problemática técnica (Hardware y Software) queda en manos de profesionales afines, ello permite que cada empresa con su problemática particular sea resuelta en forma individual a bajo costo y máxima eficiencia, Internet lo permite, para ello es necesario una conexión de banda ancha y un buen proveedor de aplicaciones (ASP).
Aplicaciones Distribuidas
En los últimos años la evolución de los mercados, la globalización y el vertiginoso cambio que se experimenta producto del avance de la tecnología y las comunicaciones, han hecho imprescindible contar con soluciones integrales, no importando el tamaño de la empresa u organización.
Como consecuencia de los cambios señalados, han surgido innumerables soluciones puntuales, las cuales, si bien es cierto resuelven parte de los problema, tienen el gran inconveniente de que apuntan a atacar áreas específicas que sólo corresponden a visiones parciales de complejos procesos. Lo que requieren las empresas es integración de procesos, lo que lleva necesariamente a la integración horizontal de secciones, departamentos y unidades, eliminando de duplicidades y optimizando la relación con proveedores y clientes.
Para todas las empresas resulta imposible abtraerse de la utilización de tecnología de punta en la automatización de sus procesos, si a ello se le suma el vertiginoso cambio tecnológico, las empresas se ven enfrentadas a un panorama complejo, de no contar con profesionales altamente calificados resulta muy difícil mantenerse al día. La alta competencia producto de la globalización de la economía, lleva necesariamente la optimización de todos los procesos al interior de las empresas.
Ahora bien, la integración de aplicaciones a través de la Internet ofrece una excelente alternativa para abordar los procesos en forma distribuida, externalizando aquellos procesos que no aportan valor a la cadena productiva propia de cada empresa, logrando con ello concentrarse en "su negocio" y en "sus clientes".
Una plataforma tecnológica adecuada es imprescindible para crecer sanamente y abordar la problemática de los clientes con la agilidad y seguridad que estos requieren, ello no significa comprar una infinidad de servidores, estaciones de trabajo y/o componentes tecnológicos complejos, sino utilizar lo que ya se tiene en forma adecuada y eficiente.
El futuro será sobre aplicaciones distribuidas, en la medida que la Internet sea más sólida y estable, las aplicaciones que estarán disponibles aumentará en forma exponencial, permitiendo con ello acceder a estas aplicaciones desde cualquier parte del mundo a un costo muy bajo.
Como consecuencia de los cambios señalados, han surgido innumerables soluciones puntuales, las cuales, si bien es cierto resuelven parte de los problema, tienen el gran inconveniente de que apuntan a atacar áreas específicas que sólo corresponden a visiones parciales de complejos procesos. Lo que requieren las empresas es integración de procesos, lo que lleva necesariamente a la integración horizontal de secciones, departamentos y unidades, eliminando de duplicidades y optimizando la relación con proveedores y clientes.
Para todas las empresas resulta imposible abtraerse de la utilización de tecnología de punta en la automatización de sus procesos, si a ello se le suma el vertiginoso cambio tecnológico, las empresas se ven enfrentadas a un panorama complejo, de no contar con profesionales altamente calificados resulta muy difícil mantenerse al día. La alta competencia producto de la globalización de la economía, lleva necesariamente la optimización de todos los procesos al interior de las empresas.
Ahora bien, la integración de aplicaciones a través de la Internet ofrece una excelente alternativa para abordar los procesos en forma distribuida, externalizando aquellos procesos que no aportan valor a la cadena productiva propia de cada empresa, logrando con ello concentrarse en "su negocio" y en "sus clientes".
Una plataforma tecnológica adecuada es imprescindible para crecer sanamente y abordar la problemática de los clientes con la agilidad y seguridad que estos requieren, ello no significa comprar una infinidad de servidores, estaciones de trabajo y/o componentes tecnológicos complejos, sino utilizar lo que ya se tiene en forma adecuada y eficiente.
El futuro será sobre aplicaciones distribuidas, en la medida que la Internet sea más sólida y estable, las aplicaciones que estarán disponibles aumentará en forma exponencial, permitiendo con ello acceder a estas aplicaciones desde cualquier parte del mundo a un costo muy bajo.
viernes, abril 01, 2005
Proyectos de Software
A medida que las principales corporaciones del mundo dependen cada vez más de sus departamentos de IT para obtener ventajas competitivas, se vuelve imprescindible la capacidad para desarrollar software a medida de manera rápida.
Pero incluso los mejores equipos de programación con la mentalidad más astuta y lógica pueden ver frustrados sus esfuerzos debido al simple problema de la falta de comunicación, que ocurre particularmente entre los ejecutivos del departamento comercial de una corporación y los equipos de desarrollo de software.
En muchas empresas importantes a menudo se presentan conflictos entre el personal ejecutivo y las organizaciones de desarrollo de software. El primero se siente frustrado debido a que los proyectos de desarrollo no logran cumplir con las expectativas y, por consiguiente, afectan los objetivos comerciales. A la vez, las organizaciones de desarrollo de software centran la culpa en los ejecutivos responsables de las decisiones, alegando que el fracaso se debe a la incapacidad de los ejecutivos para priorizar o comunicar los requisitos comerciales, la presión para cumplir con plazos irracionales y la negativa a aceptar estimaciones sensatas.
¿Cuál es la verdadera causa de este conflicto? La falta de comunicación efectiva y la necesidad de implementar procesos que exigen colaboración. Los gerentes de productos de software, así como los gerentes de programas y los analistas comerciales pueden tener objetivos y expectativas diferentes para un mismo proyecto de desarrollo. Cambios tanto del sector comercial (tal vez la necesidad de agregar nuevas características) como del sector de desarrollo (una imprevista reducción de recursos) pueden provocar que el plan original se torne obsoleto e insostenible. Sin un método global y comprendido por todos para controlar las expectativas y mitigar los riesgos del desarrollo pueden surgir conflictos que condenen el éxito de un programa y disminuyan la fe del ejecutivo en la organización del desarrollo.
El trabajo de investigación “CHAOS” de la firma analista The Standish Group demuestra que las causas más frecuentes del fracaso de un proyecto radican en la falta de una dirección competente del proyecto y del respaldo del sector ejecutivo. Sin embargo, ahora que el éxito comercial depende cada vez más de la exitosa distribución de software, se vuelve indispensable el control de riesgos en el desarrollo de software. Para mantener una ventaja competitiva, las empresas deben poner fin al juego de las culpas y crear software que se adecue a procesos de desarrollo rápidos, efectivos y dúctiles.
Este documento analiza cómo los gerentes de software y analistas comerciales pueden ganar control en el proceso de estimación y forjar la confianza en la organización de software. Este enfoque permite que quienes formen parte de la organización elaboren y respalden estimaciones creíbles de proyectos, y hace hincapié en el alineamiento de los objetivos comerciales y las estrategias de software. En última instancia, ayuda a los gerentes de software y analistas comerciales a maximizar el valor comercial de los proyectos de software que gestionan. Este documento también destaca las prácticas de desarrollo más recomendadas ante la incertidumbre que pueda surgir de un proyecto, y presenta la estrategia de Borland para la Optimización en la Distribución de Software y su innovadora solución para la gestión de requisitos y la estimación de proyectos: Borland® CaliberRM.™
Una nueva era de responsabilidad
La gestión de riesgos se practica de hecho en casi todas las disciplinas relacionadas con la ingeniería. Por lo general, se la asocia con la recopilación de varios índices a través de los ciclos de producción, que son luego analizados con el objeto de identificar los riesgos potenciales. Sin embargo, muchas organizaciones de desarrollo de software no han incorporado estas técnicas a sus procesos. Esta falta de rigor puede deberse a que no ha pasado mucho tiempo desde que el desarrollo de software es considerado una disciplina de ingeniería. Más allá de la causa, el resultado es el mismo: cancelaciones y fracasos de proyectos, excesos de costos, y dilatación de plazos. Según el informe elaborado por Standish en el año 2003, sólo el 28% de las aplicaciones cumplieron con el plazo inicial y el presupuesto, mientras que el 48% de los proyectos no contaba con las características necesarias al momento del lanzamiento del producto.
¿Por qué razón fracasan los proyectos de software tan a menudo? En un esfuerzo por maximizar el valor, las organizaciones de software operan bajo presión para optimizar recursos y producir más con menos. Los requisitos varían constantemente y los ciclos de distribución de software son cada vez más agresivos. Además, la complejidad de las tecnologías y arquitecturas se ha incrementado radicalmente, acarreando un entorno de desarrollo de caos semi-controlado.
“En varios grupos de discusión, los ejecutivos de IT nos comentaron que primero obtienen su mejor estimación, la multiplican por dos y luego suman la mitad.”
Fuente: “Caos Extremo,” The Standish Group International
Este caos a menudo concluye en un juego de culpas entre los ejecutivos de la empresa y los grupos de desarrollo de software. Los primeros critican la imprecisión en la estimación y planificación por parte del grupo de desarrollo. También suelen detenerse en la incapacidad histórica del equipo para proyectar confiabilidad, y citan la imposibilidad para establecer expectativas razonables y prever el impacto que puedan causar las alteraciones a un proyecto. Según los ejecutivos de la corporación, la organización dedicada al desarrollo de software carece de credibilidad. Debido a que con frecuencia no logra alcanzar las expectativas comerciales, el equipo de desarrollo es una de las áreas más problemáticas de la empresa.
La organización dedicada al desarrollo de software, por otra parte, suele culpar a los ejecutivos de la corporación por negarse a aceptar estimaciones precisas y responsables; y rechaza la calificación de “engañoso” que recae sobre el grupo de software. Además, los equipos de desarrollo creen que los ejecutivos no comunican ni priorizan debidamente los requerimientos comerciales. Ven cómo las estimaciones y planes originales se vuelven obsoletos, a medida que los ejecutivos comerciales agregan importantes requisitos en medio del proyecto sin haber evaluado adecuadamente el eventual impacto en los plazos y recursos del mismo.
Al mismo tiempo, los gerentes de software y analistas comerciales se ven paralizados por procesos que limitan su capacidad para generar estimaciones oportunas y sustentables.
En medio de este desorden, la realidad demuestra que el éxito comercial depende cada vez más de la exitosa distribución de software. Surge una nueva era de responsabilidad allí donde el control de riesgos en el desarrollo de software es considerado una práctica comercial obligatoria. El control de riesgos debe originarse con la imposición de una visión compartida y sistemática del proyecto. Cuando todos los interesados poseen una comprensión clara de los requisitos e impactos que ejercen los cambios sobre el proyecto, pueden trabajar en colaboración y mantener el buen funcionamiento del proyecto. Mediante la adopción de tecnologías que faciliten la conciliación entre los costos estimados y los plazos a cumplir, los gerentes de software y los analistas comerciales pueden coordinar este proceso y ayudar a sus empresas a maximizar el valor comercial de los resultados del desarrollo.
Conceptos sobre la estimación de proyectos de software y la planificación de riesgos
El éxito del software destinado a la estimación y planificación de proyectos se basa en un entorno de expectativas empresariales factibles, donde las organizaciones destinadas al desarrollo de software puedan estipular objetivamente, desde el comienzo, los esfuerzos necesarios a tiempo, los recursos humanos y tecnológicos y el presupuesto necesario para la exitosa finalización del proyecto. La organización de desarrollo también debe contar con un historial de calidad en sus productos, a fin de que su estimación de los recursos necesarios goce de autoridad.
No obstante, el entorno de las expectativas enfrenta serios desafíos. Los grupos dedicados al desarrollo de software a menudo no cuentan con toda la información respecto de la definición del proyecto y, como consecuencia, no pueden definir de manera realista el alcance del proyecto. Esta brecha en la información acarrea estimaciones y plazos poco confiables, que a su vez generan dificultades para calcular los Rendimientos de la Inversión (ROI) y la planificación comercial. En última instancia, la falta de información sobre los requerimientos conduce a un alto riesgo de elaborar proyectos de mala calidad que se alejen de los objetivos comerciales.
Con frecuencia, los grupos de desarrollo que intentan fijar expectativas también carecen de información histórica. La incapacidad para influir sobre las tendencias internas revela que las organizaciones desconocen sus estimaciones de costos y cronogramas de plazos anteriores, así como su capacidad para alcanzar determinadas metas. Y a menudo, tampoco pueden acceder a las tendencias industriales en cuanto a costos y plazos de implementación de proyectos similares.
Además, las organizaciones dedicadas al desarrollo se enfrentan a la inestabilidad del ámbito de la aplicación, el cronograma de plazos y los recursos. El alcance del proyecto se ve con frecuencia expandido por los ejecutivos de la corporación, que no respetan ni los plazos ni los recursos asignados. Como consecuencia, los cálculos originales se tornan obsoletos. Con el objeto de acelerar el ingreso al mercado, se sacrifica la calidad. Y en el entorno comercial altamente competitivo de hoy en día, muchas organizaciones restringen los recursos destinados al desarrollo, con la intención de disminuir los costos. Esta restricción de los recursos, a su vez, pone en riesgo la calidad del proyecto y su lanzamiento al mercado.
Estos desafíos, riesgos afines y consecuencias conducen a un planeamiento y estimación del proyecto insostenibles; y por lo tanto, a un entorno de escasas expectativas empresariales. Dado que el equipo de desarrollo y los ejecutivos de la corporación no se ponen verdaderamente de acuerdo en cuanto a los requisitos, campo de aplicación, esquema de plazos y recursos del proyecto, los proyectos de desarrollo se ven condenados al fracaso incluso antes de su inicio.
Lo que se necesita son herramientas que permitan al grupo dedicado al desarrollo de software integrar rigor de ingeniería tradicional al proceso de distribución del software. Estas herramientas permitirían mejorar la definición de los proyectos de software, así como la implementación de un enfoque susceptible de ser repetido y de automatización asistida para la elaboración de estimaciones y pronósticos. Esta metodología habilitaría a los interesados dentro de la organización a trabajar en colaboración para crear una visión consecuente y compartida del proyecto. El resultado reflejará una disminución del riesgo y un incremento en la calidad del proyecto.
Pero incluso los mejores equipos de programación con la mentalidad más astuta y lógica pueden ver frustrados sus esfuerzos debido al simple problema de la falta de comunicación, que ocurre particularmente entre los ejecutivos del departamento comercial de una corporación y los equipos de desarrollo de software.
En muchas empresas importantes a menudo se presentan conflictos entre el personal ejecutivo y las organizaciones de desarrollo de software. El primero se siente frustrado debido a que los proyectos de desarrollo no logran cumplir con las expectativas y, por consiguiente, afectan los objetivos comerciales. A la vez, las organizaciones de desarrollo de software centran la culpa en los ejecutivos responsables de las decisiones, alegando que el fracaso se debe a la incapacidad de los ejecutivos para priorizar o comunicar los requisitos comerciales, la presión para cumplir con plazos irracionales y la negativa a aceptar estimaciones sensatas.
¿Cuál es la verdadera causa de este conflicto? La falta de comunicación efectiva y la necesidad de implementar procesos que exigen colaboración. Los gerentes de productos de software, así como los gerentes de programas y los analistas comerciales pueden tener objetivos y expectativas diferentes para un mismo proyecto de desarrollo. Cambios tanto del sector comercial (tal vez la necesidad de agregar nuevas características) como del sector de desarrollo (una imprevista reducción de recursos) pueden provocar que el plan original se torne obsoleto e insostenible. Sin un método global y comprendido por todos para controlar las expectativas y mitigar los riesgos del desarrollo pueden surgir conflictos que condenen el éxito de un programa y disminuyan la fe del ejecutivo en la organización del desarrollo.
El trabajo de investigación “CHAOS” de la firma analista The Standish Group demuestra que las causas más frecuentes del fracaso de un proyecto radican en la falta de una dirección competente del proyecto y del respaldo del sector ejecutivo. Sin embargo, ahora que el éxito comercial depende cada vez más de la exitosa distribución de software, se vuelve indispensable el control de riesgos en el desarrollo de software. Para mantener una ventaja competitiva, las empresas deben poner fin al juego de las culpas y crear software que se adecue a procesos de desarrollo rápidos, efectivos y dúctiles.
Este documento analiza cómo los gerentes de software y analistas comerciales pueden ganar control en el proceso de estimación y forjar la confianza en la organización de software. Este enfoque permite que quienes formen parte de la organización elaboren y respalden estimaciones creíbles de proyectos, y hace hincapié en el alineamiento de los objetivos comerciales y las estrategias de software. En última instancia, ayuda a los gerentes de software y analistas comerciales a maximizar el valor comercial de los proyectos de software que gestionan. Este documento también destaca las prácticas de desarrollo más recomendadas ante la incertidumbre que pueda surgir de un proyecto, y presenta la estrategia de Borland para la Optimización en la Distribución de Software y su innovadora solución para la gestión de requisitos y la estimación de proyectos: Borland® CaliberRM.™
Una nueva era de responsabilidad
La gestión de riesgos se practica de hecho en casi todas las disciplinas relacionadas con la ingeniería. Por lo general, se la asocia con la recopilación de varios índices a través de los ciclos de producción, que son luego analizados con el objeto de identificar los riesgos potenciales. Sin embargo, muchas organizaciones de desarrollo de software no han incorporado estas técnicas a sus procesos. Esta falta de rigor puede deberse a que no ha pasado mucho tiempo desde que el desarrollo de software es considerado una disciplina de ingeniería. Más allá de la causa, el resultado es el mismo: cancelaciones y fracasos de proyectos, excesos de costos, y dilatación de plazos. Según el informe elaborado por Standish en el año 2003, sólo el 28% de las aplicaciones cumplieron con el plazo inicial y el presupuesto, mientras que el 48% de los proyectos no contaba con las características necesarias al momento del lanzamiento del producto.
¿Por qué razón fracasan los proyectos de software tan a menudo? En un esfuerzo por maximizar el valor, las organizaciones de software operan bajo presión para optimizar recursos y producir más con menos. Los requisitos varían constantemente y los ciclos de distribución de software son cada vez más agresivos. Además, la complejidad de las tecnologías y arquitecturas se ha incrementado radicalmente, acarreando un entorno de desarrollo de caos semi-controlado.
“En varios grupos de discusión, los ejecutivos de IT nos comentaron que primero obtienen su mejor estimación, la multiplican por dos y luego suman la mitad.”
Fuente: “Caos Extremo,” The Standish Group International
Este caos a menudo concluye en un juego de culpas entre los ejecutivos de la empresa y los grupos de desarrollo de software. Los primeros critican la imprecisión en la estimación y planificación por parte del grupo de desarrollo. También suelen detenerse en la incapacidad histórica del equipo para proyectar confiabilidad, y citan la imposibilidad para establecer expectativas razonables y prever el impacto que puedan causar las alteraciones a un proyecto. Según los ejecutivos de la corporación, la organización dedicada al desarrollo de software carece de credibilidad. Debido a que con frecuencia no logra alcanzar las expectativas comerciales, el equipo de desarrollo es una de las áreas más problemáticas de la empresa.
La organización dedicada al desarrollo de software, por otra parte, suele culpar a los ejecutivos de la corporación por negarse a aceptar estimaciones precisas y responsables; y rechaza la calificación de “engañoso” que recae sobre el grupo de software. Además, los equipos de desarrollo creen que los ejecutivos no comunican ni priorizan debidamente los requerimientos comerciales. Ven cómo las estimaciones y planes originales se vuelven obsoletos, a medida que los ejecutivos comerciales agregan importantes requisitos en medio del proyecto sin haber evaluado adecuadamente el eventual impacto en los plazos y recursos del mismo.
Al mismo tiempo, los gerentes de software y analistas comerciales se ven paralizados por procesos que limitan su capacidad para generar estimaciones oportunas y sustentables.
En medio de este desorden, la realidad demuestra que el éxito comercial depende cada vez más de la exitosa distribución de software. Surge una nueva era de responsabilidad allí donde el control de riesgos en el desarrollo de software es considerado una práctica comercial obligatoria. El control de riesgos debe originarse con la imposición de una visión compartida y sistemática del proyecto. Cuando todos los interesados poseen una comprensión clara de los requisitos e impactos que ejercen los cambios sobre el proyecto, pueden trabajar en colaboración y mantener el buen funcionamiento del proyecto. Mediante la adopción de tecnologías que faciliten la conciliación entre los costos estimados y los plazos a cumplir, los gerentes de software y los analistas comerciales pueden coordinar este proceso y ayudar a sus empresas a maximizar el valor comercial de los resultados del desarrollo.
Conceptos sobre la estimación de proyectos de software y la planificación de riesgos
El éxito del software destinado a la estimación y planificación de proyectos se basa en un entorno de expectativas empresariales factibles, donde las organizaciones destinadas al desarrollo de software puedan estipular objetivamente, desde el comienzo, los esfuerzos necesarios a tiempo, los recursos humanos y tecnológicos y el presupuesto necesario para la exitosa finalización del proyecto. La organización de desarrollo también debe contar con un historial de calidad en sus productos, a fin de que su estimación de los recursos necesarios goce de autoridad.
No obstante, el entorno de las expectativas enfrenta serios desafíos. Los grupos dedicados al desarrollo de software a menudo no cuentan con toda la información respecto de la definición del proyecto y, como consecuencia, no pueden definir de manera realista el alcance del proyecto. Esta brecha en la información acarrea estimaciones y plazos poco confiables, que a su vez generan dificultades para calcular los Rendimientos de la Inversión (ROI) y la planificación comercial. En última instancia, la falta de información sobre los requerimientos conduce a un alto riesgo de elaborar proyectos de mala calidad que se alejen de los objetivos comerciales.
Con frecuencia, los grupos de desarrollo que intentan fijar expectativas también carecen de información histórica. La incapacidad para influir sobre las tendencias internas revela que las organizaciones desconocen sus estimaciones de costos y cronogramas de plazos anteriores, así como su capacidad para alcanzar determinadas metas. Y a menudo, tampoco pueden acceder a las tendencias industriales en cuanto a costos y plazos de implementación de proyectos similares.
Además, las organizaciones dedicadas al desarrollo se enfrentan a la inestabilidad del ámbito de la aplicación, el cronograma de plazos y los recursos. El alcance del proyecto se ve con frecuencia expandido por los ejecutivos de la corporación, que no respetan ni los plazos ni los recursos asignados. Como consecuencia, los cálculos originales se tornan obsoletos. Con el objeto de acelerar el ingreso al mercado, se sacrifica la calidad. Y en el entorno comercial altamente competitivo de hoy en día, muchas organizaciones restringen los recursos destinados al desarrollo, con la intención de disminuir los costos. Esta restricción de los recursos, a su vez, pone en riesgo la calidad del proyecto y su lanzamiento al mercado.
Estos desafíos, riesgos afines y consecuencias conducen a un planeamiento y estimación del proyecto insostenibles; y por lo tanto, a un entorno de escasas expectativas empresariales. Dado que el equipo de desarrollo y los ejecutivos de la corporación no se ponen verdaderamente de acuerdo en cuanto a los requisitos, campo de aplicación, esquema de plazos y recursos del proyecto, los proyectos de desarrollo se ven condenados al fracaso incluso antes de su inicio.
Lo que se necesita son herramientas que permitan al grupo dedicado al desarrollo de software integrar rigor de ingeniería tradicional al proceso de distribución del software. Estas herramientas permitirían mejorar la definición de los proyectos de software, así como la implementación de un enfoque susceptible de ser repetido y de automatización asistida para la elaboración de estimaciones y pronósticos. Esta metodología habilitaría a los interesados dentro de la organización a trabajar en colaboración para crear una visión consecuente y compartida del proyecto. El resultado reflejará una disminución del riesgo y un incremento en la calidad del proyecto.
Suscribirse a:
Entradas (Atom)