This article explores the need in the classroom to teach students how to program without the need for normally exposed techniques, if not with new proposals that lead the student to learn in a more didactic way, with a more personalized dialogue with the teacher and in this way make him feel comfortable.
It also helps the student to become more competent and therefore finds efficiency in the processes related to software development with this implemented methodology. Terms Index- XP, programming, UML, java.
One of the difficulties that arise in the field of education in the classroom of a programming course and especially in the Popayán University Foundation; It is the scarce experience and predisposition of students to work or study to learn most of the programming courses in universities.
Most students prepare for the moment, that is why it is not only the software community that is concerned, but also the academic community, since their methodology is too thick and resistant, and they have begun to work on the development of techniques to increase student participation.
Instead of using study plans that only make the student worry about how to win a subject, but really with this methodology they are not preparing them for the challenges of daily life, since that is where that knowledge is really applied.
Many methods have been used by teachers in teaching programming, such as:
| One of the difficulties encountered in the choice of the course textbook;
• software development is the emphasis placed on • The choice of the programming environment; teachers to the product to be obtained and does not focus on • Variations in teaching methods; the techniques and methods that propose quality solutions. Variations in assignments. Taking into consideration the above, when treating Extreme Programming or eXtreme Programming to introduce the teaching of a language of (XP) is an approach to software engineering Programming, as is Java, we must take in formulated by Kent Beck, author of the first book on the account that there is great diversity in skills, subject, Extreme Programming Explained: Embrace speed in learning and aptitudes of the Change (1999). It is the most prominent of the student processes, that is why the attention on agile software development. difficulties faced by a person cannot be It is an agile methodology focused on enhancing those easily treated in a class in which there are many interpersonal relationships as a key to success in students, in such a way that teachers must seek software development, promoting work in various alternative ways that help to the students as a team, caring for the learning of their learning. developers, and fostering a good work environment. |
The choice of the first programming language;
XP is based on continuous feedback between the client and the development team, fluid communication between all participants, simplicity in implemented solutions and courage to face changes.
XP is defined as especially suitable for projects with highly changing and imprecise requirements, and where there is a high technical risk.
Bearing in mind that XP is based on the aforementioned, that is where it can be profitable to give effective and efficient solutions to design methodologies for education; since the traditional ones have not been useful so far.
In this scenario the question arises: How to apply agile methodology XP (Extreme Programming) for common education methodologies in programming? It is precisely in this scenario where our work proposes a teaching methodology using XP (Extreme Programming), for programming students of the FUP. To do this, we first carry out a diagnosis of the programming capacities of the students, then we propose an agile XP methodology for teaching programming. This methodology is applied in the students of the Popayán University Foundation.
In this work we explore the use of the agile XP methodology in the development of pedagogical activities facilitating learning with the purpose of formalizing a framework whose phases and activities allow defining life cycles that methodologically ensure their quality. We are going to use this framework to suggest practices that can make teaching more agile. Therefore, it is intended to promote a new methodology at the University Foundation of Popayán for students of Systems Engineering, especially in the area of Java Programming, using extreme programming as a tool in software development processes, since it reduces the analysis, development and execution time. In this way, the quality of the software produced by students in the classroom is improved.
II. STATE OF THE ART
A. Traditional Methodology
The ACM and the IEEE-CS have jointly proposed a document called Software Engineering 2004 (SE2004), which provides recommendations for undergraduate education in software engineering. This document, the Software Engineering Education Knowledge (SEEK), includes a list of topics that all graduates should know, as well as a series of guidelines for implementing curricula and a set of proposed courses. The knowledge and skills that a software engineer should have upon graduation can be summarized in the following list:
- Demonstrate mastery of a necessary set of knowledge and skills to begin your professional practice as a software engineer Work both individually and in teams to develop and generate executable software Reconcile conflicting goals, find acceptable compromises within cost, time, knowledge constraints, pre-existing systems and organizations Design appropriate solutions in one or more application domains, using engineering approaches that integrate ethical, social, legal and economic aspects Demonstrate understanding and be able to apply current theories, models and techniques that provide a basis for identification of problems and analysis, software design, development, implementation and verification Negotiate, work effectively, take leadership when needed,and communicate well with various stakeholders in a typical software development environment. Learn new models, techniques, and technologies as they emerge and appreciate the need for ongoing professional development.
Taking into account the aforementioned, it is shown in table No. 1, the traditional methodology normally used to teach Programming to Systems Engineering students:
| Table 1. Traditional Methodology (How Programming is taught) |
| 1. Objects and classes, parameters. |
| 2. Understanding definition of classes: definition of classes, fields, |
| constructors, methods. |
| Interaction with objects: objects creating objects, multiple constructors. |
| Grouping objects into collections of flexible sizes (ArrayList), collections of fixed size (Array). |
| Using class libraries |
| Testing and Debugging |
| Designing classes: cohesion, code duplication, code reuse |
| Structures with inheritance |
| Polymorphism |
| Abstract classes and interfaces. |
| Static methods - the main method. |
| the teacher, who in this case performs the functions of the client. |
| Planning: In this case, the teacher is the one who will plan the requirements and in what order they will be worked on and continuously reviewed. |
| Customer test: In this case the teacher proposes the tests to validate if the mini versions are working. |
| Small Versions: Due to the application area of the proposal, small and useful versions of software will be worked on. |
| Simple design: You will be asked to develop the mini versions in the simplest way possible. |
| Pair of programmers: Working groups of two students per workstation will be formed and they will rotate once for each laboratory session, in such a way that the code is known by all the members of the project. |
| Design improvement: The rotation of pairs by class sessions, allows the software design to be improved. |
| Continuous integration: Continuously integrate the mini versions to the project. |
| The code belongs to everyone: All the pairs will be rotated and will work in the mini versions of the other groups and the code will be the property of all the collaborators of the project. |
| Coding standards: Maintain a common development style (to be defined). |
| Metaphors: Each part of the program will be defined by names so that they are understood by all members of the team. |
| Sustainable rhythm: It will work in all class sessions, without interruptions. |
| Table 2. XP rules and their application in the proposal |
| Full Team: Full teams will be formed by classrooms, including |
B. Extreme XP Programming
Agile software development methodologies focus on the human factor, as well as on the software product, which is based on small versions, giving more value to the individual, collaborative work and software development together with the client., who can constantly monitor the software product throughout its development. Extreme programming as such is the most popular agile software development methodology today, as it seeks to change the traditional concept of software development, in which attention is focused on establishing all the software requirements at the beginning of the project in a way that it does not require subsequent modifications,by a new approach in which the flexibility of the software is sought for modifications when they are considered necessary and that they do not affect the project. Table No. 2 is shown below, which contains the rules on which extreme programming is based and how they could be applied in our research.
Below are some of the related works that have guided us towards our research.
The software company Role Model Software has implemented an alternative model to train software developers called "Software Studio" that resembles in its structure the medieval crafts workshop, where novice developers learn from master developers. The teacher solves problems by verbalizing expert solving strategies aloud, while learners observe, learn, and take on minor tasks, leaving the teacher free to take on the more difficult tasks. Progressively, the apprentices are exposed to more difficult problems, learning in this way together with their peers the various aspects of their trade. This model favors accelerated learning of expert skills from the teacher, which improves learning from learning from one's mistakes.The skills that learners acquire are based on the values, principles and practices of XP, which provide a natural context for learning all the aspects listed above.
Our article takes some strategies from this study, but without giving students minor tasks and then exposing them to more difficult problems, in this case we are focused on following a step-by-step methodology with specific points that make the student more interested in learning and develop software.
Fred Brooks in his famous article "No Silver Bullet" that corresponds in the language expressed as the accidental complexity of a software:
- Communication: A software engineer must spend a large part of his time communicating with various types of interlocutors, must be able to adapt the degree of abstraction and technicalities in his conversations according to the language that his counterpart dominates, and also must be able to listen to and correctly interpret the needs expressed by them, needs that will often impact the design and implementation of the software system to be developed. Ability to work in a team: All software engineering is executed in teams,
however this is something on which the students receive no training. Software engineers generally stand out for individual characteristics, that is why XP (Pair Programming) leads the person to form a team, this makes people who are used to performing individual ("heroic") actions not They are only capable of generating the products (documents, designs, modules) for which they are responsible but also being able to find a place within a work team.
Lund Technical Institute, in Sweden, where two branches were carried out, one at the beginning of the degree, just after the basic programming branches, in which teamwork is introduced through XP, and another subsequent deepening course, oriented to the training of coaches, whose practical part is precisely directing the teams of the first year. In these branches, not only are the “canonical” XP practices taught (originally defined by Kent Beck), but many other practices that have been proposed by the developer community that have adopted XP, and that complement those proposed by Beck.
Students' Preconceptions Versus XP
- Students dislike the extra work involved in traditional methodologies: Students are often reluctant to labor-intensive processes in producing intermediate artifacts such as detailed documentation, specifications and designs, etc., so XP's emphasis on producing functional code over generating documentation makes it more attractive to students. Students tend to push themselves to achieve the greatest amount of functionality, even though it is not required of them: In the case of the Lund Technical Institute, students are governed by the rule of "fixed time", that is, Students only have to have the defined predetermined time to carry out the course projects, this time being able to be used both to produce code and to learn from mistakes.in what constitutes an excellent interpretation of the practice "40 hours a week". Students are optimistic about how their code works: This phenomenon indicates that students believe that their code will work correctly without the need to program tests. This has two explanations: believing that the interactive review resulting from debugging is sufficient to validate the relevant cases, and ignorance about the problems that the evaluation of the code can cause. Students prefer to work in large steps: The notion of working in small steps is counterintuitive to many, because it is believed that if you have a complete solution designed, this is a waste of time. This prejudice is based on the idea that the design is 100% correct (which is never the case),and that once a design is defined, it will not change. Discomfort in the face of changes in requirements: Students tend to act with discomfort in the face of changes in natural requirements in all software projects, often thinking that this will involve more work, thus ignoring the agile management model of variable scope.
In "the authors propose to develop software through programming, using the agile XP methodology and in this way there is learning; fast, effective and with knowledge applied in everyday life. This work supports our study, since it demonstrates the need in students for a different, more didactic methodology that commits the student to produce efficiently and above all to raise awareness of the need to work as a team.
III.GENERAL OBJECTIVE
Propose a teaching methodology using XP (Extreme Programming), for programming students of the FUP.
- SPECIFIC OBJECTIVES To carry out a diagnosis of the programming capacities of the students.
Implement the agile methodology XP vs Traditional Methodology with the students of the Popayán University Foundation.
V. PROPOSAL
In the proposal, a study was developed that contained the following information:
First a diagnosis was made, then the methodology used is presented and finally a satisfaction survey.
Diagnosis
To carry out the diagnosis, a survey was applied, designed with a questionnaire of 37 closed questions with a single response selection, which was applied in physical format and the basic concepts of Java programming, databases and UML were evaluated. which contained basic questions about the knowledge acquired from previous semesters. It was carried out to the students of the University Foundation of Popayán, of the Systems Engineering program of the VIII day and night semester. The survey produced a total of 20 surveyed students, this being a representative sample of these students.
Statistical Formula
To calculate the results obtained in each of the surveys, the following formula was used:
v = (x * y) / z
x: Total correct answers y: Percentage z: Total questions (each of the surveys)
- Total answers comes from the total sum of each of the correct answers. Percentage will always be 100% in each survey. Total questions comes from multiplying the total of them by the total of the surveys carried out.
- Database Survey:
| Correct answers | 50.4166667 |
| Wrong answers | 49.5833333 |
Illustration 1: Results Obtained Databases
According to the results obtained from this graph where knowledge of databases is evaluated, it is observed that all the evaluated indicators are found in 50% for both correct and incorrect questions.
- Java Programming Survey:
| Correct answers | 59.25 |
| Wrong answers | 41 |
Illustration 2: Java Results Obtained
In relation to the Java programming survey, an accuracy level of 59% was presented with respect to the wrong questions evaluated with 41%.
- UML Survey:
| Correct answers | 56 | |
| Wrong answers | 44 |
Illustration 3: UML Results Obtained
It is observed that 56% of the participants answered the UML basic knowledge assessment survey with a medium level of accuracy.
- General Survey:
| Total Answers | 100% | Total Questions | |||
| 414 | 100 | 740 | |||
| 327 | 100 | 740 | |||
| Overall accurate | 55.94594595 | ||||
| Generally wrong | 44.18918919 | ||||
Illustration 4: Results Obtained General Survey
In general, the indicators of correct questions of the applied methodology are over 56%, it is observed that the knowledge that students have acquired in their university studies presents a low level of acceptance.
Research hypothesis
The hypotheses to be tested in this research are:
- Effective replication of an agile development environment (XP) is possible in FUP systems engineering classes: FUP systems engineering students can be offered experience representative of agile methodologies - in particular Extreme Programming - within the framework, resources and time of a semester of the degree. Exposing students to authentic development in an agile environment generates good learning about agile methodologies: Thanks to the nature of agile development environments, which are aimed at promoting continuous learning in its members in order to achieve greater productivity, when faithfully reproduced in the context of a Systems Engineering course, good results are obtained in the learning of the students.
The proposal made from the previous hypotheses is presented below.
Table No 3
| Hypothesis | Proposal |
| Effective reproduction of an agile development environment (XP) is possible in FUP systems engineering classes. | An instructional design that sets up a class of
Systems Engineering in a work environment representative of XP |
| Exposing students to authentic development in an agile environment generates good learning about agile methodologies | A conceptualization of how XP organizes the software development environment to achieve harmonization of its various components and thus achieve a continuous construction of knowledge and value. An evaluative model based on the previous conceptualization, which will serve to measure the learning of the students to whom the instructional model named above is applied. |
Image 1
Evaluation system
The evaluation that is proposed to carry out the XP methodology is focused to be applied during the semester of classes, it has 3 components and is divided into 3 roles with their respective planning that could improve the quality of teaching in FUP students..
Components:
Result evaluation (Weighting: 30%):
Like any software development course, the goal of achieving satisfactory software in the stipulated times and deadlines should not be overlooked. It is based on the quality of the software product developed, and considers in it the opinion of the client.
Process evaluation (Weighting: 40%):
This evaluation considers the following aspects:
- Completion of tasks: punctuality and fulfillment of the requirements stipulated by the teacher Co-evaluation: Evaluation received by the student from their peers, according to their dedication, responsibility and capacity for teamwork.
Experimental evaluation (Weighting: 30%): In a group and individual way, students should reflect and evaluate the methodology learned, considering:
- Application: the degree of use and relative difficulty experienced in each practice Usefulness: how useful were the practices taught.
To pass the course, the student must achieve a grade equal to or greater than 4.0 in the three specified components. In case the student does not achieve the 4 in any of these topics, he / she will have to do additional work.
Roles:
Appreciating illustration 6 we can observe the roles that are proposed to carry out the XP methodology, in which the students participate, the teacher who in turn would be the client who has knowledge of the problem and is the one who explains, guides the use of the practices, principles and values of the methodology.
Illustration 5: Roles Course planning:
The course format is sessions of 4 hours of classroom work per week and 8 hours of autonomous research work. There is a teacher and students previously enrolled academically and the work will be divided into groups of 2 people. As can be seen in Table No. 8, the course is structured in two large sections, which will be described below. Theoretical Phase (3 to 4 sessions)
In this phase the entire course collaborates to explore in detail what XP is. The first session is dictated by the professor, who presents the fundamentals that gave rise to agile methodologies and XP in particular, making a brief review of the state of the art of software engineering and emphasizing the reasons that motivate the emergence of this new perspective to software development.
Early involvement of students is achieved by the following means:
- They should discuss in a group and then present their previous knowledge about XPS. An “extreme hour” or simulation is carried out to be able to understand in a simpler way how the XP management model works. Students carry out debates about XP practices in subsequent sessions, preferably choosing the topics presented themselves
Table No 4
| Activities | |||
| In class hours | Out of class | ||
| 0 | Introduction to the course | Report on prior knowledge | |
| one | Initial presentations | Opinion reports and doubts suggested from what was presented in class | |
| two | |||
| 3 | Project development using XP |
Test generation of XP and its application Investigations with specific solutions with respect to development or methodology. Generation of report on software development and XP application in the information system. |
|
| 4 | |||
| 5 | |||
| 6 | |||
| 7 | |||
| 8 | |||
| 9 | |||
| 10 | |||
| eleven | |||
| 12 | |||
| 13 | |||
| 14 | |||
| Final presentation - group | Report generation on the application of XP in the project and its
future projection |
Practical phase
In this phase, the “miniaturized” version of XP begins to be practiced, which restricts development to the duration of the session (4 hours). The initial session starts with a “Planning game”, where the scope of the iteration is defined.
Thereafter, each session has a similar structure, as presented in Table 5:
| Moment | Description |
|
Preparation of the work environment. |
It consists of turning the classroom of the course into a conducive work environment. In particular: Installation of equipment (those necessary to teach the class) with network connectivity.
Layout of jobs: |
| week. In the case of students who missed the session, the development tasks with which they must return the hours of work that their colleagues have already contributed are defined. | |
|
Session and back to normality of the room |
The work environment set up in the room is removed: the tables, chairs and computers are returned to their normal position, the boards are completely clean and the information is saved by the students so that it can be used by the next class. |
| changes the arrangement of tables and chairs to facilitate pair programming and rotation within the team.
The students have on the board of the room the user stories that they must complete |
|
|
Stand-up meeting |
As the XP practice indicates, the team meets on their feet and catches up on their progress status. Then the goals of the session are coordinated and distributed. |
|
Development |
This is the time for the development work itself. The dynamics of work happens just as in XP: each developer has signed up for the development of a specific task, for which he requests the help of a colleague to work in pairs. In case of doubts about the user's history or methodological doubts, they should consult the teacher.
User stories are also presented to the teacher for approval according to the functional tests previously defined with him in the planning game. Respecting the principle of adaptability to change, the teacher can change user stories at any time. With regard to breaks, during the theoretical phase, it is the teacher who defines a break in the middle of the session, on the other hand, in this phase, students are encouraged to take a (reasonable) break every time they have achieved achievements, or as a way to clear up if you've been bogged down in a problem for too long. |
|
Final reflection and assignment of homework for the week |
At the end of the session, the teacher encourages the closing of the work, so that the whole course can evaluate what has been learned during the session. This is done in an open dialogue moderated by the teacher.
As a result of reflection, the teacher, together with each team, defines the research tasks for the |
| Table No 6 | |
| Excellent | 98 |
| Acceptable | 57 |
| Bad | 5 |
| TOTAL QUESTIONS | 160 |
Picture 2
Hypothesis satisfaction survey: The results obtained are presented according to the hypothesis that was proposed in our research with the students of the Popayán University Foundation, VIII Semester of Systems Engineering.
Illustration 5: Survey Results Obtained
Satisfaction Hypothesis
Of the 160 questions in total, 98 of those questions answered by the students of the Popayán University Foundation approved the survey and the hypothesis of the proposal.
VI. CONCLUSION
As indicated at the beginning of this research, this article was designed to reflect as closely as possible a much more agile teaching environment in programming, and in particular, XP. Informal observation of the article's surveys showed that the students appreciated the experience, and that quite positive results were obtained from the students who participated in it. All of the above gave rise to the proposal of this research, which is described in chapter V.
REFERENCES
- 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 Improvements in the programming teaching-learning process using methodologies from the software industry. No.1. 2011. pp.1.Gabriela Salazar Bermúdez, Challenges of the Software Engineering Course Revista Educación en Ingeniería ISSN 1900-8260 January to June 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, No. 4 (April 1987): 10-19. Hedin, G., Bendix, L., Magnusson, B.,“ Teaching Software Development using Extreme Programming ”in the "Book of Scandinavian Pedagogy of Programming Network" at: 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),April 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 and Mª Carmen Penadés, Agile Methodologies for Software Development Program (eXtreming), Polytechnic University of Valencia (UPV). No.1. 12 Nov 2003. pp.7.L. Ph.D. and MCP Ph.D., "Agile Methodologies for Software Development: eXtreme Programming (XP)." November 12, 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.net / publication / 4140018_An_Iterative_and_Agile_Process_Model_for_Teaching_Software_Engineering, October 12, 2000, pp.160.Patricio Letelier and Mª Carmen Penadés, Agile methods for software development: eXtreme Programming (XP), Polytechnic University of Valencia (UPV). No.1. 12 Nov 2003. pp.7.L. Ph.D. and MCP Ph.D., "Agile Methodologies for Software Development: eXtreme Programming (XP)." November 12, 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.net / publication / 4140018_An_Iterative_and_Agile_Process_Model_for_Teaching_Software_Engineering, October 12, 2000, pp.160.Patricio Letelier and Mª Carmen Penadés, Agile methods for software development: eXtreme Programming (XP), Polytechnic University of Valencia (UPV). No.1. 12 Nov 2003. pp.7.L. Ph.D. and MCP Ph.D., "Agile Methodologies for Software Development: eXtreme Programming (XP)." November 12, 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.D., "Agile methodologies for software development: eXtreme Programming (XP)." November 12, 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.D., "Agile Methodologies for Software Development: eXtreme Programming (XP)." November 12, 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.
