Problemas en La Planificacion de Un Proyecto de Software

 

PROBLEMAS EN LA PLANIFICACION DE UN PROYECTO DE SOFTWARE A.  A.  ESTABLECER EL AMBITO DEL SOFTWARE: Describe la función, el rendimiento, las restricciones, las interfaces y la fiabilidad.  

Se evalúan las funciones descritas en el enunciado del ámbito o se refinan.   Las consideraciones de rendimiento abarcan los requisitos de tiempos de respuesta y de procesamiento.   Las restricciones marcan los límites del software debidos al hardware externo, la memoria disponible y otros sistemas existentes.

Para la obtención de la información necesaria para el ámbito, o sea para acercar al cliente y al desarrollador (ingeniero del software, analista), y para hacer que comience el proceso de comunicación es establecer una reunión o entrevista preliminar. Se sugiere que el analista comience haciendo preguntas de que lleven a un entendimiento básico del problema.   El primer conjunto de cuestiones se centra en el cliente, en los objetivos globales y en los beneficios.   El siguiente conjunto de cuestiones permiten que el analista comprenda

•

•

mejor el problema y que el cliente exprese sus percepciones sobre una solución.   La última serie de preguntas se centra en la efectividad de la reunión, son conocidas como Meta-Cuestiones:   ¿es usted la persona apropiada para responder a estas preguntas?   ¿son oficiales sus respuestas?   ¿son relevantes mis preguntas para su problema?   ¿hago muchas preguntas?   ¿existe alguien más que pueda proporcionar más información?   ¿hay algo más que deba preguntarle?

•

Esta sesión de preguntas-y-respuestas solo se debería utilizar en el primer encuentro, reemplazándose posteriormente por un tipo de reunión que combine elementos de resolución de problemas, negociación y especificación. B.  B.  ESTIMACIÓN DE LOS RECURSOS REQUERIDOS La segunda tarea en la planificación, es la estimación de los recursos requeridos para acometer el esfuerzo de desarrollo software. - Personas, recursos humanos Componentes de software reutilizables (componentes ya desarrollados o experimentados), que reducen el coste de desarrollo y aceleran la entrega. Componentes nuevos - Recursos de ingeniería de software y de hardware. Cada recurso se especifica con 4 características:        





Descripción del recurso, Informe de disponibilidad,





Fecha la que se Tiempoendurante el requiere, que será utilizado.

 

C.  C.  ESTIMACION DEL PROYECTO DE SOFTWARE. En el principio el costo del software constituía un pequeño porcentaje del costo total de los sistemas basados en computadoras. Hoy en día el software es el elemento más caro de la mayoría de los sistemas informáticos. Es una pequeña planeación sobre qué es lo que va a ser mi proyecto. Una de las actividades cruciales del proceso de gestión del proyecto del software es la planificación. Cuando se planifica un proyecto de software ese tiene que obtener estimaciones de esfuerzo humano requerido, de la duración cronológica del proyecto y del costo. Pero en muchos de los casos las estimaciones se hacen valiéndose de la experiencia pasada como única guía. Si un proyecto es bastante similar en tamaño y funciona un proyecto pasado es probable que el nuevo requiera aproximadamente la misma cantidad de esfuerzo, que dure aproximadamente lo mismo que el trabajo anterior. Si S i el proyecto es distinto entonces puede que las experiencias obtenidas no sean suficientes.

La planeación efectiva de un proyecto de software depende de la planeación detallada de su avance, anticipando problemas que puedan surgir y preparando con anticipación soluciones tentativas a ellos. Se supondrá que el administrador del proyecto es responsable de la Planeación desde la definición de requisitos hasta la entrega del sistema terminado. Los puntos analizados posteriormente generalmente son requeridos por grandes sistemas de programación, sin embargo, estos puntos son validos también para sistemas pequeños. Panorama. Hace una descripción general del proyecto detalle de la organización   Panorama. del plan y resume el resto del documento.   Plan de fases. Se fases. Se analiza el ciclo de desarrollo del proyecto como es: análisis de requisitos, fase de diseño de alto nivel, fase de diseño de bajo nivel, etc. Asociada con cada fase debe de haber una fecha que especifique cuando se





 



 



 



 



 



debe terminar estas fases y una indicación de cómo se pueden solapar las distintas fases del proyecto. Plan de organización. Se organización. Se defínelas responsabilidades específicas de los grupos que intervienen en el proyecto. Plan de pruebas.  pruebas.  Se hace un esbozo general de las pruebas y de las herramientas, procedimientos y responsabilidades para realizar las pruebas del sistema. Plan de control de modificaciones. Se modificaciones. Se establece un mecanismo para aplicar las modificaciones que se requieran a medida que se desarrolle el sistema. Plan de documentación.  documentación.  Sus funciones definir y controlar la documentación asociada con el proyecto. Plan de capacitación.  capacitación.  Se describe la preparación de los programadores que participan en el proyecto y las instrucciones a los usuarios para la utilización del sistema que se les entregue.

 

  Plan de revisión e informes. Se informes. Se analiza cómo se informa del estado del proyecto y se definen las revisiones formales asociadas con el avance de proyecto. operación.  Se describe el procedimiento para instalar el   Plan de instalación y operación. Se sistema en la localidad del usuario.   Plan de recursos y entregas. Se entregas. Se resume los detalles críticos del proyecto como fechas programadas, marcas de logros y todos los artículos que deben entrar bajo contrato.









Índice. Se muestra en donde encontrar las cosas dentro del plan.    Índice. Se Plan de mantenimiento. mantenimiento.   Se establece un bosquejo de los posibles tipos de mantenimiento que se tienen que dar para futuras versiones del sistema.



Errores                   

Errores clásicos en un proyecto de software Mal análisis en los requerimientos. Una mala planeación. No tener una negociación (documento, contrato) con el cliente. No hacer un análisis costo beneficio. Desconocer el ambiente de trabajo de los usuarios. Desconocer los usuarios que trabajan con co n el sistema. Mala elección de recursos (hardware, software, humanos). Herramientas para la planificación y Gestión de productos Software.

Para poder completar con éxito un proyecto de software, se necesita tener un control riguroso sobre el tiempo, las personas o los imprevistos que puedan surgir, como por ejemplo cambios en el software. Para ayudarnos en la planificación y gestión de proyectos, Microsoft nos proporciona dos herramientas básicas: Microsoft Project y Microsoft Solutions Framework.

PROBLEMAS DEL EQUIPO DE UN PROYECTO DE SOFTWARE Un error frecuente en empresas de programación es tener a todo el mundo haciendo de todo. Aunque eso en algún que otro escenario puede funcionar bien, causa que esas personas no puedan emitir estimados de calidad, ya que les resulta imposible poder determinar cuánto tiempo van a dedicar a cada tarea. Es por ello que los roles dentro de un equipo de programación deben ser lo más dedicados posible. Obviamente, dependiendo del tamaño de la aplicación, del tiempo y de los recursos disponibles, el equipo podrá ser de un tamaño u otro. Pero hay una serie de puestos que son imprescindibles para que todo funcione adecuadamente. Estos puestos tienen unas responsabilidades bien definidas. Los puestos que mínimamente se deben cumplir son los siguientes: JEFE DE PROYECTO Es el encargado de realizar el análisis de los requerimientos del cliente. De hacer el seguimiento diario de las tareas y de resolver cualquier problema de comunicación con otros equipos si los

 

hubiera. En el caso de que este equipo se convierta en cliente de otro equipo, esta persona es la que se encarga de realizar la comunicación con ellos. Obligatoriamente tiene que tener un background de programador, necesita entender a los programadores y la problemática a la que se enfrentan diariamente para poder asegurar que los requerimientos recogen toda la información necesaria para poder realizar la tarea. Es el responsable de que la implementación de esos requerimientos se haga correctamente. LÍDER DE EQUIPO Es el programador líder, debe ser alguien senior, con capacidad organizativa. Se encarga de redactar y mantener actualizados los requerimientos. También se encarga de escribir las especificaciones técnicas y crear las tareas, asignándolas a los desarrolladores de su equipo. Sus tareas de programación deben limitarse única y exclusivamente a la arquitectura, marcando la línea a seguir por el resto de programadores. Aparte de esto, tiene que revisar el trabajo de los programadores a su cargo para asegurar la calidad del código có digo escrito. DESARROLLADOR Es un programador, que se encarga de ejecutar el trabajo asignado por el líder del equipo. En un proyecto de software, normalmente el 20% del código constituye arquitectura y el 80% restante consiste en utilizar esa arquitectura para completar los requerimientos. Los desarrolladores son los encargados de completar ese 80%. DISEÑADOR GRÁFICO Y UX Este rol consiste en, a nivel de UX, realizar los flujos de trabajo dentro de una aplicación a nivel de mockups, para determinar posteriormente, los diseños que habrá que realizar y como se va a comportar la aplicación. Posteriormente, es el encargado de realizar el diseño gráfico de las pantallas que compone la aplicación, atendiendo a las reglas de UX que determinen la posición de los elementos, los esquemas de colores, tipografías, etc. LÍDER DE CALIDAD Debe ser alguien con conocimientos de programación y análisis, que sea capaz, utilizando los requerimientos, de desarrollar una suite de tests que verifiquen que el software cumple con los requerimientos. El líder de calidad es el último responsable de que las características funcionan tal y como se han especificado en los requerimientos. INGENIERO EN CALIDAD Es un programador o alguien con conocimientos de programación, encargado de escribir la suite de tests para automatizar el testeo del programa. Si se desarrollan productos de software, por lo general, estos deben venir acompañados de algún tipo de documentación, para ello, se necesitarían dos roles más: LÍDER DE DOCUMENTACIÓN Alguien con conocimientos técnicos, capaz de entender los requerimientos y, a partir de ellos, generar la documentación necesaria, se encarga de organizar el contenido a escribir y marcar la línea a seguir en cuanto a documentación. DOCUMENTADOR TÉCNICO

 

También debe tener un trasfondo técnico, para poder escribir contenido que tenga significado y se utilice el vocabulario adecuado. Su objetivo o bjetivo es completar la documentación sobre todas las características del producto.

PROBLEMAS DE LA TECNOLOGÍA UN PROYECTO DE SOFTWARE La tecnología cambia rápidamente:  rápidamente:  Las nuevas versiones de los sistemas operativos salen cada pocos años, por ejemplo, hace unos veinte años estábamos trabajando con MS-DOS, y ahora prácticamente nadie lo recuerda. Hoy en día, cualquier software nuevo, es casi c asi seguro que será construido con una estructura de aplicaciones empresariales o frameworks como Java de Sun Microsystems 2 Enterprise Edition (J2EE) o Microsoft NET. Estos frameworks en los que se basan gran número de aplicaciones, van evolucionando, proporcionando nuevas características o modificando las existentes. Resumiendo, las tecnologías de desarrollo de software cambian más rápido que otras tecnologías, como pueden ser las de la construcción. La tecnología es un dominio muy vasto: vasto:   En el desarrollo de software se utilizan muchas tecnologías, normalmente estas cambian en cada proyecto, y se utilizan varias a la vez, por lo que la complejidad aumenta y los programadores no llegan a tener nunca una experiencia amplia en un juego de tecnologías concreto. Cómo factor agravante, cada año aparecen nuevas tecnologías en el mercado, que, aunque pueden tener funcionalidades interesantes, requieren aprendizaje.

La experiencia en tecnología es incompleta:  incompleta:   Las tecnologías de desarrollo de software se quedan obsoletas en muy poco tiempo, apareciendo nuevas tecnologías. Esto implica quevalor, partey de la experiencia adquirida una tecnología particular pierda quelos losconocimientos desarrolladoresy estén aprendiendo nuevascon tecnologías a la vez que está desarrollando con ellas.