CAPITULO 1

Planificacin de proyectos software Fallas en la planificacin

Ing. de Software III

Facultad Politcnica - UNA

Planificacin de proyectos de SW Fallas en la planificacin

Los problemas mas comunes que enfrentan hoy en da los proyectos de desarrollo software, son situaciones tales como: lRetraso en la entrega del producto final lAumento de los costos de desarrollo y mantenimiento lEscasa calidad del software Esto se debe principalmente a una mala o escasa planificacin
Ing. de Software III Facultad Politcnica - UNA

Planificacin de proyectos de SW Fallas en la planificacin

Causas de retrasos de los proyectos:
l l l l l l l l

Inadecuada definicin del proyecto Comprensin errnea del problema Desconocimiento o inexperiencia de cmo planificar Incumplimiento del ciclo de planificacin Escasa negociacin de compromisos con el usuario al inicio del proyecto Definicin incompleta de los requerimientos Estimaciones optimistas Supuestos y restricciones del proyecto invlidos o no verificados
Facultad Politcnica - UNA

Ing. de Software III

Planificacin de proyectos de SW Fallas en la planificacin

Causas de retrasos de los proyectos:
l l l l l l l l

Aplicacin errnea o no-utilizacin de la informacin histrica de la organizacin Mala administracin del proyecto Fallas en el uso de los planes Carencia de control de cambios Escasa motivacin Estilo errneo de liderazgo Carencia de control y gestin Organizacin errnea del grupo de trabajo.
Facultad Politcnica - UNA

Ing. de Software III

Planificacin de proyectos de SW Fallas en la planificacin

Causas de retrasos de los proyectos:
lCambio

de los requisitos del cliente que no se reflejan en los cambios de la planificacin temporal. lRiesgos predecibles y no predecibles que no se consideraron cuando comenz el proyecto. lFalta de comunicacin entre la plantilla del proyecto que causa retrasos. lFalta de reconocimiento por parte de la gestin del proyecto de su retraso y falta de medidas para corregir el problema.

Ing. de Software III

Facultad Politcnica - UNA

Planificacin excesivamente optimista

Causas fundamentales de las planificaciones demasiado optimistas Las causas fundamentales de las planificaciones excesivamente optimistas son profundas y variadas. He aqu algunas de las causas: l Hay un plazo lmite externo e inmutable, tal como la fecha de una exposicin informtica, cambios en las leyes de los impuestos, o la poca de compras en Navidad. Los responsables o clientes se niegan a aceptar un rango de estimacin y hacen los planes basndose en una estimacin puntual del mejor caso.
l lLos

responsables y desarrolladores subestiman deliberadamente el proyecto porque desean un incentivo o les gusta trabajar bajo presin. El proyecto es subestimado deliberadamente por la directiva o el responsable de ventas para proponer una oferta insuperable.
l
Ing. de Software III Facultad Politcnica - UNA

Planificacin excesivamente optimista

l

Los desarrolladores subestiman un proyecto interesante para obtener fondos para trabajar en l. El responsable del proyecto es partidario de que los desarrolladores trabajarn ms duro si la planificacin es ambiciosa, y por tanto disean la planificacin en consecuencia. La directiva principal, marketing o un cliente externo desean una fecha tope particular y el responsable del proyecto no puede contradecirles. El proyecto comienza con una planificacin realista, pero se aaden nuevas prestaciones al proyecto, y en poco tiempo el proyecto se realiza bajo una planificacin demasiado optimista. El proyecto simplemente se estima mal.

Ing. de Software III

Facultad Politcnica - UNA

Presin excesiva en la planificacin

La primera reaccin de los responsables y de los clientes cuando descubren que no estn cumpliendo una planificacin optimista es cargar ms presin en la planificacin sobre los desarrolladores e insistir en que realicen ms horas extras. La presin excesiva en la planificacin ocurre aprox. en un 75% de los proyecto grandes, y cerca del 100% en todos los proyectos muy grandes.
Ing. de Software III Facultad Politcnica - UNA

Presin excesiva en la planificacin

l

Calidad. Se ha determinado que alrededor de .un 40% de todos los errores del software son causa de la tensin; estos errores se podran haber evitado con una planificacin apropiada y no provocando tensin en los desarrolladores Azar. Como una planificacin excesivamente optimista es imposible alcanzar los objetivos, con los mtodos de desarrollo eficiente, y los directivos y desarrolladores del proyecto sienten la tentacin de apostar al azar en vez de correr riesgos calculados. Motivacin. A los desarrolladores del software les gusta trabajar. Un poco de presin en la planificacin resultante de una planificacin ligeramente optimista pero factible puede motivar. Pero en algn punto, la planificacin optimista cruza el umbral de la credibilidad, y en ese punto la motivacin decae, y rpido.

Ing. de Software III

Facultad Politcnica - UNA

Presin excesiva en la planificacin

l

Creatividad. Muchos aspectos del desarrollo del software (incluyendo la especificacin, el diseo y la construccin del producto) requieren ideas creativas. La creatividad requiere pensar mucho y una gran persistencia cuando la solucin deseada no aparece inmediatamente. El camino para pensar mucho y ser persistente requiere una motivacin interna. La motivacin externa excesiva (es decir, estrs) reduce la motivacin interna, y a su vez reduce la creatividad. Agotamiento. Si abusa de las horas extras en un proyecto, sus desarrolladores se vern afectados en el prximo proyecto. Estos se ocuparn de cosas de poca importancia durante unos meses despus de darle un gran empujn al proyecto principal, limpiando sus sistemas de archivos, comentando detalladamente el cdigo fuente, corrigiendo errores de baja prioridad que consideren interesantes y no eran lo suficientemente importantes para fijarlos en la entrega.
Facultad Politcnica - UNA

Ing. de Software III

Presin excesiva en la planificacin

l

Cambio de personal. Las planificaciones excesivamente optimistas y la presin resultante en la planificacin tienden a causar cambio voluntario excesivamente alto de personal, y las personas que dejan el proyecto tienden a ser las ms competentes, con las mejores caractersticas de rendimiento. Encontrar y formar a sus sustitutos prolonga la planificacin. Relacin entre desarrolladores y directivos. La presin en la planificacin aumenta las diferencias entre desarrolladores y directivos. Alimenta la tendencia existente entre los desarrolladores de creer que los directivos no los respetan, no se preocupan por ellos, y no saben lo suficiente sobre el desarrollo del software como para saber cundo estn pidiendo algo que es imposible. Las malas relaciones llevan a bajar la moral, perder la comunicacin y otras situaciones enemigas de la productividad.

Ing. de Software III

Facultad Politcnica - UNA

Puntos cruciales
l

Algunas personas piensan que los proyectos software deberan planificarse de forma optimista, ya que el desarrollo del software debe ser ms bien una aventura que un ejercicio montono de ingeniera. Estas personas dicen que la presin en la planificacin ayuda a la emocin. En Quality Software Management, Gerald Weinberg sugiere pensar en los proyectos del software como en sistemas (Weinberg). Cada sistema tiene unas entradas y genera unas salidas

Ing. de Software III

Facultad Politcnica - UNA

Puntos cruciales
Proyecto entregado a tiempo

Planificacin precisa

Producto de alta calidad Felicidad y satisfaccin Mayor lealtad

Otras entradas

Proyecto software con una planificacin precisa

Mayores habilidades individuales de desarrollo Aumento del respeto entre desarrolladores, directivos, clientes, marketing y otros participantes del proyecto Experiencia en la entrega de software a tiempo

Ing. de Software III

Facultad Politcnica - UNA

Puntos cruciales
Proyecto retrasado Producto de baja calidad

Planificacin excesivamente optimista Presin de planificacin

Estrs Desarrolladores disgustados y cnicos

Otras entradas

Proyecto software con una planificacin excesivamente optimista

Muchos cambios de personal; disminucin de la lealtad Deterioro de las relaciones entre desarrolladores, directivos, clientes, marketing y otros grupos implicados en el proyecto Merma de la capacidad para desarrollar el siguiente producto

Ing. de Software III

Facultad Politcnica - UNA

Principios bsicos
l

La realidad de un proyecto tcnico (tanto si implica la construccin de una planta hidroelctrica o desarrollar un sistema operativo) es que hay que realizar cientos de pequeas tareas antes de poder alcanzar el objetivo final. Algunas de estas tareas quedan fuera del camino principal y pueden completarse sin preocuparse del impacto en la fecha de fin del proyecto. Otras tareas se encuentran en el camino crtico. Si estas tareas crticas se retrasan, la fecha de finalizacin del proyecto entero se pone en peligro.

Ing. de Software III

Facultad Politcnica - UNA

Principios bsicos
l

El objetivo del gestor del proyecto es definir todas las tareas del proyecto, construir una red que describa sus interdependencias, identificar las tareas que son crticas dentro de la red y despus hacerles un seguimiento para asegurarse de que el retraso se reconoce de inmediato. Para conseguirlo, el gestor debe tener una planificacin temporal que se haya definido con un grado de resolucin que le permita supervisar el progreso y controlar el proyecto.

Ing. de Software III

Facultad Politcnica - UNA

Principios bsicos
La planificacin temporal para proyectos informticos puede verse desde dos perspectivas bastante diferentes:
l

En la primera se ha establecido ya (irrevocablemente) una fecha final de entrega del proyecto. La organizacin est limitada a distribuir el esfuerzo dentro del marco de tiempo previsto. El segundo punto de vista de la planificacin temporal asume que se han estudiado unos lmites cronolgicos aproximados pero que la fecha final ser establecida por los gestores del proyecto.
Facultad Politcnica - UNA

Ing. de Software III

Especificacin de Requerimientos

Planificacin de proyectos software

Ing. de Software III

Facultad Politcnica - UNA

Especificacin de Requerimientos
Qu es un Requerimiento ?

G
Ing. de Software III

Un requerimiento es una condicin o capacidad a la que el sistema (siendo construido) debe conformar.

Facultad Politcnica - UNA

Especificacin 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. Una capacidad del software que debe ser reunida o poseda por un sistema o componente del sistema para satisfacer un contrato, especificacin, estndar, u otra documentacin formal. Qu es Ingeniera de Requisitos ? Proceso mediante el cual se establecen los servicios que el sistema debe brindar y las restricciones que debe cumplir. Es un proceso sistemtico para derivar la definicin del sistema a ser construido

Ing. de Software III

Facultad Politcnica - UNA

Rol de Requerimientos
Si un producto no es lo que el cliente o los usuarios quieren, entonces la calidad de la construccin es irrelevante. El rol clave de los requerimientos es mostrar a los desarrolladores y usuarios QUE se necesita de un sistema. Proveer los requerimientos forma parte de un lenguaje que todos comprenden, ya que todos estn involucrados, incluyendo los clientes. El primer y bsico rol de los requerimientos es por lo tanto la COMUNICACION.

Ing. de Software III

Facultad Politcnica - UNA

Brecha en la Comunicacin
(Scharer 90)
Segn desarrolladores, no saben lo que quieren no pueden articular lo que quieren muchas necesidades por motivos polticos quieren todo ya los usuarios... Segn usuarios, los desarrolladores...

no captan las necesidades operativas ponen excesivo nfasis en aspectos meramente tcnicos pretenden indicarnos cmo hacer nuestro trabajo no son capaces de traducir necesidades claramente establecidas en un sistema siempre dicen que no siempre estn pasados del presupuesto siempre estn atrasados nos exigen tiempo y esfuerzo an a costa de las obligaciones esenciales establecen estndares no realistas para la definicin de Requisitos son incapaces de responder rpidamente a cambios en las necesidades
Facultad Politcnica - UNA

son incapaces de definir prioridades entre sus necesidades rehsan asumir responsabilidades por el sistema incapaces de dar un enunciado utilizable de sus necesidades no estn comprometidos con los proyectos de desarrollo no aceptan soluciones de compromiso no pueden mantener el cronograma

Ing. de Software III

22

Especificacin de Requerimientos
La Especificacin de Requerimientos, define y documenta en forma completa el comportamiento externo del sistema a ser construido. Caracterizndose por : Definidos sin ambigedad (Tiene una nica interpretacin ) Son completos (Define todos los Requisitos asociados con funcionalidad, desempeo, restricciones de diseo, atributos o interfaces externas) Tienen consistencia (No son contradictorios entre s) Especifica el origen Evita detalles de diseo Estn enumerados y ordenados (Ordenados por Importancia y estabilidad)

Ing. de Software III

Facultad Politcnica - UNA

Tipos de Requerimientos
Requerimientos Funcionales
Describen las interacciones entre el sistema y su entorno (usuarios u otros sistemas), sin tener en cuenta cuestiones de implementacin. Ejemplos: Se deben ingresar cdula, nombre y telfono de cada cliente Se quiere un listado de los clientes por zona
Ing. de Software III Facultad Politcnica - UNA

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. Ejemplos: Las consultas deben resolverse en menos de 3 segundos El lenguaje de programacin debe ser Java

Ing. de Software III

Facultad Politcnica - UNA

Tipos de Requerimientos
Requerimientos No Funcionales
Una clasificacin amplia, permite identificar en 3 categoras: Req. Del producto: Ej. Cantidad de memoria requerida, tiempo de respuesta Req. De la organizacin: Ej. Estndares de desarrollo, documentacin a entregar junto con el producto, etc. Req. Externos: Ej. Interoperabilidad con otros productos, aspectos legales, etc.

Ing. de Software III

Facultad Politcnica - UNA

Preguntas?

Ing. de Software III

Facultad Politcnica - UNA