1. GESTION DE PROYECTO DE DESARROLLO DE SOFTWARE
Aydee Fonseca Medina
Decimo Semestre
Ingeniera de Sistemas
UAN NEIVA
2010

2. La ingeniera del Software es definida como la disciplina que se encarga de ofrecer mtodos y tcnicas para desarrollar y mantener software de calidad.
*Es el estudio de los principios y metodologas para el desarrollo y mantenimiento de sistemas software (Zelkovitz, 1978)
*Es la aplicacin prctica del conocimiento cientfico al diseo y construccin de programas de computadora y a la documentacin asociada requerida para desarrollar, operar y mantenerlos. Se conoce tambin como Desarrollo de Software o Produccin de Software (Bohem, 1976).
3. Trata del establecimiento de los principios y mtodos de la ingeniera a fin de obtener software de modo rentable, que sea fiable y trabaje en mquinas reales (Bauer, 1972).

Es la aplicacin de un enfoque sistemtico, disciplinado y cuantificable al desarrollo, operacin y mantenimiento del software; es decir, la aplicacin de la ingeniera al software (IEEE, 1993).

La ingeniera 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.
4. Interrelacin de los agentes que configuran el proceso de desarrollo de software
GESTOR
USUARIOS
EQUIPO SW
ANALISTA
PLANSOFTWARE
REQUISITOS SOFTWARE
5. Fases del ciclo de vida
Existen muchas metodologas de desarrollo de software, perotodas ellas comprenden los mismos pasos y las mismas tcnicas.
Fase de anlisis y planificacin del sistema. Comprende:
-Definicin de requisitos de usuarios (RU)
-Definicin de requisitos de software (RS)
Fase de Desarrollo. Incluye:
-Diseo de la arquitectura(DA)
-Diseo detallado y codificacin(DD)
-Transferencia (TR)
Fase de operacin y mantenimiento (OM)
6. Fase de anlisis y Planificacin
Objetivo: Definir exactamente qu es lo que se pretende que el software a desarrollar haga, y cmo 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?
Cmo se implantar?
Qu recursos materiales, temporales y humanos hacen falta para ello?
Cmo se verificar que el sistema funcione correctamente?
7. Fase de anlisis y planificacin
Esta fase comienza con la definicin del sistema global (hardware, software, etc.) y la caracterizacin del problema a resolver, de donde se extraen las pertinentes conclusiones acerca de las restricciones temporales, econmicas.
Fase (o sub-fase) de definicin de los requisitos de usuario(RU): Documentacin del sistema, entrevista con el Cliente o usuarios, construccin 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.
8. Fase: Definicin de requisitos del software (RS):
Objetivo: Construir un modelo conceptual de lo debe hacer el software, estimar el coste asociado al mismo (con una precisin aproximada del 30%), y definir las responsabilidades individuales dentro del equipo de trabajo.
Concluida esta fase se da por terminada la participacin directa del cliente o usuario, como parte interesada en el proceso de definicin 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.
9. Fase de anlisis y planificacin
DEFINICON DE REQUISITOOS
REVISION DEREQUISITOS
PLANIFICACIN
COSTE RECURSOS PLANIFICACION
DATOS DE USUARIO
DEFINICION DEL SISTEMA
FUNCIONES HARDWARE
REVISION REQUISITOS SOFTWARE
(RRS)
DEFINICION REQUISISTOS SOFTWARE (DRS)
NECESIDAD
DISEO, OPERACIN, MANTENIMIENTO
10. Fases de Desarrollo
Comienza con la aprobacin formal de los requisitos del software por parte del usuario o Cliente hasta la puesta en funcionamiento del sistema, incluyendo tres sub-fases, de diseo de alto nivel, diseo detallado y transferencia.
La fase (o sub-fase) de diseo de alto nivel o diseo arquitectnico(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.
11. Fase de Diseo detallado (DD).
Objetivo: Refina los detalles ms significativos el diseo de alto nivel de la fase anterior, se codifica, documento y prueba.
La verificacin y pruebas del software, debe realizarse a cuatro niveles diferentes:
A nivel de unidad de software.
A nivel de integracin de todas las unidades software.
A nivel de validacin del software con respecto a los requisitos de DRS.
A nivel del sistema completo, segn los requisitos de usuario (DRU)
12. Fase de transferencia (TR)
Objeto: Se instala el software sobre la plataforma (hardware) final, se lleva a cabo los test de aceptacin especificada, y se comprueba que el programa satisface los requisitos para los que fue concebido. En tales condiciones el software recibe la aceptacin provisional, y comienza su operacin y uso.
13. 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
14. Fase de Operacin y Mantenimiento (OM)
Fase de operacin, es la de supervisin (y correccin 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 rene 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).
15. Fase de Operacin y Mantenimiento
SISTEMA
DEFINITIVAMENTE
DTR
OPERACIN Y EVALUACIO
ACEPTACION DEFINITIVA
SW
Provisionalmente aceptado
DHP
ERRORES
REGISTRO DE MANTENIMIENTO
MMTO Y DEPURACION
REGISTRO DE FALLOS
MODELO DE FIABILIDAD
FIABILIDAD
16. 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 continuacin de la que le precede y con inmediata anterioridad a la que le sigue. Cuando en una fase se detectanerrores o cambios que deben incluirse, se debe hacer una iteracin en la fase inmediatamente anterior.
17. Modelo en Cascada o Waterfall
RU
RS
DA
DD
TR
OM
18. Modelo Incremental
Coincide con el modelo de cascada hasta el final de la fase de diseo de alto nivel (DA). A partir de ese momento, las fases DD, TR y OM se descomponen en un cierto nmero de unidades menores, ms simples y manejables, que se implantan por separado.
RU
RS
DA
DD1
TR1
OM1
DD2
TR2
OM2
19. Modelo Evolutivo
Se diferencia del incremental en que no se reaprovechan las fases de requisitos ni de diseo arquitectnico, 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 intencin 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 ms 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 frustracin en los usuarios, que perciben cada versin como una correccin de errores de la anterior y, en definitiva, como un software an no terminado por completo.

20. RU
RS
DA
DD
OM1
TR
RU
RS
DA
DD
OM2
TR
RU
RS
DA
DD
OM3
TR
21. EVALUACIN 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 gestin del mismo, como son:
-La descomposicin en actividades y tareas.
-La configuracin del equipo de trabajo
-La planificacin ms adecuada.
-El riesgo en el que se incurre.
-El control de configuracin de los elementos del proyecto.
22. EVALUACIN ECONOMICA
Volumen relativo de participacin segn categora y fase del proyecto
23. Participacin del equipo de trabajo en cada fase.
La experiencia demuestra que el nivel al que se involucran en el proyecto cada tipo de persona (segn la categora 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 anlisis y planificacin, el 20% a codificacin y transferencia, y el 40% restante a validacin y pruebas.
-Del 40% asociado a las tareas de anlisis y planificacin, a su vez, el 40% se destina a labores de planificacin, el 20% al anlisis de requisitos y el 40% restante a actividades de desarrollo.

24. Modelos de costes de desarrollo software.
Modelo 40-20-40
-El 40% del esfuerzo total se destina a tareas de anlisis y planificacin, el 20% a codificacin y transferencia, y el 40% restante a validacin y pruebas.
-Del 40% asociado a las tareas de anlisis y planificacin, a su vez, el 40% se destina a labores de planificacin, el 20% al anlisis de requisitos y el 40% restante a actividades de desarrollo.

25. Modelo 40-20-40
26. 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. Segn avanza el ciclo de vida del proyecto, el coste de un cambio individual se incrementa, segn muestra la grfica.
En la figura muestra cmo los cambios a los requisitos implican costes bajos en la etapa de anlisis y planificacin del sistema, costes que crecen de manera abultada al comenzar las fases de diseo, pruebas y transferencia, y que se estabilizan durante la fase de operacin y mantenimiento.
27. Coste de mantenimiento
Se deben considerar dos aspectos:
Todo contrato estipula una cobertura por garanta, y la responsabilidad del equipo de trabajo se limita a dicho perodo, exclusivamente. Incluso aunque se detecte un defecto en la realizacin del software, el equipo no tiene porque responsabilizarse del mismo si se ha agotado dicho perodo.
Tipo de mantenimiento Correctivo, es decir, aqul orientado a corregir los defectos de diseo e implantacin del software, siendo responsabilidad del contratista solo este mantenimiento.
28. CONTROL DE CONFIGURACION
El control de configuracin (gestin de la documentacin y de los productos) de un proyecto.
Conviene considerar configurable, los siguientes elementos:

Documentacin
Cdigo de Fuente
Cdigo objeto y ejecutables.
Ficheros.
Herramientas de desarrollo.
Herramientas de validacin y prueba.
Conjunto de datos (de prueba, de configuracin, etc.).

29. Cada vez que alguna de las partes (cliente, equipo de trabajo, usuarios) detecte algn fallo o disconformidad en el software o en la documentacin generada en el proyecto, es conveniente generar, como parte de las actividades de control de configuracin, una hoja de notificacin de disconformidad, donde se refleje y describa la misma, la solucin recomendada y la solucin adoptada. La figura Muestra un posible formato para esta hoja de incidencia.
30. 31. 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 evolucin 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 configuracin del proyecto.

Controlar todas las disconformidades y documentar el proceso y resolucin de las mismas.

32. Muestra un posible formato para el informe de modificacin 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 modificacin y el esfuerzo asociado a las mismas.

33. Muestra un posible formato para la hoja de control de configuracin de cada documento. Por lo general, dicha hoja forma parte del propio documento (a continuacin de la portada), y sirve para reflejar qu versin del documento se est manejando, y qu cambios y modificaciones incluye con respecto a ediciones anteriores del mismo.
34. 35. RECOMENDACIONES FINALES
En cuanto a la Planificacin del trabajo, tener en cuenta que:
-Los desarrollos de software son tareas de muy alto valor aadido, donde la transformacin de bienes es prcticamente inexistente, y en las que el resultado (el software) es un producto intangible de mucha complejidad y difcil de analizar.
-Conviene elegir y aplicar desde el principio un modelo de ciclo de vida y un conjunto de metodologas de desarrollo, que se mantendrn durante todo el proyecto.
-No es conveniente solapar las fases del desarrollo.
-Definir desde el principio un plan de validacin del software y un plan de aceptacin del mismo que permita establecer un lmite claro a las obligaciones y a la responsabilidad del equipo de trabajo, ante el cliente y / o los usuarios.

36. Con respecto a los requisitos:

-La correcta especificacin de los requisitos es clave para la culminacin, con xito del proyecto.
-La especificacin 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 atravs de todo el ciclo de desarrollo del software.
La evaluacin econmica:

-Hay que valorar proporcionalmente el esfuerzo necesario para la gestin, planificacin, prueba y mantenimiento, y no slo las actividades de desarrollo y codificacin.
-Hay que valorar adecuadamente el impacto de un control de configuracin adecuado sobre el coste del proyecto.
37. GRACIAS