UNIVERSIDAD DE SAN CARLOS DE GUATEMALA FACULTAD DE INGENIERIA ESCUELA DE CIENCIAS Y SISTEMAS FICHA TÉCNICA DEL CURSO: Análisis y diseño de sistemas 1

Transcripción

1 UNIVERSIDAD DE SAN CARLOS DE GUATEMALA FACULTAD DE INGENIERIA ESCUELA DE CIENCIAS Y SISTEMAS FICHA TÉCNICA DEL CURSO: Análisis y diseño de sistemas 1 No. Descripción. Código 283 Créditos 4 1 Escuela Ciencias y Sistemas 2 Horas por semana 4 3 Pre-requisitos: Sistemas Administrativos de Bases de Datos Postrequistios: Análisis y diseño de sistemas Sección: Única 6 I. Descripción General Área a la que pertenece Software Vigencia Primer semestre 2016 Horario Martes 7:10 a 8:50 y jueves 7:10 a 8:50 El desarrollo de software se ha convertido en los últimos años en uno de los trabajos con mayor crecimiento. Algunos autores han dicho que la interacción diaria con otros está tan asociada a la tecnología que no se puede discutir de manera significativa la sociedad humana o el desarrollo económico sin incorporar el impacto de la tecnología. El software está presente en diferentes campos como salud, educación, manufactura y otros. Al final del curso, los estudiantes conocerán y habrán aplicado diferentes metodologías de desarrollo de software en un proyecto real, contando con una visión diferente de los elementos a considerar para un desarrollo de software de calidad. Se aplicarán metodologías ágiles y tradicionales, con el objetivo de contrastar sus características y evaluar las posibilidades de uso dependiendo del tipo de proyecto. Lo anterior, tomando en cuenta perspectivas como requerimientos del software, administración de proyectos de software, prácticas de codificación y prácticas de calidad aplicadas durante el proceso de codificación. II. Objetivos Los estudiantes que completen el curso serán capaces de: Identificar y describir las metodologías de desarrollo de software Evaluar y adaptar un proceso de desarrollo de software que se adapte a las condiciones de un proyecto Evaluar las fortalezas, debilidades y aplicabilidad de metodologías y prácticas de desarrollo de software Analizar prácticas de metodologías ágiles con base en la aplicación en un proyecto real Identificar y evaluar prácticas de manejo de requerimientos de software en proyectos de desarrollo de software III. Contenido Fecha Título y objetivos de aprendizaje Contenido 19/01 Introducción a la ingeniería Definición de conceptos básicos de software Definición de ingeniería de Describir el concepto de software ingeniería de software Calidad y métricas Conocer y discutir acerca de las actividades y principios de 21/01 la ingeniería de software Calidad en el proceso de software Evaluar el uso de métricas en el desarrollo de software Comprender el concepto de calidad y tipos de pruebas aplicables al software Asignaciones Evaluación de inicio de curso, en clase Discusión participativa de conceptos básicos Para la próxima semana: Ensayo del tema " Qué es un ingeniero de software?" 26/01 Administración de proyectos Introducción a la administración de proyectos Aplicar los conocimientos planificar el proyecto de clase

2 28/01 Gestión del alcance de proyectos 02/02 Introducción a procesos de desarrollo de software Ciclo de vida del software El estudiante debe haber leido para 02/02: Modelos: works/rational/library/mar05/bi ttner/index.html - Cascada works/rational/library/apr05/bit tner-spence/index.html - Desarrollo iterativo e incremental 04/02 - Prototipos Conocer las actividades del ciclo de desarrollo de software Conocer los modelos de ciclo de vida para desarrollo de software Evaluar los enfoques modelos de ciclo de vida agiles para desarrollo de software Analizar estudios relativos a la aplicación de metodologías ágiles 09/02 Modelos: - Modelo de espiral (análisis del riesgo) 11/02 - Introducción al proceso unificado (RUP) - Procesos ágiles 16/02 Metodologias agiles Agile Manifesto Puesta en comun metodologias rigidas y ágiles, el estudiante debe investigar y discutir en clase 18/02 Primer Examen Parcial 23/02 Exposiciones primer fase de proyecto de clase 25/02 Exposiciones primer fase de proyecto de clase 01/03 Metodologías ágiles - XP 03/03 Conocer las principales prácticas de la metodología Analizar la razón por la cual cada práctica es parte de la metodología Aplicar prácticas de XP al proyecto del curso - Descripción - Prácticas - Ejercicio de aplicación de prácticas 08/03 Metodologías ágiles Scrum 10/03 Conocer las actividades de planificación y ejecución Analizar la razón por la cual cada práctica es parte de la metodología Aplicar las prácticas de Scrum al proyecto del curso - Descripción - Actividades - Ejercicio de aplicación Resumen capitulos 1,2 y 3 del libro "The art of unit testing" SEMANA DE HUELGA Y SEMANA MAYOR - 14/03 AL 25/03

3 29/03 Metodologías ágiles Kanban 31/03 Conocer las principales prácticas de la metodología Analizar la razón por la cual cada práctica es parte de la metodología Aplicar prácticas de Kanban al proyecto del curso - Descripción - Prácticas - Similitudes y diferencias con Scrum Resumen capitulos 4,5 y 6 del libro "The art of unit testing" 05/04 Exposiciones segunda fase de proyecto de clase 07/04 Exposiciones segunda fase de proyecto de clase 12/04 Enfoques de requerimientos Casos de Uso 19/04 Conocer los principales enfoques para definición de requerimientos Evaluar las características de cada enfoque y su Historias de Usuario 21/04 aplicabilidad por tipo de Comparación: casos de uso e proyecto historias de usuario 26/04 Entrega digital ensayo a elección del estudiante para revista de ECYS, calificación en parejas Resumen capitulos 7,8 y 9 del libro "The art of unit testing" 28/04 Exposiciones Tercer fase del proyecto 03/04 Segundo Examen Parcial 05/04 Oportunidad de recuperación de parcial IV. Metodología: Se impartirá clase magistral 2 veces por semana. Así mismo se formarán grupos para el desarrollo de un proyecto grupal donde se deben aplicar los conceptos aprendidos en el curso, de forma práctica, dando solución a un problema real, lo cual se complementará con tareas y evaluaciones. Se desarrollará un ensayo relacionado con la temática del curso y se aplicarán revisiones de pares para su calificación. V. Evaluación: Evaluaciones parciales Se realizarán 2 evaluaciones parciales individuales (18 febrero y 28 de Abril). Las evaluaciones se realizarán en clase, de forma escrita o electrónica y evaluarán el contenido cubierto hasta la clase anterior a la evaluación. Proyecto Los estudiantes deben formar grupos para el desarrollo de un proyecto de curso que consistirá en la construcción de un sistema de software utilizando las metodologías y prácticas que están en el contenido del curso. El proyecto está dividido en 3 fases: Fase 1, consiste en definir elementos que serán útiles durante el semestre para el desarrollo del proyecto. Los elementos a definir son herramientas de apoyo al proyecto (administración, control de versiones, pruebas unitarias), sistema a desarrollar (de tamaño suficiente para las 3 fases siguientes) y arquitectura a utilizar. Fase 2, en esta fase se desarrollarán al menos dos iteraciones del proyecto elegido utilizando SCRUM y algunas prácticas de XP. Fase 3, en esta fase se desarrollarán al menos dos iteraciones del proyecto elegido utilizando SCRUM y algunas prácticas de XP y prácticas de Kanban. Para la evaluación de cada fase se definirá una hoja de calificación que contendrá detalle los aspectos a calificar. Exposición pruebas unitarias Los mismos grupos organizados para el proyecto, deben leer, resumir y exponer 1 o 2 capítulos del libro The art of unit testing (ver bibliografía). La implementación de pruebas unitarias es obligatoria para las fases 2 y 3 del proyecto, por lo que esta actividad es de importancia para el desarrollo del proyecto. Ensayo Cada estudiante debe desarrollar un ensayo asociado a la temática del curso y participar en una revisión de pares

4 (peer review) de otros ensayos. El tema que elija cada estudiante debe ser presentado al profesor a más tardar 2 semanas antes de la entrega del mismo. Laboratorio El auxiliar del curso llevará a cabo actividades de apoyo al desarrollo de las diferentes fases del proyecto y aplicación de las prácticas de las metodologías. Tareas y cortos En las clases durante el semestre se asignarán lecturas para resumen y discusión, así como exámenes cortos. Evaluación Evaluaciones parciales (40 puntos, 20 cada parcial) Proyectos (20 puntos) o Fase 1, 4 puntos o Fase 2, 6 puntos o Fase 3, 10 puntos Exposición pruebas unitarias (2 puntos) Ensayo (3 puntos) Laboratorio (5 puntos) Tareas de clase, participación y cortos 5 puntos) Examen final (25 puntos) VI. Requisitos para el curso Es obligatorio aprobar el proyecto para tener derecho a examen final, se aprueba con 61/100 Es obligatorio aprobar el laboratorio para tener derecho a examen final, se aprueba con 61/100 Es obligatorio aprobar el curso de SA de los laboratorios de la India Solo se calificarán exámenes y proyectos de estudiantes asignados en el curso. NO se agregan estudiantes a actas La formación de grupos para el proyecto y trabajos debe ser a más tardar el 28/01/2015, posteriormente NO se aceptarán más grupos en el curso Habrá oportunidades de puntos extra en el transcurso del semestre, por lo que al final del semestre NO se dejarán trabajos extra para quienes necesiten puntos a último momento 7 Bibliografía Software Engineering - modern approaches, Eric J. Braude, Michael E. Bernstein The art of unit testing 2 nd edition, Roy Osherove Scrum from the trenches 2 nd edition, Henrik Kniberg, Priming Kanban, Jesper Boeg, Engineering software as a service, Armando Fox, David Patterson User stories applied: for agile software development. Mike Cohn Writing effective use cases. Alistair Cockburn. Specification by example, Gojko Adzic 8 No. De Secciones 1 9 Catedráticos titulares y Inga. Ivonne Aldana auxiliares 10 Coordinadora de Área 11 Director de Escuela Ing. Marlon Pérez

5 Proyecto del curso El objetivo del proyecto del curso es implementar de forma práctica al menos 3 metodologías de desarrollo de software. Para ello, el mismo estará dividido en 4 fases. La primera fase es de preparación para el resto de fases. Las fases 2 y 3 se desarrollarán utilizando Scrum, XP y Kanban. Para cada fase se describen los entregables de la misma, así como los criterios preliminares de calificación. Fase 1 Fecha de entrega: 23 de febrero en digital, exponen aleatoriamente 23 y 25 de febrero. Descripción La primera fase del proyecto consiste en identificar elementos que serán útiles durante el semestre para el desarrollo del proyecto. Los elementos a identificar son: Investigación de aplicación de prácticas, se entrega un resumen. Herramientas Tecnología y arquitectura Propuesta de proyecto(s) a desarrollar Investigación de aplicación de prácticas Cada grupo debe realizar una investigación de las prácticas de las metodologías Scrum+XP, Kanban y RUP. A partir de la investigación se definirá un plan inicial que indiqué como el grupo cree que puede ir agregando prácticas a su proceso en cada una de las fases e iteraciones a realizar. Se debe considerar que cada fase tendrá al menos 2 iteraciones. Un ejemplo de lo que se espera es: Fase 1 o Iteración 1 Scrum Práctica 1 Práctica 2 o Iteración 2 Scrum Práctica 1 Práctica 2 Práctica 3 XP Práctica 1 Cada práctica debe ser descrita la primera vez que aparezca en la planificación. Se puede usar cualquier formato alterno para esto. Herramientas Todo proyecto de desarrollo de software requiere herramientas que apoyen al mismo. Dependiendo del tiempo y metodología utilizada, es útil definir herramientas para planificación, requerimientos, desarrollo, control de versiones, integración, pruebas y diseño. En esta fase del proyecto cada grupo decidirá que herramientas utilizará para las siguientes fases del proyecto, justificando la elección de herramientas. Los elementos mínimos a considerar para herramientas son: planificación y seguimiento de tareas, control de versiones y pruebas unitarias. Tecnología y arquitectura. Cada grupo decidirá la tecnología que usará para desarrollo (java,.net, html5+javascript, etc.), el IDE de apoyo y una arquitectura preliminar para el desarrollo sobre dicha tecnología. También se definirá la plataforma de despliegue a utilizar (Tomcat sobre Linux, IIS sobre Windows Server 2008, por ejemplo). Propuesta de proyecto(s) a desarrollar Finalmente, cada grupo debe Identificar 2 propuestas de proyectos a desarrollar. La elección de los proyectos debe considerar: Se tendrá al menos 6 iteraciones para desarrollo del proyecto, aplicando las prácticas de las metodologías Se espera que al final de las iteraciones se generen productos de software terminados Funcionalidades que pudieran ser de utilidad para el grupo en el futuro.

6 Entregables Un documento que tenga el siguiente contenido: Investigación de aplicación de prácticas Herramientas Tecnología y arquitectura Propuesta de proyecto(s) a desarrollar Referencias Criterios de evaluación Aspecto a evaluar Criterios a aplicar Ponderación Investigación de aplicación de prácticas Explicación de cada práctica Inclusión de las metodologías indicadas Justificación de orden de adopción de prácticas Herramientas Tecnología arquitectura Proyectos a desarrollar Referencias y Descripción de herramientas Justificación para elección Aspectos del desarrollo considerados Cobertura de elementos solicitados Nivel de detalle suficiente para explicar las decisiones Descripción general Descripción general de casos de uso o historias Razón de la elección del proyecto Uso de identificación de texto tomado de alguna referencia Listado de referencias usadas 60%

7 Fase 2 Fecha de entrega 05 de abril 2016 Descripción En esta fase se desarrollará al menos una iteración del proyecto elegido utilizando SCRUM+XP Las prácticas mínimas a utilizar durante esta fase son: SCRUM Sprint plannng meetng Daily scrum meeting Sprint review Sprnt retrospective Taskboard / burndown chart XP TDD Informative workspace Coding standard Las herramientas mínimas obligatorias para esta fase son: Gestión del proyecto Control de versiones (git, svn) Pruebas unitarias (junit, nunit, testng) El profesor tendrá el rol del product owner. Para la realización del sprint meeting, se publicará la hora y fecha en que se hará con cada grupo. Cada grupo es responsable de llevar a la reunión: Product backlog Historias de usuario en electrónico o físicas Cartas a usar en el poker estimation Definición de terminado Cuando se lleve a cabo la reunión de planificación, se deben tener todas las historias de usuario del proyecto elegido, para que se puedan priorizar de acuerdo al criterio del product owner. Como parte de esta fase se debe documentar la ejecución de las diferentes prácticas aplicadas, con la evidencia respectiva. Se debe preparar el sprint review para la fecha de calificación de la fase. Entregables 1. Documento que contenga: Introducción Roles utilizados Artefactos utilizados Prácticas aplicadas o Resumen de prácticas aplicadas o Como se internalizó cada práctica en el grupo y proyecto o Problemas encontrados y soluciones o Conclusión del grupo acerca del beneficio o desventaja de implementar la práctica Estado proyecto o Historias de usuario identificadas (todas) y su estado actual o Planificación de iteraciones (ejecutadas y futuras) o Estado del proyecto en cuanto a la planificación o Estado del proyecto en cuanto a la calidad Herramientas o Experiencias en uso de herramientas

8 o Organización de artefactos en herramientas Referencias 2. Código funcionando para las historias de la primera iteración. 3. Presentación de la fase, incluyendo: Sprint review Aspectos del documento que consideren mas importantes para explicar el trabajo y sus resultados Criterios de evaluación Aspecto a evaluar Criterios a aplicar Ponderación Aplicación prácticas Scrum Sprint plannng meetng Daily scrum meeting Sprint review Sprnt retrospective Taskboard / burndown chart Aplicación prácticas XP Uso de herramientas Código funcionando Presentación TDD Informative workspace Coding standard Explicación de forma de uso de control de versiones Explicación de forma de uso de pruebas unitarias Explicación de uso de otras herramientas Aplicación funcionando Código en repositorio de versiones Código de pruebas unitarias en repositorio de versiones Cumplimiento con el tiempo asignado Cobertura de todos los elementos del trabajo Presentación efectiva y amena Respuestas satisfactorias a preguntas al final 35%

9 Fase 3 Fecha de entrega 28 Abril 2016 Descripción En esta fase se desarrollarán al menos dos iteraciones del proyecto elegido utilizando SCRUM+XP+Kanban Las prácticas mínimas a utilizar durante esta fase son: SCRUM Sprint plannng meetng Daily scrum meeting Sprint review Sprint retrospective Taskboard / burndown chart XP TDD Informative workspace Coding standard Programación en parejas Kanban Visualizar el flujo de trabajo Limitar WIP (Work In Progress) Hacer las políticas administrativas explícitas Administrar el flujo Mejorar colaborativamente Las herramientas mínimas obligatorias para esta fase son: Gestión del proyecto Control de versiones (git, svn) Pruebas unitarias (junit, nunit, testng) El profesor tendrá el rol del product owner. Para la realización del sprint meeting, se publicará la hora y fecha en que se hará con cada grupo. Cada grupo es responsable de llevar a la reunión: Product backlog Historias de usuario en electrónico o físicas Cartas a usar en el poker estimation Definición de terminado Cuando se lleve a cabo la reunión de planificación, se deben tener todas las historias de usuario del proyecto elegido, para que se puedan priorizar de acuerdo al criterio del product owner. Como parte de esta fase se debe documentar la ejecución de las diferentes prácticas aplicadas, con la evidencia respectiva. Se debe preparar el sprint review para la fecha de calificación de la fase. Entregables 1. Documento que contenga: Introducción Evidencia de prácticas aplicadas o Sprint backlog o Taskboard o Burndown chart o Informative workspace o Estándares de codificación usados o Para TDD

10 Detalle de cómo se fue implementando la práctica para al menos 2 historias, con parejas diferentes El detalle debe incluir las pruebas que se van construyendo, la corrida fallida, el desarrollo del código para resolver las pruebas, la corrida exitosa y la refactorización realizada después de que funcionaron las pruebas Todo lo anterior, desde el inicio de la historia hasta la finalización de la misma o Para programación en parejas Detallar las parejas formadas Indicar los periodos de tiempo en que se aplicó la práctica para cada pareja o Visualizar el flujo de trabajo Flujo de trabajo definido en la reunión de planificación y flujo al final de la fase (en caso hubiera cambiado) o Limitar WIP (Work In Progress) Flujo de trabajo con el WIP definido para cada actividad. Se debe indicar el WIP usado para cada iteración (o sprint) por separado Explicación de cómo se eligió el WIP inicial Explicación de por qué se cambio el WIP para la 2da iteración de la fase Discusión y análisis de WIP aplicado en las 2 iteraciones o Hacer las políticas administrativas explícitas Flujo de trabajo donde se indican claramente las políticas a utilizar para cada actividad Explicación de cómo se validó la aplicación de las políticas en la fase o Administrar el flujo Explicación de qué métricas se aplicaron para mejorar el flujo y que mejoras se realizaron o Mejorar colaborativamente Indicar como se implementó esta práctica o Para pruebas unitarias Tomar el checklist de pruebas unitarias publicado en Canvas (unit testing checklist) y aplicarlo para al menos 3 casos de prueba, explicando para ítem del checklist la razón de la respuesta indicada o Problemas encontrados y soluciones o Conclusión del grupo acerca del beneficio o desventaja de implementar las prácticas Estado proyecto o Historias de usuario identificadas (todas) y su estado actual o Planificación de iteraciones (ejecutadas y futuras) o Estado del proyecto en cuanto a la planificación o Estado del proyecto en cuanto a la calidad Conclusiones finales con relación a las 3 metodologías agiles aplicadas en el proyecto. Se debe analizar cada metodología, indicando ventajas y desventajas, concluyendo cual les parece mas útil y por qué. Se debe hacer el mismo análisis para las prácticas que consideren mas aplicables en el futuro. Referencias 2. Código funcionando para las historias de la primera y segunda iteración. 3. Presentación de la fase, incluyendo: Sprint review Aspectos del documento que consideren más importantes para explicar el trabajo y sus resultados Criterios de evaluación Aspecto a evaluar Criterios a aplicar Ponderación Aplicación prácticas Scrum Sprint plannng meetng Daily scrum meeting Sprint review Sprnt retrospective Taskboard / burndown chart Aplicación prácticas XP Checklist pruebas unitarias TDD

11 Aplicación prácticas Kanban Código funcionando Presentación Informative workspace Coding standard Programación en parejas Visualizar el flujo de trabajo Limitar WIP (Work In Progress) Hacer las políticas administrativas explícitas Administrar el flujo Mejorar colaborativamente Aplicación funcionando Código en repositorio de versiones Código de pruebas unitarias en repositorio de versiones Cumplimiento con el tiempo asignado Cobertura de todos los elementos del trabajo Presentación efectiva y amena Respuestas satisfactorias a preguntas al final 35%