caso práctico de desarrollo de proyectos por equipos

Convocatorias de Innovación Docente 2009-2010 de la Universidad de Zaragoza, para realizar un proyecto en la categoría

PIIDUZ 2009/2: Proyectos de implantación de actividades de aprendizaje innovadoras en el ámbito de la docencia de una materia o asignatura específica

Caso práctico de desarrollo de proyectos por equipos

Diseño de la Actividad y Memoria

Coordinadores

M.A. Latre y F.J. López Pellicer Participantes

J. Nogueras Iso, R. Béjar Hernández, F.J. Zarazaga Soria, A. J. Florczyk y P.R. Muro Medrano

Julio de 2010

Depto. de Informática e Ingeniería de Sistemas Universidad de Zaragoza María de Luna 1, 50018, Zaragoza, España.

Indice general

1. Presentacion 11.1. Sıntesis del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Organizacion del resto del documento . . . . . . . . . . . . . . . . . . . . . . . 2

2. La asignatura de Proyectos 32.1. Objetivos generales de la asignatura . . . . . . . . . . . . . . . . . . . . . . . . 32.2. Contenidos generales de la asignatura . . . . . . . . . . . . . . . . . . . . . . . 42.3. Descripcion detallada de contenidos y actividades asociadas . . . . . . . . . . . 6

2.3.1. Tema 1. Vision global del desarrollo de proyectos software . . . . . . . 62.3.2. Tema 2. Caso practico de desarrollo de proyectos por equipos . . . . . . 72.3.3. Tema 3. Gestion de proyectos software . . . . . . . . . . . . . . . . . . 82.3.4. Tema 4. Gestion de configuraciones . . . . . . . . . . . . . . . . . . . . 82.3.5. Tema 5. Aseguramiento de la calidad . . . . . . . . . . . . . . . . . . . 9

2.4. Planificacion temporal de la asignatura . . . . . . . . . . . . . . . . . . . . . . 102.5. Diseno de la evaluacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.5.1. Criterios de evaluacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.5.2. Instrumentos de evaluacion . . . . . . . . . . . . . . . . . . . . . . . . 11

3. Caso practico de desarrollo de proyectos por equipos 123.1. Organizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2. Actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2.1. Presentacion y desarrollo del caso practico . . . . . . . . . . . . . . . . 133.2.2. Ejercicio de dinamica de grupos: Necesidad de un proceso . . . . . . . . 143.2.3. Ejercicio de dinamica de grupos: Planificacion y desarrollo de reuniones 143.2.4. Ejercicio de dinamica de grupos: Ejercicio de lanzamiento de un proyecto 153.2.5. Ejercicio de dinamica de grupos: Gestion del tiempo . . . . . . . . . . . 163.2.6. Acuerdo del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2.7. Presentacion del producto . . . . . . . . . . . . . . . . . . . . . . . . . 183.2.8. Presentacion del proceso . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2.9. Demostracion del producto . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3. Bibliografıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.4. Criterios adicionales de evaluacion . . . . . . . . . . . . . . . . . . . . . . . . . 20

Bibliografıa 21

ii

Capıtulo 1

Presentacion

El presente trabajo se enmarca en las Convocatorias de Innovacion Docente 2009-2010 de laUniversidad de Zaragoza, para realizar un proyecto en la categora PIIDUZ 2009 / 2: Proyectosde implantacion de actividades de aprendizaje innovadoras en el ambito de la docencia de unamateria o asignatura especıfica, bajo el tıtulo: Caso practico de desarrollo de proyectospor equipos.

Esta actividad tiene por objeto aprovechar las posibilidades proporcionadas por Boloniapara replantear un caso practico de desarrollo de proyectos por equipos con un mayor enfoquede aprendizaje basado en proyectos. Esta actividad se situarıa actualmente en la asignaturade Proyectos de la titulacion de Ingenierıa Informatica. El planteamiento que aquı se pretendedesarrollar permitirıa ademas ser aprovechado para la nueva asignatura de Proyecto Softwareque ha sido planteada en la solicitud del nuevo Tıtulo Oficial de Graduado o Graduada enIngenierıa Informatica. Esta actividad constituye el esfuerzo fundamental por parte del alumnoen la mencionada asignatura y se pretende introducir una mayor guıa por parte del profesor,ası como cierto incremento de actividades complementarias como ejercicios de dinamica degrupos, reuniones de seguimiento, auditorıas, presentaciones o seminarios.

1.1. Sıntesis del proyecto

La asignatura de Proyectos cierra la materia troncal de Ingenierıa del Software presentan-do las tareas vinculadas a la gestion del proceso de construccion de un producto software.En las anteriores asignaturas del bloque tematico el alumno ha recibido formacion sobre unapanoramica de las distintas fases del ciclo de vida de desarrollo del software y acerca de losproblemas, metodos y herramientas que pueden ser utilizadas en cada fase (como analisis derequisitos, diseno, produccion, tests y mantenimiento). El planteamiento de esta asignatu-ra es completar la formacion del alumno en los aspectos tecnicos y profesionales y adquirirexperiencia practica en el desarrollo en equipo de proyectos de software. El caso practico in-volucra tambien la utilizacion de conocimientos y competencias aprendidas en otras materiasque deben saber poner en practica.

Hasta ahora, la asignatura se organizaba en una serie de clases de teorıa, problemas ypracticas, con un proyecto que desarrollaban en equipo sin especial tutela y que exige unesfuerzo muy significativo por parte del alumno. Se quiere ahora racionalizar y mejorar desdeel punto de vista docente este caso practico de desarrollo de proyectos por equipos. Paraello se pretende aprovechar las posibilidades que da un planteamiento como creditos ECTS,aplicar tecnicas de aprendizaje basado en proyectos, reorganizar el desarrollo de esta actividaddando un mayor protagonismo a aspectos como ejercicios de grupo, presentaciones, reunionesde seguimiento, seminarios especializados, etc., todo ello con una mayor asistencia por parte

1

2 Latre/Lopez/Nogueras/Bejar/Zarazaga/Florczyk/Muro

del profesorado y disponer de mayor informacion de seguimiento del alumno de forma que sepueda realizar una evaluacion mas racional de su esfuerzo y conocimiento adquirido.

1.2. Organizacion del resto del documento

El resto del documento se ha organizado con un capıtulo 2 donde se da una panoramicade la asignatura donde se encuadarıa la actividad para dar paso al capıtulo 3 donde se explicaen detalle la actividad prevista.

Capıtulo 2

La asignatura de Proyectos

En esta seccion se presenta la asignatura Proyectos Software establecida en la solicituddel Tıtulo Oficial de Graduado o Graduada en Ingenierıa Informatica de la Universidad deZaragoza que se presenta con una carga de 6 creditos ECTS.

2.1. Objetivos generales de la asignatura

Como se ha indicado con anterioridad, la asignatura de “Proyecto Software” cierra lamateria troncal de Ingenierıa del Software presentando las tareas vinculadas a la gestion delproceso de construccion de un producto software.

En las anteriores asignaturas del bloque tematico de Ingenierıa del Software el alumno harecibido formacion sobre una panoramica de las distintas fases del ciclo de vida de desarrollo delsoftware y acerca de los problemas, metodos y herramientas que pueden ser utilizadas en cadafase (como analisis de requisitos, diseno, produccion, tests y mantenimiento). El planteamientode esta asignatura es completar la formacion del alumno en los aspectos tecnicos y profesionalesde la Ingenierıa del Software y adquirir experiencia practica en el desarrollo en equipo deproyectos de software. Dentro de este contexto general se plantea de forma mas particular eltrabajo en los siguientes aspectos:

Resultados de aprendizaje

• Conocer como disenar, desarrollar, seleccionar y evaluar aplicaciones y sistemasinformaticos, asegurando su fiabilidad, seguridad y calidad, conforme a principioseticos y a la legislacion y normativa vigente.

• Ser capaz de planificar, concebir, desplegar y dirigir proyectos, servicios y sistemasinformaticos en todos los ambitos, liderando su puesta en marcha y su mejoracontinua y valorando su impacto economico y social.

• Comprender la importancia de la negociacion, los habitos de trabajo efectivos, elliderazgo y las habilidades de comunicacion en todos los entornos de desarrollo desoftware.

• Conocer como elaborar el pliego de condiciones tecnicas de una instalacion in-formatica que cumpla los estandares y normativas vigentes.

• Conocer como llevar a cabo el mantenimiento de sistemas, servicios y aplicacionesinformaticas.

• Conocer los fundamentos basicos de la normativa y la regulacion de la informaticaen los ambitos nacional, europeo e internacional.

3


• Apreciar la necesidad del dialogo permanente y colaborativo.

Relacion con competencias a adquirir

• CT1. Capacidad para concebir, disenar y desarrollar proyectos de Ingenierıa.

• CT2. Capacidad para planificar, presupuestar, organizar, dirigir y controlar tareas,personas y recursos.

• CT3. Capacidad para combinar los conocimientos generalistas y los especializadosde Ingenierıa para generar propuestas innovadoras y competitivas en la actividadprofesional.

• CT4. Capacidad para resolver problemas y tomar decisiones con iniciativa, creativi-dad y razonamiento crıtico.

• CT5. Capacidad para comunicar y transmitir conocimientos, habilidades y destrezasen castellano y en ingles.

• CT8. Capacidad para trabajar en un grupo multidisciplinar y en un entorno mul-tilingue.

• CT10. Capacidad para aprender de forma continuada y desarrollar estrategias deaprendizaje autonomo.

• CT11. Capacidad para aplicar las tecnologıas de la informacion y las comunicacionesen la Ingenierıa

• CGC18. Conocimiento de la normativa y la regulacion de la informatica en losambitos nacional, europeo e internacional.

2.2. Contenidos generales de la asignatura

La asignatura de “Proyecto Software” se ha planificado con una carga de 6 creditos ECTS.Contando con una equivalencia de 25-30 horas de dedicacion del alumno por credito ECTS,se ha estimado un esfuerzo total de 174 horas por parte del alumno.

Los contenidos de la asignatura se han estructurado de forma similar a la asignatura deProyectos del plan en vigor con cinco temas principales:

Tema 1. Vision global del desarrollo de proyectos

Tema 2. Caso practico de desarrollo de proyectos por equipos

Tema 3. Gestion de proyectos Software

Tema 4. Gestion de Configuraciones

Tema 5. Aseguramiento de la Calidad

Cabe destacar ademas la importancia que tiene la realizacion de un trabajo en equipoa lo largo del desarrollo de la asignatura. Dada su relevancia, este trabajo se trata comoun tema separado (“Tema 2. Caso practico de desarrollo de proyectos por equipos”) que sedesarrolla en paralelo con el resto de temas de la asignatura. Uno de los aspectos en losque se hace especial hincapie en el curriculum del ACM [ACM/IEEE, 2001], y en generalen todas las propuestas curriculares, es la necesidad de dotar a los titulados en informaticade las capacidades y habilidades necesarias para el trabajo en equipo (punto 9.1.5). El ACMpropone la realizacion de uno o mas trabajos en equipo (punto 9.3) durante el desarrollo

Caso practico de desarrollo de proyectos por equipos 5

del currıculo, bien como parte de un curso en el que se incorporan otra gran cantidad dematerias adicionales, o como elemento principal de un curso donde las materias adicionales noson muchas. Segun el ACM las tematicas que deberıa integrar dicho trabajo en equipo son:“Fundamentos de la interaccion hombre-maquina”, “Diseno de interfaz grafica de usuario”,“Programacion de interfaz grafica de usuario”, “Diseno del software”, “Utilizacion de APIs”,“Herramientas y entornos de desarrollo”, “Proceso de desarrollo de software”, “Requerimientosy especificaciones del software”, “Validacion del software”, “Evolucion del software”, “Gestionde proyectos software”, “Gestion de equipos” y “Destrezas en la comunicacion”. Ası pues, seha considerado especialmente interesante el dar cabida a la realizacion de un proyecto softwareen equipo dentro del marco de la asignatura de “Proyectos”.

Figura 2.1: Numero de horas planificadas para cada tema

La figura 2.1 muestra un resumen de la carga en horas correspondiente a cada tema y eltipo de actividades asociadas. Las actividades que se pueden asignar a cada tema se puedencategorizar de la siguiente forma:

Presentacion de contenidos:

• Subactividad de caracter presencial: Al igual que en otras asignaturas de la materiatroncal, para la presentacion de los contenidos teoricos se ha optado por impartirlecciones magistrales participativas apoyadas en transparencias. Se parte de la basede que estas clases magistrales se imparten en aulas provistas de pizarra, canonpara ordenador portatil y proyector de transparencias.

• Subactividad de caracter no presencial: Estudio individual de los alumnos dondepreparan antes, completan e interiorizan despues el contenido.

Ejercicios de dinamica de grupos: Actividad de caracter presencial donde se trabaja engrupos sobre una serie de ejercicios practicos que tratan de servir como base para lasensibilizacion y entrenamiento de los alumnos ante problemas vinculados a la gestiondel proceso de desarrollo del software.


Seminarios: Actividad docente de caracter presencial centrada en temas muy especıficos,considerados de especial relevancia. Por ello se plantea la necesidad de abordarlos comocomplemento a las explicaciones presentadas en el normal desarrollo de las clases. Losseminarios se desarrollan en sesiones de no mas de dos horas.

Practicas de laboratorio:

• Subactividad de caracter presencial: Las practicas se desarrollan en un aula in-formatica y se resuelven de forma individual. En las sesiones del laboratorio, losalumnos tienen el apoyo del profesor que les ayuda a solventar los problemas tecni-cos o conceptuales que puedan tener.

• Subactividad de caracter no presencial: Trabajo individual de cada alumno parapreparar cada practica.

Clases de debate: Actividad de caracter presencial utilizada para que los alumnos puedanponer en comun y debatir sobre un trabajo previo que les ha sido asignado. Se utilizaprincipalmente en el Tema 2 para que cada grupo presente al resto de grupos el productoque han desarrollado y la gestion de procesos que han realizado.

Tutorıa en grupo: Actividad de caracter presencial donde el profesor realiza un seguimien-to del desarrollo del proyecto informatico que cada grupo esta realizado. El profesorresuelve dudas y problemas sobre las actividades de dicho proyecto. Estas tutorıas degrupo tienen lugar habitualmente en el mismo laboratorio donde los alumnos realizanlas practicas y desarrollan el proyecto informatico descrito en el tema 2.

En la seccion 2.3 se describe de forma pormenorizada los contenidos de cada tema y lasactividades (presenciales y no presenciales) asignadas a cada tema.

2.3. Descripcion detallada de contenidos y actividades

asociadas

2.3.1. Tema 1. Vision global del desarrollo de proyectos software

Duracion 15 horas

Objetivos El alumno debera:

1. Conocer los objetivos generales de la asignatura, y encuadrar esta asignatura dentrode la materia troncal y otras asignaturas relacionadas.

2. Tener una idea general de todos los elementos integrantes de la gestion de unproyecto software, prerrequisito para poder empezar a desarrollar el trabajo de laasignatura.

Contenidos :

1. Presentacion de la asignatura

2. Introduccion a los problemas derivados de la mala gestion de proyectos

3. La gestion del proyecto

4. La gestion de configuraciones


5. El aseguramiento de la calidad

6. Otras funciones del proyecto

Bibliografıa [Pressman, 2006], [Humphrey, 1990] y [Bruegge y Dutoit, 2002] ofrecen unavision general de las distintas actividades involucradas en la gestion del proceso de de-sarrollo de aplicaciones software. [Brooks, 1995] ofrece una reflexion historica de la evolu-cion de la ingenierıa del software. [Mazza et al., 1996] y [Mazza et al., 1994] describenlos estandares y guıas para desarrollo de proyectos propuestos por la Agencia EspacialEuropea. [Humphrey, 1997], [Humphrey, 2000] describen los modelos del PSP y el TSP.[CMU-SEI, 1995] describe los cinco niveles que miden la implantacion de de medidasde proceso en una organizacion que propone el Carnegie Mellon Institute. [Ince, 1994],[Kehoe y Jarvis, 1996] y [Schmauch, 1995] introducen a las normas ISO relacionadascon las actividades de producto y actividades de proceso involucradas en el desarrollode sistemas.

2.3.2. Tema 2. Caso practico de desarrollo de proyectos por equipos

Duracion 75 horas


1. Ser capaz de trabajar en un equipo de desarrollo de un producto. La unica formade comprender la problematica de la gestion de proyectos es experimentando unomismo mediante casos practicos de desarrollo de proyectos. En este bloque tematicose propone la realizacion de un producto en grupos de 5 alumnos.

2. Comprender que las actividades relacionadas con la gestion de proyectos implicanuna mejora en la calidad del producto desarrollado y ayudan a cumplir los compro-misos acordados con el cliente.

3. Ser capaz de aplicar los metodos y herramientas de la gestion de proyectos, lagestion de configuraciones y el aseguramiento de la calidad sobre un caso real.

4. Saber vender un producto y convencer a los clientes sobre sus beneficios y posibili-dades.

Contenidos :

1. Presentacion del proyecto informatico a realizar

2. Elaboracion del acuerdo del proyecto

3. Presentacion del producto

4. Elaboracion de un Plan de Gestion del Proyecto Software

5. Elaboracion de un Plan de Gestion de Configuraciones

6. Elaboracion de un Plan de Aseguramiento de la Calidad

7. Presentacion del proceso

Bibliografıa Los ejercicios de dinamica de grupos se basan en las propuestas de trabajo pre-sentadas por Watt S. Humphrey en sus libros “Introduction to the Team Software Pro-cess” [Humphrey, 2000] y “Introduction to the Personal Software Process” [Humphrey,1997].


2.3.3. Tema 3. Gestion de proyectos software

Duracion 26 horas


1. Conocer las labores implicadas en la gestion del desarrollo de los proyectos software.

2. Ser capaz de elaborar un Plan de Gestion del Proyecto Software.

Contenidos :

1. Introduccion

2. Gestion del proceso de desarrollo

3. Gestion de los recursos

4. Gestion de los recursos, tecnicas de estimacion de tamano

5. Gestion de los recursos, tecnicas de estimacion de esfuerzo

6. Gestion del equipo humano

7. Gestion de Riesgos

8. El Plan de Gestion del Proyecto Software

9. La gestion de proyectos y el software libre

Bibliografıa [Pressman, 2006] y [Bruegge y Dutoit, 2002] ofrecen una vision general de lagestion de proyectos. [Mazza et al., 1996], [Mazza et al., 1994] describen los estandaresy guıas propuestos por la Agencia Espacial Europea para la gestion de proyectos.

Para la preparacion del seminario sobre “PSP & TSP” se han utilizado principalmente:los libros de W.S. Humphrey sobre proceso personal de desarrollo de software [Humphrey,1995] y [Humphrey, 1997]; y su libro sobre proceso en equipo para el desarrollo desoftware [Humphrey, 2000].

Para la preparacion del seminario sobre Metrica 2 y Metrica 3 se han utilizado losmanuales de Metrica version 2.1 [MAP, 1995], y los de Metrica version 3 [MAP, 2001].

2.3.4. Tema 4. Gestion de configuraciones

Duracion 14 horas


1. Comprender que la gestion de configuraciones del software es una actividad “pro-tectiva”que se aplica a lo largo del proceso de desarrollo de un sistema software.

2. Conocer y diferenciar las principales tareas involucradas en la gestion de configu-raciones: la creacion del Plan de Gestion de Configuraciones de Software, la identi-ficacion de configuraciones, el control de configuraciones y el control de cambios.

3. Ser capaz de implantar la gestion de configuraciones en el desarrollo de un productosoftware.

Contenidos :

1. Introduccion


2. Plan de Gestion de Configuraciones de Software

3. Identificacion de configuraciones

4. Control de configuraciones

5. Control de medios

6. Gestion de cambios

7. Contabilidad de estado de las configuraciones

8. Control de suministradores

9. Herramientas, tecnicas y metodos

Bibliografıa [Pressman, 2006] y [Bruegge y Dutoit, 2002] ofrecen una vision general de las ac-tividades relacionadas con la gestion de configuraciones. [Mazza et al., 1996] y [Mazza et al.,1994] describen los estandares y guıas propuestos por la Agencia Espacial Europea (ESA)para la gestion de configuraciones.

2.3.5. Tema 5. Aseguramiento de la calidad

Duracion 15 horas


1. Comprender que todos los metodos, herramientas y procedimientos de Ingenierıadel Software van orientados a un unico fin: producir software de gran calidad.

2. Conocer y diferenciar los distintos procedimientos y mecanismos que aseguran laconstruccion de un software de calidad.

3. Ser capaz de elaborar un plan de aseguramiento de la calidad.

Contenidos :

1. Introduccion

2. Plan de aseguramiento de la calidad del software

3. Estandares

4. Revisiones y auditorıas

5. Medidas de calidad del software

6. Normas de calidad ISO 9000

7. El modelo de madurez del CMM

Bibliografıa [Pressman, 2006] contextualiza el aseguramiento de la calidad en el marco gener-al de desarrollo de sistemas software. [Mazza et al., 1996], [Mazza et al., 1994] describenlos aspectos relacionados con el aseguramiento de la calidad propuestos por la AgenciaEspacial Europea (ESA).

Para la preparacion del seminario sobre CMM se ha utilizado principalmente el librosobre el tema publicado por el Instituto de Ingenierıa del Software de la UniversidadCarnegie Mellon [CMU-SEI, 1995]. Tambien se ha utilizado el libro sobre gestion deprocesos de desarrollo de software de W.S. Humphrey [Humphrey, 1990]

Para la preparacion del seminario sobre ISO 9000 este seminario se ha utilizado el librode D.Ince sobre ISO 9001 [Ince, 1994], el de R.Kehoe y A.Jarvis sobre ISO 9000-3[Kehoe y Jarvis, 1996], y el de C.H.Schmauch sobre ISO 9000 [Schmauch, 1995].


2.4. Planificacion temporal de la asignatura

La planificacion temporal de las actividades de caracter presencial se ha llevado a cabopresuponiendo su despliegue a lo largo de un cuatrimestre integrado por 15 semanas lecti-vas. Sobre estas 15 semanas, en todas ellas se dispone de dos sesiones de aula de dos horas.Adicionalmente, las actividades a desarrollar en el laboratorio se han programado a lo largode todo el cuatrimestre tratando de conseguir una apropiada coordinacion con los contenidospresentados en las sesiones de aula.

Figura 2.2: Planificacion temporal de la asignatura

La figura 2.2 muestra la planificacion temporal establecida por semanas para las sesionesrealizadas en el aula y la sesiones realizadas en el laboratorio. Tambien se muestran los prin-cipales hitos del proyecto informatico que los alumnos deben desarrollar en grupos de cinco.


2.5. Diseno de la evaluacion

2.5.1. Criterios de evaluacion

Con la evaluacion de la asignatura se pretende valorar si el alumno domina los siguientesaspectos:

Conoce, comprende y es capaz de utilizar metodos y herramientas relacionados conlas actividades de gestion de proyectos, gestion de configuraciones y aseguramiento decalidad.

Comprende el papel de los estandares de software para la realizacion de las laboresde gestion. Ademas, sabe seleccionar el estandar adecuado para una labor de gestionconcreta dependiendo del contexto.

Es capaz de abordar el desarrollo completo de proyectos de software donde se cubrantodas las actividades de desarrollo y gestion.

Es capaz de cooperar dentro un equipo de trabajo para el desarrollo de un proyecto: dis-tingue los distintos papeles que pueden adoptar los miembros de un equipo; comprende yasume la responsabilidad en la realizacion de sus tareas; y sabe como establecer mecan-ismos de organizacion y comunicacion en el equipo.

Selecciona adecuadamente y pone en practica tecnicas aprendidas en asignaturas anteri-ores (y no solo de Ingenierıa del Software) para resolver o documentar distintos aspectosde un proyecto de software.

2.5.2. Instrumentos de evaluacion

Como instrumentos para la evaluacion de los alumnos se van a utilizar los siguientes meto-dos:

Controlar la asistencia a las sesiones de practicas en laboratorio. La asistencia a lasdos sesiones de practicas de laboratorio programadas no se valora en la nota final de laasignatura pero si que es un requisito imprescindible para superar esta asignatura. Elobjetivo de estas practicas es que algunos de los elementos que se trabajan se puedanincorporar directamente al proyecto informatico desarrollado en grupos de cinco alumnos.

Realizar un examen de conceptos basicos que permita comprobar la adquisicion de losfundamentos basicos. Se trata de un examen de conceptos basicos que recogera unaserie de preguntas cortas y/o preguntas de tipo test. Este examen tendra una duracionestimada de 1 hora. El objetivo es determinar el grado de entendimiento del alumnofrente a aspectos concretos de la asignatura. La realizacion del examen se valora con un20% de la nota final de la asignatura. Para aprobar la asignatura sera un prerrequisitoel conseguir un mınimo de un 50% de la puntuacion maxima de este examen.

Y la evaluacion del cso practico de proyecto informatico que se desarrolla mediante gru-pos de cinco alumnos siguiendo las actividades propuestas en el tema 2 de los contenidosde la asignatura. Este proyecto se valorara en un 80% de la nota final de la asignatura.Ademas, para aprobar la asignatura sera un prerrequisito el conseguir un mınimo de un50% de la puntuacion maxima de este trabajo.

Capıtulo 3

Caso practico de desarrollo deproyectos por equipos

3.1. Organizacion

Duracion 75 horas


1. Ser capaz de trabajar en un equipo de desarrollo de un producto. La unica formade comprender la problematica de la gestion de proyectos es experimentando unomismo mediante casos practicos de desarrollo de proyectos. En este bloque tematicose propone la realizacion de un producto en grupos de 5 alumnos.

2. Comprender que las actividades relacionadas con la gestion de proyectos implicanuna mejora en la calidad del producto desarrollado y ayudan a cumplir los compro-misos acordados con el cliente.

3. Ser capaz de aplicar los metodos y herramientas de la gestion de proyectos, lagestion de configuraciones y el aseguramiento de la calidad sobre un caso real.

4. Saber vender un producto y convencer a los clientes sobre sus beneficios y posibili-dades.

Contenidos :

1. Presentacion del proyecto informatico a realizar

2. Elaboracion del acuerdo del proyecto

3. Presentacion del producto

4. Elaboracion de un Plan de Gestion del Proyecto Software

5. Elaboracion de un Plan de Gestion de Configuraciones

6. Elaboracion de un Plan de Aseguramiento de la Calidad

7. Presentacion del proceso

3.2. Actividades

Nota: las actividades de este bloque tematico se desarrollan en paralelo con las actividadesde los temas 3, 4 y 5.

12


3.2.1. Presentacion y desarrollo del caso practico

Duracion: 1 hora de clase de debate/dudas PRESENCIAL + 60 horas de trabajo engrupo NO PRESENCIALES (formacion de grupos y breve descripcion del proyecto arealizar)

Descripcion: La mejor forma de aprender los conocimientos relacionados con la gestionde proyectos y saber aplicarlos es mediante la experiencia que aporta la realizacion deproyectos informaticos.

La distribucion concreta de cargas de trabajo para las actividades de desarrollo delproducto (analisis, diseno, codificacion, ...) o las actividades de proceso dependeran ex-clusivamente de las decisiones tomadas por el grupo en la elaboracion de la planificacion.

Durante la presentacion se plantea a los alumnos la realizacion de un proyecto in-formatico. Los alumnos se organizaran en grupos de cinco para desarrollar de una apli-cacion con plena libertad en la eleccion de las herramientas a utilizar (metodologıa,lenguaje de programacion etc.). Dicha aplicacion debera ir acompanada de la docu-mentacion correspondiente a toda la labor de gestion del desarrollo que es necesariorealizar.

El unico requisito del sistema a construir es que debe ser una aplicacion con limitadafuncionalidad que incluya al menos dos de estas tres caracterısticas: Interfaz Graficade Usuario, Acceso a Base de Datos, Comunicaciones. En el momento de constituir losequipos, es necesario dar una breve descripcion del sistema al profesor (cuatro o cincolıneas) al objeto de que este verifique que cumple las restricciones establecidas y que noexcede el volumen de trabajo que se considera que debe corresponder a este trabajo deasignatura.

Se explica a los alumnos que existen una serie de hitos que deben ser cubiertos por losproyectos:

• Una vez que se constituyen los grupos y se especifica brevemente como es la apli-cacion a construir, los alumnos disponen de una semana para entregar el acuerdodel proyecto en el que se recoja la planificacion, presupuesto y descripcion del sis-tema a desarrollar. En este acuerdo del proyecto sera donde los grupos especifiquenla fecha de entrega del sistema (convocatoria a la que desean concurrir). Los grupospueden planificar la entrega de su sistema en cualquiera de las dos convocatoriasde la asignatura.

• Inmediatamente despues de la entrega del acuerdo del proyecto, los alumnos debenelaborar y mantener actualizado el plan de gestion del proyecto de software (PGPS)y sus revisiones, ası como la documentacion de reuniones y comunicaciones. Estasdocumentaciones se podran solicitar a los grupos en cualquier momento del cursoy de un dıa para otro (ver tema 3).

• Se establece un hito intermedio en el que deben presentar una version revisada de losdocumentos de analisis y diseno del sistema. El objetivo de esta entrega es forzarlesa marcarse un calendario de trabajo que incluya unos compromisos en periodosiniciales del cuatrimestre que de alguna manera asegure una mayor probabilidad deentrega del sistema en fecha.

• A mitad de curso, cada grupo presentara ante el resto de los grupos el productoque esta desarrollando. El objetivo de esta primera presentacion es que los alum-nos muestren su capacidad e ingenio para proceder a la venta del producto que


estan desarrollando. Para ello se les induce a plantear la presentacion pensandoque el publico que tienen presente esta integrado por posibles compradores de suproducto que pretenden ver las diferencias existentes en el mismo con respecto a lacompetencia.

• El profesor realizara una auditorıa de calidad, revisando el Plan de Aseguramientode Calidad que hayan elaborado los alumnos (ver tema 5).

• Al final del curso, cada grupo presentara ante el resto de los grupos las actividadesde proceso que han llevado a cabo. El objetivo sera que los alumnos muestrensu capacidad e ingenio para proceder a la venta de su equipo de desarrollo. Paraello se les induce a plantear la presentacion pensando que el publico que tienendelante esta integrado por empresarios que buscan a un equipo de desarrollo que lesconstruya un software a medida y, por tanto, estan interesados en conocer la formaen que el equipo aborda la realizacion de sus desarrollos (organizacion, estandares,metodos, etc.).

• Por ultimo cada grupo debera proceder a la entrega de la documentacion del proyec-to y a la demostracion del sistema.

En las siguientes actividades se describe con mas detalle cada uno de estos hitos que losalumnos deben ir completando a lo largo del desarrollo del proyecto.

Tambien se incluyen en las actividades siguientes ejercicios de dinamica de grupos queayudan a los alumnos a comprender las dificultades del trabajo en equipo y a aplicaralgunas soluciones.

3.2.2. Ejercicio de dinamica de grupos: Necesidad de un proceso

Duracion: 2 horas de dinamica de grupos PRESENCIAL

Descripcion: Uno de los mayores problemas con los que se cuenta a la hora de explicara los alumnos la necesidad de establecer un proceso de desarrollo de software es laidentificacion de los mismos con la existencia de un problema que es necesario resolver.Con este ejercicio se intenta que el alumno vea que cualquier tarea colectiva es susceptiblede tener problemas ligados a su organizacion (y el trabajo en equipo, independientementedel contexto en el que se lleve a cabo, es una tarea colectiva), y que cobre concienciade la necesidad de establecer un proceso como la mejor de las soluciones para poderatajar dicho problema. Para ello se le plantea la realizacion de un trabajo tecnicamentesencillo, pero que requiere una buena organizacion para poder ejecutarlo con exito.

3.2.3. Ejercicio de dinamica de grupos: Planificacion y desarrollode reuniones


Objetivos: Las reuniones son uno de los recursos que mas prolıficamente se usan en eltrabajo en grupo en general, y en el desarrollo de proyectos en particular. Sin embargo,se trata de uno de los recursos mas caros: si en una reunion de una hora intervienen10 personas, el coste de esta tarea es de 10 horas. Es por ello que resulta necesaria suoptimizacion.

El objetivo de este ejercicio es que el alumno sea consciente del coste que supone la cele-bracion de una reunion y de la necesidad de poder contar con una sistematica apropiadapara las mismas.


Actividades: En una primera parte (45 minutos) se procedera a la presentacion de lasreuniones y su problematica. Se abordaran diversos aspectos de las mismas: para que sir-ven, tipos de reunion, claves del exito de una reunion, roles a desempenar dentro de unareunion, y la organizacion de una reunion (su comienzo, su desarrollo, su finalizacion).

Una segunda parte (45 minutos) consistente en un ejercicio en el que los alumnos, segunla disposicion en grupos establecida para el trabajo de evaluacion de la asignatura,desarrollen una reunion en la que organicen como llevaran a cabo sus futuras reunionesde equipo. Para ello se les proporciona una propuesta de agenda a seguir en esta primerareunion con los siguientes contenidos:

• Revisar la agenda de la reunion. Consensuar las funciones de los roles para todaslas reuniones. Asignar los roles de esta reunion y la estrategia a seguir para asignarroles en las siguientes.

• Establecer las reglas de las reuniones del equipo

• Establecer una hora y lugar estandar para la reunion semanal del equipo

• Establecer un estandar para las agendas de las reuniones y para las actas de lasmismas.

• Discutir y asignar los roles del equipo para el proyecto. Establecer polıtica derotacion de roles a lo largo del proyecto.

• Realizar una discusion de la reunion del ejercicio

• Ruegos y preguntas

• Resumen de la reunion o debriefing

El ejercicio terminara con una reflexion sobre el mismo y una discusion sobre el temavalorando la problematica expuesta y el interes del ejercicio en sı (15 minutos).

3.2.4. Ejercicio de dinamica de grupos: Ejercicio de lanzamiento deun proyecto


Objetivos: El proceso de formar un equipo no ocurre por accidente, necesita algo detiempo. Hay que establecer relaciones de trabajo, determinar roles y ponerse de acuerdoen las metas. Una hora invertida en un correcto lanzamiento del equipo permite uncuantioso ahorro de tiempo en la realizacion del proyecto.

El objetivo de este ejercicio es que el alumno sea consciente de que la realizacion deuna serie de actividades previas al inicio de trabajo en equipo va a permitir aclarar ungran numero de aspectos organizativos del equipo con el consecuente ahorro de tiempoy malos entendidos.

Actividades: En una primera parte (45 minutos) se procedera a la presentacion del lan-zamiento de un proyecto en equipo y las tareas a llevar a cabo durante el mismo. Losaspectos que se abordaran son: la necesidad de establecer un proceso de lanzamientode un proyecto, establecimiento de las metas de un equipo en un proyecto, establec-imiento de las metas de cada uno de los miembros del equipo de manera individual, y elestablecimiento de las metas para cada uno de los roles.


Una segunda parte (45 minutos) consistente en un ejercicio en el que los alumnos, segun ladisposicion en grupos establecida para el trabajo de evaluacion de la asignatura, realicenlas tareas presentadas en el apartado anterior con el objetivo de proceder a lanzar suequipo de trabajo. Para ello se les proporciona una propuesta de agenda a seguir en estareunion con los siguientes contenidos:

• Revisar la agenda de la reunion. Asignar los roles de esta reunion.

• Establecer las metas del equipo y la forma en que se medira su cumplimiento.

• Cada miembro del equipo establecera cuales van a ser sus metas individuales ycomo las va a medir.

• Presentacion de las metas individuales de cada componente del equipo y discusionsobre el grado de exigencia de cada uno.

• Establecer las metas de cada uno de los roles principales del equipo.

• Fijar fecha para la reunion en la que se comprobara el grado de cumplimiento delas metas.

• Ruegos y preguntas.

• Resumen de la reunion o debriefing. El ejercicio terminara con una reflexion sobreel mismo y una discusion sobre el tema valorando la problematica expuesta y elinteres del ejercicio en sı (15 minutos).

3.2.5. Ejercicio de dinamica de grupos: Gestion del tiempo


Objetivos: La organizacion y control del tiempo es clave para poder llevar a cabo laplanificacion y seguimiento de un trabajo. El objetivo de este ejercicio es que el alum-no sea consciente de la necesidad de organizar y controlar su tiempo, y de como estaorganizacion y control le permitiran realizar una mejor planificacion y seguimiento deactividades.

Actividades: En una primera parte (45 minutos) se procedera a la presentacion delproblema de la gestion y control del tiempo, y su utilidad a la hora de planificar y seguiractividades. Los aspectos que se abordaran son: la logica de la gestion del tiempo, lacomprension del uso que hacemos cada uno de nuestro tiempo, el control y registro deltiempo, la gestion del tiempo, la estimacion del tiempo, planificacion, uso y gestion deltiempo estimado.

Una segunda parte (45 minutos) consistente en un ejercicio en el que los alumnos, segun ladisposicion en grupos establecida para el trabajo de evaluacion de la asignatura, realicenlas tareas presentadas en el apartado anterior con el objetivo de que lleven a cabo unaprimera organizacion de su tiempo para poder luego gestionarlo y controlarlo. Para ellose les proporciona una propuesta de agenda a seguir en esta reunion con los siguientescontenidos:

• Revisar la agenda de la reunion. Asignar los roles de esta reunion.

• Disenar las hojas de control de tiempos y de resumenes que se utilizaran por todoslos componentes del equipo.

• Definir y documentar el proceso que se seguira por todos los componentes del equipopara completar las hojas de control de tiempos y de resumenes.


• Establecer los tiempos fijos que va a tener cada componente del equipo en las dosproximas semanas.

• Establecer y planificar las actividades variables para las dos proximas semanas.

• Ruegos y preguntas.

• Resumen de la reunion o debriefing.

El ejercicio terminara con una reflexion sobre el mismo y una discusion sobre el temavalorando la problematica expuesta y el interes del ejercicio en sı (15 minutos).

3.2.6. Acuerdo del proyecto

Duracion: 1 hora de tutorıa en grupo PRESENCIAL + las horas de trabajo en grupoNO PRESENCIALES que se planifiquen en cada grupo

Descripcion: El primer problema con el que se topa el alumno a la hora de dar comienzoa un proyecto informatico de corte profesional consiste en elaborar el documento que vaa servir para establecer el acuerdo con el cliente. En el mismo, que debe ser ratificadopor ambas parte, se define:

• Alcance. En el alcance se identifican los objetivos del proyecto, y se fijan los req-uisitos de usuario. Habra que destacar la necesidad de que los objetivos se fijenclaramente y que los requisitos puedan medirse al objeto de poder definir clara-mente la finalizacion o no del proyecto.

• Restricciones del sistema, tanto hardware como software: plataforma/s de desarrolloy operativas, lenguaje/s de programacion, base/s de datos,

• Calendario del proyecto que incluye la duracion y los hitos, tanto finales comointermedios.

• Presupuesto lo mas detallado posible (opcionalmente se podrıa incluir el calendariode gastos). Sera necesario mostrar detalles sobre la elaboracion del presupuestoque hagan relacion con su coherencia y ajuste a la realidad. Ası, por ejemplo, esnecesario que alumno no confunda el hecho de que haya 5 personas desarrollando conla necesidad de 5 ordenadores, o que asuma con cargo al proyecto costes completosde adquisicion de equipos, alquiler de instalaciones y mantenimientos (hay quehacer hincapie en compartir gastos y amortizaciones de los mismos). Tambien esnecesario mostrar la necesidad de que las valoraciones se realicen basandose enhoras y jornadas completas de trabajo.

• Elementos a entregar como resultado del proyecto. Entre estos elementos se in-cluyen: documentos, ejecutables, fuentes, demostraciones de funcionalidad, demostra-ciones de precision, fiabilidad, tiempo de respuesta, seguridad. Es necesario especi-ficar el formato y el soporte para todos ellos (discos, CD-ROM, formatos de losdocumentos como Word, postscript,).

• Entrega del sistema. Se debe incluir el que se entrega y donde, posible demostracional cliente (planificacion de la demostracion, duracion de la misma), periodos depruebas.

Cuando se trabaja sobre la elaboracion del acuerdo del proyecto hay que mostrarleal alumno las diferencias en lo que es acuerdo y lo que es la especificacion funcionaldel proyecto. Ası mismo, es necesario no simplificar el acuerdo convirtiendolo en unpresupuesto mas un calendario.


Para la realizacion de esta actividad se utilizaran como herramientas el procesador detextos para la redaccion del acuerdo, la hoja de calculo para la confeccion del presupuestoy una herramienta de planificacion para la construccion del calendario.

3.2.7. Presentacion del producto

Duracion: 2 horas de clases de debate PRESENCIALES + las horas de trabajo en grupoNO PRESENCIALES que se planifiquen en cada grupo

Descripcion: El ingeniero en informatica incluye entre sus obligaciones la de presentarlos resultados de su trabajo. Esto cobra mayor relevancia si se da la situacion de untrabajo por cuenta propia o en competencia con otros equipos.

El objetivo de esta actividad es que los alumnos muestren su capacidad e ingenio paraproceder a la venta del producto que estan desarrollando. Para ello se les induce aplantear una presentacion publica pensando que el publico que tienen como oyenteesta integrado por posibles compradores de su producto que pretenden ver las diferen-cias existentes en el mismo con respecto a la competencia. Previamente a la presentacionprocederan a la organizacion, planificacion y desarrollo de los materiales necesarios pararealizar la presentacion del producto que estan construyendo. Aunque todavıa se encuen-tran en las primeras fases del desarrollo del proyecto, los alumnos ya han identificado lafuncionalidad y requisitos del sistema a construir y, por tanto, ya estan en condicionesde hacer una presentacion del mismo. Sera muy necesario hacerles hincapie en el trabajosobre la duracion y el ritmo de la misma. La amenidad es un elemento basico en todapresentacion, pero esta no debe confundirse con el chascarrillo y la broma.

Posteriormente, cada uno de los grupos procedera a realizar su presentacion disponiendode unos 10 minutos mas el turno de preguntas. El resto de los grupos debera valorarla presentacion realizada mediante un cuestionario que proporcionara el profesor. Estecuestionario recogera aspectos relativos a la organizacion y claridad de la presentacion,contenidos de la misma, actitud de la persona o personas que la llevan a cabo, y gestionde los turnos de preguntas y las correspondientes respuestas. Estas valoraciones seranutilizadas para evaluar tanto al grupo que las determina, como a la presentacion a laque se refieran.

Esta actividad tiene como prerrequisito haber establecido en cada grupo los requisitosdel sistema a construir.

3.2.8. Presentacion del proceso

Duracion: 2 horas de clases de debate PRESENCIALES + las horas de trabajo en grupoNO PRESENCIALES que se planifiquen en cada grupo

Descripcion: En la actividad de presentacion del producto ya se ha hecho referencia ala necesidad de formar al ingeniero en informatica para llevar a cabo la presentacion desu trabajo. Mientras en dicha presentacion el foco estaba en la venta de su trabajo bajolas distintas perspectivas del resultado del mismo (su producto), en esta presentacion elfoco se centrara en el metodo y organizacion del trabajo (su proceso).

El objetivo de esta practica es que los alumnos muestren su capacidad e ingenio paraproceder a la venta de su equipo de desarrollo. Para ello se les induce a plantear unapresentacion publica destinada a un auditorio integrado por empresarios que buscana un equipo de desarrollo que les construya un software a medida y, por tanto, estan


interesados en conocer la forma en que el equipo aborda la realizacion de sus desarrollos(organizacion, estandares, metodos, etc.).

Al igual que ocurre con la presentacion del producto, se necesita de un trabajo previode organizacion, planificacion y desarrollo de los materiales necesarios para realizar lapresentacion del proceso que han seguido para el desarrollo de su proyecto. Frente ala necesidad de trabajar en la duracion y el ritmo de la presentacion abordada en laactividad de presentacion del producto, en esta sera necesario ayudar en el desarrollo dela abstraccion y sıntesis de los pasos dados por el equipo para abordar el proyecto, y sugeneralizacion para cualquier desarrollo futuro.

Como en el caso de la presentacion del producto, cada uno de los grupos procedera arealizar su presentacion disponiendo de unos 10 minutos mas el turno de preguntas. Elresto de los grupos debera valorar la presentacion realizada mediante un cuestionario queproporcionara el profesor. Este cuestionario recogera aspectos relativos a la organizaciony claridad de la presentacion, contenidos de la misma, actitud de la persona o personasque la llevan a cabo, y gestion de los turnos de preguntas y las correspondientes respues-tas. Estas valoraciones seran utilizadas para evaluar tanto al grupo que las determina,como a la presentacion a la que se refieran.

Esta actividad tiene como prerrequisito haber superado las fases de analisis y disenodel producto. Es deseable que se este terminando la labor de codificacion y ya se hayaavanzado con las pruebas del producto.

3.2.9. Demostracion del producto

Duracion: 1 hora de tutorıa en grupo PRESENCIAL + las horas de trabajo en grupoNO PRESENCIALES que se planifiquen en cada grupo

Descripcion: La entrega final que deben efectuar los alumnos estara compuesta por unjuego de disquetes/CDs que permitan realizar la instalacion de la aplicacion desarrollada,ası como un conjunto de documentos que describan: el analisis de requisitos, el disenodel sistema, el manual de tests, el proceso de gestion y produccion, el manual de usuarioy de instalacion del sistema, y el cierre del proyecto.

La demostracion del sistema se realizara en el ambito de una tutorıa en grupo y ten-dra lugar un mınimo de 7 dıas despues de la entrega del producto y la documentacionasociada. La unica excepcion en la entrega de la documentacion sera que el documentode cierre se entregara el mismo dıa de la demostracion de la aplicacion para que se puedadejar constancia del trabajo desarrollado en esa ultima semana.

3.3. Bibliografıa

Los ejercicios de dinamica de grupos se basan en las propuestas de trabajo presentadas porWatt S. Humphrey en sus libros “Introduction to the Team Software Process” [Humphrey,2000] y “Introduction to the Personal Software Process” [Humphrey, 1997].

[Pressman, 2006] contextualiza el aseguramiento de la calidad en el marco general de de-sarrollo de sistemas software. [Mazza et al., 1996], [Mazza et al., 1994] describen los aspectosrelacionados con el aseguramiento de la calidad propuestos por la Agencia Espacial Europea(ESA).

Para la preparacion del seminario sobre CMM se ha utilizado principalmente el libro sobreel tema publicado por el Instituto de Ingenierıa del Software de la Universidad Carnegie Mellon


[CMU-SEI, 1995]. Tambien se ha utilizado el libro sobre gestion de procesos de desarrollo desoftware de W.S. Humphrey [Humphrey, 1990]

Para la preparacion del seminario sobre ISO 9000 este seminario se ha utilizado el libro deD.Ince sobre ISO 9001 [Ince, 1994], el de R.Kehoe y A.Jarvis sobre ISO 9000-3 [Kehoe y Jarvis,1996], y el de C.H.Schmauch sobre ISO 9000 [Schmauch, 1995].

3.4. Criterios adicionales de evaluacion

Conviene detallar algunos aspectos adicionales en la valoracion del proyecto informaticoque se desarrolla en grupos de cinco alumnos. En esta valoracion se tendran en cuenta lossiguientes apartados:

La aplicacion informatica creada por cada grupo se valorara en un 20% de la nota delproyecto. Para poder evaluarla, cada grupo realizara una demostracion de la mismaal final del cuatrimestre. Se exigira como prerrequisito que la aplicacion desarrolladafuncione sin errores y se ajuste a los requerimientos determinados.

Se valorara igualmente en un 20% de la nota del proyecto la capacidad de cada grupopara realizar presentaciones ante el resto de los alumnos sobre el producto realizado ylas actividades de proceso que se han llevado a cabo (vease la descripcion detallada deestas actividades de presentacion en la seccion 2.3).

Por ultimo, la documentacion realizada supondra un 60% de la nota del trabajo. Estadocumentacion sera revisada por el profesor con el fin de evaluar los contenidos de lamisma.

Por ultimo, hay que destacar las penalizaciones que puede conllevar un retraso sobre lafecha planificada para la entrega del proyecto. Los grupos pueden planificar la entrega de susistema en cualquiera de las dos convocatorias de la asignatura (ordinaria y extraordinaria)sin que ello conlleve ninguna penalizacion. Por ejemplo, si planifican entregar en segunda con-vocatoria, en las actas de primera convocatoria aparecen como no presentados. Sin embargo, siun grupo planifica la entrega en una fecha (por ejemplo, primera convocatoria) y entrega el sis-tema con posterioridad (por ejemplo, en segunda convocatoria), sufrira una penalizacion. Estapenalizacion consistira en que los alumnos del grupo que ha incumplido la entrega aparecerancomo suspendidos en las actas de la primera convocatoria.

Bibliografıa

ACM/IEEE (2001). Computing curricula 2001, Computer Science. Technical report,ACM/IEEE-CS Joint Task Force on Computer Curricula.

Brooks FP (1995). The Mythical Man-Month, Essays on Software Engineering. Addison-Wesley.

Bruegge B, Dutoit AH (2002). Ingenierıa del Software Orientado a Objetos. Pearson Educacion(Prentice Hall), Mexico.

CMU-SEI (1995). The Capability Maturity Model: Guidelines for Improving the Software Pro-cess. Addison-Wesley. Carnegie Mellon University (CMU), Software Engineering Institute(SEI).

Humphrey WS (1990). Managing the Software Process. Addison-Wesley.

Humphrey WS (1995). A Discipline for Software Engineering. Addison-Wesley.

Humphrey WS (1997). Introduction to the Personal Software Process. Addison-Wesley.

Humphrey WS (2000). Introduction to the Team Software Process. Addison-Wesley.

Ince D (1994). ISO 9001 and Software Quality Assurance. McGraw Hill.

Kehoe R, Jarvis A (1996). ISO 9000-3 A Tool for Software Product and Process Improvement.Springer-Verlag.

MAP (1995). METRICA. Version 2.1. Metodologıa de planificacion y desarrollo de Sistemasde Informacion. Coeditado por el Ministerio de Administraciones Publicas (MAP) y laEditorial Tecnos.

MAP (2001). METRICA. Version 3. Metodologıa de planificacion y desarrollo de Sistemasde Informacion. Coeditado por el Ministerio de Administraciones Publicas (MAP) y laEditorial Tecnos.

Mazza C, Fairclough J, Melton B, de Pablo D, Scheffer A, Stevens R (1994). Software Engi-neering Standards. Prentice Hall.

Mazza C, Fairclough J, Melton B, Pablo DD, Scheffer A, Stevens R, Jones M, Alvisi G (1996).Software Engineering Guides. Prentice Hall.

Pressman RS (2006). Ingenierıa del Software, un enfoque practico. McGraw-Hill, 6th edition.

Schmauch CH (1995). ISO 9000 for Software Developers. ASQC.

21

caso práctico de desarrollo de proyectos por equipos

Documents