DESARROLLO DE SISTEMAS DE INFORMACIN 1.

1 ESTIMACION Y CONTROL DEL TIEMPO DE DESARROLLO Los proyectos de sistemas mal planeados no cumplen con lo programado y desaniman a los usuarios entusiastas. Aquellos proyectos que se desarrollan a tiempo tienen estas caractersticas en comn: 1) Una estimacin cuidadosamente formulada de los requerimientos de tiempo 2) Un medio para monitorear el avance 3) Un medio para comparar el desempeo planeado con el real 4) La informacin suficiente para enfrentarse a problemas cuando estos surjan. Estimacin de los requerimientos del tiempo Uno de los aspectos ms difciles del manejo del proyecto es la formulacin de las nociones del tiempo necesario para desarrollar un sistema. Como lo propone el nombre, las estimaciones son aproximaciones de las horas, das o meses de esfuerzo necesario para producir el sistema deseado. Su precisin depende en gran medida de la habilidad, conocimiento y experiencia de la persona que prepara las estimaciones, usualmente es el coordinador del proyecto. Mtodos de estimacin del tiempo Tres mtodos comunes para estimar el tiempo de desarrollo del proyecto. El mtodo histrico se basa en registros cuidadosos que se han mantenido con respecto a proyectos de desarrollo anteriores. Los registros indican las caractersticas del programa o proyecto, asignacin de tareas, requerimientos del tiempo del personal y los problemas o hechos no usuales. Cuando se proponen nuevos proyectos, se comparan con los registros en archivos de proyectos anteriores para dar una estimacin del tiempo esperado de desarrollo. El mantenimiento de registros es un proceso muy laborioso y que muchas organizaciones prefieren evitar. El mtodo histrico slo es tan bueno como los registros, an entonces es til nicamente si el proyecto propuesto es similar a un desarrollo anterior. Se dice que la experiencia es el mejor maestro. El mtodo intuitivo se basa en la experiencia del personal ms antiguo, el cual estima, por medio de sus experiencias personales, el tiempo de desarrollo esperado. Este mtodo se describe a menudo como una corazonada educada, donde la porcin de educacin se refiere a la experiencia anterior de la persona que hace la estimacin. El enfoque intuitivo difiere del histrico en que no se usan casos documentados y registros detallados. El mtodo de la forma estndar ofrece un enfoque ms concreto a la estimacin. Se identifican y cuantifican (con pesos individuales) los factores que afectan ms drsticamente al tiempo de desarrollo, tales como las caractersticas del personal, los detalles del sistema y la complejidad del proyecto. Las estimaciones del tiempo del proyecto son necesarias para informar a la gerencia de cuando es probable que se termine un proyecto y se implemente el sistema. Adems, se necesitan las estimaciones para ayudar al coordinador del proyecto en la programacin del personal para desarrollar varias tareas o hacer ajustes posteriores del equipo, en caso de ser necesario. Las estimaciones del tiempo del proyecto incluyen dos tipos de requerimientos: requerimientos de tiempo del proyecto y requerimientos de tiempo calendario.

Requerimientos de tiempo del proyecto Los requerimientos de tiempo del proyecto se refieren al tiempo necesario para llevar a cabo una fase de investigacin del sistema, cada actividad asociada con el desarrollo de un sistema de informacin requiere de cierta cantidad de tiempo que debe estimarse e incorporarse al calendario del proyecto. Estimacin de los tiempos de actividad del sistema El tiempo de la fase de investigacin del sistema se determina a partir del nmero de personas a entrevistar y la cantidad de tiempo necesaria para desarrollar, circular y analizar los cuestionarios, dirigir observaciones e inspeccionar registros. Esta estimacin depende de tres grandes componentes: 1. Nivel de aptitud del programador 2. Nivel de complejidad del programa 3. Nivel de comprensin del programador en el programa especfico Identificacin de las variables de desarrollo del programa Algunos coordinadores de proyectos usan un sistema de pesos para evaluar las habilidades de un individuo y asociarlas con los requerimientos de tiempo del proyecto. Entre los criterios que se usan estn los siguientes: 1.Conocimiento del lenguaje de programacin a usarse en el proyecto 2.Experiencia con el sistema de computadora en el que se procesar el sistema 3.Experiencia en programacin 4.Habilidad lgica 5.Creatividad e imaginacin 6.Paciencia 7.Madurez 8.Persistencia 9.Educacin A cada individuo se le asigna un peso, usualmente entre 1 y 5, basado en sus atributos para cada una de las categoras anteriores. La complejidad del programa es una medida del nivel de las caractersticas del sistema, tales como los mtodos de entrada y salida y la dificultad de la lgica del programa que quedar inmerso en el software. Si se incluyen varios archivos o se usa el procesamiento distribuido, se puede considerar todava mayor la complejidad del programa. Clculo de estimacin de tiempo de programacin Cada programa debe evaluarse independientemente de los otros. Para determinar el nmero de das por cada programa, el coordinador del proyecto tiene que combinar los datos identificados anteriormente. Si se sigue con cuidado un enfoque cuantitativo, complejidad del programa se multiplica por la suma de la experiencia y comprensin del programador. Estimacin usando la funcin puntual (puntos de funcin) Una funcin puntual mide la funcionalidad (es decir, las actividades) de un programa.

Los Puntos de Funcin miden la aplicacin desde una perspectiva del usuario, dejando de lado los detalles de codificacin. Es una tcnica totalmente independiente de todas las consideraciones de lenguaje y ha sido aplicada en ms de 250 lenguajes diferentes. Se supone que FPA evala con fiabilidad el valor comercial de un sistema para el usuario tamao del proyecto, costo y tiempo de desarrollo calidad y productividad del programador esfuerzo de adaptacin, modificacin y mantenimiento posibilidad de desarrollo propio beneficios de implementacin en 4GL

Un Punto de Funcin se define como una funcin comercial de usuario final. De esta manera un programa que tenga x PFs entrega x funciones al usuario final. El mejor modo de trabajo es la interaccin analista-usuario. El proceso requiere dos etapas fundamentales: 1. Se identifican las funciones disponibles para el usuario y se organizan en cinco grupos (mejor en este orden) - Salidas - Consultas - Entradas - Archivos - Interfaces. Despus se clasifica y pondera cada funcin por su nivel de complejidad (simple, media, compleja). 2. Se ajusta este total de acuerdo con unas caractersticas del entorno. Requerimientos de tiempo calendario La simple identificacin de los requerimientos de tiempo del proyecto no da como resultado el nmero de das, semanas o meses para preparar el calendario del proyecto. Slo es un factor. En la mayora de los proyectos de sistemas, se utiliza un tiempo adicional en actividades del proyecto. Reuniones con la gerencia, revisiones del proyecto, educacin, capacitacin, interaccin con los usuarios, enfermedades, vacaciones y das de descanso, y la no disponibilidad del sistema computacional, extienden los plazos ms all de las estimaciones previas. En realidad, en los proyectos de sistemas grandes, el tiempo adicional necesario para estas actividades extiende el tiempo total de desarrollo de un 50 a un 100%.

Con base en estos criterios, un proyecto estimado para usar 250 das de tiempo de programacin en realidad se llevara de 375 a 500 das de proyecto. Un da de proyecto (a veces llamado un da de persona) se usa para medir el nmero de das que requiere un proyecto sobre la base del trabajo que un individuo puede hacer durante un da. El numero de personas que trabajan sobre el proyecto afecta el tiempo calendario, pero no de manera proporcional. Al asignar ms gente a un proyecto se reduce el tiempo total calendario, pero se debe considerar un tiempo adicional no perteneciente al proyecto. Se usan comnmente tres mtodos para planear los requerimientos de tiempo calendario: diagramas de barras, eventos crticos y de PERT. 1.2 ADMINISTRACION DEL PERSONAL Y DEL PROCESO DE DESARROLLO El desarrollo de programas de trabajo confiables no garantiza el xito del proyecto, el cual an debe ser administrado. El personal debe ser asignado y utilizado adecuadamente. Al mismo tiempo, es necesario que el desarrollo cumpla especificaciones y siga lineamientos para asegurar la calidad. sta estudia la utilizacin del personal y el uso de recorridos estructurados durante el proceso de desarrollo. 1.3 SELECCIN DE EQUIPOS DE TRABAJO El desarrollo de sistemas y la programacin de computadoras en particular se consideran tpicamente como actividades individuales, sin embargo, desde el punto de vista del coordinador, es esencial estar prevenido ante la salida de personal clave, capacitar a nuevo personal y a aquel que eleva su responsabilidad, y finalmente asegurarse que el personal adecuado se emplee para trabajos especficos. Se tratan 3 variantes de equipo: Equipos responsables de la programacin, equipos de especialistas y equipos sin liderazgo. Equipos con programador en jefe: Consta de un programador principal, un programador de respaldo y personal de apoyo. El programador en jefe es un programador hbil y con gran experiencia, el cual lleva a cabo todas las tareas de diseo del proyecto y escribe el cdigo del programa para todos los mdulos crticos en un sistema, esta persona tambin integra y prueba el cdigo de su equipo. En los proyectos grandes, la comunicacin entre los usuarios y los equipos de desarrollo consume tiempo y ocasionalmente llega a ser confusa, en especial si un usuario especfico est trabajando con varios miembros del equipo al mismo tiempo o si distintos miembros del equipo contactan en forma individual a los mismos usuarios repetidamente. El programador de respaldo, quien tiene habilidades anlogas pero menos experiencia que el programador en jefe, realiza actividades tales como la investigacin de alternativas de diseo y estrategias de desarrollo, esta persona tambin participa en el diseo del software, codificacin del programa y planificacin de la prueba. El personal de apoyo que generalmente no tiene experiencia de programacin o de diseo, es el responsable de mantener la biblioteca externa de programas y la biblioteca de documentacin interna. La biblioteca externa de programas consta de conjuntos de cdigo fuente, mdulos objeto y directivos temporales, al igual que datos de prueba y procedimientos del lenguaje de control de procesos, se mantiene en forma impresa, normalmente en un conjunto de carpetas. La biblioteca interna de programas sirve como

un archivo de informacin, un respaldo para los programadores en caso de que la biblioteca externa de programas se dale o destruya. Equipos de especialistas: El equipo de especialistas incluye el uso de especialistas conforme surja la necesidad, un ncleo comn de miembros del equipo permanece unido durante todo el proyecto, cada miembro tiene una asignacin especial que aprovecha su talento, el equipo incluye un administrado responsable de los presupuestos, que organiza el espacio fsico y el tiempo de mquina y que trata con los asuntos personales. El equipo de especialistas ofrece ventajas semejantes a las de equipo con programador en jefe, pero involucra individuos con una habilidad especfica lo cual beneficia al equipo, al individuo y al proyecto. Los especialistas son, por lo general, miembros de varios equipos de trabajo al mismo tiempo. Equipos sin liderazgo: Algunas organizaciones han modificado el concepto de programador en jefe, estableciendo equipos que no tienen un lder permanente, algunos miembros particulares del equipo toman el liderazgo sobre una base informal para distintos proyectos, dependiendo de la naturaleza de la tarea y de sus propias habilidades. Los miembros del equipo distribuyen la asignacin del trabajo entre ellos mismos, con base a sus habilidades. Los equipos sin liderazgo no tienen una amplia aceptacin, aunque en el concepto existen algunas ventajas. Sin embargo, muchas organizaciones sienten que a cada persona se le debe asignar una responsabilidad gerencial especfica para el proyecto un aspecto que se excluye explcitamente en los equipos sin liderazgo.

1.4 RECORRIDOS ESTRUCTURADOS Un recorrido estructurado es una revisin planificada de un sistema o un software para las personas involucradas en el desarrollo. Los participantes estn generalmente al mismo nivel en la organizacin, es decir, son analistas o analistas programadores. Generalmente, los jefes de departamento por ejemplo de compras o de produccin no se involucran en la revisin aun cuando sean beneficiarios del sistema. A veces, los recorridos estructurados se llaman revisiones de igualdad puesto que los participantes son compaeros al mismo nivel de la organizacin. Caractersticas El propsito de los recorridos es halla reas donde se puede mejorar el sistema o el proceso de desarrollo. Los miembros del equipo no se reprochan los problemas hallados. Hacer esto niega los posibles beneficios del proceso. Un recorrido debe verse por los programadores y analistas como una oportunidad para recibir apoyo, no como un obstculo a evitar o tolerar. La sesin de revisin no da como resultado la correccin de errores o cambios de especificaciones. Estas actividades siguen siendo responsabilidad de los que desarrollan el sistema. Por lo tanto, se enfatiza en la revisin, no en la reparacin. El concepto de recorrido reconoce que el desarrollo es un proceso de equipo. Los participantes, con la posible excepcin de los participantes de los departamentos de

usuarios, son aquellos que realmente estn involucrados en el desarrollo del sistema o en la produccin de software. Los individuos que formularon las especificaciones de diseo o crearon el cdigo de programa son, como es de esperarse, parte del equipo de revisin, a veces se escoge un moderador para dirigirla revisin, aunque muchas organizaciones prefieren que la sesin sea encabezada por el analista o diseador que hizo las especificaciones o el programa, ya que ellos estn muy familiarizados con lo que hay que revisar, tambin se requiere de alguien que escriba o registre los detalles de la reunin y las ideas que surjan, tambin hay que estudiar el mantenimiento durante los recorridos. El equipo de recorrido debe ser lo suficientemente grande para que se pueda enfrentar al objeto de la revisin de forma significativa, pero no tan numeroso que no pueda llevar a cabo nada, por lo general no mas de 7 a 9 personas deben estar involucradas, incluyendo a las personas que desarrollaron el producto a revisar, la persona que tiene que hacer el registro y el lder de la revisin, por el contrario un equipo de revisin de slo 2 3 personas generalmente no genera el suficiente numero de ideas independientes y la objetividad para producir los resultados deseados. Las revisiones estructuradas rara vez duran mas de 90 minutos. Y puede usar durante el proceso de desarrollo del sistema como una herramienta de administracin constructiva y eficiente en cuanto a costos, despus de la investigacin detallada, despus del diseo y durante el desarrollo del programa. 1.5 METODOLOGIA DE DESARROLLO DE APLICACIONES El primer paso en el desarrollo de una aplicacin es planificar lo que el usuario ver, en otras palabras, disear las pantallas. El segundo paso en la organizacin es la escritura del cdigo para activar la interfaz visual construida en el primer paso. El tercero y cuarto paso son la bsqueda de errores en el cdigo (depuracin en la jerga) y su posterior correccin. Este es un resumen de los pasos para el diseo de una aplicacin Visual Basic: 1.- Personalizar las ventanas que vera el usuario 2.- Decidir que eventos deben reconocer los controles de la ventana. 3.- Escribir los procedimientos de evento para esos eventos (y los procedimientos auxiliares que hacen que los procedimientos de eventos trabajen). Esto es lo que sucede cuando una aplicacin se est ejecutando: 1. Visual Basic monitoriza las ventanas y los controles de cada ventana para todos los eventos que cada control puede reconocer (movimientos de ratn, pulsaciones de teclas y otros). 2. Cuando Visual Basic detecta un evento, si no hay una respuesta incorporada que responda al evento, Visual Basic examina la aplicacin para comprobar si se ha escrito un procedimiento de evento para ese evento. 3. Si se ha escrito un procedimiento de evento, Visual Basic ejecuta el cdigo de ese procedimiento de evento y vuelve al paso 1.

4. Si no hay escrito un procedimiento de evento, VB espera el siguiente evento y vuelve al paso 1.