CC Ingeniería de Software II Sergio F. Ochoa Clase 1 - Versión 14

Responsables: Profesor a Cargo: Sergio F. Ochoa Tel: Oficina 406 Auxiliares: Maíra Márques Tel: Oficina 422 Luis Silvestre Tel: Oficina 423 Felipe González

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.

Objetivos de Curso Realizar trabajo de ingeniero: –Entender lo que significa “hacer ingeniería”. –Resolver un problema real utilizando un producto de software. –Desarrollar un producto trabajando en equipo. –Asumir roles dentro del equipo. – Lidiar con el cliente y con los miembros del equipo. – Implantar la solución y evaluar su impacto.

Contenidos del Curso 1.Introducción a la IS. 2.Especificación de Requisitos. 3.Diseño de Sistemas de Software. 4.Implantación y Entrega del Producto. 5.Revisiones y Pruebas de Software. 6.Gestión de un Proyecto de Software.

Metodología (1) Cátedra: – Clases Teóricas (Q13 - Mar-Jue. 10:15- 11:45hs). – Clases Auxiliares (Q13 – Viernes 14:30 a 16:00hs). Revisiones de proyectos en las auxiliares. Alumnos: –Ejecución de un Proyecto en Equipo. –Selección y Ejecución de un Rol.

Metodología (2) 1º- Los alumnos trabajarán en equipos de 5 o 7 personas. 2º- A cada equipo se le asignará un proyecto, que deberá desarrollar durante el semestre. 3º- Cada equipo autoasigna los roles de los miembros del equipo (el profesor dirime en caso de conflictos). Los roles posibles son: –Administrador del Proyecto. –Analista. –Diseñador-Implementador. –Ingeniero de Calidad. La estructura del equipo debe tener el OK del profesor Los roles de un miembro pueden cambiarse al final de cada fase, pero se debe tener el OK del profesor.

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 hace el profesor y los auxiliares del curso. 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.

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

Requisitos de Aprobación Promedio de notas de los controles 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.70 * 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 un promedio de controles >= 5.0. En ese caso, la nota del examen será el promedio de los controles. El examen no reemplaza a la peor nota de control.

30 % - Controles -10 % corresponde a la nota del Examen. -10 % corresponde a la nota del Control % corresponde a la nota del Control 2.

70% - Proyecto: El Proyecto consta de 4 Etapas o Fases: -El profesor califica los productos, y los miembros del equipo califican el aporte de sus pares a través de la co-evaluación. -Si no hay co-evaluación para algún alumno el profesor asigna las calificaciones correspondientes. -El profesor se reserva el derecho de vetar las co- evaluaciones injustificadas.

70 % - Proyecto: La nota del cliente es grupal, y no se ve afectada por la Co-Evaluación Fases/RolesAdP.Analist.Dis.-Impl.Ing.Cal. Concepción del Proyecto - Prototipo10% Coevaluación5% Iteración I – Producto10% Coevaluación5% Iteración II – Producto10% Coevaluación5% Implantación - Prod. Implantado (nota grupal cátedra) 10% Coevaluación5% Implantación - Prod. Implantado (nota grupal cliente) 10% TOTAL70%

El Rol de la Co-Evaluación Es un formulario donde cada miembro califica diversos aspectos de sus pares: 1.Compromiso de la persona para con el proyecto. 2.Cumplimiento de las tareas asignadas. 3.Iniciativa para sacar adelante el proyecto. 4.Comunicación con el resto del equipo. 5.Coordinación entre sus tareas y las de sus pares. 6.Calidad del trabajo realizado. 7.Apoyo a otros roles. 8.Convivencia con el resto del equipo.

Nota del Cliente: La nota del cliente considera: -Calidad / funcionalidad del producto obtenido. -Compromiso del equipo para con el proyecto. -Proactividad del equipo. -Comunicación y coordinación con el cliente.

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 del profesor. 2- Si el alumno es expulsado, la responsabilidad del acto será asumida por el profesor. 3- El expulsado tendrá un 1 como nota final del proyecto, y reprobará el curso.

Regla de Evaluación (2) NOTA: 1- El administrador de cada proyecto puede recomendar al profesor, 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 el profesor. 3- El expulsado tendrá un 1 como nota final del proyecto, y reprobará el curso.

Roles a asumir durante el Proyecto….

Roles (1): Adm. del Proyecto Es el principal responsable proyecto (Project Manager). Entre sus responsabilidades está: 1.Determinar el Objetivo y el Alcance del Proyecto (con los analistas). 2.Planificar/replanificar y Administrar el Proyecto. Incluyendo el plan de pruebas e implantación junto con el implementador. 3.Coordinar el trabajo de los distintos miembros del equipo. 4.Interactuar con el Cliente. 5.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, coordinación y planificación. Debe tener alta disponibilidad.

Roles (2): Analista Es el encargado de levantar y especificar los requisitos del sistema a desarrollar. Entre sus tareas está: 1.Determinar el Objetivo y el Alcance del Proyecto (con el AdP). 2.Identificar y entrevistar a clientes y usuarios. 3.Desambiguar y especificar los requisitos. 4.Apoyar al Ing. de Calidad en la especificación de las pruebas de sistema y de usuario. 5.Velar porque el diseño cumpla con los requisitos (junto con el Ing. de Calidad). 6.Velar porque el producto final cumpla con los requisitos (junto con el Ing. de Calidad). Debe trabajar rápido y a conciencia. Debe ser detallista y “preguntón”, y siempre tratar de ver más allá de lo que el cliente le dice.

Roles (3): Diseñador-Implem. Es el encargado de generar el diseño del front-end y back-end del sistema. Entre sus funciones está: 1.Generar el diseño arquitectónico y diseño detallado de la solución, basándose en los requisitos. El diseño debe ser implementable. 2.Diseñar e implementar las interfaces del sistema para chequear los requisitos entregados por el cliente. 3.Implementar el sistema. 4.Validar (junto con los Ing. de Calidad) los prototipos con los clientes y usuarios pertinentes. Debe ser creativo (pero realista), inteligente (no trabajar de más), y proactivo…. no debe dejar las cosas para último momento.

Roles (4): Ingeniero de Calidad Es el encargado de asegurar la calidad de cada uno de los productos (documentos, prototipos, etc). Entre sus tareas está: 1.Validar la calidad de los productos del proyecto, partiendo por las interfaces de usuario. 2.Coordinar las revisiones de los productos del proyecto. 3.Generar los informes post-revisión. 4.Realizar un seguimiento de las falencias identificadas. 5.Velar por la completitud y exactitud (no ambigüedades) de los documentos. 6.Velar por la calidad del producto final (cumplimiento de los requisitos). 7.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).

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

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

Hints (varios)… Controles son sin apuntes… Se puede usar un torpedo de 1 hoja (dos planas) escrita a mano. Cada incremento se debe implantar. Se debe usar un CVS por equipo de trabajo. Se debe usar MainReq para administrar los requisitos y llevar el tracking de las tareas asignadas a los miembros (No negociable). Las inspecciones se llevarán a cabo en base a la información que esté en MainReq.

Hints (varios)… Cada equipo tiene que tener al menos un cliente, un usuario y un monitor. Este último pertenece al equipo de cátedra. Los horarios de las inspecciones son estrictos... Dar cumplimiento a los horarios asignados será responsabilidad de cada grupo. Las revisiones serán exhaustivas (sin límite de tiempo).

Guía de Supervivencia: - Piensa, y luego actúa Preguntar es un síntoma de interés e inteligencia. - Sé proactivo.... 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 a los problemas del equipo, siempre puedes recurrir al profesor. -Ven a clases. En los controles se preguntan cosas que se dicen/hacen en clases, y que no necesariamente están en las transparencias.

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 (pero 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).

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. Los miembros del equipo de trabajo deben juntarse en forma periódica (1 vez a la semana, minutos)... Hay un abismo de diferencia entre la comunic./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. El 90% de las sorpresas en un proyecto de software son desagradables… por lo tanto. evítenlas.

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 (Idem), adelántense a esos riesgos y generen planes de contingencia. Asuman que los plazos nunca son suficientes, por lo tanto,… Idem….. 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.

Postulación de Proyectos Los alumnos/profesores/funcionarios pueden postular proyectos para los próximos semestres. Los proyectos tienen que beneficiar al DCC, a la Facultad/Univ., a los alumnos o a alguna entidad benéfica. Se require un cliente con al menos 1 hora semanal de disponibilidad. El cliente puede ser cualquiera que pueda venir al DCC para las actividades de trabajo con el equipo desarrollador. Se debe entregar al profesor una breve descripción del proyecto (1/2 o 1 página).

Tarea para el Viernes 13 de Marzo Los que están inscritos en el curso y no lo van a tomar, por favor avísenme. Los que no están inscritos y quieren tomar el curso, por favor avísenme. Los que van a tomar el curso deben dejar en la oficina de Sandra Gáez (# 420), 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. El viernes hay clase auxiliar,… y es importante que todos vayan (será corta)….

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 9° Ed. (2010). Pearson Education. “Software Engineering - A Practitioner’s Approach” - Roger S. Pressman, Bruce R. Maxim. 8º Ed. (2014). McGraw Hill.