本文探讨了在教室中教学生如何编程的需求，而无需使用通常暴露的技术，如果没有的话，新建议可以使学生以更具说服力的方式学习，并且可以与学生进行更个性化的对话。老师，使他感到很舒服。
它还可以帮助学生提高能力，因此可以通过这种实施方法在与软件开发相关的过程中找到效率。术语索引-XP，编程，UML，java。
在编程课程的课堂中，特别是在波帕扬大学基金会中，在教育领域出现的困难之一；工作或学习以学习大学的大多数编程课程的学生的稀缺经验和倾向。
大多数学生为此做好准备，这就是为什么不仅关注软件社区，而且关注学术社区，因为他们的方法过于繁琐和缺乏耐力，他们已开始致力于开发软件。提高学生参与度的技巧。
与其使用仅使学生担心如何赢得一门学科的学习计划，不如使用这种方法，他们并没有为应对日常生活中的挑战做好准备，因为这是真正应用知识的地方。
教师在编程教学中使用了许多方法，例如：
| 选择课程教科书时遇到的困难之一；
• 软件开发是重点 • 选择编程环境； 教师要获得的产品，而不是专注于 • 教学方法的变化； 提出质量解决方案的技术和方法。作业中的变化。 考虑到以上情况，在治疗时 极限编程或极限编程来介绍语言的教学 （XP）是一种软件工程方法 编程和Java一样，我们必须接受第一本书的作者肯特·贝克（Kent Beck）的表述，他认为，技能，主题“极限编程说明：掌握编程的速度和知识的天赋”差异很大。 变化（1999）。这是学生过程中最突出的部分，这就是为什么关注敏捷软件开发的原因。一个人面临的困难是不可能的 它是一种敏捷的方法论，致力于增强班级中那些容易解决的问题，因为在班级中存在许多人际关系是学生成功的关键，以这种方式，教师必须寻求软件开发，以各种替代方式促进工作，从而有助于以学生为团队，关心学习的过程。开发人员，并营造良好的工作环境。 |
选择第一种编程语言；
XP基于客户与开发团队之间的持续反馈，所有参与者之间的流畅沟通，简化的已实施解决方案以及勇于面对变化的基础。
XP被定义为特别适用于需求变化多，要求不严格，技术风险高的项目。
牢记XP是基于上述内容的，即为教育设计方法提供有效且有效的解决方案可能会有利可图；因为传统的工具到目前为止还没有用。
在这种情况下，出现了一个问题：如何将敏捷方法XP（极限编程）应用于编程中的普通教育方法？正是在这种情况下，我们的工作为使用FUP的学生提供了使用XP（极限编程）的教学方法。为此，我们首先对学生的编程能力进行诊断，然后提出一种用于编程教学的敏捷XP方法论。该方法论被波帕扬大学基金会的学生所采用。
在这项工作中，我们探索在开发教学活动以促进学习的过程中使用敏捷XP方法的目的，从而形成一个框架的目的，该框架的阶段和活动可以定义方法论上确保其质量的生命周期。我们将使用该框架来建议可以使教学更加敏捷的实践。因此，打算在Popayán大学基金会为系统工程专业的学生推广一种新的方法论，特别是在Java编程领域，使用极限编程作为软件开发过程中的工具，因为它减少了分析，开发和执行时间。这样，可以提高教室中学生制作的软件的质量。
二。最先进的
A.传统方法
ACM和IEEE-CS共同提出了一份名为Software Engineering 2004（SE2004）的文档，该文档为软件工程的本科教育提供了建议。本文档为软件工程教育知识（SEEK），其中包括所有毕业生都应该知道的主题列表，以及一系列实施课程的准则和一系列建议的课程。以下列表总结了软件工程师毕业时应具备的知识和技能：
- 表现出对必要的知识和技能的掌握，以开始您作为软件工程师的专业实践。单独工作和团队合作，开发和生成可执行软件。调解冲突的目标，在成本，时间和知识限制内找到可接受的折衷方案，先前存在的系统和组织，使用融合了道德，社会，法律和经济方面的工程方法，在一个或多个应用程序域中设计适当的解决方案，展示出理解力，并能够运用当前的理论，模型和技术，为识别产品和服务提供基础问题和分析，软件设计，开发，实施和验证，进行谈判，有效开展工作，在需要时发挥领导作用，并在典型的软件开发环境中与各种利益相关者进行良好的沟通，了解新模型，新技术和新技术的出现，并意识到持续进行专业开发的必要性。
考虑到上述情况，表1中显示了它，这是通常用于向系统工程专业学生教授编程的传统方法：
| 表1.传统方法（如何教授编程） |
| 1.对象和类，参数。 |
| 2.了解类的定义：类，字段的定义， |
| 构造函数，方法。 |
| 与对象的交互：创建对象的对象，多个构造函数。 |
| 将对象分为灵活大小的集合（ArrayList）和固定大小的集合（Array）。 |
| 使用类库 |
| 测试与调试 |
| 设计类：内聚，代码重复，代码重用 |
| 具有继承性的结构 |
| 多态性 |
| 抽象类和接口。 |
| 静态方法-主要方法。 |
| 老师，在这种情况下，他执行委托人的职能。 |
| 计划：在这种情况下，老师将负责计划需求，并以什么顺序进行工作并不断进行审查。 |
| 客户测试：在这种情况下，教师会提出测试以验证迷你版本是否正常工作。 |
| 小型版本：由于该提案的应用领域，将开发小型且有用的软件版本。 |
| 设计简单：系统会要求您以最简单的方式开发迷你版本。 |
| 程序员对：将组成每个工作站由两个学生组成的工作组，并且在每个实验室会议中，他们将轮换一次，以使项目的所有成员都知道代码。 |
| 设计改进：按班级轮换安排，可以改进软件设计。 |
| 持续集成：持续将迷你版本集成到项目中。 |
| 该代码属于每个人：所有代码对都将轮换使用，并可以在其他组的微型版本中使用，并且代码将是项目所有协作者的财产。 |
| 编码标准：保持通用的开发风格（待定义）。 |
| 隐喻：程序的每个部分都将由名称定义，以便团队的所有成员都能理解它们。 |
| 可持续的节奏：它将在所有课堂上都有效，不会间断。 |
| 表2. XP规则及其在提案中的应用 |
| 完整的团队：完整的团队将由教室组成，包括 |
B.极限XP编程
敏捷软件开发方法论着重于人为因素以及基于小版本的软件产品，从而为与客户一起进行的个人协作工作和软件开发提供了更多价值。 ，他们可以在整个产品开发过程中不断监视该软件产品。这样的极限编程是当今最流行的敏捷软件开发方法，因为它试图改变传统的软件开发概念，在这种概念中，注意力集中在以某种方式建立项目开始时的所有软件需求上。它不需要后续修改，通过一种新方法，其中在认为有必要且不影响项目的情况下寻求软件的灵活性进行修改。下表2所示，其中包含极限编程的规则以及如何将其应用到我们的研究中。
以下是一些指导我们进行研究的相关著作。
软件公司Role Model Software已实施了另一种培训软件开发人员的模型，称为“ Software Studio”，其结构类似于中世纪的手工艺作坊，新手开发人员可在此学习主要开发人员的知识。教师通过大声说出专家的解决方案来解决问题，而学习者观察，学习和执行次要任务，而老师则可以自由地执行较困难的任务。随着时间的推移，学徒面临着更困难的问题，他们与同龄人一起学习贸易的各个方面。这种模式有利于加速从老师那里学习专业技能，从而提高从错误中学到的知识。学习者获得的技能基于XP的价值观，原理和实践，它们为学习上述所有方面提供了自然的环境。
Nuestro artículo toma algunas estrategias de este estudio, pero sin entregar a los estudiantes tareas menores y luego exponerlos a problemas más difíciles, en este caso estamos enfocados en seguir una metodología paso a paso con puntos específicos que hacen que el estudiante se interese más por aprender y desarrollar software.
Fred Brooks en su famoso artículo “No Silver Bullet” que corresponde en el lenguaje expresado como la complejidad accidental de un software:
- Comunicación: Un ingeniero de software debe dedicar gran parte de su tiempo comunicándose con diversas tipos de interlocutores, debiendo ser capaz de adaptar el grado de abstracción y de tecnicismos en sus conversaciones de acuerdo al lenguaje que domine su contraparte, y además debe ser capaz de escuchar e interpretar correctamente las necesidades expresadas por ellos, necesidades que muchas veces impactarán el diseño e implementación del sistema de software a desarrollar.Habilidad de trabajar en equipo: Toda ingeniería de software es ejecutada en equipos,
sin embargo esto es algo sobre lo cual los alumnos no reciben entrenamiento. Los ingenieros de software por lo general se destacan por características individuales, es por eso que XP (Programación a Pares) lleva a la persona a formarse en equipo, esto hace que las personas que se acostumbran a realizar acciones individuales (“heroicas”) no solo sean capaces de generar los productos (documentos, diseños, módulos) de lo que es responsable sino también poder encontrar un lugar dentro de un equipo de trabajo.
Instituto Técnico de Lund, en Suecia donde se realizaron dos ramos, uno a comienzos de la carrera, justo después de los ramos de programación básica, en el que se introduce el trabajo en equipo mediante XP, y otro curso posterior de profundización, orientado a la formación de coaches, cuya parte práctica es justamente dirigir a los equipos del primer curso. En dichos ramos, no sólo se enseñan las prácticas de XP “canónicas” (definidas originalmente por Kent Beck), sino muchas otras prácticas que han sido propuestas por la comunidad de desarrolladores que ha adoptado XP, y que complementan las propuestas por Beck.
Preconceptos de los alumnos versus XP
- A los alumnos no les agrada el trabajo adicional implicado por las metodologías tradicionales: Los alumnos suelen ser reticentes a procesos que exigen demasiado esfuerzo en producir artefactos intermedios tales como documentación, especificaciones y diseños detallados, etc., por lo que el énfasis de XP en producir código funcional por sobre generar documentación lo hace más atractivo a los alumnos. Los alumnos tienden a auto-presionarse para lograr la mayor cantidad de funcionalidades, a pesar de que no se les exija: En el caso del Instituto Técnico de Lund, los alumnos se rigen por la regla del “tiempo fijo”, es decir que los alumnos sólo tienen que disponer del tiempo predeterminado definido para realizar los proyectos del curso, pudiendo este tiempo ser destinado tanto a producir código como a aprender de errores cometidos, en lo que constituye una excelente interpretación de la práctica “40 horas a la semana”. Los alumnos son optimistas sobre el funcionamiento de su código: Este fenómeno, indica que los alumnos creen que su código funcionará correctamente sin la necesidad de programar pruebas. Esto tiene dos explicaciones: creer que la revisión interactiva resultante de la depuración es suficiente para validar los casos relevantes, y a la ignorancia acerca de los problemas que la evaluación del código puede provocar. Los alumnos prefieren trabajar en pasos grandes: La noción de trabajar en pasos pequeños resulta contra intuitiva para muchos, debido a que se cree que si se tiene diseñada una solución completa, lo anterior es una pérdida de tiempo. Este preconcepto se basa en la idea de que el diseño está 100% correcto (lo que nunca es así), y que una vez definido un diseño, éste no variará. Incomodidad ante cambios de requerimientos: Los alumnos suelen actuar con incomodidad ante los cambios de requerimientos naturales en todo proyecto de software, muchas veces pensando que esto implicará más trabajo, ignorando por ende el modelo de gestión ágil de alcance variable.
En ” los autores proponen desarrollar software por medio de la programación, usando la metodología ágil XP y de esta manera haya un aprendizaje; rápido, eficaz y con un conocimiento aplicado en la vida cotidiana. Este trabajo apoya nuestro estudio, ya que demuestra la necesidad que hay en los estudiantes por una metodología diferente, más didáctica que comprometa al estudiante a producir con eficiencia y por sobre todo a concientizar la necesidad de trabajar en equipo.
III.OBJETIVO GENERAL
Proponer una metodología de enseñanza utilizando XP (Extreme Programming), para estudiantes de programación de la FUP.
- OBJETIVOS ESPECÍFICOS Realizar un diagnóstico de las capacidades de programación de los estudiantes.
Implementar la metodología ágil XP vs Metodología tradicional con los estudiantes de la Fundación Universitaria de Popayán.
V. PROPUESTA
En la propuesta se desarrolló un estudio que contenía la siguiente información:
Primero se hizo un diagnóstico, luego se presenta la metodología usada y por último una encuesta de satisfacción.
Diagnóstico
Para realizar el diagnóstico se realizó la aplicación de una encuesta, diseñada con un cuestionario de 37 preguntas cerradas con selección de única respuesta, la cual fue aplicada en formato físico y se evaluaban los conceptos básicos de programación java, bases de datos y UML, las cuales contenían preguntas básicas acerca del conocimiento adquirido de semestres anteriores. Se realizó a los estudiantes de la Fundación Universitaria de Popayán, del programa de Ingeniería de Sistemas VIII semestre diurno y nocturno. La encuesta produjo un total de 20 alumnos encuestados siendo esta una muestra representativa de estos estudiantes.
Fórmula Estadística
Para calcular los resultados obtenidos en cada una de las encuestas se usó la siguiente fórmula:
v = (x*y)/z
x: Total de respuestas acertadas y: Porcentaje z: Total de preguntas (cada una de las encuestas)
- Total de respuestas sale de la suma total de cada una de las respuestas acertadas. Porcentaje siempre será el 100% en cada encuesta. Total de preguntas sale de multiplicar el total de ellas por el total de las encuestas realizadas.
- Encuesta Bases de Datos:
| Respuestas acertadas | 50,4166667 |
| Respuestas erróneas | 49,5833333 |
Ilustración 1: Resultados Obtenidos Bases de Datos
De acuerdo a los resultados arrojados que otorga esta grafica donde se evalúa conocimientos de bases de datos, se logra observar que todos los indicadores evaluados se encuentran en un 50% tanto para preguntas acertadas como las erróneas.
- Encuesta Programación Java:
| Respuestas acertadas | 59,25 |
| Respuestas erróneas | 41 |
Ilustración 2: Resultados Obtenidos Java
En relación a la encuesta de programacion java se presentó un nivel de acertacion del 59% con respecto a las preguntas erroneas evaluadas con un 41%.
- Encuesta UML:
| Respuestas acertadas | 56 | |
| Respuestas erróneas | 44 |
Ilustración 3: Resultados Obtenidos UML
Se observa que el 56% de los participantes contestaron la encuesta de evaluacion de conocimientos basicos UML con un nivel medio de acertacion.
- Encuesta General:
| Total Respuestas | 100% | Total Preguntas | |||
| 414 | 100 | 740 | |||
| 327 | 100 | 740 | |||
| En general acertadas | 55,94594595 | ||||
| En general erróneas | 44,18918919 | ||||
Ilustración 4: Resultados Obtenidos Encusta General
En general los indicadores de preguntas acertadas de la metodología aplicada se encuentran sobre el 56%, se observa que el conocimiento que los estudiantes han adquirido en sus estudios universitarios presenta bajo nivel de aceptación.
Hipótesis de la investigación
Las hipótesis que se busca poner a prueba en esta investigación son:
- Es posible la reproducción efectiva de un ambiente de desarrollo ágil (XP) en las clases de ingeniería de sistemas de la FUP: Se puede ofrecer a los alumnos de ingeniería de sistemas de la FUP una experiencia representativa de las metodologías ágiles – en particular Extreme Programming – dentro del marco, recursos y tiempo de un semestre de la carrera.La exposición de los alumnos a un desarrollo auténtico en un ambiente ágil genera buenos aprendizajes sobre las metodologías ágiles: Gracias a la naturaleza de los ambientes de desarrollo ágil, que están orientados a potenciar el aprendizaje continuo en sus integrantes para así lograr la mayor productividad, al reproducirlos fielmente en el contexto de un curso de Ingeniería de Sistemas se obtienen buenos resultados en los aprendizajes de los alumnos.
A continuación se presenta la propuesta elaborada a partir de las hipótesis anteriores.
Tabla No 3
| Hipótesis | Propuesta |
| Es posible la reproducción efectiva de un ambiente de desarrollo ágil (XP) en las clases de ingeniería de sistemas de la FUP. | Un diseño instruccional que configura una clase de
Ingeniería de Sistemas en un ambiente de trabajo representativo de XP |
| La exposición de los alumnos a un desarrollo auténtico en un ambiente ágil genera buenos aprendizajes sobre las metodologías ágiles | Una conceptualización de como XP organiza en ambiente de desarrollo de software para lograr armonizar los diversos componentes de éste y lograr así una construcción continua de conocimiento y valor. Un modelo evaluativo basado en la conceptualización anterior, que servirá para medir los aprendizajes de los alumnos a los que se les aplica el modelo instruccional nombrado anteriormente. |
Imagen 1
Sistema de evaluación
La evaluación que se propone para llevar a cabo la metodología XP está enfocada para ser aplicada durante el semestre de clases, tiene 3 componentes y está divido por 3 roles con su respectiva planificación que podría mejorar la calidad de la enseñanza en los estudiantes de la FUP.
Componentes:
Evaluación de resultado (Ponderación: 30%):
Como todo curso de desarrollo software, no debe omitirse la meta de lograr un software satisfactorio en los tiempos y plazos estipulados. Se basa en la calidad del producto de software desarrollado, y considera en ella la opinión del propio cliente.
Evaluación de proceso (Ponderación: 40%):
Esta evaluación considera los siguientes aspectos:
- Cumplimiento de tareas: puntualidad y cumplimiento requisitos estipulados por el profesorCo-evaluación: Evaluación recibida por el alumno de sus pares, de acuerdo a su dedicación, responsabilidad y capacidad de trabajo en equipo.
Evaluación experimental (Ponderación: 30%): En forma grupal e individual los alumnos deberán reflexionar y evaluar la metodología aprendida, considerando:
- Aplicación: el grado de uso y la dificultad relativa experimentada en cada práctica.Utilidad: qué tan útiles fueron las prácticas enseñadas.
Para aprobar el curso, el alumno debe lograr una calificación superior o igual a 4.0 en los tres componentes especificados. En caso de que el alumno no logre el 4 en alguno de éstos tópicos, deberá realizar un trabajo adicional.
Roles:
Apreciando la ilustración 6 podemos observar los roles que se plantea para llevar a cabo la metodología XP, en donde participan los estudiantes, el profesor que a su vez sería el cliente el cual tiene el conocimiento del problema y es quien explica, orienta el uso de las prácticas, principios y valores de la metodología.
Ilustración 5: Roles Planificación del curso:
El formato del curso es de sesiones de 4 horas de trabajo presencial a la semana y 8 horas de trabajo de investigación autónoma. Se dispone de un profesor y los estudiantes previamente matriculados académicamente y el trabajo se dividirá en grupos de 2 personas. Tal como se puede apreciar en la Tabla No 8 el curso está estructurado en dos grandes secciones, las que serán descritas a continuación. Fase Teórica (3 a 4 sesiones)
En esta fase todo el curso colabora para explorar en detalle en qué consiste XP. La primera sesión es dictada por el profesor, quien presenta los fundamentos que dieron origen a las metodologías ágiles y a XP en particular, haciendo una breve revisión del estado del arte de la Ingeniería de software y enfatizando las razones que motivan el surgimiento de esta nueva mirada al desarrollo de software.
El involucramiento temprano de los alumnos se logra por los siguientes medios:
- Deben discutir en grupo y luego presentar sus conocimientos previos sobre XPSe realiza un “extreme hour” o una simulación para poder entender de manera más simple cómo funciona el modelo de gestión de XP.Los alumnos realizan debates sobre prácticas de XP en las sesiones posteriores, de preferencia escogiendo ellos mismos los temas presentados
Tabla No 4
| Actividades | |||
| En horas de clase | Fuera de clase | ||
| 0 | Introducción al curso | Informe sobre conocimientos previos | |
| 1 | Presentaciones iniciales | Informes de opinión y dudas sugeridas a partir de lo expuesto en clase | |
| 2 | |||
| 3 | Desarrollo del proyecto usando XP |
Generación de ensayo de XP y su aplicación Investigaciones con soluciones específicas con respecto al desarrollo o a la metodología. Generación de informe del desarrollo software y la aplicación XP en el sistema de información. |
|
| 4 | |||
| 5 | |||
| 6 | |||
| 7 | |||
| 8 | |||
| 9 | |||
| 10 | |||
| 11 | |||
| 12 | |||
| 13 | |||
| 14 | |||
| Presentación final – grupal | Generación de informe sobre la aplicación de XP en el proyecto y su
proyección futura |
Fase Práctica
En esta fase se comienza a practicar la versión “miniaturizada” de XP, que restringe el desarrollo a la duración de la sesión (4 horas). La sesión inicial parte con un “Planning game”, en donde se define el alcance de la iteración.
A partir de entonces, cada sesión tiene una estructura de manera similar, tal como se presenta en la Tabla 5:
| Momento | Descripción |
|
Preparación del ambiente de trabajo. |
Consiste en convertir la sala de clases del curso en un ambiente propicio de trabajo. En particular: Instalación de equipos (los necesarios para dictar la clase) con conectividad a red.
Disposición de puestos de trabajo: se |
| semana. En el caso de los alumnos que faltaron a la sesión, se definen las tareas de desarrollo con las que deberán devolver las horas de trabajo que sus compañeros ya aportaron. | |
|
Sesión y vuelta a la normalidad de la sala |
El ambiente de trabajo configurado en la sala es retirado: las mesas, sillas y los computadores son devueltos a su posición normal, los tableros totalmente limpios y la información es guardada por los alumnos para poderla utilizar la clase siguiente. |
| cambia la disposición de mesas y sillas para facilitar la programación de a pares y la rotación dentro del equipo.
Los alumnos disponen en el tablero de la sala los las historias de usuario que deben completar |
|
|
Stand-up meeting |
Tal como lo indica la práctica de XP, el equipo se reúne de pie y se pone al día acerca de cuál es el estado de avance. Luego se coordinan y distribuyen las metas de la sesión. |
|
Desarrollo |
Este es el momento del trabajo de desarrollo en sí. La dinámica del trabajo sucede tal como en XP: cada desarrollador se ha anotado para el desarrollo de alguna tarea específica, para lo cual solicita la ayuda de algún compañero para trabajar de a pares. En caso de dudas sobre la historia de usuario o dudas metodológicas deben consultarle al profesor.
También se le van presentando al profesor las historias de usuario para su aprobación de acuerdo a las pruebas funcionales anteriormente definidas con él en el planning game. Respetando el principio de adaptabilidad al cambio, el profesor puede en cualquier momento cambiar historias de usuario. Con respecto a los descansos, durante la fase teórica, es el profesor quien define un receso en la mitad de la sesión, en cambio en esta fase se motiva a los alumnos que tomen un descanso (razonable) cada vez que se han obtenido logros, o como una manera de despejarse en el caso de llevar demasiado tiempo empantanados en un problema. |
|
Reflexión final y asignación de tareas para la semana |
Al ir finalizando el tiempo de la sesión, el profesor motiva el cierre del trabajo, con el objeto de que el curso en conjunto pueda evaluar lo aprendido durante la sesión. Esto se realiza en un diálogo abierto moderado por el profesor.
Fruto de la reflexión, el profesor en conjunto con cada equipo define las tareas de investigación para la |
| Tabla No 6 | |
| Excelente | 98 |
| Aceptable | 57 |
| Malas | 5 |
| TOTAL PREGUNTAS | 160 |
Imagen 2
Encuesta de satisfacción de la Hipótesis: Se presentan los resultados obtenidos de acuerdo a la hipótesis que se propuso en nuestra investigación con los estudiantes de la Fundación Universitaria de Popayán, VIII Semestre de Ingeniería de Sistemas.
Ilustración 5: Resultados Obtenidos Encuesta
Satisfacción Hipótesis
De las 160 preguntas en total, el 98 de aquellas preguntas respondidas por los estudiantes de la Fundación Universitaria de Popayán aprueban la encuesta y la hipótesis de la propuesta.
VI.CONCLUSIÓN
Tal como se indicó al inicio de esta investigación, este artículo fue pensado para reflejar de la manera más fiel posible un ambiente de enseñanza en la programación mucho más ágil, y en particular, de XP. La observación informal de las encuestas del artículo mostró que los alumnos agradecían la experiencia vivida, y que se obtenían resultados bastante positivos de los alumnos que participaban de él. Todo lo anterior dio pie a la propuesta de esta investigación, que está descrita en el capítulo V.
REFERENCIAS
- Kuljis, «Orienting the Teaching of an Introductory Object-Oriented Programming to Meet the Learning Objective,» presented at the 26th Int. Conf. Information Techonlogy Interfaces ITI 2004, Cavtat, Croatia, June 7-10, 2004.Aubin, Verónica Blautzik, Leonardo Dejan, Gustavo Mejoras en el Proceso de enseñanza-aprendizaje de programación utilizando metodologías de la industria del software. No.1. 2011. pp.1.Gabriela Salazar Bermúdez, Desafíos del Curso de Ingeniería de Software Revista Educación en Ingeniería ISSN 1900-8260 Enero a Junio de 2012, Vol. 7, N°. 13, pp. 32-43 • © 2012 ACOFI. Talbott, N., Auer, K., “Apprenticeship in a Software Studio: An Old and New Model for Education”, Educator’s Symposium, OOPSLA 2000, Minneapolis, Minnesota, USA, October 15-19, 2000. pp. 49-51.Brooks, Fred. “No silver bullet: Essence and Accidents of Software Engineering”, Computer, Vol. 20, Nº 4 (April 1987): 10-19.Hedin, G., Bendix, L., Magnusson, B., “Teaching Software Development using Extreme Programming” en el “Book of Scandinavian Pedagogy of Programming Network” en: https://issuu.com/univida8/docs/revista-conciencia_-2015/191, pp. 586-593, 2003.Hedin, G., Bendix, L., Magnusson, B., “Introducing Software Engineering by means of Extreme Programming” Proceedings of the 25th International Conference on Software Engineering, pp. 586- 593, 2003.Williams, L., Upchurch, R. “Extreme Programming For Software Engineering Education?” 31st Annual Frontiers in Education Conference, 2001.Alfonso and Botia, An Iterative and Agile Process Model for Teaching Software Engineering, Proceedings of the 18th Conference on Software Engineering Education & Training, (CSEET’05), Abril 2005. pp. 9-16Kent Beck Planning Extreme programming https://www.researchgate.net/publication/4140018_An_Iterative_and_Agile_Process_Model_for_Teaching_Software_Engineering, October 12, 2000, pp.160.Patricio Letelier y Mª Carmen Penadés, Métodologías ágiles para el desarrollo de software: eXtreme Programming (XP), Universidad Politécnica de Valencia (UPV). No.1. 12 Nov 2003. pp.7.L. Ph.D. and M. C. P. Ph.D., «Metodologías ágiles para el desarrollo de software: eXtreme Programming (XP).» 12 de Noviembre de 2003 pp. 1-59.Xinogalos, et al., «Re-designing an OOP course based on BlueJ,» presented at the Seventh International Conference on Advanced Learning Technologies (ICALT’07), 2007.
