Gestion De Proyecto De Desarrollo De Software
Upcoming SlideShare
Loading in...5
×
 

Gestion De Proyecto De Desarrollo De Software

on

  • 15,046 views

anteproyecto, desarrollo de software

anteproyecto, desarrollo de software

Statistics

Views

Total Views
15,046
Views on SlideShare
14,963
Embed Views
83

Actions

Likes
1
Downloads
469
Comments
1

3 Embeds 83

http://www.slideshare.net 67
http://aydeefonseca.blogspot.com 15
http://aydeefonseca.blogspot.ru 1

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Gestion De Proyecto De Desarrollo De Software Gestion De Proyecto De Desarrollo De Software Presentation Transcript

  • GESTION DE PROYECTO DE DESARROLLO DE SOFTWARE
    Aydee Fonseca Medina
    Decimo Semestre
    Ingeniería de Sistemas
    UAN – NEIVA
    2010
  • La ingeniería del Software es definida como la disciplina que se encarga de ofrecer métodos y técnicas para desarrollar y mantener software de calidad.
    *Es el estudio de los principios y metodologías para el desarrollo y mantenimiento de sistemas software (Zelkovitz, 1978)
    *Es la aplicación práctica del conocimiento científico al diseño y construcción de programas de computadora y a la documentación asociada requerida para desarrollar, operar y mantenerlos. Se conoce también como Desarrollo de Software o Producción de Software (Bohem, 1976).
  • Trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener software de modo rentable, que sea fiable y trabaje en máquinas reales (Bauer, 1972).
     
    Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software; es decir, la aplicación de la ingeniería al software (IEEE, 1993).
     
    La ingeniería del software parte del concepto de ciclo de vida como conjunto de actividades que ocurren durante el desarrollo de software, esto es determinar la secuencia desde que se inicia hasta que termina.
     
    En un ciclo de vida participan: Gestor, Analista, Usuarios, plan de software, Requisitos de software, Equipo SW.
  • Interrelación de los agentes que configuran el proceso de desarrollo de software
    GESTOR
    USUARIOS
    EQUIPO SW
    ANALISTA
    PLAN SOFTWARE
    REQUISITOS SOFTWARE
  • Fases del ciclo de vida
    Existen muchas metodologías de desarrollo de software, pero todas ellas comprenden los mismos pasos y las mismas técnicas.
    Fase de análisis y planificación del sistema. Comprende:
    -Definición de requisitos de usuarios (RU)
    -Definición de requisitos de software (RS)
    Fase de Desarrollo. Incluye:
    -Diseño de la arquitectura(DA)
    -Diseño detallado y codificación(DD)
    -Transferencia (TR)
     Fase de operación y mantenimiento (OM) 
  • Fase de análisis y Planificación
    Objetivo: Definir exactamente qué es lo que se pretende que el software a desarrollar haga, y cómo queremos que lo haga, respondiendo a las preguntas tales como: 
    ¿Qué es lo que debe hacer el sistema?
    ¿Qué es lo que debe hacer el software a desarrollar?
    ¿En qué condiciones debe funcionar?
    ¿Qué limitaciones tendrá?
    ¿Cómo se implantará?
    ¿Qué recursos materiales, temporales y humanos hacen falta para ello?
    ¿Cómo se verificará que el sistema funcione correctamente?
  • Fase de análisis y planificación 
    Esta fase comienza con la definición del sistema global (hardware, software, etc.) y la caracterización del problema a resolver, de donde se extraen las pertinentes conclusiones acerca de las restricciones temporales, económicas.
    Fase (o sub-fase) de definición de los requisitos de usuario(RU): Documentación del sistema, entrevista con el Cliente o usuarios, construcción de prototipos o cualquier otro procedimiento que se estime oportuno, se “capturan” los requisitos que debe cumplir el sistema con el fin de que satisfaga las necesidades del usuario.
  • Fase: Definición de requisitos del software (RS):
    Objetivo: Construir un modelo conceptual de lo debe hacer el software, estimar el coste asociado al mismo (con una precisión aproximada del 30%), y definir las responsabilidades individuales dentro del equipo de trabajo.
    Concluida esta fase se da por terminada la participación directa del cliente o usuario, como parte interesada en el proceso de definición del trabajo. A partir de este momento, al comenzar la fase de desarrollo, el Cliente pasa a ser un supervisor del avance de los trabajos, como en cualquier otro tipo de proyecto.
  • Fase de análisis y planificación 
    DEFINICON DE REQUISITOOS
    REVISION DE REQUISITOS
    PLANIFICACIÓN
    COSTE RECURSOS PLANIFICACION
    DATOS DE USUARIO
    DEFINICION DEL SISTEMA
    FUNCIONES HARDWARE
    REVISION REQUISITOS SOFTWARE
    (RRS)
    DEFINICION REQUISISTOS SOFTWARE (DRS)
    NECESIDAD
    DISEÑO, OPERACIÓN, MANTENIMIENTO
  • Fases de Desarrollo
    Comienza con la aprobación formal de los requisitos del software por parte del usuario o Cliente hasta la puesta en funcionamiento del sistema, incluyendo tres sub-fases, de diseño de alto nivel, diseño detallado y transferencia.
    La fase (o sub-fase) de diseño de alto nivel o diseño arquitectónico(DA)
    Objeto: Definir la estructura del software a desarrollar a partir del modelo establecido en la fase RS. Dicha arquitectura se obtiene asignando funciones a componentes de software, y definiendo los flujos de datos y de control entre dichas componentes.
  • Fase de Diseño detallado (DD).
    Objetivo: Refina los detalles más significativos el diseño de alto nivel de la fase anterior, se codifica, documento y prueba.
    La verificación y pruebas del software, debe realizarse a cuatro niveles diferentes:
    A nivel de unidad de software.
    A nivel de integración de todas las unidades software.
    A nivel de validación del software con respecto a los requisitos de DRS.
    A nivel del sistema completo, según los requisitos de usuario (DRU)
  • Fase de transferencia (TR)
    Objeto: Se instala el software sobre la plataforma (hardware) final, se lleva a cabo los test de aceptación especificada, y se comprueba que el programa satisface los requisitos para los que fue concebido. En tales condiciones el software recibe la aceptación provisional, y comienza su operación y uso.
  • Fase de Desarrollo 
    ESTANDARES
    DRS
    DA
    RDA
    DD
    RDD
    DDA
    Plan Desarrollo DD
    PLAN DESARROLLO DA
    DDD
    CODIF
    Plan Desarrollo TR
    TU1
    TUn
    MUS

    SRD
    TR
    TEST INTEGR
    TEST VALID
    TEST SISTEMA
    SOFTWARE
    TRANSFERIDO
    SWINTEGRADA
  • Fase de Operación y Mantenimiento (OM)
    Fase de operación, es la de supervisión (y corrección de los vicios o defectos del producto).
     
    Fase de Mantenimiento, a las modificaciones que se le deben realizar al software como consecuencia de errores detectados, o como respuesta ante nuevas necesidades del usuario.
     
    Durante la fase de OM, se genera y actualiza el documento de historia del proyecto (DHP), que reúne todos los errores y todas las modificaciones realizadas sobre el software, y que permite calcular y analizar la fiabilidad del software, y el rendimiento del equipo de trabajo (para futuros proyectos).
  • Fase de Operación y Mantenimiento 
    SISTEMA
    DEFINITIVAMENTE
    DTR
    OPERACIÓN Y EVALUACIO
    ACEPTACION DEFINITIVA
    SW
    Provisionalmente aceptado
    DHP
    ERRORES
    REGISTRO DE MANTENIMIENTO
    MMTO Y DEPURACION
    REGISTRO DE FALLOS
    MODELO DE FIABILIDAD
    FIABILIDAD
  • Tipos de ciclo de vida
    Se adopta un modelo de ciclo de vida que defina en que secuencia relativa se ejecuta cada fase y, sobre cambios al software.
    Modelo en Cascada o Waterfall
    Cada fase se ejecuta una única vez, a continuación de la que le precede y con inmediata anterioridad a la que le sigue. Cuando en una fase se detectan errores o cambios que deben incluirse, se debe hacer una iteración en la fase inmediatamente anterior.
  • Modelo en Cascada o Waterfall
    RU
    RS
    DA
    DD
    TR
    OM
  • Modelo Incremental
    Coincide con el modelo de cascada hasta el final de la fase de diseño de alto nivel (DA). A partir de ese momento, las fases DD, TR y OM se descomponen en un cierto número de unidades menores, más simples y manejables, que se implantan por separado.
    RU
    RS
    DA
    DD1
    TR1
    OM1
    DD2
    TR2
    OM2
  • Modelo Evolutivo
    Se diferencia del incremental en que no se reaprovechan las fases de requisitos ni de diseño arquitectónico, y que todas las versiones del producto son el resultado de un ciclo completo que incorpora toda la experiencia de los ciclos precedentes.
    Se utiliza cuando existe la intención a priori, de liberar en el tiempo varias versiones del mismo desarrollo del software.
    Obliga a mantener “vivas” varias versiones a la vez, en el caso de haya más de un usuario y no se produzca un cambio coordinado de versiones entre todos los usuarios a la vez. Los costes se incrementan de manera notable. Provoca frustración en los usuarios, que perciben cada versión como una corrección de errores de la anterior y, en definitiva, como un software aún no terminado por completo.
     
  • RU
    RS
    DA
    DD
    OM1
    TR
    RU
    RS
    DA
    DD
    OM2
    TR
    RU
    RS
    DA
    DD
    OM3
    TR
  • EVALUACIÓN ECONOMICA
    Objetivo: Ayudar al responsable de un proyecto a identificar las peculiaridades de un trabajo de este tipo que tienen incidencia sobre los aspectos de gestión del mismo, como son:
    -La descomposición en actividades y tareas.
    -La configuración del equipo de trabajo
    -La planificación más adecuada.
    -El riesgo en el que se incurre.
    -El control de configuración de los elementos del proyecto.
  • EVALUACIÓN ECONOMICA
    Volumen relativo de participación según categoría y fase del proyecto
  • Participación del equipo de trabajo en cada fase. 
    La experiencia demuestra que el nivel al que se involucran en el proyecto cada tipo de persona (según la categoría profesional a la que pertenece) cambia durante el ciclo de vida del proyecto.
    Modelos de costes de desarrollo software.
    Modelo “40-20-40”
    -El 40% del esfuerzo total se destina a tareas de análisis y planificación, el 20% a codificación y transferencia, y el 40% restante a validación y pruebas.
    -Del 40% asociado a las tareas de análisis y planificación, a su vez, el 40% se destina a labores de planificación, el 20% al análisis de requisitos y el 40% restante a actividades de desarrollo.
     
  • Modelos de costes de desarrollo software.
    Modelo “40-20-40”
    -El 40% del esfuerzo total se destina a tareas de análisis y planificación, el 20% a codificación y transferencia, y el 40% restante a validación y pruebas.
    -Del 40% asociado a las tareas de análisis y planificación, a su vez, el 40% se destina a labores de planificación, el 20% al análisis de requisitos y el 40% restante a actividades de desarrollo.
     
  • Modelo “40-20-40”
  • Coste de los cambios
    El coste de un cambio en el alcance del trabajo depende en gran medida del momento en el que se identifique la necesidad del mismo. Según avanza el ciclo de vida del proyecto, el coste de un cambio individual se incrementa, según muestra la gráfica.
    En la figura muestra cómo los cambios a los requisitos implican costes bajos en la etapa de análisis y planificación del sistema, costes que crecen de manera abultada al comenzar las fases de diseño, pruebas y transferencia, y que se estabilizan durante la fase de operación y mantenimiento.
  • Coste de mantenimiento
    Se deben considerar dos aspectos:
    Todo contrato estipula una cobertura por garantía, y la responsabilidad del equipo de trabajo se limita a dicho período, exclusivamente. Incluso aunque se detecte un defecto en la realización del software, el equipo no tiene porque responsabilizarse del mismo si se ha agotado dicho período.
    Tipo de mantenimiento Correctivo, es decir, aquél orientado a corregir los defectos de diseño e implantación del software, siendo responsabilidad del contratista solo este mantenimiento.
  • CONTROL DE CONFIGURACION
    El control de configuración (gestión de la documentación y de los productos) de un proyecto. 
    Conviene considerar configurable, los siguientes elementos:
     
    Documentación
    Código de Fuente
    Código objeto y ejecutables.
    Ficheros.
    Herramientas de desarrollo.
    Herramientas de validación y prueba.
    Conjunto de datos (de prueba, de configuración, etc.).
     
  • Cada vez que alguna de las partes (cliente, equipo de trabajo, usuarios) detecte algún fallo o disconformidad en el software o en la documentación generada en el proyecto, es conveniente generar, como parte de las actividades de control de configuración, una hoja de notificación de disconformidad, donde se refleje y describa la misma, la solución recomendada y la solución adoptada. La figura Muestra un posible formato para esta hoja de incidencia.
  • Tener una idea clara de los cambios realizados sobre los elementos configurables, los autores de los mismos, las razones de los cambios, etc.
     
    Plasmar documentalmente la evolución de las diferentes versiones y revisiones de cada elemento configurable.
     
    Dirimir a posteriori las responsabilidades derivadas de cambios (o no cambios) en los elementos de configuración del proyecto.
     
    Controlar todas las disconformidades y documentar el proceso y resolución de las mismas.
     
  • Muestra un posible formato para el informe de modificación del software, como respuesta a un cambio al mismo, en el que se documentan los cambios realizados, el responsable y la fecha, así como las razones de la modificación y el esfuerzo asociado a las mismas.
     
  • Muestra un posible formato para la hoja de control de configuración de cada documento. Por lo general, dicha hoja forma parte del propio documento (a continuación de la portada), y sirve para reflejar qué versión del documento se está manejando, y qué cambios y modificaciones incluye con respecto a ediciones anteriores del mismo.
  • RECOMENDACIONES FINALES
    En cuanto a la Planificación del trabajo, tener en cuenta que:
    -Los desarrollos de software son tareas de muy alto valor añadido, donde la transformación de bienes es prácticamente inexistente, y en las que el resultado (el software) es un producto intangible de mucha complejidad y difícil de analizar.
    -Conviene elegir y aplicar desde el principio un modelo de ciclo de vida y un conjunto de metodologías de desarrollo, que se mantendrán durante todo el proyecto.
    -No es conveniente solapar las fases del desarrollo. 
    -Definir desde el principio un plan de validación del software y un plan de aceptación del mismo que permita establecer un límite claro a las obligaciones y a la responsabilidad del equipo de trabajo, ante el cliente y / o los usuarios.
     
  • Con respecto a los requisitos:
     
    -La correcta especificación de los requisitos es clave para la culminación, con éxito del proyecto.
    -La especificación de los requisitos del usuario es responsabilidad única del usuario (aunque se le preste la ayuda necesaria para desenvolverse adecuadamente en dicha tarea).
    -Hay que definir requisitos completos, consistentes, verificables y que se propaguen a través de todo el ciclo de desarrollo del software. 
    La evaluación económica:
     
    -Hay que valorar proporcionalmente el esfuerzo necesario para la gestión, planificación, prueba y mantenimiento, y no sólo las actividades de desarrollo y codificación.
    -Hay que valorar adecuadamente el impacto de un control de configuración adecuado sobre el coste del proyecto.
  • GRACIAS ………