Tópicos Selectos para la Enseñanza de la Ingeniería de Software: Introducción a la Ingeniería de Software

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Tópicos Selectos para la Enseñanza de la Ingeniería de Software: Introducción a la Ingeniería de Software"

Transcripción

1 Benemérita Universidad Autónoma de Puebla Facultad de Ciencias de la Computación Tópicos Selectos para la Enseñanza de la Ingeniería de Software: Introducción a la Ingeniería de Software ISBN: Academia del Área de Bases de Datos e Ingeniería de Software Otoño 2011

2 Autoridades. Dr. Enrique Agüera Ibáñez Rector de la Benemérita Universidad Autónoma de Puebla Mtro. José Jaime Vázquez López Vicerrector de Docencia Dr. Pedro Hugo Hernández Tejeda Vicerrector de Investigación y Estudios de Posgrado M.C. Marcos González Flores Director de la Facultad de Ciencias de la Computación Dr. Luis Carlos Altamirano Robles Secretario De investigación y de Estudios de Posgrado M.C. Yalú Galicia Hernández Secretaria Académica Dr. Roberto Contreras Juárez Secretario Administrativo Revisores. M.C. Martín Estrada Analco. Prof. José Luis Luna Govea. Edición: 1ra, Otoño 2011 ISBN: Benemérita Universidad Autónoma de Puebla Dirección de Fomento Editorial 4 sur 104 Puebla, Pue. México. Teléfono y fax

3 Autores y Profesores de la Academia del Área de Bases de Datos e Ingeniería de Software participantes: M.C. Alma Delia Ambrosio Vázquez. C. Dr. Mario Anzures García. Dra. Etelvina Archundia Sierra. M.C. María del Rocío Boone Rojas Dra. Maya Carrillo Ruiz. Dr. Juan Manuel González Calleros Dra. Josefina Guerrero García M.C. María del Consuelo Molina García. Dra. María de la Concepción Pérez de Celis Herrero. Dra. María Josefa Somodevilla García. Coordinadora del Área de Bases de Datos e Ingeniería de Software y Coordinadora de la Publicación del Libro. M.C. María del Rocío Boone Rojas Autora Colaboradora, P.I. de la Facultad de Ciencias de la Computación, BUAP.: M.E. María del Carmen Cerón Garnica. 3

4 Presentación La comunidad de la Facultad de Ciencias de la Computación, se ha distinguido entre cosas, por su constante preocupación por actualizar los contenidos temáticos de los planes y programas de estudio, lo cual se ha reflejado formalmente en la actualización de los planes y programas de estudio realizada en diferentes periodos y bajo los diversos modelos establecidos institucionalmente, tales como el modelo de créditos y recientemente el Modelo Minerva. Sin embargo, el desarrollo vertiginoso, propio del ámbito de las Ciencias de la Computación, requiere que se adopten estrategias propias que permitan atender las demandas de actualización de los planes y programas de estudio y que bajo las restricciones propias institucionales para oficializar tales cambios, se puedan realizar en la práctica y permitan atender adecuadamente las necesidades de preparación actualizada de nuestros estudiantes. En particular, en nuestra comunidad se han adoptado un conjunto de estrategias que pretenden atender los retos anteriores, entre las cuales, se pueden citar las siguientes: -Incorporar, dentro de los planes y programas de estudio, asignaturas con programas abiertos que permitan introducir tópicos selectos correspondientes al desarrollo de las Ciencias de la Computación. -Contemplar, dentro de los planes y programas de estudio, un conjunto de materias electivas, con programas que permitan la especialización y actualización en las diversas líneas del conocimiento de las Ciencias de la Computación. -Promover la participación de los profesores en diversas actividades de actualización disciplinaria, profesional y docente. Tales como su incorporación a programas de especialización, de diplomado y de certificación profesional, entre otros. -Promover el desarrollo o la incorporación del personal docente en diversos proyectos de investigación de las diferentes áreas de las Ciencias de la Computación así como su participación activa en los diversos eventos y foros académicos especializados y de relevancia tanto a nivel nacional como internacional. 4

5 En este contexto, en el presente periodo de verano y como parte de los trabajos del personal docente del área de Bases de Datos e Ingeniería de Software de la Facultad de Ciencias de la Computación, se ha organizado el seminario del área, en el cual se ha propuesto como objetivo fundamental lograr unificar los materiales, métodos, estrategias y técnicas en la enseñanza de las asignaturas del área. Lo cual lleve por una parte a preparar los elementos necesarios para poder enfrentar las futuras actualizaciones de los programas de estudio, que de acuerdo a los lineamientos institucionales y propios del desarrollo de la educación, deberán de tener un enfoque orientado al desarrollo de competencias. Y por otra, integrar elementos necesarios para conformar a mediano plazo nuestro repositorio de objetos de aprendizaje para las diversas asignaturas del área. Asimismo y con base en el planteamiento realizado en la primera sesión de los trabajos del seminario del área, se abordaron los contenidos de las primeras unidades del programa de la asignatura de Ingeniería de Software correspondiente a los Planes y Programas de Estudio de los Programas de Licenciatura e Ingeniería de la Facultad. En el presente texto, se reportan los resultados de los trabajos desarrollados en el citado seminario, las experiencias compartidas y principalmente el conjunto de actividades propuestas por cada uno de los profesores participantes. Para cada uno de los temas desarrollados se ha propuesto adoptar el siguiente tipo de esquema de trabajo, en este caso correspondiente al tema de Antecedentes y Conceptos básicos de la Ingeniería de Software 2. Antecedentes y Conceptos básicos de la Ingeniería de Software. 2.1 Propuesta de actividades de motivación y diagnóstica para el estudio de la Ingeniería de Software. 2.2 Planeación didáctica de los antecedentes y conceptos básicos de la Ingeniería de Software. 2.3 Desarrollo de las actividades de antecedentes y conceptos básicos de la Ingeniería de Software Conceptos y términos de la Ingeniería de Software Antecedentes de la Ingeniería de Software El Concepto de Ingeniería de Software Factores de Calidad del Software. 5

6 2.4 Comentarios, Conclusiones y Actividades Complementarias sobre los antecedentes y conceptos básicos de la Ingeniería de Software. 2.5 Referencias capítulo 2. De acuerdo al esquema de trabajo anterior, el presente texto, consta de seis capítulos. Con el propósito de establecer un antecedente al marco de trabajo adoptado para el presente texto, en el capítulo 1 se presenta un panorama general sobre los antecedentes y conceptos de Planeación Didáctica. En el capítulo 2, se revisan los antecedentes, conceptos y términos de la Ingeniería de Software. El ciclo de vida y las etapas del proceso de desarrollo de un proyecto de software, se aborda en el capítulo 3. En el Capítulo 4, se revisan los modelos Desarrollo Rápido de Aplicaciones y de Métodos Formales. La tecnología CASE (Ingeniería de Software Asistida por Computadora) se revisa en el Capítulo 5. Finalmente y como parte de las tendencias en el desarrollo de la Ingeniería de Software, en el capítulo 6, se presentan los modelos ágiles de Procesos. Expreso mi reconocimiento y agradecimiento a cada uno de los profesores participantes en estos trabajos, sin duda alguna, sus valiosas experiencias en el ejercicio docente y profesional, reflejadas en este documento, establecen ya un precedente y referencia para la organización y mejora de la calidad de los trabajos académicos en nuestra Facultad. En particular, agradezco ampliamente la contribución de la Dra. Etelvina Archundia S., quien nos ha proporcionado la orientación metodológica para el desarrollo de los mismos. Así mismo, de manera especial, agradezco al M.C. Martín Estrada Analco y al Prof. Jose Luis Luna Govea, su trabajo y disposición para realizar la revisión general de este reporte. Resalto también el valioso apoyo de las autoridades administrativas tanto a nivel institucional como de la Facultad que hacen posible la divulgación y oficialización de los resultados de estos trabajos. A cada uno ellos, expreso mi agradecimiento. M.C. María del Rocío Boone Rojas. Coordinadora del área de Bases de Datos e Ingeniería de Software Facultad de Ciencias de la Computación. Otoño

7 Contenido Portada 1 Página Legal 2 Autores 3 Presentación 4 Capítulo 1 Perspectivas de la Reforma Integral Educativa en México. 10 Etelvina Archundia Sierra, María del Carmen Cerón Garnica. 1.1 Comentarios sobre el Proyecto Tuning en América Latina Experiencias en Espacios Comunes en México ECOES Planeación didáctica en la Educación Superior Actividades de aprendizaje Evaluación sumativa y formativa Referencias Capítulo 1 16 Capítulo 2 Antecedentes y Conceptos Básicos de la Ingeniería de Software. 17 Etelvina Archundia Sierra, María del Rocío Boone Rojas. 2.1 Propuesta de actividades de motivación y diagnóstico para el estudio de la Ingeniería de 18 Software. 2.2 Planeación didáctica de los antecedentes y conceptos básicos de la Ingeniería de Software Desarrollo de las actividades de antecedentes y conceptos básicos de la Ingeniería de 21 Software Conceptos y términos de la Ingeniería de Software Antecedentes de la Ingeniería de Software El Concepto de Ingeniería de Software Factores de Calidad del Software Comentarios, Conclusiones y Actividades Complementarias sobre los antecedentes y 29 conceptos básicos de la Ingeniería de Software. 2.5 Referencias Capítulo

8 Capítulo 3 Ciclo de Vida. 31 Alma Delia Ambrosio Vázquez, Ma. del Consuelo Molina García. 3.1 Propuesta de Actividades de Motivación y Diagnóstico para el Estudio de el Ciclo 32 de vida del software. 3.2 Planeación Didáctica de Ciclo de vida en la Ingeniería de Software Desarrollo de las Actividades de ciclo de vida del software Conceptos y Términos de ciclo de vida, las P`s de la Ingeniería de Software Comentarios, Conclusiones y Actividades Complementarias del ciclo de vida del 40 software. 3.5 Referencias Capítulo 3 41 Capítulo 4 Los Modelos DRA y de Métodos Formales 42 Mario Anzures García, Maya Carrillo Ruiz. 4.1 Planeación Didáctica del Modelo de Desarrollo Rápido de Aplicaciones Propuesta de Actividades del Modelo de Desarrollo Rápido de Aplicaciones Planeación Didáctica del Modelo de Métodos Formales Propuesta de Actividades del Modelo de Métodos Formales Referencias Capítulo 4 51 Capítulo 5 Herramientas de Ingeniería de Software Asistida por Computadora. 52 María Josefa Somodevilla García, María de la Concepción Pérez de Celis Herrero, María del Rocío Boone Rojas. 5.1 Propuesta de actividades de motivación y diagnóstico para el estudio de las Herramientas 53 de la Ingeniería de Software Asistida por Computadora. 5.2 Planeación didáctica de los antecedentes y conceptos básicos de las Herramientas de la 57 Ingeniería de Software Asistida por Computadora. 5.3 Desarrollo de las actividades de antecedentes y conceptos básicos de las Herramientas de 58 la Ingeniería de Software Asistida por Computadora El Concepto CASE Componentes básicos de CASE Taxonomía de Herramientas CASE Caso de Estudio. Introducción a una Herramienta de Ingeniería de Software 66 Asistida por Computadora. 5.4 Comentarios, Conclusiones y Actividades Complementarias sobre los antecedentes y 68 conceptos básicos de las Herramientas de la Ingeniería de Software Asistida por Computadora. 5.5 Referencias Capítulo

9 Capítulo 6 Modelos Ágiles de Procesos. 70 Josefina Guerrero García, Juan Manuel González Calleros. 6.1 Propuesta de actividades de motivación y diagnóstico para el estudio de modelos ágiles de 71 proceso. 6.2 Planeación Didáctica de modelos ágiles de proceso Desarrollo de las Actividades de Introducción a los métodos ágiles de la Ingeniería de 75 Software Introducción a los modelos ágiles Desarrollo de las actividades de métodos ágiles de la Ingeniería de Software Programación Extrema [Extreme Programming ( XP)] Metodologías Crystal [CrystalMethodologies (CM)] SCRUM Comentarios, conclusiones y actividades complementarias sobre los antecedentes y 94 conceptos básicos de la ingeniería de software. 6.6 Referencias Capítulo

10 Capítulo 1 Antecedentes y Conceptos de Planeación Didáctica. Etelvina Archundia Sierra María del Carmen Cerón Garnica 1. Perspectivas de la Reforma Integral Educativa en México La Secretaría de Educación Pública ha emitido documentos para la formación docente como lo son el desarrollo de proyectos didácticos, los cuales permiten atender diferentes aspectos que se vinculen con los aprendizajes, las relaciones docente/alumno, la organización de actividades y los intereses educativos en general. De esta manera, los proyectos didácticos son entendidos como actividades planificadas que involucran secuencias de acciones y reflexiones coordinadas e interrelacionadas para alcanzar los aprendizajes esperados que, en el caso de la asignatura de español favorecerán el desarrollo de competencias comunicativas. Los proyectos didácticos se conforman de cuatro elementos fundamentales para su desarrollo: propósito, actividades a desarrollar, productos y evaluación. [1]. Basándose en las investigaciones educativas y el consenso del camino que debe de seguir el sistema educativo mexicano, se han establecido acuerdos para la 10

11 implementación del enfoque en competencias, el cual incide desde el nivel básico, medio superior y superior, en donde cada nivel contempla las competencias a desarrollar, en el caso del nivel básico se promueve la comunicación y las habilidades del pensamiento como observar, analizar, razonar, aprender y el ser a través de la socialización. En el nivel medio superior se contempla: la comunicación, el pensamiento crítico y creativo, la responsabilidad social y cívica. En la educación superior el estudio de la propia disciplina y su relación con el campo laboral (Véase figura 1). Figura 1. Competencias a desarrollar de acuerdo a los niveles de estudio Fuente: Elaboración propia de los autores Con lo anterior se busca la articulación curricular, en el marco de la Reforma Integral de la Educación Básica (RIEB), basándose en el requisito para el cumplimiento del perfil de egreso, lo que implica integrar los niveles de preescolar, primaria y secundaria para que exista consistencia entre las competencias a desarrollar, a fin de sentar las bases para atender las necesidades de la sociedad actual [2]. Hoy la necesidad de educar para la vida demanda múltiples competencias a los maestros, de modo que éstos sean agentes de cambio que contribuyan a elevar los aprendizajes en los niños, en dotarles de herramientas para el pensamiento complejo y para un desarrollo humano pleno e integral, así como competencias cívicas y sociales que contribuyan a que todas las personas gocen de iguales derechos, libertades y oportunidades, así como elevar el bienestar general. Lo mencionado para la educación básica y media superior se debe de continuar en la educación universitaria en las diversas áreas del conocimiento para desarrollar individuos con capacidades que les permita incidir en el momento actual y sean transformadores de su contexto social. Por lo que la actividad del docente en el proceso de enseñanza aprendizaje requiere de la profesionalización del docente para atender los retos de la educación hoy en día, por lo que el docente universitario debe de ser competente en el dominio de los contenidos de enseñanza del currículo y que desarrolle las capacidades intelectuales de pensamiento abstracto y complejo en los alumnos universitarios. Para el proceso de enseñanza aprendizaje el docente debe de estudiar la forma en la cual planea, el cómo imparte y evalúa sus actividades en el aula. Debe de relacionar en el conocimiento disciplinar los beneficios de las corrientes pedagógicas a través de los estudiosos como los 11

12 son: Jean Piaget, Bruner, Lev Vigotsky y Gagne; además del uso de recursos de vanguardia como lo son las Tecnologías de Información TIC s(véase figura 2). Figura 2: Esquema aprendizaje para el docente en la impartición de su práctica profesional Fuente: Elaboración propia de los autores 1.1 Comentarios sobre el Proyecto Tuning en América Latina El enfoque en competencias presentado desde las Reflexiones y Perspectivasde la Educación Superioren América Latina en el Informe Final del Proyecto Tuningen América Latina durante los años , muestra las propuestas de las competencias genéricas, disciplinares y laborales en las diversas áreas del conocimiento. Las competencias genéricas son los criterios generales que se desarrollan durante los procesos de aprendizaje y su autogestión, por ejemplo: la comunicación, aprender a aprender, aprender ser, aprender a hacer (habilidades procedimentales y técnicas). Las competencias disciplinares se construyen por la integración de los saberes disciplinares y su aplicación contextual en un marco de conciencia social. La competencias laborales se relacionan con las disciplinares para la formación y desempeño profesional en un puesto laboral, identificando lo que es capaz de realizar, juzgar y la aptitud del poseedor de la competencia. Cabe mencionar de acuerdo al informe Tuning, la participación de 62 universidades latinoamericanas debatiendo en 4 grupos de trabajo: Administración de Empresas, Educación, Historia y Matemáticas. En un segundo momento, dada la repercusión que alcanzaronlas actividades realizadas en el marco del proyecto y respondiendo a una demanda de los países latinoamericanos, se incorporaron 120 nuevas universidades en 8 áreas del conocimiento: Arquitectura, Derecho, Enfermería, Física, Geología, Ingeniería, Medicina y Química. Estas 182 universidades, provenientes de 18 países de América Latina (Argentina, Brasil, Bolivia, Colombia, Costa Rica, Cuba, Chile, Ecuador, El Salvador, Guatemala, Honduras, México, Nicaragua, Panamá, Paraguay, Perú, Uruguay y Venezuela)[3]. 12

13 1.2 Experiencias en espacios comunes en México Las acciones mencionadas en el Proyecto Tuning se plasman en el Proyecto Experiencias en Espacios Comunes de Educación Superior ECOES, donde participan la Universidad Nacional Autónoma de México UNAM, Instituto Politécnico Nacional IPN y la Universidad Autónoma de México UAM, propiciando el intercambio y la movilidad estudiantil. La colaboración se da también en la educación a distancia y en el enlace de las bibliotecas digitales [4]. Si bien el compartir experiencias docentes entre las Universidades también deben de crear estrategias que les permita aplicar el enfoque en competencias en la Educación Superior en México por lo que se requiere integrar los estudios realizados a la fecha en un modelo a seguir en los aspectos de: Diseño curricular, formación docente, desarrollo de programas académicos, planeación didáctica, actividades de aprendizaje y evaluación de los programas académicos y curriculares (véase figura 3). Figura 3. Aspectos a atender en la Educación Superior en México Fuente: Elaboración propia de los autores Planeación didáctica en la Educación Superior El intercambio de experiencias entre los docentes de distintas Universidades Públicas Mexicanas aportaría en el proceso de enseñanza aprendizaje una oportunidad de enriquecer la práctica docente y generar materiales que permitan aprendizajes basados en problemas y proyectos, al igual que estudios de casos en contextos reales de excelente calidad, lo cual propiciaría en los alumnos, el interés por las asignaturas de los programas académico y un aprecio al esfuerzo docente vislumbrado en el poder hacer para incidir en la sociedad y transformación de la misma (Véase figura 4). 13

14 Figura 4 Formas de aprendizaje en educación superior Fuente: Elaboración propia de los autores La planeación didáctica en la Educación Superior requiere en un primer momento de un diagnóstico que nos permita ubicar los conocimientos, experiencias y prácticas que el alumno ha generado en las asignaturas anteriores. En un segundo momento el docente debe despertar el interés y motivación por los nuevos conocimientos, los cuales se contemplan bajo el control del tiempo, los materiales, recursos a utilizar en las actividades de aprendizaje a realizar para alcanzar las competencias establecidas al inicio. Las actividades de aprendizaje requieren la transferencia de las técnicas de aprendizaje y de los conocimiento disciplinares para llevarlas a cabo durante el desarrollo y ejecución en el aula de los contenidos plasmados en los programas académicos. Otro aspecto a considerar es la evaluación de las actividades de aprendizaje y de los objetivos y propósitos plasmados al principio. Las actividades de aprendizaje requieren de los recursos de vanguardia especializados en la educación a través de las Tecnologías de Información y Comunicación TIC s Actividades de aprendizaje Para las actividades de aprendizaje se requiere del estudio de las estrategias y técnicas en la enseñanza, aunado al conocimiento disciplinar de las asignaturas. Por lo que se recomienda utilizar los mapas conceptuales, mapa mental, cuadros sinópticos, esquemas, gráficos, diagramas; también durante las actividades de aprendizaje se sugieren técnicas de dinámicas grupales como el Panel, Philips 6/6, Trabajos en pequeños grupos y debates. En la planeación didáctica se destacan las actividades desarrolladas en la motivación e interés respecto al tema de estudio y en el desarrollo del mismo (véase figura 5). La actividad inicial motivacional se considera como un diagnóstico a partir de los conocimientos previos del alumno mediante los recursos de un video, el diálogo, texto o 14

15 una imagen. En este momento el clima de confianza en el aula propicia un medio de investigación e interés por parte del alumno respecto del tema. Para las actividadesen el desarrollo del tema se considera la búsqueda de los conocimientos disciplinarios del tema de diversas fuentes, a partir de datos, investigaciones, solución de problemas y estudio de casos. Motivación Diagnóstica Actividad inicial Actividad de desarrollo Trabajo en equipo. Estudio de casos Solución de problemas Investigaciones Lecturas Conclusiones Evaluación Cierre Figura 5. Actividades de inicio y desarrollo en la Planeación didáctica Fuente. Elaboración propia de los autores En el proceso de desarrollo el docente debe pensar en la organización de las actividades a través de equipos de trabajo y de prácticas de procesos constructivistas para enriquecer el proceso cognitivo de aprendizaje. Posterior a las actividades de desarrollo las conclusiones y cierre donde el alumno extrae y concreta lo aprendido en el cambio y transformación de los conocimientos previos a los nuevos. El pensamiento analógico, crítico y reflexivo representa la funcionalidad del aprendizaje del tema establecido [5]. 1.3 Evaluación sumativa y formativa La evaluación de los aprendizajes es un proceso complejo puesto que considera la implicación de diversas variables presentes en el aula como lo es la relación entre el docente-alumno, las evidencias del aprendizaje, la relación entre los alumnos, los recursos, las estrategias de aprendizaje aplicadas y la planeación didáctica. Cuando el docente integra las dimensiones mencionada debe de contemplar que la evaluación se puede dar en lo aprendido del tema, de la asignatura y lo que trasciende en el alumno para continuar con el aprendizaje en su práctica profesional. A continuación se presentan los dos tipos de evaluación esenciales a considerar en el proceso de aprendizaje: la evaluación sumativa y la formativa. La evaluación sumativa debe de ser coherente con las actividades de aprendizaje establecidas durante el desarrollo de la Planeación didáctica. La evaluación sumativa se 15

16 puede establecer mediante rúbricas, enseñanza asistida por el grupo, lista de cotejo o nota técnica. En la evaluación formativa el docente deberá crear una guía que permita al alumno integrar sus conocimientos, habilidades y actitudes en la solución de problemas disciplinares y aprendizaje basado en proyectos. El docente establecerá los tiempos de revisión y de rúbricas que le permita al alumno conocer su progreso y retroalimentación. El ambiente que se propicia en la evaluación formativa es de confianza y logros, permitiendo al alumno el pensamiento creativo para la innovación. 1.4 Referencias Capítulo 1 [1] Secretaría de Educación Pública, (2009) Programas de estudio Primer grado. Educación básica. Primaria, Segunda edición, 2009, Primera reimpresión, 2010, D. R. México, DF pág. 31. [2] Curso Básico de Formación Continua para Maestros en Servicio, Planeación didáctica para el desarrollo de competencias en el aula 2010 fue elaborado en la Dirección General de Formación Continua de Maestros en Servicio de la Subsecretaría de Educación Básica, de la Secretaría de Educación Pública. [3] Reflexiones y perspectivas de la Educación Superior en América Latina. Informe Final Proyecto Tuning América Latina Tuning América Latina: [4] Rositas, J. y Torres, G. Diseño de planes educativos bajo un enfoque de competencias. Ed. Trillas, México, [5] García, A. y Gómez, E. Notas del Diplomado en Planeación y organización de secuencias e intervención didácticas en torno a aprendizajes cognitivos, BUAP. México, Puebla,

17 Capítulo 2 Antecedentes y Conceptos Básicos de la Ingeniería de Software. Etelvina Archundia Sierra María del Rocío Boone Rojas Introducción Los programas de estudio en computación cuentan, actualmente, con la asignatura de Ingeniería de Software. Los docentes que imparten la asignatura están convencidos de que a los alumnos se les debe motivar el interés por conocer y practicar las metodologías para el desarrollo de sistemas de calidad en computación. Para que el alumno se interese en el estudio de la Ingeniería de Software el docente deberá realizar una planificación docente para que el alumno comprenda: Cuál es el objeto de su estudio y por lo tanto, la necesidad de aprender su aplicación en el campo de desarrollo de sistemas de cómputo de calidad. 17

18 Los aspectos que debe identificar el alumno son: el ingenio del sujeto capaz de transformar mediante la Ingeniería de Software, sistemas de cómputo de calidad al servicio de las personas y de los diversos campos de la sociedad. En el presente capítulo se propone una serie de actividades de aprendizaje para que el docente pueda desarrollar en su clase los siguientes aspectos: o Conceptos y términos de la Ingeniería de Software. o Antecedentes de la Ingeniería de Software. o El Concepto de Ingeniería de Software. o Factores de Calidad del Software. 2.1 Propuesta de Actividades de Motivación y Diagnóstico para el Estudio de la Ingeniería de Software. Actividades Propuestas. Actividad 1 Objetivo. Que el alumno identifique, a priori, algunas de las actividades y ventajas inherentes a la Ingeniería de Software. Especificaciones. E1) Selecciona un producto de programación que hayas desarrollado en un curso anterior. Ejemplo de Resultados. Programa para el curso de algoritmos y estructuras de datos. Profesor. M.C. Marco Antonio Soriano Ulloa. E2) Resuelve el siguiente cuestionario: 1.-Proporciona una lista de, al menos, tres especificaciones de requisitos establecidos por el profesor. Ejemplo de Resultados. Requisito1. 18

19 Programa que encuentre los caminos de costo mínimo que hay entre cada par de nodos de una digráfica pesada. Requisito 2. Considerar como datos de entrada: n número de nodos. N conjunto de nodos. R conjunto de arcos. P pesos asignados a cada arco. Requisito 3. Utilizar el algoritmo de Dijkstra. 2.- Consideras que el producto que desarrollaste se apegó a los requisitos establecidos? Por qué? Ejemplo de Resultados. - Al principio no entendí el problema. - Los resultados fueron incorrectos. 3.- Cumpliste en tiempo y forma, con la fecha de entrega? Justifica tu respuesta. Ejemplo de Resultados. -Sí se entregó en la fecha establecida pero no era exactamente lo que pidió el profesor. 4.- El tiempo establecido de desarrollo fue suficiente? Justifica tu respuesta. Ejemplo de Resultados. -El tiempo sí fue suficiente, pero faltó organizar actividades personales. 5.-Indica, por lo menos, dos aspectos del proceso de desarrollo de tu proyecto que se podrían mejorar. Ejemplo de Resultados. Realizar una mejor planeación de mis actividades. -Interactuar con el profesor para aclarar los requisitos. Recursos. R1) Producto de Programación desarrollado previamente, de preferencia en un lenguaje de alto nivel. 2.2 Planeación Didáctica de los Antecedentes y Conceptos Básicos de la Ingeniería de Software. 19

20 Tiempo. Se propone cubrir el tema en un intervalo de 4 hrs. Contenido. 1. Conceptos y Términos de la Ingeniería de Software. 2. Antecedentes de la Ingeniería de Software. 3. El Concepto de Ingeniería de Software. 4. Factores de Calidad del Software. Materiales. Referencias Bibliográficas. [1] Fairley Ingenierìa de Software. Prentice Hall. IEEE Trans. on Software Engineering. [2] Capítulo 1 Pressman Roger S. Ingeniería de Software, Un Enfoque Práctico. Mc Graw Hill. [3] Capítulo 1 IanSommerville. Ingeniería de Software Addison Wesley. Recursos Electrónicos. [4] Gabriel Buades Rubio. Concepto de Calidad Ingeniería de Software III Depto. De Ciencias Matemáticas e Informática. Universidad de las Islas Balares Consulta: Junio 2011 [5] Xavier Ferré Grau Principios Básicos de Usabilidad para Ingenieros Software 20

21 Facultad de Informática Universidad Politécnica de Madrid Consulta: Junio 2011 [6] Moisés Rodríguez Monje Calidad de Procesos y Productos Software, ISO/IEC Alarcos Quality Center Consulta: Junio Desarrollo de las Actividades de Antecedentes y Conceptos Básicos de la Ingeniería de Software Conceptos y Términos de la Ingeniería de Software. Material de Referencia. De Pressman [2] se incluye el siguiente material: Ingeniería. Software. Ingeniería de Software. Profesión que posee conocimientos científicos, actividades y criterios (ingenio) para crear dispositivos, métodos y sistemas para transformar los recursos y satisfacer mejor las necesidades de una sociedad. Conjunto de programas que se pueden ejecutar en una computadora, así como toda la información, utilerías y recursos necesarios para su diseño, instalación, operación, mantenimiento y refinamiento. Disciplina que establece el uso de principios de ingeniería robustos, orientados a obtener software económico que sea confiable y funcione de manera eficiente. Perfil del Ingeniero de Software. Diferencia entre programador e Ingeniero de Software. Debe ser capaz de encabezar o ser miembro de grupos multidisciplinarios de desarrollo de de todo tipo de software y que en equipo logre producir software de alta calidad. La Ingeniería de Software difiere de la programación tradicional en que se utilizan técnicas de ingeniería para especificar, diseñar, codificar, validar y mantener los productos dentro del tiempo y presupuesto establecidos para el proyecto. Además, la ingeniería se preocupa por aspectos administrativos que quedan fuera del dominio normal de la programación. El término programador se emplea para denominar a la persona preocupada y abocada a las tareas y detalles de la codificación, empacado y modificación de los algoritmos y estructuras de datos codificados en algún lenguaje de programación particular. Los Ingenieros de Software están, además, capacitados para hacer frente a aspectos de análisis, diseño, verificación, prueba de programas, documentación, mantenimiento y administración del proyecto. 21

22 Actividades Propuestas. Actividad 1 Objetivo. Que el alumno identifique los términos y conceptos elementales de la Ingeniería de software. Especificación. E1) Revisa las referencias [1] y [2], y realiza tu propia investigación sobre los conceptos y términos de la ingeniería de software. -Elabora un mapa conceptual que involucre los principales términos y conceptos de la ingeniería de software. Ejemplo tipo de Resultados. (Ver mapa conceptual en Programa de curso de la asignatura de Ingeniería de Software, Modelo MUM). Recursos. R1) Referencias [1] y [2] R2) Conexión a Internet Antecedentes de la Ingeniería de Software. Material de Referencia. Recomendación: Revisar Refs. [1] y [2]. A continuación se incluye material de Pressman [2]: 22

23 La Crisis del Software se denomina una etapa en la que todos los programas desarrollados, se corregían cuando había fallos o eran modificados debido a necesidades cambiantes, y que requerían de grandes esfuerzos para mantenerlos, con un costo mayor, a medida que la complejidad del software crecía. En las pasadas décadas los ejecutivos y desarrolladores se hacían las siguientes preguntas: Por qué lleva tanto tiempo terminar los programas? Por qué es tan elevado el costo? Por qué no podemos detectar los errores antes de entregar el software a los clientes? Por qué resulta tan difícil constatar el progreso del desarrollo del software? Estas y otras preguntas manifiestan el carácter del software y la forma en que se desarrolla, estos problemas hacen necesaria la adopción de técnicas de Ingeniería de Software. El software es ahora la clave del éxito de muchos de los sistemas basados en computadora. El software marca la diferencia. Lo que diferencia una compañía de otra, es la suficiencia, exactitud y oportunidad de la información proporcionada por el software. 23

24 Ejemplo de la importancia del software: Dos consultorios dentales; ambos cuentan con los últimos modelos de computadoras personales destinadas a apoyar las tareas y actividades relacionadas con el consultorio. Sólo que uno de ellos, cuenta con un dispositivo especial conectado a la computadora y con un Software para obtener radiografías de piezas dentales por computadora. En un par de minutos la muestra radiográfica está en pantalla y el médico puede obtener diferentes vistas de la placa usando este software. Además, puede establecer una conexión a través de internet o vía modem, para enviar el archivo de la radiografía a otro colega experto, con el fin de consultar y apoyar el diagnostico, todo ello en la misma cita. En la forma tradicional la placa radiográfica estaría lista en un par de días. El desarrollo de software se ha convertido en una industria con crecimiento vertical en los últimos años, hoy por hoy uno de los hombres más ricos del mundo es el dueño de una casa de software, Microsoft. Hace un par de décadas se sostenía la teoría de que los países que poseían los mejores recursos naturales estaban destinados a ser los más ricos y poderosos del mundo, en México por ejemplo, se manejó la idea de que el petróleo era la gran puerta de entrada al mundo desarrollado. Indudablemente los recursos naturales tienen un papel importante en la economía de los países, sin embargo, poco a poco se fue acuñando una nueva ideología que se sintetiza en lo siguiente: Aquél que posee la información y el conocimiento y hace mejor uso de él, es el que tiene el poder. Problemas del software. La planificación y estimación de costos frecuentemente son imprecisas. Falta de productividad en la comunidad de software La calidad del software, a veces, es inaceptable. Estos problemas al final crean insatisfacción y falta de confianza por parte de los clientes. Los problemas anteriores son sólo manifestación de otras dificultades: No tenemos tiempo de recoger datos sobre el proceso de desarrollo del software. Los proyectos de desarrollo de software se llevan a cabo con sólo una vaga indicación de los requisitos del cliente. La calidad del software es normalmente cuestionable. El mantenimiento de software es muy costoso y no se le ha considerado un aspecto importante. Los problemas anteriores son corregibles, la clave es: Dar un enfoque de ingeniería al desarrollo de software. 24

25 Actividades Propuestas. Actividad 1 Objetivo. Que el alumno identifique el tipo de productos de software desarrollados a partir de la segunda generación de computadoras, cuyo tamaño y complejidad resultó imposible de manejar sin una metodología adecuada. Especificación. -Revisar el Cap.1 de las refs. [1] y [2]. -Proporcionar una lista de los tipos de productos de software que se desarrollaron a partir de la segunda generación de computadoras. Ejemplo de Resultados. -Sistemas de tiempo compartido. -Sistemas con multiprogramación. -Sistemas multitarea. Recursos. R1) Referencias [1] y [2] Actividad 2 Objetivo. Que el alumno identifique los problemas que surgen cuando los productos de software se desarrollan sin el enfoque de la ingeniería de software. Especificación. -Revisar el Cap.1 de las refs. [1] y [2]. (Ver II Planeación, Materiales.) -Proporcionar una lista de los problemas que surgieron durante el desarrollo de los productos de programación durante la etapa llamada crisis del software. Ejemplo de Resultados. -El Producto se entregó fuera de tiempo. -El producto no corresponde a los requisitos especificados por el cliente. -Algunas de las opciones del producto NO funcionan o bien, fallan. 25

26 Recursos. R1) Referencias [1] y[2] El Concepto de Ingeniería de Software. Material de Referencia. Ref.[1]. En [1] se incluyen algunas definiciones de la Ingeniería de Software: Definición 1 Ingeniería de Software es el estudio de los principios y metodologías para desarrollo y mantenimiento de sistemas de software [Zelkovitz, 1978] Definición 2 Ingeniería del Software es la aplicación práctica del conocimiento científico en el diseño y construcción de programas de computadora, así como de la documentación asociada, requerida para desarrollar, operar (funcionar) y mantenerlos. Se conoce también como desarrollo de software o producción de software [Bohem, 1976] ' Definición 3 Ingeniería del Software trata del establecimiento de principios y métodos de ingeniería, con el fin de obtener software de modo rentable, que sea fiable y trabaje en máquinas reales [Bauer,1972]. Definición 4 La aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación (funcionamiento) y mantenimiento del software; es decir, la aplicación de ingeniería al software. 2. El estudio de enfoques como en (1) [IEEE, 1993]. ZELKOVITZ, M. V., SHAW, A. C. y GANNON, J. D.: Principles of Software Engineering and Design. Prentice-Hall, EnglewoodsClif, BOEHM, B. W.: Software Engineering., IEEE Transactions on Computers, C-25, núm. 12, pp BAUER, F. L.: Software Engineering, Information Processing, 71, North Holland Publishing Co., Amsterdarn, 1972 IEEE: Standards Collection: Software Engineering, IEEE Standard , IEEE,

27 Actividades Propuestas. Actividad 1 Objetivo: Identificar los conceptos clave asociados a la Ingeniería de Software. Especificación. E1) Realizar una revisión y análisis grupal de las diferentes definiciones de ingeniería de software presentadas previamente. En cada caso, señalar los conceptos clave que se resaltan en cada una de ellas. Recursos. R1) Ref.[2] Factores de Calidad del Software. Material de Referencia. -Concepto de Calidad. [4], [2], [6], [7] -Factores de Calidad Estructurales y Derivados. [4] -Descripción de Factores. [1], Cap. 18 y en [4] y [5]. Actividad 1 Objetivo. Que el alumno identifique atributos de calidad en un producto de Programación. Especificación. E1) Selecciona un producto de programación que hayas desarrollado en un curso anterior. E2) Identifica tres factores de calidad que consideres se le pueden atribuir a tu producto. Justifica tu respuesta. Ejemplo de Tipo de Resultados. Es portable, porque se desarrolló en Java, el cual tiene una máquina virtual. Recursos. 27

28 R1) Referencias [4] y [5]. R2) Un producto de programación desarrollado previamente, de preferencia en un lenguaje de programación de alto nivel. R3) Conexión a Internet. Actividad 2 Objetivo. Que el alumno identifique que es posible mejorar la calidad de sus productos de programación. Especificaciones. E1) Desde el punto de vista del programador, indica al menos tres características de tu producto de programación que consideres se podrían mejorar. Ejemplo de Resultados. -Utilizar estructuras de datos dinámicas para la implementación de los archivos indizados. E2) Desde el punto de vista del usuario, indica al menos tres características de tu producto de programación que consideres se podrían mejorar. Ejemplo de Resultados. -Mejorar la interfaz del usuario. -Dar más opciones para generar otro tipo de reportes. Recursos. R1) Referencias [6] y [7]. R2) Un producto de programación desarrollado previamente, de preferencia en un lenguaje de programación de alto nivel. R3) Conexión a Internet. Actividad 3 Objetivo. Que el alumno conozca que existen herramientas para evaluar factores de calidad de software y que pueden ser de diferentes tipos. (En un siguiente capítulo, Métricas, se espera que sea capaz de experimentar con al menos una de ellas). Especificaciones. E1) Realiza una búsqueda por Internet y desarrolla una breve documentación sobre tres herramientas para evaluar factores de calidad de un producto de software. Incluye al menos los siguientes aspectos: Nombre. 28

29 Empresa. Propósito. Puedes organizar tus resultados en una tabla. Ejemplo de Tipo de Resultados. Nombre. KEMIS Kybele Environment Mesaurement Information System Empresa.KybeleConsulting. Propósito. Facilitar la medición automatizada de la calidad de los productos software. Ej. Factores relacionados con capacidad de un producto para ser probado, de soportar actualizaciones. Recursos. R1) Conexión a internet. R2) Referencias disponibles en [6]. 2.4 Comentarios, Conclusiones y Actividades Complementarias sobre los Antecedentes y Conceptos Básicos de la Ingeniería de Software. Se propone realizar una actividad grupal de análisis y reflexión, relacionada con las siguientes cuestiones. - Cuál es el objetivo fundamental de la Ingeniería de software? - Consideras que el desarrollo de tus productos de software que has desarrollado hasta la fecha, ha sido metodológico y disciplinado? - Tus productos de programación cumplen con algunos o la mayoría de los factores de calidad que se han revisado? 2.5 Referencias Capítulo 2 [1] Fairley Ingenierìa de Software. Prentice Hall. IEEE Trans. on Software Engineering. [2] Capítulo 1 29

30 Pressman Roger S. Ingeniería de Software, Un Enfoque Práctico. Mc Graw Hill. [3] Capítulo 1 IanSommerville. Ingeniería de Software Addison Wesley. Recursos Electrónicos. [4] Gabriel Buades Rubio. Concepto de Calidad Ingeniería de Software III Depto. De Ciencias Matemáticas e Informática. Universidad de las Islas Balares Consulta: Junio 2011 [5] Xavier Ferré Grau Principios Básicos de Usabilidad para Ingenieros Software Facultad de Informática Universidad Politécnica de Madrid Consulta: Junio 2011 [6] Moisés Rodríguez Monje Calidad de Procesos y Productos Software, ISO/IEC Alarcos Quality Center Consulta: Junio 2011 [7] 30

31 Capítulo 3 Ciclo de Vida. Alma Delia Ambrosio Vázquez Ma. del Consuelo Molina García Introducción Un modelo de ciclo de vida define el estado de las fases a través de las cuales se lleva un proyecto de desarrollo de software, este proceso es parte de la calidad del software que un ingeniero de software debe aplicar y al cual debe dar seguimiento. 31

32 Uno de los objetivos de la asignatura de ingeniería de software, es conseguir que el alumno conozca el concepto de calidad del software, que comprenda, conozca y valore la importancia del uso de metodologías de la ingeniería de software, así como de que le confiera un seguimiento durante todo el ciclo de vida del software. Tomando en cuenta que la Ingeniería de Software es el resultado de llevar la tradicional disciplina de las ingenierías al mundo de la construcción de sistemas de software es necesario el estudio de los principios y metodologías para el desarrollo y mantenimiento de sistemas software así como de las personas que se involucran en ello. Por las razones expuestas, el objetivo del presente trabajo es realizar una intervención didáctica, que planifique las tareas de aprendizaje en los temas involucrados. En el presente capítulo se propone una serie de actividades de aprendizaje para que el docente pueda desarrollar en su clase los siguientes aspectos: o Paradigmas de Programación o Las 4 P`s de la Ingeniería de software (Proceso, Producto, Proyecto y Personas) o Metodologías de la Ingeniería de software o Ciclo de vida del software. 3.1 Propuesta de Actividades de Motivación y Diagnóstico para el Estudio del Ciclo de vida del software. Dentro de las actividades diagnósticas en esta materia, es trascendental que el alumno conozca las conceptos básicos como paradigmas de programación, las 4 P s de la Ingeniería de Software, Ciclo de Vida, Modelo, Metodología, Calidad del Software, Planeación y Administración de Proyectos, Factibilidad, Viabilidad, Prototipos, y la Certificación de Procesos. Actividades Propuestas. Actividad 1 Objetivo. Que el alumno identifique las ventajas de aplicar las metodologías de la ingeniería de software. 32

33 Especificaciones. E1) Que el alumno realice una investigación sobre el conjunto de métodos, técnicas y herramientas relacionadas con las metodologías de desarrollo de software. E2) Que el alumno realice una investigación sobre las diferencias en los paradigmas de programación. E3) Con base en un análisis crítico-objetivo el alumno basado en un andamiaje, resuma las condiciones apropiadas para la aplicación de metodologías de la Ingeniería de Software estructurada u orientada hacia objetos. E4) Resuelva el siguiente cuestionario: 1. Cuáles son las cuatro componentes P de la ingeniería de software? 2. Qué es el proceso en cascada? 3. Qué estándares existen para documentación? 4.-Establezca las diferencias entre aplicar, o no, una metodología de la Ingeniería de Software en el desarrollo de software. Justifica tu respuesta. Recursos. R1) Consultar bibliografía. 3.2 Planeación Didáctica de Ciclo de vida en la Ingeniería de Software. Tiempo. Se propone cubrir el tema en un intervalo de 4 hrs. Contenido. Paradigmas de Programación Las 4 P`s de la Ingeniería de software Metodologías de la ingeniería de software 33

34 Materiales. Ciclo de vida del software. Referencias Bibliográficas. [1] Capítulo 1 Braude Ingeniería de Software Una perspectiva orientada a objetos Alfaomega 2003 IEEE Trans. on Software Engineering. [2] Capítulo 1 Pressman Roger S. Ingeniería del Software, Un Enfoque Práctico. Mc Graw Hill. [3] Capítulo 1 Ian Sommerville. Ingeniería de Software Addison Wesley. Recursos Electrónicos. [4] Gabriel Buades Rubio. Concepto de Calidad Ingeniería de Software III Depto. De Ciencias Matemáticas e Informática. Universidad de las Islas Balares Consulta: Junio 2011 [5] Xavier Ferré Grau Principios Básicos de Usabilidad para Ingenieros Software Facultad de Informática Universidad Politécnica de Madrid Consulta: Junio 2011 [6] Moisés Rodríguez Monje Calidad de Procesos y Productos Software, ISO/IEC Alarcos Quality Center 34

35 Consulta: Junio Desarrollo de las Actividades de ciclo de vida del software Conceptos y Términos de ciclo de vida, las P`s de la Ingeniería de Software. Material de Referencia. De Braude [1] se incluye el siguiente material: Ciclo de Vida El ciclo de vida de desarrollo de sistemas informáticos puede dividirse en actividades o fases que, en general, se ajustan al esquema mostrado en el gráfico. Este esquema gráfico es el ciclo de vida típico, dado que existen gran cantidad de variantes que dependen de la organización, del tipo de sistema que se realizará, de los gustos de los administradores, de los tiempos, etc. Las actividades típicas del ciclo de vida son: 1- Estudio de factibilidad. 2- Análisis (de requerimientos). 3- Diseño 4.1- Creación de prototipos 4.2- Implementación 5 - Validación y prueba 6 - Operación y mantenimiento 35

36 La Ingeniería de Software es el resultado de llevar la tradicional disciplina de las ingenierías al mundo de la construcción de sistemas de software. Es el estudio de los principios y metodologías para el desarrollo y mantenimiento de sistemas software. Los desafios de la Ingenieria de Software son: La Ing. Sw es una tecnología estratificada Enfoque de calidad La IS debe estar sustentada en un compromiso con la calidad (Gestión de Calidad Total, Sigma Seis, etc.) que fomente una cultura de mejora continua del proceso. 36

37 Procesos Define un marco de trabajo que debe establecerse para la entrega efectiva, la gestión de proyectos, el contexto en el cual se aplican los métodos técnicos, se generan los productos del trabajo, se establecen los fundamentos, se asegura la calidad y el manejo adecuado de cambios Métodos: Definen los cómo para construir el software desde el punto de vista técnico. Herramientas: Proporcionan un soporte automático o semi-automático para los métodos. Herramientas CASE Métodos: Planificación y estimación de proyectos. Análisis de requisitos. Diseño. Codificación. Pruebas. Mantenimiento. Herramientas: CASE. CAD,... Procesos. PSP TSP CMMi.. Qué es un proceso? Define un marco de trabajo que forma la base del control de gestión de proyectos de SW y establecen el contexto en que se aplican los métodos técnicos, se producen los resultados del trabajo, se asegura la calidad, etc Los métodos: Indican cómo construir técnicamente el SW. Las tareas que incluye son: Análisis de requisitos. Diseño (estructuras de datos, arquitectura de programación y procedimientos algorítmicos). Pruebas. Mantenimiento. Procedimientos: Relacionan métodos y herramientas desde un punto de vista formal. Entre otras cosas, se define la secuencia en que se aplican los métodos 37

38 Las Cuatro p`s de la Ingenieria de Software Actividades del Ingeniero del SW Dependencias profundas entre los ejes: No se puede ser un buen diseñador sin saber de tecnologías No se puede diseñar el proceso sin tener en cuenta la Arquitectura El proceso tiene que ir apoyado por metodologías No se puede ser un buen director de proyecto sin saber del resto No se puede ser un buen arquitecto sin saber de tecnología No basta con saber de tecnología para ser un buen arquitecto. Trabajo en equipo de desarrollo de software de paradigma estructurado y orientado a objetos. Actividades Propuestas. Actividad 1 Objetivo. Que el alumno conozca los conceptos básicos relacionados con el ciclo de vida de la Ingeniería de software. Especificación. E1) Revisar las referencias [1], [2] y [3] para realizar una investigación sobre los conceptos y términos de ciclo de vida. -Elaborar un mapa conceptual que represente las metodologías de la ingeniería de software. 38

39 Ejemplo tipo de Resultados. (Ver mapa conceptual en Programa de curso de la asignatura de Ingeniería de Software). Recursos. R1) Referencias [1] y [2] R2) Conexión a Internet. Actividad 2 Objetivo. Comprender los conceptos básicos de la Ingeniería de software Especificación. E1) Revisar las referencias [1], [2] y [3] 1. Se expone por parte del profesor los conceptos básicos de Ingeniería de Software Proceso, Producto, Personas, Proyecto, Modelo y Metodología. 2. Se reproducirá el video de Apolo 13 a partir de la escena 8 donde inicia el problema de bióxido de carbono y en tierra se dan instrucciones a un equipo que trabaje con el material a disposición de la tripulación a fin de hacer algo para solucionar el problema. 3. Los estudiantes se reúnen en equipos comentan el video examinado y cada equipo se le entregan unas preguntas tales como: Es importante el proceso para la solución de un problema? La organización del equipo de trabajo ayuda a la solución? Es importante trabajar con roles? Qué estrategia siguieron en el video para solucionar el problema? 4. Un alumno de cada equipo, podrá ser elegido al azar para presentar y justificar ante el grupo las respuestas 5. Por último, se entregará a cada alumno una prueba de verificación del aprendizaje de los conceptos vistos y comentados en clase. Ejemplo tipo de Resultados. (Ver mapa conceptual en Programa de curso de la asignatura de Ingeniería de Software). Recursos. R1) Referencias [1] y [2] 39

40 R2)Video, Laptop, cañón, plumones, pizarrón, resumen de la clase y prueba de verificación del aprendizaje Distribución de tiempo 25 min. Inicio de la clase (Introducción al conocimiento) Exposición por el profesor 35 min. Ver las escenas del video 10 min. Actividad de cada uno de los equipos genera respuestas. 20 min. Presentación de resultados por un alumno de cada equipo 10 min. Realizar la prueba de verificación de conceptos aprendidos 10 min. Conclusiones Total 1 hr. 50 min. 3.4 Comentarios, Conclusiones y Actividades Complementarias del Ciclo de Vida del Software. En esta etapa el alumno tendrá claro el concepto y la importancia de generar software de Calidad.El alumno conocerá la existencia de varios modelos de ciclo de vida a aplicar de acuerdo a sus características durante el desarrollo de software. Asimismo hará conciencia de la importancia de las P s de la ingeniería de software. Se propone realizar una actividad grupal de análisis y reflexión, relacionada con las siguientes cuestiones. - Cuál es la diferencia entre aplicar o no una metodología de la Ingeniería de software? - Para un caso dado, es posible aplicar indistintamente paradigma estructurado u orientado a objetos? - Cómo garantizarías la calidad de tu producto de software? 40

41 3.5 Referencias Capítulo 3 Referencias Bibliográficas. [1] Fairley Ingenierìa de Software. Prentice Hall. IEEE Trans. on Software Engineering. [2] Capítulo 1 Pressman Roger S. Ingeniería de Software, Un Enfoque Práctico. Mc Graw Hill. [3] Capítulo 1 IanSommerville. Ingeniería de Software Addison Wesley. 41

42 Capítulo 4 Los Modelos DRA y de Métodos Formales Mario Anzures García Maya Carrillo Ruiz Introducción Para resolver problemas reales de una empresa, un ingeniero del software o un equipo de ingenieros deben de incorporar una estrategia que a menudo se llama modelo de proceso o paradigma de ingeniería de software. Se selecciona un modelo de proceso para la ingeniería del software de acuerdo a la naturaleza del proyecto y de la aplicación, los métodos y las herramientas que se utilizan, así como los controles y entregas que se requieren. En este capítulo se abordan el modelo de Desarrollo Rápido de Aplicaciones (DRA/RAD) y el Modelo de Métodos Formales. 42

43 4.1 Planeación Didáctica del Modelo de Desarrollo Rápido de Aplicaciones. Tiempo. Se propone cubrir el tema en un intervalo de 2 hrs. Contenido. Materiales. Introducción a RAD. Definiciones y elementos fundamentales de RAD. R1) Consultar bibliografía. [1] James Martin Rapid application development Macmillan Publishing Co., Inc. Indianapolis, IN, USA 1991 [2] Beynon-Davies P.1; Carne C.1; Mackay H.2; Tudhope D. Rapid application development (RAD): an empirical review European Journal of Information Systems, Volume 8, Number 3, 1 Palgrave MacmillanSeptember 1999, pp (13) [3] Carlo Ghezzi, Mehdi Jazayeri y Dino Mandrioli. Fundamentals of Software Engineering. Prentice Hall International, [4] Pressman Roger S. Ingeniería del Software, Un Enfoque Práctico. Mc Graw Hill. [5] Ian Sommerville. Ingeniería de Software Addison Wesley. Recursos Electrónicos. [5] Vídeo tutorial RDA en 43

44 Fig. 4.1 Tutorial RAD 4.2 Propuesta de Actividades del Modelo de Desarrollo Rápido de Aplicaciones. Actividades Propuestas. Las acciones que se llevarán a cabo tienen como fin incentivar la utilización del modelo DRA. Actividad 1. Objetivo. Estudiar el enfoque DRA. Especificaciones. E1) Que el alumno entienda el modelo DRA Ejemplo de Resultados. En la formación del alumno es significativo, que éste estudie, comprenda y utilice diversos modelos o metodologías relacionadas con el desarrollo de los diferentes modelos de procesos existentes en la actualidad. Uno de estos es el Modelo de Desarrollo Rápido de Aplicaciones (DRA) o RAD (Rapid Application Development), que es un proceso de desarrollo de software, creado inicialmente por James Martin en 44

45 1980. El método comprende el desarrollo iterativo, la construcción de prototipos y el uso de utilidades CASE, enfatizando un ciclo de desarrollo extremadamente corto utilizando un enfoque de construcción basado en componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un "sistema completamente funcional" dentro de periodos cortos de tiempo. E2) Que el alumno realice una investigación y redacción de las etapas que comprende el modelo DRA. Ejemplo de Resultados. Modelado de gestión: el flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: Qué información conduce el proceso de gestión? Qué información se genera? Quién la genera? A dónde va la información? Quién la procesa? Modelado de datos: el flujo de información definido como parte de la fase de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos. Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario que implemente una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicación entre los objetos. Generación de aplicaciones: El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software. Pruebas de entrega: Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo. 45

46 Fig. 4.2 Modelo DRA E3) Que el alumno realice una investigación sobre las ventajas y desventajas del modelo DRA. Ejemplo de Resultados. Ventajas de RAD Comprar puede ahorrar dinero en comparación con construir. Los entregables pueden ser fácilmente trasladados a otra plataforma. El desarrollo se realiza a un nivel de abstracción mayor. Visibilidad temprana. Mayor flexibilidad. Menor codificación manual. Mayor involucramiento de los usuarios. Posiblemente menos fallas. Posiblemente menor costo. Ciclos de desarrollo más pequeños. Interfaz gráfica estándar. Desventajas de RAD Comprar puede ser más caro que construir. 46

47 Costo de herramientas integradas y equipo necesario. Progreso más difícil de medir. Menos eficiente. Menor precisión científica. Riesgo de revertirse a las prácticas sin control de antaño. Más fallas. Prototipos pueden no escalar. Funciones reducidas (por "timeboxing"). Dependencia en componentes de terceros. E3) Con base en un análisis crítico-objetivo el alumno debe resumir las condiciones apropiadas para la aplicación de modelos DRA. RAD se aplica cuando: La aplicación funcionará de manera independiente. Se pueden usar principalmente bibliotecas existentes. Desempeño no crítico. Distribución limitada, interna o vertical. Alcance del proyecto limitado. Confiabilidad no crítica. El sistema puede dividirse en muchos módulos independientes. El producto está dirigido a un mercado altamente especializado. El proyecto cuenta con fuertes limitantes de tiempos parciales La tecnología requerida tiene más de un año en el mercado. E4) Resuelva el siguiente cuestionario: 1. Qué es el Modelo de Desarrollo Rápido de Aplicaciones? 2. Cuáles son las Fases del Modelo del Desarrollo Rápido de Aplicaciones? 3. Mencione algunas de las características del Modelo de Desarrollo rápido de Aplicaciones? 4. Cuáles son las ventajas del modelo de Desarrollo Rápido de Aplicaciones? 5. Cuáles son las desventajas del modelo de Desarrollo Rápido de Aplicaciones? 4.3 Planeación Didáctica del Modelo de Métodos Formales. Tiempo. Se propone cubrir el tema en un intervalo de 4 hrs. 47

48 Contenido. Introducción Modelo de Métodos Formales Formalismos matemáticos usados en el Modelo de Métodos Formales Materiales. Referencias Bibliográficas. [1] Zohar Manna y Richard Waldinger. The Logical Basis for Computer Programming. Vol 1: Deductive Reasoning. [2] Helmut Ehrig y Bernd Mahr. Fundamental of Algebraic Specification. Equations and Initial Semantics. Springer-Verlag [3] Z. Manna y A. Pnueli. The Temporal Logic of Reactiveand Concurrent Systems. [4] L. Lamport y N. Lynch. Distributed Computing: Models and Methods. Handbook of Theoretical Computer Science. Elsevier Publishers B.V Recursos Electrónicos. [5] Formal Methods 4.4 Propuesta de Actividades del Modelo de Métodos Formales. Actividades Propuestas. Las acciones que se llevarán a cabo tienen como fin incentivar la utilización del modelo de Métodos Formales. 48

49 Actividad 1. Objetivo. Estudiar el modelo de Métodos Formales. Especificaciones. E1) Que el alumno realice una investigación y redacción sobre el modelo de Métodos Formales. Ejemplo de Resultados. Los métodos formales son un conjunto de tendencias de desarrollo de software en donde la especificación, verificación y diseño de componentes se realiza mediante notaciones, lenguajes, herramientas y técnicas basadas en teorías con sólido fundamento matemático completamente funcional" dentro de periodos cortos de tiempo. El uso de notaciones y lenguajes formales permite plantear de manera clara los requerimientos de un sistema, a través de generar especificaciones que definen el comportamiento en términos del qué debe hacer y no del cómo lo hace. Gracias al proceso correcto de especificación, propiedades derivadas de cada módulo, se pueden verificar mediante técnicas de razonamiento asociadas a los modelos formales, tales como, probadores de teoremas y verificadores de modelos. A partir de las especificaciones, la implementación de un sistema puede ser generada de manera casi automática. En este proceso, denominado diseño formal, es necesario garantizar que cada nivel de abstracción generado, cumpla con las propiedades verificadas en las abstracciones de más alto nivel. En los procesos de especificación, los lenguajes de especificación formal más conocidos y utilizados son Z y VDM, los cuales han sido recomendados como un estándar oficial para la especificación en la construcción de sistemas de software. E2) Que el alumno realice una investigación sobre en qué tipos de formalismo matemáticos se basan los Modelos de Métodos Formales. Ejemplo de Resultados. Los métodos formales son un conjunto de tendencias de desarrollo de software en donde la especificación, verificación y diseño de componentes se realiza mediante notaciones, lenguajes, herramientas y técnicas basadas en teorías con sólido fundamento matemático completamente funcional" dentro de periodos cortos de tiempo. 49

50 El término formal queda caracterizado por la categoría de modelos matemáticos utilizados. Ejemplos de formalismos son: lógica de primer orden, álgebras, redes de Petri y lógica temporal. Los formalismos basados en lógica de primer orden y teoría de conjuntos permiten especificar el sistema mediante un concepto formal de estado y operaciones sobre estados. Con este propósito, datos y relaciones/funciones se describen en detalle y sus propiedades se expresan en lógica de primer orden. La semántica de los lenguajes está basada en la teoría de conjuntos. Durante el diseño e implementación del sistema, los elementos descritos matemáticamente pueden modificarse preservando las características esenciales de la especificación inicial. Los formalismos algebraicos proponen la descripción de estructuras de datos estableciendo el nombre de los diferentes conjuntos de datos, funciones básicas y propiedades. No hay concepto de estado modificable en el tiempo. Las propiedades se escriben mediante fórmulas, generalmente, ecuaciones. Diferentes modelos semánticos se han propuesto para caracterizarlas especificaciones algebraicas: modelos iniciales, finales y laxos. Los modelos iniciales identifican términos cuya igualdad puede ser probada desde los axiomas. Los modelos finales identifican términos diferentes cuya desigualdad puede ser probada desde sus axiomas y los modelos laxos identifican todas las álgebras cuyos elementos pueden denotarse con términos sin variables. Para describir sistemas (de estructuras de datos) se propone una amplia gama de operadores de composición y parametrización. Los formalismos basados en redes de Petri establecen la noción de estado de un sistema mediante lugares que pueden contener marcas. Un conjunto de transiciones (con pre y post-condiciones) describe la evolución del sistema entendida como consumo y producción de marcas en varios puntos de la red. Existe una extensa literatura sobre las redes de Petri y sus caracterizaciones semánticas: semántica de entrelazado y semántica basada en concurrencia real. Los formalismos basados en lógica temporal se usan para describir sistemas concurrentes y reactivos. Un aspecto común asociado a las diferentes lógicas temporales es la noción de tiempo y estado. Una especificación escrita en lógica temporal describe las secuencias admisibles de estados (incluyendo estados concurrentes) para el sistema especificado. E3) Con base en un análisis crítico-objetivo el alumno debe resumir las condiciones apropiadas para utilizar cada formalismo matemático. E4) Resuelva el siguiente cuestionario: 1. Qué es el Modelo de Métodos Formales? 2. Cuál es la diferencia del Método Formal basado en lógica de primer orden y aquel basado en lógica temporal? 50

51 3. Cuál es la diferencia del Método Formal basado en lógica de primer orden y aquel basado en redes de Petri? 4. Cuál es la diferencia del Método Formal basado en álgebras y aquel basado en redes de Petri? 5. Cuál es la diferencia del Método Formal basado en redes de Petri y aquel basado en lógica temporal?. Recursos. R1) Consultar bibliografía. 4.5 Referencias Capítulo 4 [1] James Martin Rapid application development Macmillan Publishing Co., Inc. Indianapolis, IN, USA 1991 [2] Beynon-Davies P.1; Carne C.1; Mackay H.2; Tudhope D. Rapid application development (RAD): an empirical review European Journal of Information Systems, Volume 8, Number 3, 1 Palgrave MacmillanSeptember 1999, pp (13) [3] Carlo Ghezzi, Mehdi Jazayeri y Dino Mandrioli. Fundamentals of Software Engineering. Prentice Hall International, [4] Pressman Roger S. Ingeniería del Software, Un Enfoque Práctico. Mc Graw Hill. [5] Ian Sommerville. Ingeniería de Software Addison Wesley. 51

52 Capítulo 5 Herramientas de Ingeniería de Software Asistida por Computadora María Josefa Somodevilla García María de la Concepción Pérez de Celis Herrero María del Rocío Boone Rojas Introducción En términos generales, la Ingeniería de Software Asistida por Computadora (CASE) identifica al software que se utiliza para asistir a las actividades del proceso del software, tales como la Ingeniería de Requerimientos, el diseño, el desarrollo de programas y las pruebas. De tal forma que las herramientas CASE incluyen, herramientas de diseño, compiladores, herramientas para construcción de sistemas, etc. 52

53 La tecnología CASE proporciona ayuda al proceso del software al automatizar algunas de sus actividades y al proporcionar información acerca del proceso desarrollado. Esto permite algunas mejoras en la calidad y productividad del software. En el presente capítulo se revisa el objetivo y el concepto de Herramientas de Ingeniería de Software Asistida por Computadora. Para los componentes de CASE, se incluye una taxonomía de herramientas CASE y ejemplos específicos. Como caso de estudio se considera, el entorno de herramientas integradas para el diseño, administración y desarrollo de bases de datos SQL, MySqlWorkbench. 5.1 Propuesta de Actividades de Motivación y Diagnóstica para el Estudio de las Herramientas de Ingeniería de Software Asistida por Computadora. Actividades Propuestas. Actividad 1 Objetivo. Que el alumno identifique a priori algunas de las ventajas inherentes de utilizar Herramientas de la Ingeniería de Software Asistida por Computadora. Especificaciones. E1) Desarrolla el diseño de una base de datos elemental, mediante el modelo ER y por medio de las facilidades de diseño o de dibujo de una herramienta de edición básica. Ejemplo. Considera la siguiente porción de una Base de Datos para la Administración de una cadena de Talleres-Mecánicos. Los talleres se identifican mediante un Número de Taller (NTall), tienen un Supervisor y se ubican en una Ciudad. Cada taller puede tener varios Mecánicos, los cuales se identifican por una clave NMec, y se registra su nombre y edad. Los mecánicos tienen varias Especialidades, tales como (Afinación, Ajuste de Motor, Sistema Hidráulico, ) pero con diferentes años de experiencia. 53

54 Ejemplo de Resultados. Fig. 5.1 Diseño ER, Base de Datos Mecánicos-Talleres. E2) Resuelve el siguiente cuestionario: 1. Consideras que la herramienta que utilizaste fue la más adecuada para apoyar el proceso de diseño de tu base de datos? 2. Por medio de esta herramienta y con respecto al diseño de tu base de datos, se distinguen claramente las entidades, llaves, atributos y las relaciones de tu base de datos? 3. A partir del diseño ER de tu base de datos, podrías fácilmente traducirlo a un nivel lógico, posiblemente a tablas relacionales? Recursos. R1) Base de Datos Experimental posiblemente desarrollada en un curso paralelo o previo. R2) Procesador de Texto o herramienta equivalente con facilidades de diseño. 54

55 Actividad 2 Objetivo. Que el alumno identifique, a priori, algunas de las ventajas inherentes de utilizar Herramientas de la Ingeniería de Software Asistida por Computadora. Así como en este caso, el apoyo que pueden ofrecer en la formalización y documentación del proceso de desarrollo de un proyecto. Considera la siguiente porción del documento en [5], relacionado con la especificación de Requisitos funcionales mediante la técnica de casos de uso y para un sistema de gestión de un video club. Requisitos relacionados con el Almacenamiento de Información. RI 03 Objetivos asociados Requisitos asociados Descripción Información sobre cuentas de socios OBJ 02 Gestionar los socios RF 01 Alta de socio RF 02 Baja de socio RF 05 Alquiler de cinta de vídeo RF 08 Devolución de cintas de vídeo RF 09 Ingreso a cuenta RF 11 Consulta de un socio RF 12 Consulta de socios con pagos pendientes El sistema deberá almacenar la información correspondiente a las cuentas de los socios del vídeo club. En concreto: Datos específicos Saldo de la cuenta en cada momento Ingresos realizados en la cuenta, indicando fecha y cantidad Cargos realizados en la cuenta, indicando fecha, motivo y cantidad Pagos pendientes, indicando motivo que podrá ser alquiler no pagado o multa; en el caso de alquiler no pagado se debe indicar también la película alquilada y la fecha del alquiler Intervalo temporal sólo presente Estabilidad Comentarios Alta Un socio puede hacer ingresos a cuenta, por ejemplo para enviar a sus hijos por películas sin que éstos tengan que llevar dinero 55

56 Fig. 5.2 Diagrama de casos de uso del subsistema Gestión de socios Especificaciones. E1. Realiza la especificación anterior mediante las facilidades que te proporciona la herramienta que utilizaste para la actividad anterior. E2. Resuelve el siguiente cuestionario. 1. Consideras que la herramienta que utilizaste fue la más adecuada para apoyar la especificación de requisitos desarrollada mediante esta técnica? 2. Por medio de tu herramienta, y con respecto a la especificación realizada, se podría fácilmente dar seguimiento y durante el proceso de desarrollo del proyecto a los requisitos establecidos? 3. Por medio de esta especificación, podrías fácilmente, continuar con el proceso de desarrollo del proyecto? 56

57 5.2 Planeación Didáctica de los Antecedentes y Conceptos Básicos de Ingeniería de Software Asistida por Computadora. Tiempo. Se propone cubrir el tema en un intervalo de 4 hrs. Contenido. 5. El Concepto CASE. 6. Componentes básicos de CASE. 7. Taxonomía de Herramientas CASE. 8. Caso de Estudio. Introducción a una Herramienta de Ingeniería de Software Asistida por Computadora. Materiales. Referencias Bibliográficas. [1] Capítulo 29 Pressman Roger S. Ingeniería de Software, Un Enfoque Práctico. McGraw Hill. [2] Pags. 11,79-82, 225,280. Ian Sommerville. Ingeniería de Software Addison Wesley. Recursos Electrónicos. [3]López Quesada Juan Antonio. Herramientas CASE Alguna herramienta CASE. Ejemplo.MySQLWorkbench 57

58 5.3 Desarrollo de las Actividades de Antecedentes y Conceptos Básicos de Ingeniería de Software Asistida por Computadora El Concepto CASE. Material de Referencia. De Pressman [2]: El mejor taller de un artesano -sea mecánico, carpintero o ingeniero del software- tiene tres características fundamentales: (1) una colección de herramientas útiles que le ayudarán en todos los pasos de la construcción de un producto; (2) una disposición organizada que permitirá hallar rápidamente las herramientas y utilizarlas con eficacia; y (3) un artesano calificado que entienda la forma de utilizar las herramientas de manera eficaz. Ahora es cuando los ingenieros del software reconocen que necesitan más herramientas y más variadas, junto con un taller eficiente y organizado en el que puedan ubicarlas. El taller de ingeniería del software se denomina un entorno de apoyo integrado a proyectos y el conjunto de herramientas que llena ese taller se denomina ingeniería del software asistida por computadora (CASE). CASE proporciona al ingeniero la posibilidad de automatizar actividades manuales y de mejorar su visión general de la ingeniería. Al igual que las herramientas de ingeniería y de diseño asistidos por computadora que utilizan los ingenieros de otras disciplinas, las herramientas CASE ayudan a garantizar que la calidad se diseñe antes de llegar a construir el producto. En [3] se establece: Objetivos de la tecnología CASE. INCREMENTAR Productividad del equipo. Calidad del Software. Reusabilidad del software. REDUCIR Costes de desarrollo y mantenimiento. AUTOMATIZAR Gestión del proyecto. Desarrollo del software. mantenimiento del software (Incluyendo la automatización y estandarización de la documentación y de su mantenimiento) AUTOMATIZACIÓN DEL DESARROLLO DE SW.: Productividad del equipo Calidad del Software 58

59 INCREMENTAR Reusabilidad del software. REDUCIR Costos de desarrollo y mantenimiento. AUTOMATIZAR/SIMPLIFICAR Gestión del proyecto. Desarrollo del sw. (permitir aplicación met. estructuradas; prototipos; desarrollo visual ) Mantenimiento del software (Incluyendo la automatización y estandarización de la documentación y de su mantenimiento) Concepto CASE (Computed Aided Software Engineering) Conjunto de herramientas y métodos asociados que proporcionan asistencia automatizada en el proceso de desarrollo del software a lo largo de su ciclo de vida. Gestión del proyecto. (planificación, estimación y control) Desarrollo del software. (análisis, diseño, implementación, validación) Mantenimiento del software. Actividades Propuestas. Actividad 1 Objetivo. Que el alumno identifique el concepto de Ingeniería de Software Asistida por Computadora. Especificación. E1) Revisa las referencias [1], [2] y realiza tu propia investigación sobre el concepto de ingeniería de software asistida por computadora. -Elabora un mapa conceptual que involucre los principales elementos que involucra el concepto de ingeniería de software asistida por computadora. Ejemplo tipo de Resultados. (Ver mapa conceptual en Programa de curso de la asignatura de Ingeniería de Software, Modelo MUM). Recursos. R1) Referencias [1] y [2] 59

60 R2) Conexión a Internet Componentes básicos de CASE. Material de Referencia. Revisar Referencias [1] y [2]. De acuerdo a López-Quesada [3]: Fig. 5.3 Componentes CASE Interfaz gráfica. Editor de textos y gráficos. BD de soporte (BD del proyecto, depósito o repositorio CASE) Mecanismos de control para: acceso a componentes. (datos, código, documentos, dispositivos) Compatibilidad de las herramientas. Consistencia de los productos. Detección de olvidos. Trazado de modificaciones. Donde la BD de soporte: 60

61 Reúne las funciones de: Catálogo central de archivos y BD s. Diccionario de datos y procesos. Biblioteca de programas y documentación. y es la base para: La integración de herramientas. El mantenimiento de la integridad del sistema. La coordinación y compartición de información entre usuarios, con controles de seguridad y privilegios de acceso. El control de cambios y versiones. La estandarización de la documentación. La reutilización del software. La gestión del proyecto (incluyendo auditorías). La incorporación a otro sistema informático. De una forma más específica en [1] se indica: Aunque se pueden obtener beneficios individualmente de las herramientas CASE que abarcan actividades de ingeniería del software por separado, la verdadera potencia de CASE solamente se puede lograr mediante la integración. Entre los beneficios del CASE integrado (I-CASE) se incluyen: (1) una transferencia regular de información (modelos, programas, documentos, datos) entre una herramienta y otra, y entre un paso de ingeniería y el siguiente; (2) una reducción del esfuerzo necesario para efectuar actividades globales tales como la gestión de configuración de software, el control de calidad y la producción de documentos; ( 3 ) un aumento del control del proyecto que se logra mediante una mejor planificación, monitorización y comunicación; (4) una mejor coordinación entre los miembros del personal que estén trabajando en grandes proyectos de software Taxonomía de Herramientas CASE. Material de Referencia. De acuerdo a [1] Existe un cierto número de riesgos que son inherentes siempre que se intenta efectuar una categorización de las herramientas CASE. Existe una sutil implicación que consiste en que para crear un entorno CASE efectivo se deberán implementar todas las categorías de herramientas esto no es ni sencillo, ni cierto-. Cuando hay personas que creen que una herramienta pertenece a una categoría, se puede crear cierta confusión (o contradicción) al ubicar una herramienta específica dentro de otra categoría. Es posible que algunos lectores piensen que se ha omitido una categoría completa -e1iminando por tanto un conjunto de herramientas completo e incluirlo así en el entorno CASE global-. Además, 61

62 una categorización sencilla tiende a ser plana - esto es, no se muestra la interacción jerárquica de las herramientas o las relaciones que existen entre ellas-. A pesar de estos riesgos, es necesario crear una taxonomía de herramientas CASE, para comprender mejor la amplitud de CASE y para apreciar mejor en donde se pueden aplicar estas herramientas dentro del proceso del software. Las herramientas CASE se pueden clasificar por su función, por su papel como instrumentos para administradores o personal técnico, por su utilización en los distintos pasos del proceso de ingeniería del software, por la arquitectura del entorno (hardware y software) que les presta su apoyo, o incluso por su origen o costo. La clasificación de la taxonomía que se presenta a continuación utiliza como criterio principal la función. Herramientas de ingeniería de procesos de negocio. Modelado de procesos y herramientas de gestión. Modelado de procesos y herramientas de gestión. Herramientas de análisis de riesgos. Herramientas de gestión de proyectos. Herramientas de seguimiento de requisitos. Herramientas de métricas y de gestión. Herramientas de documentación. Herramientas de software de sistema. Herramientas de control de calidad. Herramientas de gestión de bases de datos del proyecto. Herramientas de gestión de configuración de software. Herramientas de análisis y diseño. Herramientas PRO/SIM. (De construcción de prototipos y simulación). Herramientas de desarrollo y diseño de interfaz. Herramientas de construcción de prototipos. Herramientas de programación. Herramientas de desarrollo de Webs. Herramientas de integración y pruebas. Herramientas de análisis estático. Herramientas de análisis dinámico. Herramientas de gestión de pruebas. Herramientas de pruebas cliente/servidor. Herramientas de reingeniería. En la taxonomía de [3] se incluyen ejemplos específicos dentro de algunas de sus categorías: Herramientas de análisis y diseño. 62

63 Permiten crear y verificar DFD s, diagramas E/R, de clase, de estructura... Herramientas de prototipado: Diseñadores de pantallas Generadores de menús Generadores de informes Lenguajes de especificación ejecutables Ejemplos: DESIGNER/2000 de ORACLE EASY CASE de Evergreen Rational ROSE EXCELERATOR de Intersolv OBJECT MAKER de Mark IV. OMTool de GTE. PARADIGM Plus de Platinum SILVERRUN de CSA Research SYSTEM Architect de PopkinSofware& Systems Herramientas de acuerdo a su funcionalidad. Herramientas de gestión de proyectos ayudan a la planificación y seguimiento del proyecto Planificación: agenda de desarrollo. Estimación: costes, duración, esfuerzo. Control: productividad, calidad. Herramientas de análisis y diseño. Herramientas de prototipado y simulación. Herramientas de programación. Editores dirigidos por la sintaxis (cabeceras de subrutinas, palabras clave, indentación, nomenclatura de variables,...) Generadores de estructuras de programas. Entornos integrados de desarrollo para soporte de un lenguaje (editor, compilador, depurador). Herramientas de integración y pruebas. Analizadores estáticos. Depuradores. Generadores de datos. Comparadores (e.g. de archivos). Herramientas de soporte. Herramientas de mantenimiento. Ingeniería inversa. 63

64 Reingeniería. En [2] se presenta un ejemplo ilustrativo de una posible clasificación de la tecnología CASE como ayuda para el proceso del software. Se puntualiza que la tecnología CASE proporciona ayuda automatizada a los procesos del software. Las herramientas CASE ayudan a las actividades individuales del proceso; los bancos de trabajo ayudan a un conjunto de actividades relacionadas; los entornos ayudan a todas o a la mayoría de las actividades del proceso del software. Actividad 1 Fig. 5.4 Herramientas, Bancos de Trabajo y Entornos. Objetivo. Que el alumno organice una versión propia de una taxonomía de herramientas CASE, como resultado de la consulta de al menos tres referencias. Especificaciones. E1. Revisa la taxonomía de herramientas CASE en las referencias [1] [2] [3]. 64

65 E2. Organiza en una tabla una taxonomía que resulte de la unión de los diferentes tipos de herramientas CASE que se consideran en las taxonomías de las referencias [1] [2] y [3]. Ejemplo de resultados. Tomar como referencia alguna de las taxonomías incluidas en [1] [2] y [3]. Actividad 2 Objetivo. Que el alumno conozca que existen muy diversos tipos de herramientas CASE y que pueden ser de diferentes tipos, propósitos y alcances. Especificaciones. E1) Realiza una búsqueda por Internet y toma como referencia la taxonomía de herramientas CASE que se ha revisado en este capítulo. Desarrolla una breve documentación sobre cinco herramientas de diferentes tipos. Incluye al menos la siguiente información: Nombre. Empresa. Propósito. Puedes organizar tus resultados en una tabla. Ejemplo de Tipo de Resultados. Nombre Empresa Propósito Herramienta MySQLWorkbench. Oracle. Entorno integrado de herramientas para el diseño, administración y desarrollo de bases de datos SQL. Recursos. R1) Conexión a internet. 65

66 Actividad 3 Objetivo. Que el alumno esté informado sobre las facilidades básicas de un entorno integrado / banco de Trabajo CASE. Especificaciones. E1) Toma como referencia la investigación realizada en la actividad anterior, selecciona un entorno integrado de herramientas CASE que sea de tu interés, realiza un breve reporte (3-5 cuartillas) sobre sus características generales y facilidades básicas. Ejemplo de Tipo de Resultados. (Complementar información de Caso de Estudio de la Sig. sección) 5.3.4Caso de Estudio. Introducción a una Herramienta de Ingeniería de Software Asistida por Computadora. Se propone revisar las facilidades básicas y a nivel de introducción de alguna herramienta de Ingeniería de Software Asistida por Computadora. Ej. Para el diseño de Bases de Datos, Para Especificación de Requisitos/ Casos de Uso, Generador de Reportes, entre otros. Ejemplo. Introducción al entorno de herramientas MySQLWorkbench para el caso de diseño de bases de Datos. Se propone revisar las características generales del producto, Fig y a continuación ofrecer un panorama general de las facilidades básicas para el diseño de base de datos de la herramienta, Fig

67 Fig. 5.5Workbench Central. Fig. 5.6 Herramientas para diseño visual de bases de datos en MysqlWorkbench. 67

68 Actividad 1. Objetivo. Que el alumno realice una experimentación básica con alguna herramienta CASE, en este caso para el diseño de bases de datos mediante las herramientas de Mysql Workbench. Especificaciones. E1. Considera la base de datos experimental cuyo diseño desarrollaste en la actividad 1 de la Sección 5.1. E2. Desarrolla el diseño de tu base de datos experimental mediante las facilidades para el diseño de bases de datos de Mysql Workbench. 5.4 Comentarios, Conclusiones y Actividades Complementarias sobre los Antecedentes y Conceptos Básicos de Ingeniería de SoftwareAsistida por Computadora. -Se propone dar continuidad a las actividades de investigación y experimentación realizadas previamente. -Se propone continuar experimentando con la herramienta CASE que se ha abordado como caso de estudio. -Se propone realizar investigación y experimentación complementaria sobre otro tipo de herramientas CASE más especializadas, tales como para la Admon. De Proyectos o Ingeniería Web. -Realizar una discusión grupal sobre las posibles ventajas del desarrollo de proyectos individuales y/o grupales mediante el apoyo de la tecnología CASE. 5.5 Referencias, Capítulo 5 Referencias Bibliográficas. [1] Capítulo 29 / 31 Pressman Roger S. Ingeniería de Software, Un Enfoque Práctico. McGraw Hill. 68

69 [2] Pags. 11,79-82, 225,280. Ian Sommerville. Ingeniería de Software Addison Wesley. Recursos Electrónicos. [3]López-Quesada, Juan Antonio. Herramientas CASE [4] MySQL Workbench [5] Domínguez D., R. García. Ejemplo de Casos de Uso, Gestión de un Video Club. 69

70 Capítulo 6 Modelos Ágiles de Procesos. Josefina Guerrero García Juan Manuel González Calleros Introducción La ingeniería de software ha evolucionado en los últimos años y se ha adaptado al entorno dinámico donde es usada y como tal sus métodos han evolucionado. Es ahí donde nacen los métodos ágiles que promueven, entre otras cosas, la adaptación constante y efectiva a los cambios que ocurren con las necesidades del cliente. Este capítulo introduce brevemente los conceptos de los métodos ágiles como una invitación al alumno a descubrirlos a lo largo del curso. El docente tiene como objetivo motivar la importancia actual que tienen los métodos ágiles y que favorecen la retención de los conceptos relevantes al tema. La asignación de actividades dinámicas que ayuden a retener los conceptos aquí presentados es el objetivo de esta unidad. El alumno se tendrá que involucrar en las actividades grupales e individuales de tal forma que vaya adquiriendo el conocimiento asociado a los métodos ágiles. En el presente capítulo se propone una serie de actividades de aprendizaje para que el docente pueda desarrollar en su clase los siguientes aspectos: 70

71 o Modelos Ágiles de Proceso o Programación Extrema o Metodologías Cristal o Scrum 6.1 Propuesta de actividades de motivación y diagnóstica para el estudio de modelos ágiles de proceso. Actividades Propuestas. Actividad 1. Identificación de limitantes de métodos actuales de ingeniería de software Objetivo. El alumno será capaz de identificar las limitantes de los métodos de desarrollo de software tradicionales y proponer mejoras. Especificaciones. Plantear un caso de estudio simple, donde sean muy notorias las limitantes del uso de un método tradicional. Dar oportunidad al alumno a la reflexión considerando el conocimiento ya adquirido sobre procesos de desarrollo de software usando una lista de fallas en el software para que puedan identificar las causas de las fallas. Ver video de Ariane 5. Disponible en El 4 de junio de 1996, el primer vuelo de la nueva Agencia Aeroespacial Europea lanzó el cohete Ariane 5, mismo que falló poco después del lanzamiento, lo que resultó en una pérdida estimada de mil quinientos millones de dólares. El problema: 71

72 La altitud y trayectoria del cohete es medía por un equipo de referencia inercial computarizado. Este transmitía los comandos a los motores para mantener la altitud y la dirección. a. El software falló y este sistema y el sistema de soporte se apagaron b. Los comandos de diagnóstico fueron transmitidos a los motores lo cuales fueron interpretados como datos reales e hicieron girar el cohete a una posición extrema Falla de software: Un Fallo de software se produjo cuando se intentó hacer una conversión de un número de 64 bits de punto flotante, a un entero con signo de 16 bits, lo que hizo que se desbordara la memoria. a. No había manejador de excepciones asociado con la conversión de números. Por seguridad, ésto apagó la computadora. b. La aplicación de respaldo tenía el mismo error así que, también falló. Se pudo evitar la catástrofe El software que falló fue rehusado del sistema del Ariane 4. El cálculo computacional que falló no fue usado en el Ariane 5. Se tomaron decisiones en su momento: a. No quitar esta facilidad ya que podría producir errores no controlados b. No poner a prueba las excepciones de desbordamiento de memoria ya que el procesador estaba muy cargado. Por razones de fiabilidad, se pensaba que era deseable tener un poco de capacidad del procesador de repuesto c. En el Ariane 4 nunca se hubiera generado este error pues la velocidad nunca sería tan rápida como la del Ariane 5. La cadena de omisiones Esta funcionalidad del Ariane 4 no era necesaria en el Ariane 5 por lo tanto nunca fue un requerimiento. Dado que no era requerimiento nunca se probó su funcionalidad ni correcta operación durante las pruebas. La simulación nunca llego a este escenario ya que no estaba en la lista de pruebas. Lección aprendida Todo software debe ser revisado y probar que funcione No ejecutar software en sistemas críticos a menos que sea realmente necesario (por eso los aviones no llevan computadoras para controlar el avión, sino puros controles y sensores) Así como se prueba lo que el sistema debe hacer se debe probar lo escenarios donde el sistema hace lo que no debe hacer Tomar en cuenta todas las variantes de excepciones que pueden ocurrir y no recaer en el uso del gestor por default de excepciones En cálculos computacionales críticos, siempre tener clara la alternativa numérica a asignar en caso de error al sistema En la medida de la posibilidad hacer pruebas reales y no solo simulaciones 72

73 Mejorar el proceso de revisión incluyendo participantes externos y revisando todas las suposiciones que se hacen en el código El diseñador del Ariane 5 cometió un error elemental pero critico. Diseño un sistema complejo donde la falla de un componente simple lo hizo fallar. Errores muy graves pese a que el software estaba dirigido por método formal, rígido. Ahora el alumno debe identificar en los siguientes casos las causas posibles del error de software. Ejemplo de Resultados. 1. En febrero de 2008, problemas de software en el sistema automático de clasificación de equipajes en un aeropuerto importante, impidieron la partida de miles de pasajeros al no poder documentar su equipaje para sus respectivos vuelos Se informó que la falla se produjo durante una actualización de software, a pesar de la pre-prueba del mismo. El sistema continuó teniendo problemas en los meses siguientes. Pruebas no exhaustivas. 2. Informes de prensa en diciembre de 2007 indicaban que seguían ocurriendo problemas importantes de software en un nuevo sistema de nóminas ERP para un sistema escolar urbano. Se pensaba que en varias ocasiones, más de un tercio de los empleados, había recibido cheques de pago incorrectos, desde que el nuevo sistema se puso en marcha en enero, lo que dio lugar a pagos en exceso por 53 millones de dólares, además de otros pagos erróneos. El sindicato de trabajadores presentó una demanda contra el sistema escolar, se espera que el costo del sistema ERP aumente en un 40%, y la parte que no pertenece a la nómina del sistema de ERP se retrasó. Según los informes, pruebas inadecuadas han contribuido a los problemas. 3. En noviembre de 2007 un gobierno regional interpuso una demanda multimillonaria en contra de un proveedor de servicios de software, afirmando que èste "minimizó la calidad del software " de un gran sistema de información sobre justicia penal y que por lo tanto, el sistema no cumplía los requisitos. El vendedor también demandó a su subcontratista en el proyecto. Fallo de comunicación, ausencia de interacción con el cliente ya que seguramente al ser subcontratado no trabajaba directamente con los actores involucrados. 4. Según informes periodísticos, en abril de 2007, un problema de software contribuyó a un incendio de vagones de ferrocarril, en un importante sistema de metro. Se comunicó que el software no funcionó como era de esperarse para detectar y prevenir el exceso de consumo de energía en los equipos de un vagón de pasajeros nuevo, ocasionando un sobrecalentamiento y fuego en dicho vagón, 73

74 la consecuente evacuación y el cierre de parte del sistema. Falta de pruebas, liberación temprana del sistema. E1) Identificar problemas a partir de la lista arriba descrita Recursos. R1) Caso de estudio de experiencia de desarrollo de software fallida. Material descriptivo de métodos tradicionales de ingeniería de software. Lista de errores de software. 6.2 Planeación Didáctica de modelos agiles de proceso. Tiempo. Se propone cubrir el tema en un intervalo de 5 hrs. 2 h. para la introducción a los métodos ágiles (sección x.2.3) 2 h. para la descripción de los diferentes procesos (sección x.2.4) 1h. para consolidar el conocimiento adquirido (sección x.2.5) Contenido. 9. Modelo Ágiles de proceso 10. Programación Extrema 11. Cristal 12. Scrum 13. Melé Materiales. Texto en este capítulo. Metodos-Agiles.PDF nerur.pdf carlos-reynoso-metodos-agiles-academia.ppt Referencias Bibliográficas. [1] SridharNerur, RadhaKantaMahapatra, George Mangalaraj Challenges of migrating to agile methodologies Communications of the ACM - Adaptive complex enterprises Volume 48 Issue 5, May

75 [2] Desarrollo de Software mediante Metodologías Ágiles. [3] Capitulo1 Ken Schwaber, Mike Beedle Agile Software Development with Scrum Prentice Hall [4] Carlos Reynoso Métodos Ágiles en desarrollo de software UNIVERSIDAD DE BUENOS AIRES [7] GrigoriMelnik Microsoft p&p summit, 2007 Empirical Evidence Of Agile Methods 6.3 Desarrollo de las Actividades de Introducción a los métodos ágiles de la Ingeniería de Software Introducción a los modelos ágiles. Material de Referencia. Síntesis y extracción de [4]: Los modelos de los métodos clásicos difieren bastante en su conformación y en su naturaleza, pero exaltan casi siempre las virtudes del planeamiento y poseen un espíritu normativo. Comienzan con la licitación y el análisis completo de los requerimientos del usuario. Después de un largo período de intensa interacción con usuarios y clientes, los ingenieros establecen un conjunto definitivo y exhaustivo de rasgos, requerimientos funcionales y no funcionales. Esta información se documenta en forma de especificaciones para la segunda etapa, el diseño, en el que los arquitectos, trabajando junto a otros expertos en temas puntuales (como ser estructuras y bases de datos), generan la arquitectura del sistema. Luego los programadores implementan ese diseño bien documentado y finalmente, el sistema completo se prueba y se despacha. 75

76 Castigando sobre todo al modelo en cascada se ha publicado: Gran parte de los procedimientos actuales de adquisición de software reposan en el supuesto de que se puede especificar de antemano un sistema satisfactorio, obtener requisitos para su construcción, construirlo e instalarlo. Pienso que este supuesto es fundamentalmente equivocado y que muchos de los problemas de adquisición se originan en esta falacia. Descrédito de los procesos en cascada (1988) Department of Defense Standard 2167A), titled "Defense Systems Software Development MIL STD 498 "establish uniform requirements for software development and documentation." (1994) Crisis de confianza en los procesos regidos por metodologías prescriptivas con análisis completo de requerimientos y planificación detallada CMM, CMMI, Spice, Bootstrap, TickIt, ISO 9000 CMM no es una metodología ni un modelo en cascada, pero coincide con su espíritu Legislación negativa sobre conformidad con estándares de calidad Ante esa evidencia los expertos, en masa, aconsejaron el abandono de los métodos en cascada y las normativas fuertes. Trabajaron en sus propias alternativas dinámicas, iterativas, evolutivas y en suma, ágiles. Reforzado por el entorno donde se trabaja Nerur [1] expone: Software development methodologies are constantly evolving due to changing technologies and new demands from users. Today s dynamic business 76

77 environment has given rise to emergent organizations that continuously adapt their structures, strategies, and policies to suit the new environment 1. Such organizations need information systems that constantly evolve to meet their changing requirements but the traditional, plan-driven software development methodologies lack the flexibility to dynamically adjust the development process. A comienzos del siglo XXI ante el descrédito de los métodos tradicionales se daban las condiciones para los 17 proponentes de métodos ágiles se juntaran en marzo de 2001 en Salt Lake City para discutir los nuevos métodos. Lo que surgió de su reunión fue el Manifiesto Ágil de Desarrollo de Software. De donde surgen ideas como: De hecho, muchos de nosotros deseamos restaurar credibilidad a la palabra metodología. Queremos recuperar un equilibrio. Promovemos el modelado, pero no con el fin de archivar algún diagrama en un polvoriento repositorio corporativo. Promovemos la documentación, pero no cientos de páginas en tomos nunca mantenidos y rara vez usados. Planificamos, pero reconocemos los límites de la planificación en un entorno turbulento. Los individuos y la interacción por encima de los procesos y herramientas.la gente es el principal factor de éxito de un proyecto software. No se necesitan desarrolladores brillantes, sino desarrolladores que se adapten bien al trabajo en equipo. Así mismo, las herramientas (compiladores, depuradores, control de versiones, etc.) son importantes para mejorar el rendimiento del equipo, pero el disponer de más recursos que los estrictamente necesarios también puede afectar negativamente. El software que funciona por encima de la documentación abarcadora. Aunque se parte de la base de que el software sin documentación es un desastre, la regla a seguir es no producir documentos a menos que sean necesarios de forma inmediata para tomar un decisión importante. Estos documentos deben ser cortos y centrarse en lo fundamental. La colaboración con el cliente por encima de la negociación contractual. Se propone que exista una interacción constante entre el cliente y el equipo de desarrollo. Esta colaboración entre ambos será la que marque la marcha del proyecto y asegure su éxito. La respuesta al cambio por encima del seguimiento de un plan. La habilidad de responder a los cambios que puedan surgir a los largo del proyecto (cambios en los requisitos, en la tecnología, en el equipo, etc.) determina también el éxito o fracaso del mismo. Por lo tanto, la planificación no debe ser estricta puesto que hay muchas variables en juego, debe ser flexible para poder adaptarse a los cambios que puedan surgir. 1 Truex, D.P., Baskerville, R. and Klein, H. Growing systems in emergent organizations. Commun. ACM 42, 8 (Aug. 1999),

78 Aunque hay valor en los elementos a la derecha, valorizamos más los de la izquierda. Los principios que rigen a la comunidad de métodos ágiles: 1. Nuestra prioridad más alta es satisfacer al cliente a través de la entrega temprana y continua de software valioso. 2. Los requerimientos cambiantes son bienvenidos, incluso cuando llegan tarde en el desarrollo. Los procesos ágiles se pliegan al cambio en procura de una ventaja competitiva para el cliente. 3. Entregar con frecuencia software que funcione, desde un par de semanas hasta un par de meses, con preferencia por las escalas de tiempo más breves. 4. La gente de negocios y los desarrolladores deben trabajar juntos cotidianamente a través de todo el proyecto. 5. Construir proyectos en torno de individuos motivados. Darles la oportunidad y el respaldo que necesitan y procurarles confianza para que realicen la tarea. 6. La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo de desarrollo es mediante la conversación cara a cara. 7. El software que funciona es la medida primaria de progreso. 8. Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante indefinidamente. 9. La atención continua a la excelencia técnica enaltece la agilidad. 10. La simplicidad (el arte de maximizar la cantidad de trabajo que no se hace) es esencial. 11. Las mejores arquitecturas, requerimientos y diseños emergen de equipos que se auto organizan. 12. A intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo, y ajusta su conducta en consecuencia. Nerur [1] realza las diferencias entre métodos ágiles y tradicionales en el siguiente gráfico. 78

79 Los modelos ágiles se pueden describir como aquellos modelos que son lo suficientemente buenos, donde cumplen con las siguientes características: satisfacen un propósito, son inteligentes, son lo suficientemente precisos, son lo suficientemente detallados, aportan valor positivo y son lo más simple posible. Para poder tener más clara las ideas un modelo ágil es más eficiente que los modelos tradicionales, un prototipo de papel podría ser un modelo ágil, un dibujo de pizarra podría ser un modelo ágil, un diagrama de Visio puede ser un modelo ágil o un modelo de datos físicos podría ser un modelo ágil. El tipo de modelo, o herramienta con la que se creó en realidad no importa, lo importante es que el modelo sólo sea sólo lo suficientemente bueno para obtener su máximo provecho. El desarrollo ágil de software es un marco de trabajo conceptual de la ingeniería de software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen muchos métodos de desarrollo ágil; la mayoría minimiza riesgos desarrollando software en lapsos cortos de tiempo. El software desarrollado en una unidad de tiempo es llamado una iteración, la cual debe durar de una a cuatro semanas. Cada iteración del ciclo de vida incluye: planificación, análisis de requerimientos, diseño, codificación, revisión y documentación. Una iteración no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, pero la meta es tener un demo (sin errores) al final de cada iteración. Al final de cada iteración el equipo vuelve a evaluar las prioridades del proyecto. La mayoría de los equipos ágiles están localizados en una simple oficina abierta, a veces llamadas "plataformas de lanzamiento". La oficina debe incluir revisores, escritores de documentación y ayuda, diseñadores de iteración y directores de proyecto. Los métodos ágiles también enfatizan que el software funcional es la primera medida del progreso. 79

80 Actividades Propuestas. Actividad 1. Requerimientos para cambiar de un paradigma clásico a uno ágil Objetivo. Que el alumno proponga los cambios organizacionales necesarios para adoptar un proceso de desarrollo ágil. Especificación. E1) Llena la siguiente tabla en equipos de 4 indicando los cambios necesarios para adoptar un proceso iterativo. Cambio organizacional y en la administración Cambio en la gente Cambio en los procesos Cambio en la tecnología (técnicas y herramientas) Ejemplo tipo de Resultados. Cambio organizacional y en la administración Cultura organizacional Estilo de administración Forma organizacional Manejo del conocimiento de desarrollo de software Sistemas de recompensas Cambio en la gente Trabajo efectivo en equipo Alto nivel de competencias Relaciones con clientes compromiso, conocimiento, proximidad, confianza, respeto Cambio en los procesos Cambio de un proceso centralizado a uno guiado por características, centrado en la persona 80

81 Guiado por elementos como ser: corto, iterativo, evaluativo con énfasis en la adaptabilidad Manejo de proyectos grandes y escalables Selección del proceso ágil adecuado a la empresa Cambio en la tecnología (técnicas y herramientas) Revisar que herramientas y tecnología sean apropiadas Desarrollo de nuevas habilidades - Recursos. R1) Referencia [1] R2) Material de esta sección 6.4 Desarrollo de las actividades de métodos ágiles de la ingeniería de software PROGRAMACIÓN EXTREMA [extreme programming( XP)] Kent Beck [5] sentó las bases de los patrones de diseño y XP en XP es la primera metodología ágil y la que le dio conciencia al movimiento actual de metodologías ágiles, se centra en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en retroalimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios [6]. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico. Los principios y prácticas son de sentido común pero llevadas al extremo, de ahí proviene su nombre. Las características esenciales de XP se pueden organizar en: historias de usuario, roles, proceso y prácticas. A. Las Historias de Usuario [Tarjetas de historia (StoryCards)] Son la técnica utilizada para especificar los requisitos del software. Se trata de tarjetas de papel en las cuales el cliente describe brevemente las características que el sistema debe poseer, sean requisitos funcionales o no funcionales. Las tarjetas se usan para estimar prioridades, alcance y tiempo de realización; en caso de discrepancia, gana la estimación más optimista. El tratamiento de las historias de usuario es muy dinámico y flexible. Cada historia de usuario es lo suficientemente comprensible y delimitada para que los programadores puedan implementarla en unas semanas. Un ejemplo de ficha presenta los siguientes contenidos: fecha, tipo de actividad (nueva, corrección, mejora), prueba funcional, número de historia, prioridad técnica y del cliente, referencia a otra historia previa, riesgo, estimación técnica, descripción, notas y una lista de seguimiento con la 81

82 fecha, estado, cosas por terminar y comentarios. A efectos de planificación, las historias pueden ser de una a tres semanas de tiempo de programación (para no superar el tamaño de una iteración). Las historias de usuario son descompuestas en tareas de programación (taskcard) y asignadas a los programadores para ser implementadas durante una iteración. B. Roles XP Los roles de acuerdo con la propuesta original de Beck son: - Programador. El programador escribe las pruebas unitarias y produce el código del sistema. - Cliente. Escribe las historias de usuario y las pruebas funcionales para validar su implementación. Además, asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada iteración centrándose en aportar mayor valor al negocio. - Encargado de pruebas (Tester). Ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas. - Encargado de seguimiento (Tracker). Proporciona realimentación al equipo. Verifica el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, para mejorar futuras estimaciones. Realiza el seguimiento del progreso de cada iteración. - Entrenador (Coach). Es responsable del proceso global. Debe proveer guías al equipo de forma que se apliquen las prácticas XP y se siga el proceso correctamente. - Consultor. Es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto, en el que puedan surgir problemas. - Gestor (Big boss). Es el vínculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinación. C. Proceso XP Un proyecto XP tiene éxito cuando el cliente selecciona el valor de negocio a implementar basado en la habilidad del equipo para medir la funcionalidad que puede entregar a través del tiempo. El ciclo de desarrollo consiste en los siguientes pasos: 1. El cliente define el valor de negocio a implementar. 2. El programador estima el esfuerzo necesario para su implementación. 3. El cliente selecciona qué construir, de acuerdo con sus prioridades y las restricciones de tiempo. 4. El programador construye ese valor de negocio. 5. Vuelve al paso 1. En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. No se debe presionar al programador a realizar más trabajo que el estimado, ya que se perderá calidad en el software o no se cumplirán los plazos. De la misma forma el cliente tiene la obligación de manejar el ámbito de entrega del producto, para asegurarse que el sistema tenga el mayor valor de negocio posible con cada iteración. 82

83 El ciclo de vida ideal de XP consiste de seis fases: Exploración, Planificación de la Entrega (Release), Iteraciones, Producción, Mantenimiento y Muerte del Proyecto. Figura 1 Ciclo de vida de XP, fuente [8] D. Prácticas XP La principal suposición que se realiza en XP es la posibilidad de disminuir la mítica curva exponencial del costo del cambio a lo largo del proyecto, lo suficiente para que el diseño evolutivo funcione. Esto se consigue gracias a las tecnologías disponibles para ayudar en el desarrollo de software y a la aplicación disciplinada de las siguientes prácticas. Juego de Planeamiento. Busca determinar rápidamente el alcance de la versión siguiente, combinando prioridades de negocio definidas por el cliente con las estimaciones técnicas de los programadores. Éstos estiman el esfuerzo necesario para implementar las historias del cliente y éste decide sobre el alcance y la agenda de las entregas. Las historias se escriben en pequeñas fichas, que algunas veces se tiran. Cuando esto sucede, lo único restante que se parece a un requerimiento es una multitud de pruebas automatizadas, las pruebas de aceptación. Entregas pequeñas y frecuentes. Se produccioniza un pequeño sistema rápidamente, al menos uno cada dos o tres meses. Pueden liberarse nuevas versiones diariamente (como es práctica en Microsoft); se agregan pocos rasgos cada vez. Metáforas del sistema. El sistema de define a través de una metáfora o un conjunto de metáforas, una historia compartida por clientes, managers y programadores que orienta todo el sistema describiendo como funciona. Una metáfora puede interpretarse como una arquitectura simplificada. Diseño simple. El énfasis se deposita en diseñar la solución más simple susceptible de implementarse en el momento. Se eliminan complejidades innecesarias y código extra, y se define la menor cantidad de clases posible. No debe duplicarse el código. Prueba continua. El desarrollo está orientado por las pruebas. Los clientes ayudan a escribir las pruebas funcionales antes de que se escriba el código. El propósito del código real no es cumplir un requerimiento, sino pasar las pruebas. Las pruebas y el código son escritas por el mismo programador, pero la prueba debería realizarse sin intervención humana, y es a todo o nada. Hay dos clases de prueba: 1) la prueba unitaria, que verifica una sola clase, o un pequeño conjunto de clases y2) la prueba de aceptación que verifica todo el sistema, o una gran parte. 83

84 Refactorízación continua. Se refactoriza el sistema eliminando duplicación, mejorando la comunicación y agregando flexibilidad sin cambiar la funcionalidad La práctica también se conoce como Mejora Continua de Código o Refactorízación implacable. Programación en pares. Todo el código está escrito por pares de programadores. Dos personas escriben código en una computadora, turnándose en el uso del ratón y el teclado. El que no está escribiendo, piensa desde un punto de vista más estratégico y realiza lo que podría llamarse revisión de código en tiempo real. Los roles pueden cambiarse varias veces al día. Propiedad colectiva del código. Cualquiera puede cambiar cualquier parte del código en cualquier momento, siempre que escriba antes la prueba correspondiente. Integración continua. Cada pieza se integra a la base de código apenas está lista, varias veces al día. Debe correrse la prueba antes y después de la integración. Hay una máquina (solamente) dedicada a este propósito. Ritmo sostenible, trabajando un máximo de 8 horas por día. Antes se llamaba a esta práctica Semana de 40 horas. Dado que el desarrollo de software se considera un ejercicio creativo, se estima que hay que estar fresco y descansado para hacerlo eficientemente; con ello se motiva a los participantes, se evita la rotación del personal y se mejora la calidad del producto. Todo el equipo en el mismo lugar. El cliente debe estar presente y disponible a tiempo completo para el equipo. También se llama El Cliente en el Sitio. Como esto parecía no cumplirse, se especificó que el representante del cliente debe ser preferentemente un analista. Estándares de codificación. Se deben seguir reglas de codificación y comunicarse a través del código. Algunos practicantes se ponen de acuerdo en estilos de notación, indentación y nomenclatura, así como en un valor apreciado en la práctica, el llamado código revelador de intenciones. Espacio abierto. Es preferible una sala grande con pequeños cubículos o, mejor todavía, sin divisiones. Los pares de programadores deben estar en el centro. En la periferia se ubican las máquinas privadas. Reglas justas. El equipo tiene sus propias reglas a seguir, pero se pueden cambiar en cualquier momento. En XP se piensa que no existe un proceso que sirva para todos los proyectos; lo que se hace habitualmente es adaptar un conjunto de prácticas simples a las características de cada proyecto. El mayor beneficio de las prácticas se consigue con su aplicación conjunta y equilibrada puesto que se apoyan unas en otras. Esto se ilustra en la Figura 2, donde una línea entre dos prácticas significa que las dos prácticas se refuerzan entre sí. La mayoría de las prácticas propuestas por XP no son novedosas sino que en alguna forma ya habían sido propuestas en ingeniería del software e incluso demostrado su valor en la práctica. El mérito de XP es integrarlas de una forma efectiva y complementarlas con otras ideas desde la perspectiva del negocio, los valores humanos y el trabajo en equipo. 84

85 Figura 2 Las prácticas se refuerzan entre sí Metodologías Crystal [Crystal Methodologies (CM)] Las metodologías Crystal fueron creadas por el antropólogo de proyectos Alistair Cockburn en 1998.Se trata de un conjunto de metodologías para el desarrollo de software caracterizadas por estar centradas en las personas que componen el equipo (de ellas depende el éxito del proyecto) y la reducción al máximo del número de artefactos producidos. La familia Crystal dispone un código de color para marcar la complejidad de una metodología: cuanto más oscuro un color, más pesado es el método. Cuanto más crítico es un sistema, más rigor se requiere. El código cromático se aplica a una forma tabular elaborada por Cockburn que se usa en muchos MAs para situar el rango de complejidad al cual se aplica una metodología. En la figura se muestra una evaluación de las pérdidas que puede ocasionar la falla de un sistema y el método requerido según este criterio. Los parámetros son Comodidad (C), Dinero Discrecional (D), Dinero Esencial (E) y Vidas (L). En otras palabras, la caída de un sistema que ocasione incomodidades indica que su nivel de criticalidad es C, mientras que si causa pérdidas de vidas su nivel es L. Los números del cuadro indican el número de personas afectadas a un proyecto, ±20%. Los métodos se llaman Crystal evocando las facetas de una gema: cada faceta es otra versión del proceso, y todas se sitúan en torno a un núcleo idéntico. Hay cuatro variantes de metodologías: Crystal Clear ( Claro como el cristal ) para equipos de 8 o menos integrantes; Amarillo, para 8 a 20; Naranja, para 20 a 50; Rojo, para 50 a 100. Se promete seguir con Marrón, Azul y Violeta. 85

86 Figura 3 Familia de CrystalMethods [Crystalmethodologies.org] La más exhaustivamente documentada es Crystal Clear (CC), puede ser usado en proyectos pequeños de categoría D6, aunque con alguna extensión se aplica también aniveles E8 a D10. El otro método elaborado en profundidad es el Naranja, apto para proyectos de duración estimada en 2 años, los otros dos aún se están desarrollando. Como casi todos los otros métodos, CC consiste en valores, técnicas y procesos. A. Valores de cristal clear Los siete valores o propiedades de CC [9] son: 1. Entrega frecuente. Consiste en entregar, con frecuencia, software a los clientes con frecuencia, no solamente en compilar el código. La frecuencia dependerá del proyecto, pero puede ser diaria, semanal, mensual o lo que fuere. La entrega puede hacerse sin despliegue, si es que se consigue algún usuario cortés o curioso que suministre realimentación. 2. Comunicación osmótica. Todos juntos en el mismo cuarto. Una variante especial es disponer en la sala de un diseñador senior; eso se llama Experto al Alcance de la Oreja. Una reunión separada para que los concurrentes se concentren mejor es descrita como El Cono del Silencio. 3. Mejora reflexiva. Tomarse un pequeño tiempo (unas pocas horas cada algunas semanas o una vez al mes) para pensar bien qué se está haciendo, cotejar notas, reflexionar, discutir. 4. Seguridad personal. Hablar cuando algo molesta: decirle amigablemente al manager que la agenda no es realista, o a un colega que su código necesita mejorarse, o que sería conveniente que se bañase con mayor frecuencia. Esto es importante porque el equipo puede descubrir y reparar sus debilidades. No es provechoso encubrir los desacuerdos con gentileza y conciliación. Técnicamente, estas cuestiones se han caracterizado como una importante variable de confianza y han sido estudiadas con seriedad en la literatura. 5. Foco. Saber lo que se está haciendo y tener la tranquilidad y el tiempo para hacerlo. Lo primero debe venir de la comunicación sobre dirección y prioridades, típicamente con el Patrocinador Ejecutivo. Lo segundo, de un ambiente en que la gente no se vea compelida a hacer otras cosas incompatibles. 86

87 6. Fácil acceso a usuarios expertos. No hay un dogma de vida o muerte sobre esto, como sí lo hay en XP. Un encuentro semanal o semi-semanal con llamadas telefónicas adicionales parece ser una buena pauta. Otra variante es que los programadores se entrenen para ser usuarios durante un tiempo. El equipo de desarrollo, de todas maneras, incluye un Experto en Negocios. 7. Ambiente técnico con prueba automatizada, management de configuración e integración frecuente. Microsoft estableció la idea de los builds(se refiere tanto al proceso de conversión de archivos de código fuente en los artefactos de software independiente(s)que se pueden ejecutar en una computadora, o el resultado de hacerlo) cotidianamente, y no es una mala práctica. Muchos equipos ágiles compilan e integran varias veces al día. B. Técnicas En cuanto a las técnicas, se favorecen: 1. Entrevistas de proyectos. Se suele entrevistar a más de un responsable para tener visiones más ricas. La idea es averiguar cuáles son las prioridades, obtener una lista de rasgos deseados, saber cuáles son los requerimientos más críticos y cuáles los más negociables. Si se trata de una actualización o corrección, saber cuáles son las cosas que se hicieron bien y merecen preservarse y los errores que no se quieren repetir. 2. Talleres de reflexión. El equipo debe detenerse treinta minutos o una hora para reflexionar sobre sus convenciones de trabajo, discutir inconvenientes y mejoras y planear para el período siguiente. 3. Planeamiento Blitz. Una técnica puede ser el Juego de Planeamiento de XP. En este juego, se ponen tarjetas indexadas en una mesa, con una historia de usuario o función visible en cada una. El grupo finge que no hay dependencias entre tarjetas, y las alinea en secuencias de desarrollo preferidas. Los programadores escriben en cada tarjeta el tiempo estimado para desarrollar cada función. El patrocinador o embajador del usuario escribe la secuencia de prioridades, teniendo en cuenta los tiempos referidos y el valor de negocio de cada función. Las tarjetas se agrupan en períodos de tres semanas llamados iteraciones que se agrupan en entregas (releases), usualmente no más largas de tres meses. Pueden usarse tarjetas CRC. Cockburn propone otras variantes del juego, las diferencias entre la versión de Cockburn y el juego de XP son varias: en XP las tarjetas tienen historias, en CC listas de tareas; el juego de XP asume que no hay dependencias, el de CC que sí las hay; en XP hay iteraciones de duración fija, en CC no se presupone nada sobre la longitud de la iteración. 4. Estimación Delphi con estimaciones de pericia. La técnica se llama así por analogía con el oráculo de Delfos. En el proceso Delphi se reúnen los expertos responsables y proceden como en un remate para proponer el tamaño del sistema, su tiempo de ejecución, la fecha de las entregas según dependencias técnicas y de negocios y para equilibrar las entregas en paquetes de igual tamaño. 5. Encuentros diarios de pie. La palabra clave es brevedad, cinco a diez minutos como máximo. No se trata de discutir problemas, sino de identificarlos. Los problemas sólo se discuten en otros encuentros posteriores, con la gente que tiene que ver en ellos. 87

88 6. Miniatura de procesos. La Hora Extrema fue inventada por Peter Merel para introducir a la gente en XP en 60 minutos (http://c2.com/cgi/wiki?extremehour) y proporciona lineamientos canónicos que pueden usarse para articular esta práctica. Una forma de presentar Crystal Clear puede consumir entre 90 minutos y un día. La idea es que la gente pueda degustar la nueva metodología. 7. Gráficos de quemado. Su nombre viene de los gráficos de quemado de calorías de los regímenes dietéticos; se usan también en Scrum. Se trata de una técnica de graficación para descubrir demoras y problemas tempranamente en el proceso, evitando que se descubra demasiado tarde aún que todavía no se sabe cuánto falta. Para ello se hace una estimación del tiempo faltante para programar lo que resta al ritmo actual, lo cual sirve para tener dominio de proyectos en los que las prioridades cambian bruscamente y con frecuencia. 8. Programación lado a lado. Mucha gente siente que la programación en pares de XP involucra una presión excesiva; la versión de Crystal Clear establece proximidad, pero cada quien se aboca a su trabajo asignado, prestando un ojo a lo que hace su compañero, quien tiene su propia máquina. C. Procesos El proceso de Crystal Clear se basa en una exploración refinada de los inconvenientes de los modelos clásicos. Dice Cockburn que la mayoría de los modelos de proceso propuestos entre 1970 y 2000 se describían como secuencias de pasos. Aún cuando se recomendaran iteraciones e incrementos (que no hacían más que agregar confusión a la interpretación) los modelos parecían dictar un proceso en cascada, por más que los autores aseguraran que no era así. El problema con estos procesos es que realmente están describiendo un workflow requerido, un grafo de dependencia: el equipo no puede entregar un sistema hasta que está integrado y corre. No puede integrar y verificar hasta que el código no está escrito y corriendo. Y no puede diseñar y escribir el código hasta que se le dice cuáles son los requerimientos. Un grafo de dependencia se interpreta necesariamente en ese sentido, aunque no haya sido la intención original. En lugar de esta interpretación lineal, Crystal Clear enfatiza el proceso como un conjunto de ciclos anidados. En la mayoría de los proyectos se perciben siete ciclos: (1) el proyecto, (2) el ciclo de entrega de una unidad, (3) la iteración (nótese que CCrequiere múltiples entregas por proyecto pero no muchas iteraciones por entrega), (4)la semana laboral, (5) el período de integración, de 30 minutos a tres días, (6) el día de trabajo, (7) el episodio de desarrollo de una sección de código, de pocos minutos apocas horas. Los métodos Crystal no prescriben las prácticas de desarrollo, las herramientas o los productos que pueden usarse, pudiendo combinarse con otros métodos como Scrum, XP y Microsoft Solutions Framework. 88

89 Figura 4 Ciclos anidados de Crystal Clear D. Roles Hay ocho roles nominados en cristal clear: 1. Patrocinador. Produce la Declaración de Misión con Prioridades de Compromiso(Tradeoff). Consigue los recursos y define la totalidad del proyecto. 2. Usuario Experto. Junto con el Experto en Negocios produce la Lista de Actores- Objetivos y el Archivo de Casos de Uso y Requerimientos. Debe familiarizarse con el uso del sistema, sugerir atajos de teclado, modos de operación, información a visualizar simultáneamente, navegación, etcétera. 3. Diseñador Principal. Produce la Descripción Arquitectónica. Se supone que debe ser al menos un profesional de Nivel 3. (En métodos ágiles se definen tres niveles de experiencia: Nivel 1 es capaz de seguir los procedimientos ; Nivel 2 es capaz de apartarse de los procedimientos específicos y encontrar otros distintos; Nivel 3 es capaz de manejar con fluidez, mezclar e inventar procedimientos). El Diseñador Principal tiene roles de coordinador, arquitecto, mentor y programador más experto. 4. Diseñador-Programador. Produce, junto con el Diseñador Principal, los Borradores de Pantallas, el Modelo Común de Dominio, las Notas y Diagramas de Diseño, el Código Fuente, el Código de Migración, las Pruebas y el Sistema Empaquetado. Cockburn no distingue entre diseñadores y programadores. Un programa en CC es diseño y programa ; sus programadores son diseñadores-programadores. En CC un diseñador que no programe no tiene cabida. 5. Experto en Negocios. Junto con el Usuario Experto produce la Lista de Actores- Objetivos y el Archivo de Casos de Uso y Requerimientos. Debe conocer las reglas y políticas del negocio. 6. Coordinador. Con la ayuda del equipo, produce el Mapa de Proyecto, el Plan de Entrega, el Estado del Proyecto, la Lista de Riesgos, el Plan y Estado de Iteración y la Agenda de Visualización. 7. Verificador. Produce el Reporte de Bugs. Puede ser un programador en tiempo parcial, o un equipo de varias personas. 8. Escritor. Produce el Manual de Usuario SCRUM Scrum define un proceso empírico, iterativo e incremental de desarrollo que intenta obtener ventajas respecto a los procesos definidos (cascada, espiral, prototipos, etc.) mediante la aceptación de la naturaleza caótica del desarrollo de software, y la utilización de prácticas tendientes a manejar lo impredecible y el riesgo a niveles aceptables. El mismo surge en 1986, de un artículo de la Harvard Business Review titulado The New New Product 89

90 Development Game de Hirotaka Takeuchi e Ikujiro Nonaka, que introducía las mejores prácticas más utilizadas en 10 compañías japonesas altamente innovadoras. A partir de ahí y tomando referencias al juego de rugby, Ken Scwaber y Jeff Sutherland formalizan el proceso conocido como Scrum en el año La intención de Scrum es la de maximizar la realimentación sobre el desarrollo pudiendo corregir problemas y mitigar riesgos de forma temprana. Su uso se está extendiendo cada vez más dentro de la comunidad de Metodologías Ágiles, siendo combinado con otras como XP para completar sus carencias. Cabe mencionar que Scrum no propone el uso de ninguna práctica de desarrollo en particular; sin embargo, es habitual emplearlo como un framework ágil de administración de proyectos que puede ser combinado con cualquiera de las metodologías mencionadas. A. Roles Scrum define seis roles: 1. El Scrum Master. Interactúa con el cliente y el equipo. Es responsable de asegurarse que el proyecto se lleve a cabo de acuerdo con las prácticas, valores y reglas de Scrum y que progrese según lo previsto. Coordina los encuentros diarios, formula lastres preguntas canónicas y se encarga de eliminar eventuales obstáculos. Debe ser miembro del equipo y trabajar a la par de sus integrantes. 2. Propietario del Proyecto. Es el responsable oficial del proyecto, gestión, control y visibilidad de la lista de acumulación o lista de retraso del producto (productbacklog). Es elegido por el Scrum Master, el cliente y los ejecutivos a cargo. Toma las decisiones finales de las tareas asignadas al registro y convierte sus elementos en rasgos a desarrollar. 3. Equipo de Scrum. Tiene autoridad para reorganizarse y definir las acciones necesarias o sugerir la remoción de impedimentos. 4. Cliente. Participa en las tareas relacionadas con los ítems del registro. 5. Management. Está a cargo de las decisiones fundamentales y participa en la definición de los objetivos y requerimientos. Por ejemplo, selecciona al Dueño del Producto, evalúa el progreso y reduce el registro de acumulación junto con el Scrum Master. 6. Usuario. La dimensión del equipo total de Scrum no debería ser superior a diez ingenieros. El número ideal es siete, más o menos dos, una cifra canónica en ciencia cognitiva. Si hay más, lo más recomendable es formar varios equipos. B. Ciclo de Vida El ciclo de vida de Scrum es el siguiente: 1. Pre-Juego: Planeamiento. El propósito es establecer la visión, definir expectativas y asegurarse el financiamiento. Las actividades son la escritura de la visión, el presupuesto, el registro de acumulación o retraso (backlog) del producto inicial y los ítems estimados, así como la arquitectura de alto nivel, el diseño exploratorio y los prototipos. El registro de acumulación es de alto nivel de abstracción. 2. Pre-Juego: Montaje (Staging). El propósito es identificar más requerimientos y priorizar las tareas para la primera iteración. Las actividades son planificación, diseño exploratorio y prototipos. 90

91 3. Juego o Desarrollo. El propósito es implementar un sistema listo para entrega en una serie de iteraciones de treinta días llamadas corridas (sprints). Las actividades son un encuentro de planeamiento de corridas en cada iteración, la definición del registro de acumulación de corridas y los estimados, y encuentros diarios de Scrum. 4. Pos-Juego: Liberación. El propósito es el despliegue operacional. Las actividades, documentación, entrenamiento, mercadeo y venta. Figura 5 Ciclo de Scrum, basado en [10] Usualmente los registros de acumulación se llevan en planillas de cálculo comunes, antes que en una herramienta sofisticada de gestión de proyectos. Los elementos del registro pueden ser prestaciones del software, funciones, corrección de bugs, mejoras requeridas y actualizaciones de tecnología. Hay un registro total del producto y otro específico para cada corrida de 30 días. En la jerga de Scrum se llaman paquetes a los objetos o componentes que necesitan cambiarse en la siguiente iteración. Figura 6 Ciclo de Carrera (Sprint) de Scrum, basado en [http://www.controlchaos.com] 91

92 La lista de Acumulación del Producto contiene todos los rasgos, tecnología, mejoras y lista de bugs que, a medida que se desenvuelven, constituyen las futuras entregas del producto. Los rasgos más urgentes merecerán mayor detalle, los que pueden esperar se tratarán de manera más sumaria. La lista se origina a partir de una variedad de fuentes. El grupo de mercadeo genera los rasgos y la función; la gente de ventas genera elementos que harán que el producto sea más competitivo; los de ingeniería aportarán paquetes que lo harán más robusto; el cliente ingresará debilidades o problemas que deberán resolverse. El propietario de la administración y el control del backlog en productos comerciales bien puede ser el product manager; para desarrollos in-house podría ser el project manager, o alguien designado por él. Se recomienda que una sola persona defina la prioridad de una tarea; si alguien tiene otra opinión, deberá convencer al responsable. Se estima que priorizar adecuadamente una lista de producto puede resultar difícil al principio del desarrollo, pero deviene más fácil con el correr del tiempo. Al fin de cada iteración de treinta días hay una demostración a cargo del Scrum Master. Las presentaciones en PowerPoint están prohibidas. Todos tienen que ser puntuales; si alguien llega tarde, se le cobra una multa que se destinará a obras de caridad. Es permitido usar artefactos de los métodos a los que Scrum acompañe, por ejemplo Listas de Riesgos si se utiliza UP o los Planes de Proyecto sugeridos en la disciplina de Gestión de Proyectos de Microsoft Solutions Framework. No es legal, en cambio, el uso de instrumentos tales como diagramas PERT, porque éstos parten del supuesto de que las tareas de un proyecto se pueden identificar y ordenar; en Scrum el supuesto dominante es que el desarrollo es semicaótico, cambiante y tiene demasiado ruido como para que se le aplique un proceso definido. Algunos textos sobre Scrum establecen una arquitectura global en la fase de prejuego; otros dicen que no hay una arquitectura global en Scrum, sino que la arquitectura y el diseño emanan de múltiples corridas [SB02]. No hay una ingeniería del software prescrita para Scrum; cada quien puede escoger entonces las prácticas de automatización, inspección de código, prueba unitaria, análisis o programación en pares que le resulten adecuadas. Es habitual que Scrum se complemente con XP; en estos casos, Scrum suministra un marco de management basado en patrones organizacionales, mientras XP constituye la práctica de programación, usualmente orientada a objetos y con fuerte uso de patrones de diseño. Uno de los nombres que se utiliza para esta alianza es Actividades para el Estudio de Modelos Ágiles de Procesos. Actividad 1 Objetivo. Que el alumno aprecie las convergencias y divergencias en la definición de los modelos ágiles resumiendo sus características claves, los nombres de los promotores iniciales y sus fechas de aparición. Especificación. -Revisar el capitulo. 92

93 -Hacer una tabla mencionando los acrónimos, el tipo de modelo, las características claves, los nombres de los promotores iniciales y sus fechas de aparición de los modelos vistos. Ejemplo de Resultados. Metodología Acrónimo Creación Tipo de modelo Característica Programación extrema XP Beck, 1999 Disciplina en prácticas de Método ágil radical ingeniería Crystal Methods CM Cockburn, 1998 Familia de metodologías Scrum Scrum Sutherland - Schwaber, 1995 Actividad 2 Proceso (framework de management) Método ágil con énfasis en modelo de ciclos Complemento de otros métodos, ágiles o no Objetivo. Que el alumno comprenda las cualidades y características de los modelos ágiles. Especificación. -Revisar y analizar el capitulo. -Hacer un resumen de los valores, prácticas y principios de los modelos ágiles. Ejemplo de Resultados. Los Valores de AM Comunicación. Valentía. Retroalimentación. Humildad. Simplicidad. Principios centrales de AM Asumir simplicidad. Bienvenido el cambio. Permitir el siguiente esfuerzo es el objetivo secundario. Cambio incremental. Maximizar la inversión de las partes interesadas en el proyecto. Modelar con un propósito. Múltiples modelos. Trabajo de calidad. Rápida retroalimentación. El software es el objetivo primario. Prácticas centrales de AM Participación activa de todos aquellos que soportan el proyecto. Aplicar los artefactos correctos. Propiedad colectiva. Considerar la puesta a prueba del sistema. 93

94 Crear varios modelos en paralelo. Crear contenidos simples. Representar los modelos de manera simple. Presentar los modelos públicamente. Iterar a otros artefactos. Modelar en pequeños incrementos. Modelar con otros. Demuéstrelo con código. Use las herramientas más simples. Referencias Bibliográficas. [1] Sridhar Nerur, Radha Kanta Mahapatra, George Mangalaraj, Challenges of migrating to agile methodologies. Communications of the ACM - Adaptive complex enterprises Volume 48 Issue 5, May 2005 [5] Kent Beck. Extreme Programming Explained: Embrace Change. Reading, Addison Wesley, [6] Letelier P., Penadés C., Metodologías ágiles para el desarrollo de Software:eXtremeProgramming (XP), Universidad Politécnica de Valencia Disponible en: [8] Carlos Reynoso Método heterodoxos en Desarrollo de Software (Survey de Métodos Ágiles) [9] Alistair Cockburn. Crystal Clear. A human-powered methodology for small teams, including The Seven Properties of Effective Software Projects.Borrador. Humans and Technology, versión del 27 de febrero de [10]Pekka Abrahamsson. Agile Software development methods: A minitutorial. VTT Technical Research Centre of Finland,http://www.vtt.fi/virtual/agile/seminar2002/Abrahamsson_agile_methods_minituto rial.pdf, Comentarios, conclusiones y actividades complementarias sobre los antecedentes y conceptos básicos de la ingeniería de software. Se propone realizar una actividad grupal de análisis y reflexión para cerrar el estudio de métodos ágiles. Debido a la novedad de las metodologías ágiles, muy pocos datos empíricos están disponibles en relación con cada método. El desafío más grande para el líder del proyecto, por lo tanto, es la selección de un método apropiado dentro de la cantidad de métodos ágiles disponibles en la actualidad. Esto es muy parecido a la situación que enfrentaron los primeros desarrolladores al adoptar la tecnología de objetos. Aunque todos los métodos ágiles, en cierta medida, se ajustan a los principios descritos en el manifiesto ágil, no todos se gobiernen en el mismo sentido. Existen diferencias significativas en términos de tamaño 94

95 del equipo, la propiedad del código, la duración de cada ciclo iterativo, el énfasis de actividades de flujo al frente y de flujo inverso, y los mecanismos para una rápida retroalimentación y adaptación al cambio. Melnik [7] hace un estudio empírico para identificar el uso de métodos ágiles en la práctica. Algunos de sus resultados son los siguientes: 1. Estado de uso en la práctica a. Zona amplia libre de mediciones Pocos experimentos Incluso menos resultados publicados Foco mínimo en recolección de datos Datos existentes generalmente incompletos Consultores de muy alto nivel solo transmiten anécdotas b. Experimentos existentes Muy triviales o Defectos experimentales i) Gran cantidad de variables que no pueden ser controladas ii) Pequeñas muestras iii) Sujetos ajenos a la profesión iv) Conducido en un lapso breve de tiempo 2. La adopción de esta metodología ha sido lenta en la industria (41%) 3. Poco conocida (54 % no sabe de ella) y de los que la conocen y aún no la adoptan (29%) muy pocos se encuentran en la posibilidad (7%) de adoptarla. 95

96 4. El tamaño es importante. Cuando nos referimos al volumen de personas que trabajan en una compañía. Mientras mayor sea el número mayor el nivel de conocimiento de los métodos ágiles. 5. Los proyecto que usan métodos ágiles han logrado un nivel de madurez mayor que solo proyectos piloto 96

97 6. Los beneficios tangibles que se reportan, 90% incremento de productividad, 85% reducción de defectos de software, 83% aceleración de tiempo para poner en el mercado el producto, 66% reducción de costo. 7. Un caso de estudio que muestra el éxito en el área aeroespacial con la empresa Boeing. El 97

98 8. Técnicas que son más usadas, planeación iterativa (65%), pruebas de unidades de desarrollo (60%), discusión diaria (55%), planeación de entregables (54%), integración continua (50%). 9. Las metodologías más usadas 10. Han logrado pasar el abismo los métodos ágiles y no quedar en ser algo para visionarios, al parecer ha pasado esa barrera. 98

99 11. Veamos ahora que industrias han adoptado los métodos ágiles 12. La satisfacción en el trabajo es mayor en un esquema ágil 99

100 Actividad 1. Reflexión sobre uso de métodos ágiles Objetivo. El alumno reflexionará sobre la eficacia de los métodos ágiles. Especificaciones. Responder al cuestionario y hacer un debate en clase. Ejemplo de Resultados. 1. Los métodos ágiles son buenos por las prácticas que promueven o por qué sus promotores simplemente son muy buenos desarrolladores? Para lograr resultados se requiere disciplina, y mucha practica, es por eso que un método ágil sólo será exitoso si se adopta de forma correcta. Un proceso ágil va a funcionar con personas competentes y por encima del promedio [1]. 2. Qué consecuencias negativas puede haber en la empresa respecto al nivel de los profesionales que se requieren para el uso de métodos ágiles? Dificultad para conseguir personal, ya que será muy complicado encontrar equipos de desarrolladores que funcionen en el médelo ágil. Afectar autoestima de tu personal al ser un esquema de selección de personal muy elitista lo cual afectará la moral de los desarrolladores no-áiles. 3. Cómo se va afectada la toma de decisiones? Los desarrolladores de software y el cliente toman la mayoría de las decisiones. Esto crea un ambiente plural de toma de decisiones con diferente historial, actitud, metas, y disposición cognitiva. La toma de decisiones es más 100

Benemérita Universidad Autónoma de Puebla Vicerrectoría de Docencia Dirección General de Educación Superior Facultad de Ciencias de la Computación

Benemérita Universidad Autónoma de Puebla Vicerrectoría de Docencia Dirección General de Educación Superior Facultad de Ciencias de la Computación PLAN DE ESTUDIOS (PE): Licenciatura en Ingeniería en Tecnologías de la Información AREA: Integración Disciplinaria ASIGNATURA: CÓDIGO: IDTI-200 CRÉDITOS: 5 FECHA: 27 de Mayo de 2013 1 1. DATOS GENERALES

Más detalles

Benemérita Universidad Autónoma de Puebla Vicerrectoría de Docencia Dirección General de Educación Superior Facultad de Ciencias de la Computación

Benemérita Universidad Autónoma de Puebla Vicerrectoría de Docencia Dirección General de Educación Superior Facultad de Ciencias de la Computación PLAN DE ESTUDIOS (PE): LICENCIATURA E INGENIERIA EN CIENCIAS DE LA COMPUTACION AREA: Integración disciplinar ASIGNATURA: CÓDIGO: IDCO-201 CRÉDITOS: 5 FECHA: 08 DE FEBRERO DE 2013 1 1. DATOS GENERALES Nivel

Más detalles

PROGRAMA ANALÍTICO DE LA UNIDAD DE APRENDIZAJE

PROGRAMA ANALÍTICO DE LA UNIDAD DE APRENDIZAJE I. IDENTIFICACIÓN DE LA UNIDAD DE APRENDIZAJE Programa Educativo: PROGRAMA ANALÍTICO DE LA UNIDAD DE APRENDIZAJE Fecha de elaboración Julio 2012 Fecha última revisión Diciembre 2013 Unidad de Aprendizaje:

Más detalles

1.- DATOS DE LA ASIGNATURA

1.- DATOS DE LA ASIGNATURA 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura : Taller de Ingeniería de Software Ingeniería en Tecnologías de la Carrera : Información y Comunicaciones Clave de la asignatura : TIC-1028 SATCA 1 2-2-4

Más detalles

SATCA 1 2-2-4. En la primera unidad, el estudiante conocerá los fundamentos de la Ingeniería de Software y los sistemas de información.

SATCA 1 2-2-4. En la primera unidad, el estudiante conocerá los fundamentos de la Ingeniería de Software y los sistemas de información. 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura : Ingeniería de Software Ingeniería en Tecnologías de la Carrera : Información y Comunicaciones Clave de la asignatura : TIC-1014 SATCA 1 2-2-4 2.- PRESENTACIÓN

Más detalles

Carrera : SATCA 1 2-2-4

Carrera : SATCA 1 2-2-4 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura : Ingeniería de Software Carrera : Clave de la asignatura : TIC-1014 SATCA 1 2-2-4 Ingeniería en Tecnologías de la Información y Comunicaciones 2.- PRESENTACIÓN

Más detalles

Benemérita Universidad Autónoma de Puebla Vicerrectoría de Docencia Dirección General de Educación Superior Facultad de Ciencias de la Computación

Benemérita Universidad Autónoma de Puebla Vicerrectoría de Docencia Dirección General de Educación Superior Facultad de Ciencias de la Computación PLAN DE ESTUDIOS (PE): Licenciatura en Ingeniería en Ciencias de la Computación AREA: Integración DESIT ASIGNATURA: CÓDIGO: IDDM-001 CRÉDITOS: 5 FECHA: 15 de Agosto 2011 1 1. DATOS GENERALES Nivel Educativo:

Más detalles

Gestión de Proyectos de Software SCG-1009 3-3-6

Gestión de Proyectos de Software SCG-1009 3-3-6 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Clave de la asignatura: (Créditos) SATCA 1 Gestión de Proyectos de Software Ingeniería en Sistemas Computacionales SCG-1009 3-3-6 2.- PRESENTACIÓN

Más detalles

SATCA 1 3-2-5. Las principales aportaciones que esta asignatura brinda al perfil profesional son:

SATCA 1 3-2-5. Las principales aportaciones que esta asignatura brinda al perfil profesional son: 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura : Análisis y Modelado de Sistemas de Información Carrera : Ingeniería Informática Clave de la asignatura : IFF-1005 SATCA 1 3-2-5 2.- PRESENTACIÓN Caracterización

Más detalles

Metodología para desarrollar materiales electrónicos educativos para el aprendizaje a distancia autónomo

Metodología para desarrollar materiales electrónicos educativos para el aprendizaje a distancia autónomo Metodología para desarrollar materiales electrónicos educativos para el aprendizaje a distancia autónomo P. Gómez*, F. Vázquez* y J. Rodas** *Unidad Profesional Interdisciplinaria de Ingeniería y Ciencias

Más detalles

INTRODUCCION A LA INGENIERIA DE SOFTWARE

INTRODUCCION A LA INGENIERIA DE SOFTWARE UNIDAD I INTRODUCCION A LA INGENIERIA DE SOFTWARE Contenido: 1.1 Definiciones 1.2 Evolucion del Software 1.3 Importancia del Software 1.4 Problemas del Software 1.5 Caracteristicas del Software 1.6 Conceptos

Más detalles

Programa de estudio. 6. Área de conocimiento. 7. Academia(s) PSICOLÓGICA, FILOSÓFICA Y PSICOLÓGICA, FILOSÓFICA Y SOCIAL

Programa de estudio. 6. Área de conocimiento. 7. Academia(s) PSICOLÓGICA, FILOSÓFICA Y PSICOLÓGICA, FILOSÓFICA Y SOCIAL Datos generales 0. Área Académica HUMANIDADES Programa de estudio 1. Programa educativo PEDAGOGÍA 2. Facultad 3. Código PEDAGOGÍA SISTEMA DE ENSEÑANZA ABIERTA 4. Nombre de la experiencia educativa FUNDAMENTOS

Más detalles

Carrera: SCD-1008 SATCA 1 2-3-5

Carrera: SCD-1008 SATCA 1 2-3-5 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Fundamentos de programación Sistemas Computacionales Clave de la asignatura: SATCA 1 SCD-1008 2-3-5 2.- PRESENTACIÓN Caracterización de la asignatura.

Más detalles

Carrera: SCD-1011 SATCA 1 2-3-5

Carrera: SCD-1011 SATCA 1 2-3-5 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Ingeniería de Software Carrera: Ingeniería en Sistemas Computacionales Clave de la asignatura: SATCA 1 SCD-1011 2-3-5 2.- PRESENTACIÓN Caracterización

Más detalles

DISEÑO Y DESARROLLO DEL CHAT DEL ESPACIO DE APRENDIZAJE COLABORATIVO DE LA INSTITUCIÓN VIRTUAL DE LAS CARRERAS DE INFORMÁTICA DE LA UPIICSA 1

DISEÑO Y DESARROLLO DEL CHAT DEL ESPACIO DE APRENDIZAJE COLABORATIVO DE LA INSTITUCIÓN VIRTUAL DE LAS CARRERAS DE INFORMÁTICA DE LA UPIICSA 1 DISEÑO Y DESARROLLO DEL CHAT DEL ESPACIO DE APRENDIZAJE COLABORATIVO DE LA INSTITUCIÓN VIRTUAL DE LAS CARRERAS DE INFORMÁTICA DE LA UPIICSA 1 Fernando Vázquez Torres*, Pilar Gómez Miranda* * Unidad Profesional

Más detalles

SATCA 1 3-1-4. Las principales aportaciones que ésta asignatura brinda al perfil profesional son:

SATCA 1 3-1-4. Las principales aportaciones que ésta asignatura brinda al perfil profesional son: 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura : Fundamentos de Sistemas de Información Carrera : Ingeniería Informática Clave de la asignatura : IFE-1015 SATCA 1 3-1-4 2.- PRESENTACIÓN Caracterización

Más detalles

Carrera: SCD-1027 SATCA 1 2-3-5

Carrera: SCD-1027 SATCA 1 2-3-5 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Tópicos Avanzados de Programación Ingeniería en Sistemas Computacionales Clave de la asignatura: SATCA 1 SCD-1027 2-3-5 2.- PRESENTACIÓN Caracterización

Más detalles

BENEMÉRITA UNIVERSIDAD AUTÓNOMA DE PUEBLA FACULTAD CIENCIAS DE LA COMPUTACION

BENEMÉRITA UNIVERSIDAD AUTÓNOMA DE PUEBLA FACULTAD CIENCIAS DE LA COMPUTACION BENEMÉRITA UNIVERSIDAD AUTÓNOMA DE PUEBLA FACULTAD CIENCIAS DE LA COMPUTACION PROGRAMA DE LA MATERIA CORRESPONDIENTE A LA INGENIERIA EN CIENCIAS DE LA COMPUTACIÓN. Coordinación: NOMBRE DE LA MATERIA: Área

Más detalles

GUÍA DOCENTE 1. DESCRIPCIÓN DE LA ASIGNATURA

GUÍA DOCENTE 1. DESCRIPCIÓN DE LA ASIGNATURA 1. DESCRIPCIÓN DE LA ASIGNATURA Grado: Ingeniería Informática en Sistemas de Información Doble Grado: Asignatura: Ingeniería del Software 1 Módulo: M3: Ingeniería del Software, Sistemas de Información

Más detalles

UNIVERSIDAD DEL VALLE DE MÉXICO PROGRAMA DE ESTUDIO NIVEL MEDIO SUPERIOR PLANEACIÓN DIDÁCTICA BACHILLERATO GENERAL SEMESTRAL

UNIVERSIDAD DEL VALLE DE MÉXICO PROGRAMA DE ESTUDIO NIVEL MEDIO SUPERIOR PLANEACIÓN DIDÁCTICA BACHILLERATO GENERAL SEMESTRAL UNIVERSIDAD DEL VALLE DE MÉXICO PROGRAMA DE ESTUDIO NIVEL MEDIO SUPERIOR PLANEACIÓN DIDÁCTICA BACHILLERATO GENERAL SEMESTRAL Enfoque educativo basado en el desarrollo de competencias ASIGNATURA CONTABILIDAD

Más detalles

Dirección General de Educación Superior Tecnológica 1-4-5. Carrera:

Dirección General de Educación Superior Tecnológica 1-4-5. Carrera: Dirección General de Educación Superior Tecnológica 1. Datos Generales de la asignatura Nombre de la asignatura: Clave de la asignatura: Créditos (Ht-Hp_ créditos): Carrera: Proyecto Integrador de Tecnologías

Más detalles

BENÉMERITA UNIVERSIDAD AUTÓNOMA DE PUEBLA VICERRECTORÍA DE DOCENCIA DIRECCIÓN GENERAL DE EDUCACIÓN SUPERIOR FACULTAD DE CIENCIAS DE LA COMPUTACIÓN

BENÉMERITA UNIVERSIDAD AUTÓNOMA DE PUEBLA VICERRECTORÍA DE DOCENCIA DIRECCIÓN GENERAL DE EDUCACIÓN SUPERIOR FACULTAD DE CIENCIAS DE LA COMPUTACIÓN Programa Educativo (PE): Licenciatura en Ciencias de la computación Área: Ciencias de la Computación Programa de Asignatura: Programación Distribuida Código: CCOM-255 Créditos: 5 Fecha: Junio de 2009 1

Más detalles

1.- DATOS DE LA ASIGNATURA. Fundamentos de Gestión Empresarial. Nombre de la asignatura: Ingeniería en Gestión Empresarial y Gastronomía AEF-1074

1.- DATOS DE LA ASIGNATURA. Fundamentos de Gestión Empresarial. Nombre de la asignatura: Ingeniería en Gestión Empresarial y Gastronomía AEF-1074 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Fundamentos de Gestión Empresarial Carrera: Clave de la asignatura: Ingeniería en Gestión Empresarial y Gastronomía AEF-1074 (Créditos) SATCA 1 3-2 -

Más detalles

1.- DATOS DE LA ASIGNATURA. Nombre de la asignatura: Fundamentos de Ingeniería de Software. Ingeniería en Sistemas Computacionales.

1.- DATOS DE LA ASIGNATURA. Nombre de la asignatura: Fundamentos de Ingeniería de Software. Ingeniería en Sistemas Computacionales. 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Clave de la asignatura: (Créditos) SATCA 1 Fundamentos de Ingeniería de Software Ingeniería en Sistemas Computacionales SCC-1007 2-2-4 2.- PRESENTACIÓN

Más detalles

CARTA DESCRIPTIVA Código: FO-MI-108 Versión: 3 Fecha: 25-10-2013

CARTA DESCRIPTIVA Código: FO-MI-108 Versión: 3 Fecha: 25-10-2013 CARTA DESCRIPTIVA Código: FO-MI-108 Versión: 3 Fecha: 25-10-2013 1. PRESENTACIÓN FACULTAD: Ingenierías PROGRAMA: Ingeniería de sistemas NOMBRE DEL CURSO: Ingeniería de Software PLAN DE ESTUDIOS: IS01 CRÉDITOS

Más detalles

PROGRAMA ANALÍTICO DE LA UNIDAD DE APRENDIZAJE. I. IDENTIFICACIÓN DE LA UNIDAD DE APRENDIZAJE Fecha de elaboración Julio 2012

PROGRAMA ANALÍTICO DE LA UNIDAD DE APRENDIZAJE. I. IDENTIFICACIÓN DE LA UNIDAD DE APRENDIZAJE Fecha de elaboración Julio 2012 PROGRAMA ANALÍTICO DE LA UNIDAD DE APRENDIZAJE I. IDENTIFICACIÓN DE LA UNIDAD DE APRENDIZAJE Programa Educativo: Fecha de elaboración Julio 2012 Fecha última revisión Julio 2013 Unidad de Aprendizaje:

Más detalles

CARTA DESCRIPTIVA 1. PRESENTACIÓN PLAN DE ESTUDIOS: IS02 CRÉDITOS 5 CÓDIGO DEL CURSO: IS020 NIVEL: VI ÁREA O COMPONENTE DE FORMACIÓN: Específica

CARTA DESCRIPTIVA 1. PRESENTACIÓN PLAN DE ESTUDIOS: IS02 CRÉDITOS 5 CÓDIGO DEL CURSO: IS020 NIVEL: VI ÁREA O COMPONENTE DE FORMACIÓN: Específica FACULTAD: Ingenierías PROGRAMA: Ingeniería de sistemas NOMBRE DEL CURSO: CARTA DESCRIPTIVA Ingeniería de Software 1. PRESENTACIÓN PLAN DE ESTUDIOS: IS02 CRÉDITOS 5 CÓDIGO DEL CURSO: IS020 NIVEL: VI ÁREA

Más detalles

GUÍA DOCENTE. Curso 2014-2015. Ingeniería Informática en Sistemas de Información Doble Grado: M6: Tecnología Específica de Sistemas de Información

GUÍA DOCENTE. Curso 2014-2015. Ingeniería Informática en Sistemas de Información Doble Grado: M6: Tecnología Específica de Sistemas de Información 1. DESCRIPCIÓN DE LA ASIGNATURA Grado: Ingeniería Informática en Sistemas de Información Doble Grado: Asignatura: Ingeniería de Proyectos Módulo: M6: Tecnología Específica de Sistemas de Información Departamento:

Más detalles

La tecnología informática aplicada a los centros escolares

La tecnología informática aplicada a los centros escolares Licenciatura en Educación Primaria Plan de estudios 2012 Programa del curso La tecnología informática aplicada a los centros escolares Segundo semestre Primera edición: 2013 Esta edición estuvo a cargo

Más detalles

Bases de Datos. Carrera: LOH-0902 SATCA 1 1-3-4

Bases de Datos. Carrera: LOH-0902 SATCA 1 1-3-4 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Clave de la asignatura: SATCA 1 Bases de Datos Ingeniería en Logística LOH-0902 1-3-4 2.- PRESENTACIÓN Caracterización de la asignatura. Fundamentación.

Más detalles

Instruir al alumno con los conceptos, modelos, teorías y principios básicos estudiados en la Ingeniería de Software

Instruir al alumno con los conceptos, modelos, teorías y principios básicos estudiados en la Ingeniería de Software Universidad de Colima Dirección General de Educación Superior Facultad de Ingeniería Mecánica y Eléctrica Licenciatura en Ingeniería en Sistemas Computacionales I. DATOS GENERALES P R O G R A M A A N A

Más detalles

Estrategias de trabajo docente

Estrategias de trabajo docente Subsecretaría de Educación Superior Dirección General de Educación Superior para Profesionales de la Educación Estrategias de trabajo docente CUARTO SEMESTRE PLAN DE ESTUDIOS, 2012 LICENCIATURA EN EDUCACIÓN

Más detalles

Profesionalización en Línea

Profesionalización en Línea Profesionalización en Línea Diplomado en Profesionalización de los docentes del nivel medio superior del GEM por competencias Integrado por 8 módulos que se ofrecen en la modalidad de educación a distancia,

Más detalles

Carrera: SCM - 0406 3-2-8. Participantes. Representantes de la academia de sistemas y computación de los Institutos Tecnológicos.

Carrera: SCM - 0406 3-2-8. Participantes. Representantes de la academia de sistemas y computación de los Institutos Tecnológicos. 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Clave de la asignatura: Horas teoría-horas práctica-créditos Desarrollo de proyectos de software Ingeniería en Sistemas Computacionales SCM

Más detalles

Desarrollo y Cultura Organizacional. Programa de estudio. Facultad de Psicología Xalapa

Desarrollo y Cultura Organizacional. Programa de estudio. Facultad de Psicología Xalapa Desarrollo y Cultura Organizacional Programa de estudio Facultad de Psicología Xalapa Área académica Ciencias de la salud Programa educativo Facultad de psicología Dependencia Entidad académica Facultad

Más detalles

Licenciatura en Administración

Licenciatura en Administración 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Clave de la asignatura: (Créditos)SATCA: Tecnologías de la Información y las Comunicaciones para la Administración Licenciatura en Administración

Más detalles

Nombre de la asignatura: Proceso Personal para el Desarrollo de - --------------------------------------------------Software

Nombre de la asignatura: Proceso Personal para el Desarrollo de - --------------------------------------------------Software 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Proceso Personal para el Desarrollo de - --------------------------------------------------Software Carrera: Clave de la asignatura: Ingeniería en Sistemas

Más detalles

Línea de investigación o de trabajo: Todas de Ciencias de la Computación. Horas teoría-horas prácticas-horas trabajo adicional-horas totales-créditos

Línea de investigación o de trabajo: Todas de Ciencias de la Computación. Horas teoría-horas prácticas-horas trabajo adicional-horas totales-créditos Nombre de la asignatura: Ingeniería de Software I Línea de investigación o de trabajo: Todas de Ciencias de la Computación Horas teoría-horas prácticas-horas trabajo adicional-horas totales-créditos 22

Más detalles

AUTOREFLEXION Y EVALUACIÓN DE LA PRÁCTICA DOCENTE

AUTOREFLEXION Y EVALUACIÓN DE LA PRÁCTICA DOCENTE AUTOREFLEXION Y EVALUACIÓN DE LA PRÁCTICA DOCENTE Roxana Guadalupe Castillo Melara* "A todos los profesores y maestros que les pueda interesar y ayudar esta guía, con el deseo de que tanto alumnos y docentes

Más detalles

1.- DATOS DE LA ASIGNATURA

1.- DATOS DE LA ASIGNATURA 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Clave de la asignatura: (Créditos) SATCA 1 Taller de Administración Ingeniería en Sistemas Computacionales SCH-1024 1-3 - 4 2.- PRESENTACIÓN

Más detalles

Planificación y Modelado

Planificación y Modelado 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Clave de la asignatura: Horas teoría-horas práctica-créditos Planificación y Modelado Ingeniería en Sistemas Computacionales SCM - 0423 3-2-8

Más detalles

ESTRATEGIAS PARA EL TRABAJO EN EDUCACIÓN ESPECIAL

ESTRATEGIAS PARA EL TRABAJO EN EDUCACIÓN ESPECIAL Página 1 de 6 I. Datos Generales Semestre en que se imparte:séptimo, octavo o noveno Materias antecedentes:procesos Cognitivos, Bases biológicas del comportamiento, Psicología de la niñez, Procesos afectivos

Más detalles

PROGRAMA ANALÍTICO DE LA UNIDAD DE APRENDIZAJE

PROGRAMA ANALÍTICO DE LA UNIDAD DE APRENDIZAJE PROGRAMA ANALÍTICO DE LA UNIDAD DE APRENDIZAJE I. IDENTIFICACIÓN DE LA UNIDAD DE APRENDIZAJE Programa Educativo: Fecha de elaboración Fecha última revisión Julio 2012 Julio 2013 Unidad de Aprendizaje:

Más detalles

Desarrollo Profesional Docente y de Directivos

Desarrollo Profesional Docente y de Directivos Desarrollo Profesional Docente y de Directivos Octubre 2009 México Dirección General de Sistema Nacional de y Superación México Dirección General de Sistema Nacional de y Superación Antecedentes PRONAP:

Más detalles

PROGRAMA ANALÍTICO DE LA UNIDAD DE APRENDIZAJE

PROGRAMA ANALÍTICO DE LA UNIDAD DE APRENDIZAJE I. IDENTIFICACIÓN DE LA UNIDAD DE APRENDIZAJE Programa Educativo en el que se imparte: PROGRAMA ANALÍTICO DE LA UNIDAD DE APRENDIZAJE Fecha de elaboración Julio 2012 Fecha última revisión Julio 2013 Unidad

Más detalles

Benemérita Universidad Autónoma de Puebla Vicerrectoría de Docencia Dirección General de Educación Superior Facultad de Ciencias de la Computación

Benemérita Universidad Autónoma de Puebla Vicerrectoría de Docencia Dirección General de Educación Superior Facultad de Ciencias de la Computación PLAN DE ESTUDIOS (PE): Licenciatura en Ingeniería en Tecnologías de la Información. AREA: Optativas ASIGNATURA: CÓDIGO: ITIM-601 CRÉDITOS: 5 FECHA: Julio de 2013 1 1. DATOS GENERALES Nivel Educativo: Licenciatura.

Más detalles

Guía Docente 2013-14

Guía Docente 2013-14 Guía Docente 2013-14 Gestión de Proyectos Empresariales Business Project Management Grado en Ingeniería Informática A distancia Rev. 10 29/04/2014 17:14 Universidad Católica San Antonio de Murcia Tlf:

Más detalles

BENÉMERITA UNIVERSIDAD AUTÓNOMA DE PUEBLA VICERRECTORÍA DE DOCENCIA DIRECCIÓN GENERALDE EDUCACIÓN SUPERIOR FACULTAD DE CIENCIAS DE LA COMPUTACION

BENÉMERITA UNIVERSIDAD AUTÓNOMA DE PUEBLA VICERRECTORÍA DE DOCENCIA DIRECCIÓN GENERALDE EDUCACIÓN SUPERIOR FACULTAD DE CIENCIAS DE LA COMPUTACION Programa Educativo (PE): Ingeniería en Ciencias de la Computación Área: Interacción Humano Computadora Programa de Asignatura: Aplicaciones Multimedia Código: ICCM-610 Créditos: 5 Fecha: Julio de 2009

Más detalles

Carrera: IFM - 0434 3-2-8. Participantes. Representantes de la academia de sistemas y computación de los Institutos Tecnológicos.

Carrera: IFM - 0434 3-2-8. Participantes. Representantes de la academia de sistemas y computación de los Institutos Tecnológicos. 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Clave de la asignatura: Horas teoría-horas práctica-créditos Sistemas de I Licenciatura en Informática IFM - 0434 3-2-8 2.- HISTORIA DEL PROGRAMA

Más detalles

ESCUELA: UNIVERSIDAD DEL ISTMO

ESCUELA: UNIVERSIDAD DEL ISTMO 1.-IDENTIFICACIÓN ESCUELA: UNIVERSIDAD DEL ISTMO CLAVE: 3045 GRADO: ING. EN COMPUTACIÓN, CUARTO SEMESTRE TIPO DE TEÓRICA/PRÁCTICA ANTECEDENTE CURRICULAR: 3035 2.- OBJETIVO GENERAL Proporcionar al estudiante

Más detalles

Benemérita Universidad Autónoma de Puebla Vicerrectoría de Docencia Dirección General de Educación Superior Facultad de Ciencias de la Computación

Benemérita Universidad Autónoma de Puebla Vicerrectoría de Docencia Dirección General de Educación Superior Facultad de Ciencias de la Computación PLAN DE ESTUDIOS (PE): Ingeniería en Ciencias de la Computación AREA: Tecnología ASIGNATURA: redes CÓDIGO: ICCM-258 CRÉDITOS: 5 créditos FECHA: 30 de septiembre 2013 1 1. DATOS GENERALES Nivel Educativo:

Más detalles

Programa de estudio. 4.- Código 5.-Nombre de la Experiencia educativa 6.- Área de formación principal secundaria Economía Internacional

Programa de estudio. 4.- Código 5.-Nombre de la Experiencia educativa 6.- Área de formación principal secundaria Economía Internacional Programa de estudio 1.-Área académica Económico Administrativa 2.-Programa educativo Licenciatura en Contaduría 3.-Dependencia/Entidad académica Contaduría y Administración 4.- Código 5.-Nombre de la Experiencia

Más detalles

PROGRAMA ANALÍTICO DE LA UNIDAD DE APRENDIZAJE

PROGRAMA ANALÍTICO DE LA UNIDAD DE APRENDIZAJE PROGRAMA ANALÍTICO DE LA UNIDAD DE APRENDIZAJE I. IDENTIFICACIÓN DE LA UNIDAD DE APRENDIZAJE Programa Educativo: Fecha de elaboración Fecha última revisión Julio 2012 Diciembre 2013 Unidad de Aprendizaje:

Más detalles

Ingeniería de software

Ingeniería de software Ingeniería de software MSC-0102 Nombre de la asignatura: Ingeniería de Software Línea de trabajo: Asignatura básica Tiempo de dedicación del estudiante a las actividades de: DOC TIS TPS Horas totales Créditos

Más detalles

PLAN DE ESTUDIOS POR COMPETENCIAS 2010

PLAN DE ESTUDIOS POR COMPETENCIAS 2010 Universidad Autónoma de Guerrero Comisión General de Reforma Universitaria Educación Media Superior Universidad Autónoma de Guerrero. Educación Media Superior Plan de Estudios 2010 PLAN DE ESTUDIOS POR

Más detalles

Benemérita Universidad Autónoma de Puebla Vicerrectoría de Docencia Dirección General de Educación Superior Facultad de Ciencias de la Computación

Benemérita Universidad Autónoma de Puebla Vicerrectoría de Docencia Dirección General de Educación Superior Facultad de Ciencias de la Computación PLAN DE ESTUDIOS (PE): Licenciatura en Ingeniería en Tecnologías de la Información. AREA: Optativas ASIGNATURA: CÓDIGO: ITIM-602 CRÉDITOS: 5 FECHA: Septiembre 2013 1 1. DATOS GENERALES Nivel Educativo:

Más detalles

Fecha de elaboración: Fecha de última actualización:

Fecha de elaboración: Fecha de última actualización: PROGRAMA DE ESTUDIO Modelos de desarrollo de software Programa elaborado por: Fecha de elaboración: Fecha de última actualización: Seriación explícita Asignatura antecedente Programa Educativo: Licenciatura

Más detalles

LICENCIA PROFESIONAL EN DESARROLLO DE APLICACIONES MÓVILES

LICENCIA PROFESIONAL EN DESARROLLO DE APLICACIONES MÓVILES LICENCIA MÓVILES HOJA DE ASIGNATURA CON DESGLOSE DE UNIDADES TEMÁTICAS 1. Nombre de la asignatura Metodologías Ágiles. 2. Competencias Desarrollar Aplicaciones web o móviles empleando lenguaje Java o.net,

Más detalles

PROGRAMA ANALÍTICO DE LA UNIDAD DE APRENDIZAJE

PROGRAMA ANALÍTICO DE LA UNIDAD DE APRENDIZAJE PROGRAMA ANALÍTICO DE LA UNIDAD DE APRENDIZAJE I. IDENTIFICACIÓN DE LA UNIDAD DE APRENDIZAJE Programa Educativo: Fecha de elaboración Fecha última revisión Julio 2012 Julio 2013 Unidad de Aprendizaje:

Más detalles

Carrera : Ingeniería Mecánica SATCA 1 2-1-3

Carrera : Ingeniería Mecánica SATCA 1 2-1-3 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura : Contabilidad y Costos Carrera : Ingeniería Mecánica Clave de la asignatura : MER-1005 SATCA 1 2-1-3 2.- PRESENTACIÓN Caracterización de la asignatura.

Más detalles

Taller de Administración I ADD-1030 2-3-5

Taller de Administración I ADD-1030 2-3-5 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Clave de la asignatura: (Créditos) SATCA1 Taller de Administración I Ingeniería en Administración ADD-1030 2-3-5 2.- PRESENTACIÓN Caracterización

Más detalles

Carrera: LOC-0913 SATCA 1 2-2-4

Carrera: LOC-0913 SATCA 1 2-2-4 1.- DATOS DE LA MATERIA Nombre de la asignatura: Carrera: Clave de la asignatura: SATCA 1 Fundamentos de Administración Ingeniería en Logística LOC-0913 2-2-4 2.- PRESENTACIÓN Caracterización de la asignatura

Más detalles

Estándares y Métricas de Software

Estándares y Métricas de Software PROGRAMA DE ESTUDIO Programa Educativo: Área de Formación : Licenciatura en Tecnología de Información Estándares y Métricas de Software Horas teóricas: 2 Horas prácticas: 4 Total de Horas: 8 Total de créditos:

Más detalles

Carrera: ISH-1203 1-3 - 4

Carrera: ISH-1203 1-3 - 4 1.DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Clave de la asignatura: Horas teoría-horas practica-créditos: Proceso Personal para el Desarrollo de Software. Ingeniería en Sistemas Computacionales

Más detalles

EVALUACIÓN AL DESEMPEÑO DOCENTE

EVALUACIÓN AL DESEMPEÑO DOCENTE Dirección General de Desarrollo Académico e Innovación Educativa Dirección de Fortalecimiento Académico EVALUACIÓN AL DESEMPEÑO DOCENTE DA-EDA-OT-11 0 INDICE Pág. 1. Presentación 2 2. Introducción 3 3.

Más detalles

AEF-1031 3-2 - 5. La unidad tres, revisa el modelo relacional, como uno de los más utilizados en el modelado de base de datos.

AEF-1031 3-2 - 5. La unidad tres, revisa el modelo relacional, como uno de los más utilizados en el modelado de base de datos. 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Clave de la asignatura: SATCA 1 Fundamentos de Bases de Datos Ingeniería Informática, Ingeniería en Sistemas Computacionales e Ingeniería en

Más detalles

El Aprendizaje por Proyectos: Una metodología diferente

El Aprendizaje por Proyectos: Una metodología diferente El Aprendizaje por Proyectos: Una metodología diferente Juana Mónica Coria Arreola Instituto Latinoamericano de la comunicación Educativa-Red Escolar monica.coria@ilce.edu.mx Resumen: Utilizar proyectos

Más detalles

Aprendizaje apoyado por computadora: una experiencia en formación docente

Aprendizaje apoyado por computadora: una experiencia en formación docente Notas Aprendizaje apoyado por computadora: una experiencia en formación docente Introducción Ana María Bañuelos M. CUAED, UNAM El uso de la computadora en la Universidad Nacional Autónoma de México estuvo

Más detalles

Ingeniería en Sistemas Computacionales Clave de la asignatura: (Créditos) SATCA1 2-2-4

Ingeniería en Sistemas Computacionales Clave de la asignatura: (Créditos) SATCA1 2-2-4 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Calidad en Arquitectura de Software Carrera: Ingeniería en Sistemas Computacionales Clave de la asignatura: ARC-1303 (Créditos) SATCA1 2-2-4 2.- PRESENTACIÓN

Más detalles

Programa de experiencias educativas. Formato. Programa de estudio

Programa de experiencias educativas. Formato. Programa de estudio Programa de experiencias educativas Formato Programa de estudio 1.-Área académica Económico - Administrativa 2.-Programa educativo Licenciatura en Contaduría, Licenciatura en Administración 3.-Dependencia/Entidad

Más detalles

Gestión de. Requisitos previos. Carácter ECTS. Periodo NINGUNOO. Idiomas en Inglés. Departamento. Ciencias de. Presentación. Despacho y.

Gestión de. Requisitos previos. Carácter ECTS. Periodo NINGUNOO. Idiomas en Inglés. Departamento. Ciencias de. Presentación. Despacho y. = =drð^=al`bkqb qfqri^`flkbp=ab=do^al= TITULACIÓN: INGENIERÍA DE SISTEMAS DE INFORMACIÓN CURSO: Segundo ASIGNATURA: Ingeniería del Software I Nombre del Módulo o Materia al que pertenece la asignatura.

Más detalles

Carrera: GEC-0925 2-2 - 4

Carrera: GEC-0925 2-2 - 4 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Clave de la asignatura: (Créditos) SATCA 1 Habilidades Directivas II Ingeniería en Gestión Empresarial GEC-0925 2-2 - 4 2.- PRESENTACIÓN Caracterización

Más detalles

Denominación: Sistemas Operativos Multiusuario Área o campo de conocimiento: Clave: Semestre: 4

Denominación: Sistemas Operativos Multiusuario Área o campo de conocimiento: Clave: Semestre: 4 UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO FACULTAD DE CONTADURÍA Y ADMINISTRACIÓN DIVISIÓN SISTEMA UNIVERSIDAD ABIERTA Y EDUCACIÓN A DISTANCIA PLAN DE ESTUDIOS DE LA LICENCIATURA EN INFORMÁTICA Programa

Más detalles

Secretaría de Docencia Dirección de Estudios Profesionales

Secretaría de Docencia Dirección de Estudios Profesionales PROGRAMA DE ESTUDIO POR COMPETENCIAS PROGRAMACIÓN AVANZADA I. IDENTIFICACIÓN DEL CURSO Espacio Educativo: Facultad de Ingeniería Licenciatura: Ingeniería Mecánica Área de docencia: Administración Año de

Más detalles

Cultura empresarial. Carrera: SCE - 0405 2-2-6. Participantes. Representantes de la academia de sistemas y computación de los Institutos Tecnológicos.

Cultura empresarial. Carrera: SCE - 0405 2-2-6. Participantes. Representantes de la academia de sistemas y computación de los Institutos Tecnológicos. 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Clave de la asignatura: Horas teoría-horas práctica-créditos Cultura empresarial Ingeniería en Sistemas Computacionales SCE - 0405 2-2-6 2.-

Más detalles

Reflexiones en torno al Currículo para el Profesor de Matemáticas de Secundaria.

Reflexiones en torno al Currículo para el Profesor de Matemáticas de Secundaria. Reflexiones en torno al Currículo para el Profesor de Matemáticas de Secundaria. Prof. Luis Rico Departamento de Didáctica de la Matemática Universidad de Granada Logroño, enero 1997 Presentación dei problema:

Más detalles

UNIVERSIDAD LIBRE PROGRAMAS ANALÍTICOS PROGRAMA ACADÉMICO: ING. SISTEMAS. 1.- INFORMACION DEL DOCENTE Carlos Alberto Ocampo Sepúlveda

UNIVERSIDAD LIBRE PROGRAMAS ANALÍTICOS PROGRAMA ACADÉMICO: ING. SISTEMAS. 1.- INFORMACION DEL DOCENTE Carlos Alberto Ocampo Sepúlveda PROGRAMAS ANALÍTICOS SECCIONAL: PEREIRA FACULTAD: INGENIERIAS PROGRAMA ACADÉMICO: ING. SISTEMAS JORNADA: DIURNA 1.- INFORMACION DEL DOCENTE Carlos Alberto Ocampo Sepúlveda E-mail institucional: caos@unilibrepereira.edu.co

Más detalles

Competencias docentes asociadas a los procesos de aprendizaje de las matemáticas

Competencias docentes asociadas a los procesos de aprendizaje de las matemáticas Instituto INSTITUTO Pedagógico PEDAGÓGICO DE de FORMACIÓN PROFESIONAL Competencias docentes asociadas a los procesos de aprendizaje de las matemáticas Coordinador: Dr. Sergio Raúl García Mtz. PRESENTACIÓN

Más detalles

Modelos de desarrollo de software. septiembre de 2007 1

Modelos de desarrollo de software. septiembre de 2007 1 Modelos de desarrollo de software septiembre de 2007 1 Referencias básicas Ingeniería de software. Un enfoque práctico. Pressman, R. Quinta edición. Mc. Graw Hill 2002 Ingeniería de software. Sommerville,

Más detalles

Área Dominio de Contenidos Curriculares

Área Dominio de Contenidos Curriculares Área Dominio de Contenidos Curriculares PRIMER TALLER DE ORIENTACIÓN E INDUCCIÓN PARA EL EXAMEN DE NUEVO INGRESO AL SERVICIO EDUCATIVO NIVEL BÁSICO: PRIMARIA 2010-2011 Esta edición estuvo a cargo del Grupo

Más detalles

Carrera: IFM - 0435 3-2-8. Participantes. Representantes de la academia de sistemas y computación de los Institutos Tecnológicos.

Carrera: IFM - 0435 3-2-8. Participantes. Representantes de la academia de sistemas y computación de los Institutos Tecnológicos. 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Clave de la asignatura: Horas teoría-horas práctica-créditos Sistemas de Información II Licenciatura en Informática IFM - 0435 3-2-8 2.- HISTORIA

Más detalles

INTEGRACION DE BASES DE DATOS EN LA WEB

INTEGRACION DE BASES DE DATOS EN LA WEB 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Clave de la asignatura: INTEGRACION DE BASES DE DATOS EN LA WEB Ingeniería en Tecnologías de la Información y Comunicaciones DSD-1202 SATCA1

Más detalles

Curso Básico de Formación Continua para Maestros en Servicio. Relevancia de la profesión docente en la escuela del nuevo milenio

Curso Básico de Formación Continua para Maestros en Servicio. Relevancia de la profesión docente en la escuela del nuevo milenio Curso Básico de Formación Continua para Maestros en Servicio Relevancia de la profesión docente en la escuela del nuevo milenio El Curso Básico de Formación Continua para Maestros en Servicio, Relevancia

Más detalles

DIPLOMADO EN DOCENCIA UNIVERSITARIA DE LA UNIVERSIDAD DE SANTIAGO DE CHILE: MEJORAR LA DOCENCIA PARA MEJORAR LA RETENCIÓN ESTUDIANTIL

DIPLOMADO EN DOCENCIA UNIVERSITARIA DE LA UNIVERSIDAD DE SANTIAGO DE CHILE: MEJORAR LA DOCENCIA PARA MEJORAR LA RETENCIÓN ESTUDIANTIL DIPLOMADO EN DOCENCIA UNIVERSITARIA DE LA UNIVERSIDAD DE SANTIAGO DE CHILE: MEJORAR LA DOCENCIA PARA MEJORAR LA RETENCIÓN ESTUDIANTIL Línea Temática: Prácticas para la reducción del abandono: acceso, integración,

Más detalles

3-2-8. Participantes

3-2-8. Participantes 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Clave de la asignatura: Horas teoría-horas práctica-créditos: METODOLOGIAS AGILES Licenciatura en Informática 3-2-8 2.- HISTORIA DEL PROGRAMA

Más detalles

NOMBRE DEL TALLER: Eje temático: Comunicación. Autor: Marisol Hernández Corona. Institución de procedencia. Escuela de Técnicos Laboratoristas

NOMBRE DEL TALLER: Eje temático: Comunicación. Autor: Marisol Hernández Corona. Institución de procedencia. Escuela de Técnicos Laboratoristas NOMBRE DEL TALLER: Desarrollo de habilidades tecnológicas en el docente para diseñar páginas web, integrando herramientas para el trabajo colaborativo y en tiempo real que permite fortalecer su actividad

Más detalles

PROGRAMA DE ESTUDIO POR COMPETENCIAS SOCIOLOGIA. Programa elaborado por: L.S. Martín José Chong Campuzano Lic.Ludivina Del Rayo Estrada Herrera

PROGRAMA DE ESTUDIO POR COMPETENCIAS SOCIOLOGIA. Programa elaborado por: L.S. Martín José Chong Campuzano Lic.Ludivina Del Rayo Estrada Herrera PROGRAMA DE ESTUDIO POR COMPETENCIAS SOCIOLOGIA I. IDENTIFICACIÓN DEL CURSO Espacio Educativo: Facultad de Ingeniería Licenciatura: Ingeniería electrónica Área de docencia: Ciencias Sociales y Humanidades

Más detalles

Carrera: SCM - 0413 3-2-8. Participantes. Representantes de la academia de sistemas y computación de los Institutos Tecnológicos.

Carrera: SCM - 0413 3-2-8. Participantes. Representantes de la academia de sistemas y computación de los Institutos Tecnológicos. 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Clave de la asignatura: Horas teoría-horas práctica-créditos Fundamentos de desarrollo de sistemas Ingeniería en Sistemas Computacionales SCM

Más detalles

Benemérita Universidad Autónoma de Puebla Vicerrectoría de Docencia Dirección General de Educación Superior Facultad de Ingeniería Química

Benemérita Universidad Autónoma de Puebla Vicerrectoría de Docencia Dirección General de Educación Superior Facultad de Ingeniería Química PLAN PLAN DE ESTUDIOS (PE): Licenciatura en Ingeniería Química. Licenciatura en Ingeniería Ambiental. Licenciatura en Ingeniería en Alimentos Licenciatura en Ingeniería Agroindustrial. Licenciatura en

Más detalles

PROGRAMA ANALÍTICO DE LA UNIDAD DE APRENDIZAJE

PROGRAMA ANALÍTICO DE LA UNIDAD DE APRENDIZAJE I. IDENTIFICACIÓN DE LA UNIDAD DE APRENDIZAJE Programa Educativo en el que se imparte: PROGRAMA ANALÍTICO DE LA UNIDAD DE APRENDIZAJE Fecha de elaboración Julio 2012 Fecha última revisión Julio 2013 Unidad

Más detalles

1.- DATOS DE LA ASIGNATURA. Sistema de Gestión de la Calidad: ISO 18000 Ingeniería en Gestión Empresarial. Nombre de la asignatura: Carrera:

1.- DATOS DE LA ASIGNATURA. Sistema de Gestión de la Calidad: ISO 18000 Ingeniería en Gestión Empresarial. Nombre de la asignatura: Carrera: 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Clave de la asignatura: (Créditos) SATCA 1 4-2- 6 Sistema de Gestión de la Calidad: ISO 18000 Ingeniería en Gestión Empresarial 2.- PRESENTACIÓN

Más detalles

CARTA DESCRIPTIVA (FORMATO MODELO EDUCATIVO UACJ VISIÓN 2020)

CARTA DESCRIPTIVA (FORMATO MODELO EDUCATIVO UACJ VISIÓN 2020) CARTA DESCRIPTIVA (FORMATO MODELO EDUCATIVO UACJ VISIÓN 2020) I. Identificadores de la asignatura Instituto: IADA Modalidad: Presencial Departamento: Materia: Diseño Planeación y Diseño de Producto Créditos:

Más detalles

PROGRAMA ANALÍTICO DE LA UNIDAD DE APRENDIZAJE

PROGRAMA ANALÍTICO DE LA UNIDAD DE APRENDIZAJE PROGRAMA ANALÍTICO DE LA UNIDAD DE APRENDIZAJE I. IDENTIFICACIÓN DE LA UNIDAD DE APRENDIZAJE Programa Educativo: Fecha de elaboración Fecha última revisión Julio 2012 Diciembre 2013 Unidad de Aprendizaje:

Más detalles

INGENIERIA DE SOFTWARE

INGENIERIA DE SOFTWARE CURSO: INGENIERIA DE SOFTWARE 1 SEMESTRE: VI 2 CODIGO: 602601 3 COMPONENTE: 4 CICLO: 5 AREA: Profesional 6 FECHA DE APROBACIÓN: 2010 7 NATURALEZA: Teórica - Practica 8 CARÁCTER: Obligatorio 9 CREDITOS

Más detalles

Pontificia Universidad Católica del Ecuador

Pontificia Universidad Católica del Ecuador 1. DATOS INFORMATIVOS: MATERIA O MÓDULO: INGENIERÍA DE SOFTWARE I CÓDIGO: CARRERA: SISTEMAS NIVEL: QUINTO No. CRÉDITOS: 4 CRÉDITOS TEORÍA: 4 SEMESTRE/AÑO ACADÉMICO: Segundo Semestre 2011-2012 CRÉDITOS

Más detalles