CAPITULO 1

Planificación de proyectos software Fallas en la planificación

Ing. de Software III

Facultad Politécnica - UNA

Planificación de proyectos de SW Fallas en la planificación
Los problemas mas comunes que enfrentan hoy en día los proyectos de desarrollo software, son situaciones tales como: Retraso en la entrega del producto final Aumento de los costos de desarrollo y mantenimiento Escasa calidad del software Esto se debe principalmente a una mala o escasa planificación
Ing. de Software III Facultad Politécnica - UNA

UNA Planificación de proyectos de SW Fallas en la planificación Causas de retrasos de los proyectos: Aplicación errónea o no-utilización de la información histórica de la organización Mala administración del proyecto Fallas en el uso de los planes Carencia de control de cambios Escasa motivación Estilo erróneo de liderazgo Carencia de control y gestión Organización errónea del grupo de trabajo.Planificación de proyectos de SW Fallas en la planificación Causas de retrasos de los proyectos: Inadecuada definición del proyecto Comprensión errónea del problema Desconocimiento o inexperiencia de cómo planificar Incumplimiento del ciclo de planificación Escasa negociación de compromisos con el usuario al inicio del proyecto Definición incompleta de los requerimientos Estimaciones optimistas Supuestos y restricciones del proyecto inválidos o no verificados Ing.UNA . de Software III Facultad Politécnica . Ing. de Software III Facultad Politécnica .

UNA . de Software III Facultad Politécnica . o la época de compras en Navidad. tal como la fecha de una exposición informática. de Software III Facultad Politécnica .UNA Planificación excesivamente optimista Causas fundamentales de las planificaciones demasiado optimistas Las causas fundamentales de las planificaciones excesivamente optimistas son profundas y variadas. El proyecto es subestimado deliberadamente por la directiva o el responsable de ventas para proponer una oferta insuperable. Ing. Falta de reconocimiento por parte de la gestión del proyecto de su retraso y falta de medidas para corregir el problema.Planificación de proyectos de SW Fallas en la planificación Causas de retrasos de los proyectos: Cambio de los requisitos del cliente que no se reflejan en los cambios de la planificación temporal. Ing. He aquí algunas de las causas: Hay un plazo límite externo e inmutable. cambios en las leyes de los impuestos. Los responsables y desarrolladores subestiman deliberadamente el proyecto porque desean un incentivo o les gusta trabajar bajo presión. Los responsables o clientes se niegan a aceptar un rango de estimación y hacen los planes basándose en una estimación puntual del «mejor caso». Riesgos predecibles y no predecibles que no se consideraron cuando comenzó el proyecto. Falta de comunicación entre la plantilla del proyecto que causa retrasos.

UNA . El responsable del proyecto es partidario de que los desarrolladores trabajarán más duro si la planificación es ambiciosa.UNA Presión excesiva en la planificación La primera reacción de los responsables y de los clientes cuando descubren que no están cumpliendo una planificación optimista es cargar más presión en la planificación sobre los desarrolladores e insistir en que realicen más horas extras. La presión excesiva en la planificación ocurre aprox. Ing. marketing o un cliente externo desean una fecha tope particular y el responsable del proyecto no puede contradecirles. pero se añaden nuevas prestaciones al proyecto. La directiva principal. Ing.Planificación excesivamente optimista Los desarrolladores subestiman un proyecto interesante para obtener fondos para trabajar en él. de Software III Facultad Politécnica . y en poco tiempo el proyecto se realiza bajo una planificación demasiado optimista. en un 75% de los proyecto grandes. El proyecto simplemente se estima mal. El proyecto comienza con una planificación realista. y por tanto diseñan la planificación en consecuencia. de Software III Facultad Politécnica . y cerca del 100% en todos los proyectos muy grandes.

Si abusa de las horas extras en un proyecto. de Software III Facultad Politécnica . y a su vez reduce la creatividad.Presión excesiva en la planificación Calidad. comentando detalladamente el código fuente. con los métodos de desarrollo eficiente. Un poco de presión en la planificación resultante de una planificación ligeramente optimista pero factible puede motivar. y rápido. La motivación externa excesiva (es decir.UNA Presión excesiva en la planificación Creatividad. el diseño y la construcción del producto) requieren ideas creativas. Estos se ocuparán de cosas de poca importancia durante unos meses después de darle un gran empujón al proyecto principal. estrés) reduce la motivación interna. y los directivos y desarrolladores del proyecto sienten la tentación de apostar al azar en vez de correr riesgos calculados. corrigiendo errores de baja prioridad que consideren interesantes y no eran lo suficientemente importantes para fijarlos en la entrega. Motivación. Ing.un 40% de todos los errores del software son causa de la tensión. A los desarrolladores del software les gusta trabajar. y en ese punto la motivación decae. limpiando sus sistemas de archivos. La creatividad requiere pensar mucho y una gran persistencia cuando la solución deseada no aparece inmediatamente. Pero en algún punto. de Software III Facultad Politécnica . Muchos aspectos del desarrollo del software (incluyendo la especificación. Agotamiento. estos errores se podrían haber evitado con una planificación apropiada y no provocando tensión en los desarrolladores Azar. Ing. El camino para pensar mucho y ser persistente requiere una motivación interna. Se ha determinado que alrededor de . Como una planificación excesivamente optimista es imposible alcanzar los objetivos. la planificación optimista cruza el umbral de la credibilidad.UNA . sus desarrolladores se verán afectados en el próximo proyecto.

con las mejores características de rendimiento. perder la comunicación y otras situaciones enemigas de la productividad. Gerald Weinberg sugiere pensar en los proyectos del software como en sistemas (Weinberg). Encontrar y formar a sus sustitutos prolonga la planificación. de Software III Facultad Politécnica . Ing. no se preocupan por ellos.UNA Puntos cruciales Algunas personas piensan que los proyectos software deberían planificarse de forma optimista. ya que el desarrollo del software debe ser más bien una aventura que un ejercicio monótono de ingeniería.UNA . En Quality Software Management. Las malas relaciones llevan a bajar la moral. Estas personas dicen que la presión en la planificación ayuda a la emoción. y las personas que dejan el proyecto tienden a ser las más competentes. Alimenta la tendencia existente entre los desarrolladores de creer que los directivos no los respetan. Relación entre desarrolladores y directivos. Cada sistema tiene unas entradas y genera unas salidas Ing. Las planificaciones excesivamente optimistas y la presión resultante en la planificación tienden a causar cambio voluntario excesivamente alto de personal. de Software III Facultad Politécnica . La presión en la planificación aumenta las diferencias entre desarrolladores y directivos.Presión excesiva en la planificación Cambio de personal. y no saben lo suficiente sobre el desarrollo del software como para saber cuándo están pidiendo algo que es imposible.

directivos. directivos. clientes.Puntos cruciales Proyecto entregado a tiempo Planificación precisa Producto de alta calidad Felicidad y satisfacción Mayor lealtad Otras entradas Proyecto software con una planificación precisa Mayores habilidades individuales de desarrollo Aumento del respeto entre desarrolladores. marketing y otros participantes del proyecto Experiencia en la entrega de software a tiempo Ing. clientes. de Software III Facultad Politécnica . marke% ting y otros grupos impli% cados en el proyecto Merma de la capacidad para desarrollar el siguiente producto Ing. de Software III Facultad Politécnica .UNA .UNA Puntos cruciales Proyecto retrasado Producto de ba a calidad Planificación excesivamente optimista Presión de planificación Estr!s "esarrolladores disgustados y c#nicos Otras entradas Proyecto software con una planificación excesivamente optimista Muchos cambios de personal$ disminución de la lealtad "eterioro de las relaciones entre desarrolladores.

Ing. construir una red que describa sus interdependencias. la fecha de finalización del proyecto entero se pone en peligro. Si estas tareas «críticas» se retrasan. Algunas de estas tareas quedan fuera del camino principal y pueden completarse sin preocuparse del impacto en la fecha de fin del proyecto.Principios básicos La realidad de un proyecto técnico (tanto si implica la construcción de una planta hidroeléctrica o desarrollar un sistema operativo) es que hay que realizar cientos de pequeñas tareas antes de poder alcanzar el objetivo final. Otras tareas se encuentran en el «camino crítico». Para conseguirlo. de Software III Facultad Politécnica .UNA . el gestor debe tener una planificación temporal que se haya definido con un grado de resolución que le permita supervisar el progreso y controlar el proyecto.UNA Principios básicos El objetivo del gestor del proyecto es definir todas las tareas del proyecto. de Software III Facultad Politécnica . Ing. identificar las tareas que son críticas dentro de la red y después hacerles un seguimiento para asegurarse de que el retraso se reconoce «de inmediato».

UNA Planificación de proyectos software Especificación de Requerimientos Ing.Principios básicos La planificación temporal para proyectos informáticos puede verse desde dos perspectivas bastante diferentes: En la primera se ha establecido ya (irrevocablemente) una fecha final de entrega del proyecto. de Software III Facultad Politécnica . Ing.UNA . El segundo punto de vista de la planificación temporal asume que se han estudiado unos límites cronológicos aproximados pero que la fecha final será establecida por los gestores del proyecto. de Software III Facultad Politécnica . La organización está limitada a distribuir el esfuerzo dentro del marco de tiempo previsto.

Ing. • Una capacidad del software que debe ser reunida o poseída por un sistema o componente del sistema para satisfacer un contrato. estándar. ¿ Qué es Ingeniería de Requisitos ? • Proceso mediante el cual se establecen los servicios que el sistema debe brindar y las restricciones que debe cumplir. de Software III Facultad Politécnica . u otra documentación formal.UNA Especificación de Requerimientos Definiciones Un requerimiento de software puede ser definido como: • Una capacidad del software necesaria por el usuario para resolver un problema o alcanzar un objetivo.Especificación de Requerimientos ¿ Qué es un Requerimiento ? Un requerimiento es una condición o capacidad a la que el sistema (siendo construido) debe conformar. especificación. • Es un proceso sistemático para derivar la definición del sistema a ser construido Ing.UNA . de Software III Facultad Politécnica .

UNA Brecha en la Comunicación (Scharer ’90) Según desarrolladores.. entonces la calidad de la construcción es irrelevante' El rol clave de los re(uerimientos es mostrar a los desarrolladores y usuarios QUE se necesita de un sistema' Proveer los re(uerimientos forma parte de un lengua e (ue todos comprenden. de Software III 22 .UNA son incapaces de definir prioridades entre sus necesidades rehúsan asumir responsabilidades por el sistema incapaces de dar un enunciado utilizable de sus necesidades no están comprometidos con los proyectos de desarrollo no aceptan soluciones de compromiso no pueden mantener el cronograma Ing.Rol de Requerimientos &i un producto no es lo que el cliente o los usuarios quieren. incluyendo los clientes' El primer y b)sico rol de los re(uerimientos es por lo tanto la CO U!"C#C"O!' Ing. de Software III Facultad Politécnica . no captan las necesidades operativas ponen excesivo énfasis en aspectos meramente técnicos pretenden indicarnos cómo hacer nuestro trabajo no son capaces de traducir necesidades claramente establecidas en un sistema siempre dicen que no siempre están pasados del presupuesto siempre están atrasados nos exigen tiempo y esfuerzo aún a costa de las obligaciones esenciales establecen estándares no realistas para la definición de Requisitos son incapaces de responder rápidamente a cambios en las necesidades Facultad Politécnica . Según usuarios. no saben lo que quieren no pueden articular lo que quieren muchas necesidades por motivos políticos quieren todo ya los usuarios... los desarrolladores.. ya (ue todos est)n involucrados.

de Software III Facultad Politécnica . Ejemplos: • Se deben ingresar cédula. atributos o interfaces externas) •Tienen consistencia (No son contradictorios entre sí) •Especifica el origen •Evita detalles de diseño •Están enumerados y ordenados (Ordenados por Importancia y estabilidad) Ing. sin tener en cuenta cuestiones de implementación. desempeño. nombre y teléfono de cada cliente • Se quiere un listado de los clientes por zona Ing. restricciones de diseño. de Software III Facultad Politécnica .UNA . Caracterizándose por : •Definidos sin ambigüedad (Tiene una única interpretación ) •Son completos (Define todos los Requisitos asociados con funcionalidad.Especificación de Requerimientos La Especificación de Requerimientos. define y documenta en forma completa el comportamiento externo del sistema a ser construido.UNA Tipos de Requerimientos Requerimientos Funcionales Describen las interacciones entre el sistema y su entorno (usuarios u otros sistemas).

Ejemplos: • Las consultas deben resolverse en menos de 3 segundos • El lenguaje de programación debe ser Java Ing.Tipos de Requerimientos Requerimientos No Funcionales Describen aspectos del sistema visibles por el usuario que no se relacionan de forma directa con el comportamiento funcional del sistema. de Software III Facultad Politécnica .UNA . de Software III Facultad Politécnica .UNA Preguntas? Ing.