CC51A - Ingeniería de Software

Presentación del tema: "CC51A - Ingeniería de Software"— Transcripción de la presentación:

1 CC51A - Ingeniería de Software
Alexandre Bergel - Sergio Ochoa Clase 1 - Versión 9.

2 Responsables: Profesores a Cargo: Auxiliar: Ayudante:
Alexandre Bergel Tel: Oficina 409 Sergio F. Ochoa Tel: Oficina 406 Auxiliar: Alcides Quispe Tel: Oficina 423 Ayudante: Maíra Márques

3 Agenda Definición de Objetivos. Contenidos del Curso.
Metodología de Desarrollo del Curso. Roles de los Alumnos. Requisitos de Aprobación. Evaluación. Guía de Supervivencia.

4 Objetivos de Curso Realizar trabajo de ingeniero:
Resolver un problema real a través de un producto de software. Desarrollar un producto trabajando en equipo. Desempeñar un rol dentro del equipo. Lidiar con el cliente y con los miembros del equipo. Implantar la solución y evaluar su impacto.

5 Contenidos del Curso (1)
Introducción a la IS. Especificación de Requisitos. Diseño de Sistemas de Software. Entrega e Implantación del Producto. Testing. Buenas Prácticas en la Escritura de Código.

6 Metodología (1) Cátedra: Alumnos:
Clases Teóricas (B205 - Mar-Jue. 10:15-11:45hs). Clases Auxiliares (B*** - Viernes14:30 a 16:00hs). Alumnos: Selección y Ejecución de un Rol. Ejecución de un Proyecto en Equipo.

7 Metodología (2) 1º- A cada alumno se le asigna un rol, de acuerdo a su Currículum y a sus preferencias. Los roles posibles son: Administrador de Proyectos. Analista. Diseñador. Implementador. Téster. 2º- Los alumnos son divididos en equipos de trabajo de 5 o 6 personas. 3º- A cada equipo se le asignará un proyecto, que deberá desarrollar durante el semestre.

8 Metodología (3) 4º- Cada equipo ejecutará el proyecto según las pautas dadas por la cátedra. 5º- Habrá dos tipos de proyectos: de implantación y extensión, y de desarrollo e implantación. 6º- La asignación de proyectos a equipos de trabajo la hacen los profesores y el auxiliar. 7º- Al finalizar cada etapa del proyecto (incremento), cada equipo de trabajo, deberá entregar una versión implantada del sistema, ajustándose a los requisitos especificados por el cliente.

9 Roles….

10 Roles (1): Adm. del Proyecto
Es el principal responsable proyecto (Decision-maker). Entre sus responsabilidades está: Delimitar el Alcance del Sistema (con los analistas). Planificar/replanificar y Administrar el Proyecto. Incluyendo el plan de pruebas e implantación junto con el implementador. Coordinar el trabajo de los distintos miembros del equipo. Interactuar con el Cliente. Velar por el cumplimiento de los objetivos, plazos y costos comprometidos. Este es uno de los roles más críticos dentro de cualquier proyecto de desarrollo de software. Debe ser organizado, proactivo y tener buenas capacidades de comunicación y coordinación.

11 Roles (2): Analista Es el encargado de relevar y especificar los requisitos del sistema a desarrollar. Entre sus tareas está: Identificar y entrevistar a clientes y usuarios. Delimitar el alcance del sistema (con el AdP). Desambiguar los requisitos. Generar el documento de requisitos que incluye los requisitos de software y de usuario, dentro de los plazos comprometidos. Apoyar al Téster en la especificación de las pruebas de sistema y de usuario. Velar porque el diseño cumpla con los requisitos (junto con el téster). Velar porque el producto final cumpla con los requisitos (junto con el téster). Debe trabajar rápido y a conciencia. Debe ser detallista.

12 Roles (3): Diseñador Es el encargado de generar el diseño del front-end y back-end del sistema. Entre sus funciones está: Generar el diseño arquitectónico y diseño detallado del sistema (DD-Documento de Diseño), basándose en los requisitos. El diseño debe ser implementable. Generar prototipos rápidos del sistema (con analistas e implementadores) para chequear los requisitos entregados por el cliente. Validar los prototipos con clientes y usuarios pertinentes. Velar porque el producto final se ajuste al diseño realizado (funciones de téster). Debe ser creativo, pero realista.

13 Roles (4): Implementador
Es el encargado de implementar el sistema. Entre sus funciones está: Implementar los prototipos rápidos para chequear los requisitos. Implementar los diseños del sistema, especificados por los diseñadores (en el DD). Realizar la primera batería de pruebas y ajustar el sistema en base a los resultados. Diseñar (junto al AdP) y llevar a cabo el plan de implantación. Debe ser proactivo, inteligente (no trabajar de más), y…. no debe dejar las cosas para último momento.

14 Roles (5): Téster Es el encargado de asegurar la calidad de cada uno de los productos (documentos, prototipos, etc). Entre sus tareas está: Coordinar las revisiones de los productos del proyecto. Generar los informes post-revisión. Realizar un seguimiento de las falencias identificadas. Informar al AdP acepta de riesgos identificados. Velar por la adhesión al estándar adoptado. Velar por la completitud, y exactitud (no ambigüedades) de los documentos. Velar por la calidad del producto final (cumplimiento de los requisitos). Especificar las pruebas a realizar (con analistas). Debe ser muy detallista y constructivo …. Ojalá nunca tenga nada que decir. Es uno de los roles que más contribuye al éxito del proyecto (junto al AdP).

15 Trabajar en equipo para resolver el problema asignado
… El Desafío (1) Trabajar en equipo para resolver el problema asignado

16 … y que el cliente quede felíz.
… El Desafío (2) … y que el cliente quede felíz.

17 Proceso de Calificación – Requisitos de Aprobación.

18 Requisitos de Aprobación
Promedio de notas de los controles, el ejercicio distribuido y la nota del examen debe ser mayor o igual a 4.0. Promedio de notas del proyecto debe ser mayor o igual a 4.0. NF = 0.6 * PNP * PNC NF = Nota Final PNP = Promedio de Notas del Proyecto PNC = Promedio de Notas de Controles Podrán eximirse del examen aquellos que tengan 5.5 o más en cada control. En ese caso, la nota del examen será el promedio de los controles. El examen reemplaza a la peor nota de control.

19 60 % - Proyecto: Roles / Phases AdP Analist Diseñad Implemen Téster
Iteración I – EC 20% Iteración I – Cliente 5% Iteración II – EC Iteración II – Implantación 10% TOTAL 60% EC: Equipo de Cátedra

20 60 % - Proyecto: La nota que pone el Equipo de Cátedra (EC) es individual… Evalúa al producto y al miembro del equipo. La nota del cliente es grupal. La nota del EC se basa en: La calidad del trabajo realizado en relación con el rol asignado a cada alumno. El resultado de la co-evaluación. La nota del cliente considera: Compromiso mostrado con el proyecto. Proactividad. Funcionamiento como equipo (comunicac./coord.) Calidad / funcionalidad del producto obtenido.

21 40 % - Controles -10 % corresponde a la nota del Examen.
-10 % corresponde a la nota del Control 1. -10 % corresponde a la nota del Control 2. -10 % corresponde a la nota del Ejercicio de Diseño Distribuido de Software. La nota del examen puede reemplazar a la peor nota de control (siempre que ésta sea superior).

22 Regla de Evaluación (1) NOTA:
1- Si más del 50 % de los miembros del equipo de trabajo está de acuerdo con expulsar a uno de sus integrantes, puede hacerlo. Para ello deberá contar con el consentimiento de los profesores. 2- Si el alumno es expulsado, la responsabilidad del acto será asumida por los profesores. 3- El expulsado tendrá un 1 como nota final del proyecto, y reprobará el curso.

23 Regla de Evaluación (2) NOTA:
1- El administrador de cada proyecto puede recomendar a los profesores, la expulsión justificada de un miembro del equipo de trabajo, sin necesidad de que la mayoría de los miembros del equipo estén de acuerdo. 2- Si el alumno es expulsado, la responsabilidad del acto será asumida por los profesores. 3- El expulsado tendrá un 1 como nota final del proyecto, y reprobará el curso.

24 Guía de Supervivencia:
-  Piensa, y luego actúa ..... -   Preguntar es un síntoma de interés e inteligencia. -   Pregunta a tiempo.... no dejes las cosas para el final... -   Trata a los demás como deseas que te traten. -   Discute los problemas con tus compañeros..... pero debes ser honesto. - Si el AdP no da soluciones, siempre puedes recurrir al profesor. Ven a clases. En los controles se preguntan cosas que dicen en clases y que no necesariamente están en las transparencias.

25 Guía de Supervivencia:
-   Entiende que cada uno de nosotros piensa y actúa en forma diferente…. Pero todos debemos respetar aquello que acordemos. - Bienvenida la diversidad !!! Entiende que el éxito de tu proyecto sólo puede ser construido en equipo. ... Por lo tanto, sé generoso con tus conocimientos, responsable con tu trabajo, y crítico (constructivo) con el trabajo de los demás. Acepta la ayuda o las sugerencias de tus compañeros, ellos están tratando de mejorar el producto final (y la nota de todos).

26 Guía de Supervivencia:
La comunicación y coordinación entre los miembros del equipo de trabajo, y entre estos y el cliente, es la piedra angular para el éxito de cualquier proyecto. Júntense en forma periódica (1 vez a la semana, 30 minutos), los miembros del equipo de trabajo... Hay un abismo de diferencia entre la comunicación/coordinación cara a cara versus vía o inclusive teléfono. Júntense en forma periódica (1 vez a la semana, minutos), con el cliente para verificar el avance del proyecto y obtener feedback de lo que han hecho... SIEMPRE antes de una entrega, revisen lo que van a entregar. Se deben hacer dos revisiones: una interna al grupo, y otra con el cliente. Las sorpresas en un proyecto de software, el 90% de las veces son desagradables… por lo tanto evítenlas.

27 Guía de Supervivencia:
Asuman que van a tener problemas de comunicación y coordinación, por lo tanto adelántese a esos riesgos y generen planes de contingencia. Asuman que van a tener problemas de internos (por ejemplo gente enferma) y externos (con el cliente), por lo tanto adelántense a esos riesgos y generen planes de contingencia. Asuman que los plazos nunca son suficientes, por lo tanto adelántense a esos riesgos y generen planes de contingencia. La obra gruesa se realiza muy rápidamente. Ajustar los detalles lleva más de la mitad del proyecto. Es recomendable usar la ley del mínimo esfuerzo, por lo tanto no tiren horas-hombre a la basura.

28 Postulación de Proyectos
Los alumnos pueden postular proyecto para los próximos semestres. Los proyectos tienen que beneficiar al DCC, a la Facultad/Univ., a los alumnos o a alguna entidad sin fines de lucro. Se require un cliente con al menos 1 hora semanal de disponibilidad. Los clientes pueden ser cualquiera, menos los alumnos de la carrera que no hayan pasado por cc51a. Se debe entregar a los profesores una breve descripción del proyecto (1/2 o 1 página).

29 Tarea para el Viernes 13/8 Los que están inscritos en el curso y no lo van a tomar, por favor avísennos. Los que no están inscritos y quieren tomar el curso, por favor avísennos. Los que van a tomar el curso deben dejar en la oficina de Sandra Gáez un currículum impreso, 3 hojas máx.: Datos Personales (incluir: teléfonos, s y foto). Experiencia en desarrollo de software. Experiencia en diseño gráfico. Experiencia en administración de proyectos de software. 2 Roles que le interesaría desarrollar (1 rol preferido, y 1 rol secundario). El viernes hay auxiliar, y es importante que vayan….

30 Bibliografía Material Docente en U-Cursos.
“ESA Software Engineering Standards”. PSS-05-0 Issue 2. ESA Board for Software Standardization and Control (BSSC) - European Space Agency. (1991). URL: “Software Engineering” - Ian Somerville. 8º Ed. (2007) o 9° Ed. (2010). Pearson Education. “Software Engineering - A Practitioner’s Approach” - Roger S. Pressman. 7º Ed. (2007). McGraw Hill.