Unidad1-02-IsIII CAP1 Planificacion 2 Fallas Req
Transcript of 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
Ing. de Software III Facultad Politécnica - UNA
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
Ing. de Software III Facultad Politécnica - UNA
Planificación de proyectos de SWFallas en la 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
Ing. de Software III Facultad Politécnica - UNA
Planificación de proyectos de SWFallas en la planificación
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.
Ing. de Software III Facultad Politécnica - UNA
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.
Ing. de Software III Facultad Politécnica - UNA
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.
Ing. de Software III Facultad Politécnica - UNA
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.
Ing. de Software III Facultad Politécnica - UNA
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.
Ing. de Software III Facultad Politécnica - UNA
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.
Ing. de Software III Facultad Politécnica - UNA
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.
Ing. de Software III Facultad Politécnica - UNA
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.
Ing. de Software III Facultad Politécnica - UNA
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
Ing. de Software III Facultad Politécnica - UNA
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
Ing. de Software III Facultad Politécnica - UNA
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
Ing. de Software III Facultad Politécnica - UNA
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.
Ing. de Software III Facultad Politécnica - UNA
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.
Ing. de Software III Facultad Politécnica - UNA
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.
Ing. de Software III Facultad Politécnica - UNA
Planificación de proyectos softwareEspecificación de Requerimientos
Ing. de Software III Facultad Politécnica - UNA
Especificación de Requerimientos
¿ Qué es un Requerimiento ?
Un requerimiento es una condición ocapacidad a la que el sistema (siendoconstruido) debe conformar.G
Ing. de Software III Facultad Politécnica - UNA
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
Ing. de Software III Facultad Politécnica - UNA
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.
Ing. de Software III Facultad Politécnica - UNA
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
Ing. de Software III Facultad Politécnica - UNA
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)
Ing. de Software III Facultad Politécnica - 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 implementación.
Ejemplos:• Se deben ingresar cédula, nombre y teléfono
de cada cliente• Se quiere un listado de los clientes por zona
Ing. de Software III Facultad Politécnica - UNA
Tipos de Requerimientos
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
Ing. de Software III Facultad Politécnica - UNA
Tipos de Requerimientos
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.
Ing. de Software III Facultad Politécnica - UNA
Preguntas?