Unidad1-02-IsIII CAP1 Planificacion 2 Fallas Req

Ing. de Software III Facultad Politécnica - UNA

CAPITULO 1

Planificación de proyectos software

Fallas en la planificación


Planificación de proyectos de SWFallas en la planificación

Los problemas mas comunes que enfrentanhoy en día los proyectos de desarrollosoftware, son situaciones tales como:lRetraso en la entrega del producto finallAumento de los costos de desarrollo ymantenimientolEscasa calidad del softwareEsto se debe principalmente a una mala oescasa planificación



Causas de retrasos de los proyectos:l Inadecuada definición del proyectol Comprensión errónea del problemal Desconocimiento o inexperiencia de cómo planificarl Incumplimiento del ciclo de planificaciónl Escasa negociación de compromisos con el usuario

al inicio del proyectol Definición incompleta de los requerimientosl Estimaciones optimistasl Supuestos y restricciones del proyecto inválidos o

no verificados



Causas de retrasos de los proyectos:l Aplicación errónea o no-utilización de la información

histórica de la organizaciónl Mala administración del proyectol Fallas en el uso de los planesl Carencia de control de cambiosl Escasa motivaciónl Estilo erróneo de liderazgol Carencia de control y gestiónl Organización errónea del grupo de trabajo.


Planificación de proyectos de SWFallas en la planificaciónCausas de retrasos de los proyectos:lCambio de los requisitos del cliente que no se reflejan en los cambios de la planificación temporal.lRiesgos predecibles y no predecibles que no se consideraron cuando comenzó el proyecto.lFalta de comunicación entre la plantilla del proyecto que causa retrasos.lFalta de reconocimiento por parte de la gestión del proyecto de su retraso y falta de medidas para corregir el problema.


Planificación excesivamente optimistaCausas 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 límite externo e inmutable, tal como la fecha de una exposición informática, cambios en las leyes de los impuestos, o la época de compras en Navidad.

l Los responsables o clientes se niegan a aceptar un rango deestimación y hacen los planes basándose en una estimación puntual del«mejor caso».

lLos responsables y desarrolladores subestiman deliberadamente elproyecto porque desean un incentivo o les gusta trabajar bajo presión.

l El proyecto es subestimado deliberadamente por la directiva o elresponsable de ventas para proponer una oferta insuperable.


Planificación excesivamente optimistal Los desarrolladores subestiman un proyecto interesante para obtener

fondos para trabajar en él.

l El responsable del proyecto es partidario de que los desarrolladorestrabajarán más duro si la planificación es ambiciosa, y por tantodiseñan la planificación en consecuencia.

l La directiva principal, marketing o un cliente externo desean una fechatope particular y el responsable del proyecto no puede contradecirles.

l El proyecto comienza con una planificación realista, pero se añadennuevas prestaciones al proyecto, y en poco tiempo el proyecto serealiza bajo una planificación demasiado optimista.

l El proyecto simplemente se estima mal.


Presión excesiva en la planificaciónLa primera reacción de losresponsables y de los clientescuando descubren que no estáncumpliendo una planificaciónoptimista es cargar más presión enla planificación sobre losdesarrolladores e insistir en querealicen más horas extras.

La presión excesiva en laplanificación ocurre aprox. en un75% de los proyecto grandes, ycerca del 100% en todos losproyectos muy grandes.


Presión excesiva en la planificaciónl Calidad. Se ha determinado que alrededor de .un 40% de todos

los errores del software son causa de la tensión; estos errores sepodrían haber evitado con una planificación apropiada y noprovocando tensión en los desarrolladores

l Azar. Como una planificación excesivamente optimista esimposible alcanzar los objetivos, con los métodos de desarrolloeficiente, y los directivos y desarrolladores del proyecto sienten latentación de apostar al azar en vez de correr riesgos calculados.

l Motivación. A los desarrolladores del software les gusta trabajar.Un poco de presión en la planificación resultante de unaplanificación ligeramente optimista pero factible puede motivar.Pero en algún punto, la planificación optimista cruza el umbral de lacredibilidad, y en ese punto la motivación decae, y rápido.


Presión excesiva en la planificaciónl Creatividad. Muchos aspectos del desarrollo del software

(incluyendo la especificación, el diseño y la construcción delproducto) requieren ideas creativas. La creatividad requiere pensarmucho y una gran persistencia cuando la solución deseada noaparece inmediatamente. El camino para pensar mucho y serpersistente requiere una motivación interna. La motivación externaexcesiva (es decir, estrés) reduce la motivación interna, y a su vezreduce la creatividad.

l Agotamiento. Si abusa de las horas extras en un proyecto, susdesarrolladores se verán afectados en el próximo proyecto. Estosse ocuparán de cosas de poca importancia durante unos mesesdespués de darle un gran empujón al proyecto principal, limpiandosus sistemas de archivos, comentando detalladamente el códigofuente, corrigiendo errores de baja prioridad que considereninteresantes y no eran lo suficientemente importantes para fijarlosen la entrega.


Presión excesiva en la planificaciónl Cambio de personal. Las planificaciones excesivamente

optimistas y la presión resultante en la planificación tienden acausar cambio voluntario excesivamente alto de personal, y laspersonas que dejan el proyecto tienden a ser las máscompetentes, con las mejores características de rendimiento.Encontrar y formar a sus sustitutos prolonga la planificación.

l Relación entre desarrolladores y directivos. La presión en laplanificación aumenta las diferencias entre desarrolladores ydirectivos. Alimenta la tendencia existente entre los desarrolladoresde creer que los directivos no los respetan, no se preocupan porellos, y no saben lo suficiente sobre el desarrollo del software comopara saber cuándo están pidiendo algo que es imposible. Lasmalas relaciones llevan a bajar la moral, perder la comunicación yotras situaciones enemigas de la productividad.


Puntos cruciales

l Algunas personas piensan que los proyectos softwaredeberían planificarse de forma optimista, ya que eldesarrollo del software debe ser más bien una aventuraque un ejercicio monótono de ingeniería. Estaspersonas dicen que la presión en la planificación ayudaa la emoción.

l En Quality Software Management, Gerald Weinbergsugiere pensar en los proyectos del software como ensistemas (Weinberg). Cada sistema tiene unas entradasy genera unas salidas


Puntos cruciales

Proyecto softwarecon una planificación

precisa

Planificación precisa

Otras entradas

Proyecto entregadoa tiempo

Producto de alta calidad

Felicidad y satisfacción

Mayor lealtad

Mayores habilidadesindividuales de desarrollo

Aumento del respeto entredesarrolladores, directivos,

clientes, marketing y otros participantes

del proyecto

Experiencia en la entregade software a tiempo


Puntos cruciales

Proyecto softwarecon una planificación

excesivamente optimista

Planificación excesivamente optimista

Otras entradas

Proyecto retrasado

Producto de baja calidad

Estrés

Desarrolladores disgustadosy cínicos

Muchos cambios de personal;disminución de la lealtad

Deterioro de las relacionesentre desarrolladores,

directivos, clientes, marke-ting y otros grupos impli-

cados en el proyecto

Merma de la capacidad paradesarrollar el siguiente

producto

Presión deplanificación


Principios básicosl La realidad de un proyecto técnico (tanto si implica la

construcción de una planta hidroeléctrica o desarrollarun sistema operativo) es que hay que realizar cientosde pequeñas tareas antes de poder alcanzar el objetivofinal.

l Algunas de estas tareas quedan fuera del caminoprincipal y pueden completarse sin preocuparse delimpacto en la fecha de fin del proyecto. Otras tareas seencuentran en el «camino crítico». Si estas tareas«críticas» se retrasan, la fecha de finalización delproyecto entero se pone en peligro.


Principios básicosl El objetivo del gestor del proyecto es definir todas las

tareas del proyecto, construir una red que describa susinterdependencias, identificar las tareas que son críticasdentro de la red y después hacerles un seguimientopara asegurarse de que el retraso se reconoce «deinmediato».

l Para conseguirlo, el gestor debe tener una planificacióntemporal que se haya definido con un grado deresolución que le permita supervisar el progreso ycontrolar el proyecto.


Principios básicosLa planificación temporal para proyectos informáticospuede verse desde dos perspectivas bastantediferentes:

l En la primera se ha establecido ya (irrevocablemente)una fecha final de entrega del proyecto. La organizaciónestá limitada a distribuir el esfuerzo dentro del marco detiempo previsto.

l El segundo punto de vista de la planificación temporalasume que se han estudiado unos límites cronológicosaproximados pero que la fecha final será establecidapor los gestores del proyecto.


Planificación de proyectos softwareEspecificación de Requerimientos


Especificación de Requerimientos

¿ Qué es un Requerimiento ?

Un requerimiento es una condición ocapacidad a la que el sistema (siendoconstruido) debe conformar.G


Especificación de RequerimientosDefiniciones

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 poseída por un

sistema o componente del sistema para satisfacer un contrato, especificación, estándar, u otra documentación formal.

¿ 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.• Es un proceso sistemático para derivar la definición del sistema a

ser construido


Rol de RequerimientosSi un producto no es lo que el cliente o los usuarios quieren, entonces la calidad de la construcción 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 están involucrados, incluyendo los clientes.

El primer y básico rol de los requerimientos es por lo tanto la COMUNICACION.


22

Brecha en la Comunicación(Scharer ’90)

Según desarrolladores, los usuarios... Según usuarios, los desarrolladores...

no saben lo que quieren no captan las necesidades operativas

no pueden articular lo que quieren ponen excesivo énfasis en aspectos meramente técnicos

muchas necesidades por motivos políticos pretenden indicarnos cómo hacer nuestro trabajo

quieren todo ya no son capaces de traducir necesidades claramente establecidas en un sistema

son incapaces de definir prioridades entre sus necesidades

siempre dicen que no

rehúsan asumir responsabilidades por el sistema siempre están pasados del presupuesto

incapaces de dar un enunciado utilizable de sus necesidades

siempre están atrasados

no están comprometidos con los proyectos de desarrollo

nos exigen tiempo y esfuerzo aún a costa de las obligaciones esenciales

no aceptan soluciones de compromiso establecen estándares no realistas para la definición de Requisitos

no pueden mantener el cronograma son incapaces de responder rápidamente a cambios en las necesidades


Especificación de Requerimientos

La Especificación de Requerimientos, define y documenta en forma completa el comportamiento externo del sistema a ser construido.

Caracterizándose por :

•Definidos sin ambigüedad (Tiene una única interpretación )•Son completos (Define todos los Requisitos asociados con funcionalidad, desempeño, restricciones de diseño, 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)


Tipos de Requerimientos

Requerimientos Funcionales

Describen las interacciones entre el sistema y su entorno (usuarios u otros sistemas), sin tener en cuenta cuestiones de implementación.

Ejemplos:• Se deben ingresar cédula, nombre y teléfono

de cada cliente• Se quiere un listado de los clientes por zona



Requerimientos No FuncionalesDescriben 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 programación debe ser Java



Requerimientos No FuncionalesUna clasificación amplia, permite identificar en 3 categorías:Req. Del producto: Ej. Cantidad de memoria requerida, tiempo de respuestaReq. De la organización: Ej. Estándares de desarrollo, documentación a entregar junto con el producto, etc.Req. Externos: Ej. Interoperabilidad con otros productos, aspectos legales, etc.


Preguntas?

Unidad1-02-IsIII CAP1 Planificacion 2 Fallas Req

Documents

Transcript of Unidad1-02-IsIII CAP1 Planificacion 2 Fallas Req