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 : ####
jueves, abril 28, 2005
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)