PROBLEMAS EN LA PLANIFICACION DE UN PROYECTO DE SOFTWARE

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. 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 en la que se requiere,
 Tiempo durante el que será utilizado.
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 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

del plan y resume el resto del documento.
 Plan de 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 defínelas responsabilidades específicas de los grupos
que intervienen en el proyecto.
 Plan de 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 establece un mecanismo para aplicar las
modificaciones que se requieran a medida que se desarrolle el sistema.
 Plan de documentación. Sus funciones definir y controlar la documentación
asociada con el proyecto.
 Plan de 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 analiza cómo se informa del estado del proyecto
y se definen las revisiones formales asociadas con el avance de proyecto.
 Plan de instalación y operación. Se describe el procedimiento para instalar el
sistema en la localidad del usuario.
 Plan de recursos y 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.
 Plan de 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 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 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 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:

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 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:

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:

Las tecnologías de desarrollo de software se quedan obsoletas en muy poco tiempo,

apareciendo nuevas tecnologías.

Esto implica que parte de los conocimientos y la experiencia adquirida con una tecnología
particular pierda valor, y que los desarrolladores estén aprendiendo nuevas tecnologías a la vez
que está desarrollando con ellas.