End-User Software Engineering in K-12 by Leveraging Existing

Curricular Activities

Ilenia Fronza and Claus Pahl

Free University of Bozen-Bolzano, Piazza Domenicani 3, 39100, Bolzano, Italy

Keywords:

End-User Software Engineering, K-12, High School.

Abstract:

In recent years, an increasing number of people (called “end-users”) have started to perform a range of activi-

ties related to software development, such as coding with domain-speciﬁc languages. The research in the area

of End-User Software Engineering (EUSE) aims at improving the quality of end-user-produced software by

paying attention to the entire software life cycle. The increasing number of activities dedicated to the diffusion

of coding in K-12 motivates the need of EUSE also in this environment. Students indeed will probably need to

produce software in their future careers (even if not professionally), and the quality of their software may be

crucial. In this work, we describe a didactic module in which the activities usually carried out in the existing

study programme are exploited to introduce software engineering principles. The module does not shift the

students’ attention from their main objectives and does not introduce additional lectures on software engineer-

ing topics. We describe the results of a ﬁrst edition of the module that involved 17 students in a trilingual

international high school. The results are promising and allow us to formulate hypotheses for further work,

such as extending our approach to other activities and observe if and when students will develop a “software

engineering mindset”, even without developing software.

1 INTRODUCTION

The gap between end-users and professional software

developers has narrowed noticeably: an increasing

number of people not only use software, but also par-

ticipate in the development process in order to solve

different types of problems. The evolution of the me-

aning of the term end-user well represents this phe-

nomenon. Indeed, the term end-user has been initi-

ally introduced as antonym of “professional develo-

per”, in order to distinguish those who use software

systems in their daily activities from those who create

software systems professionally. Today, the term end-

user encompasses a wide range of software-related

activities (Burnett and Myers, 2014), such as software

development with domain-speciﬁc languages (Ye and

Fischer, 2007).

The disadvantage of this phenomenon is the over-

all low quality of end-user-produced software. The

research ﬁeld of End-User Software Engineering

(EUSE) addresses this issue by looking beyond the

“creation” part of software, and paying attention to

the rest of the software life cycle (Burnett, 2009).

In the last decade, computational thinking has

been recognized as part of the key skills that must be

acquired by all students, regardless of the degree and

course of study (Wing, 2006). For this reason, activi-

ties are increasingly often proposed in K-12 to streng-

then computational thinking skills, in all disciplines

and also in non-vocational schools, where students

are less inclined to Science, Technology, Engineering

and Mathematics (STEM). The aim is to prepare stu-

dents for the characteristics of the current labour mar-

ket: information technology plays an important role,

independent of the chosen career, therefore being able

to creatively use technology to solve problems (rather

than being passive users) could make a difference. If

these activities in K-12 will achieve their objectives,

we can expect more and more end-users to be enga-

ged in non-professional programming activities in the

future (Fronza et al., 2014).

For this reason, it is important to equip students

with the necessary means to improve software qua-

lity: in their future career, developing (although not

professionally) reliable software could be crucial.

This means that EUSE, which aims at bringing the

beneﬁts of a Software Engineering (SE) approach to

end-users, ﬁnds an application also in K-12 to im-

prove the quality of students’ software. Moreover,

students can beneﬁt from the application of SE prin-

Fronza, I. and Pahl, C.

End-User Software Engineering in K-12 by Leveraging Existing Curricular Activities.

DOI: 10.5220/0006846702490255

In Proceedings of the 13th International Conference on Software Technologies (ICSOFT 2018), pages 249-255

ISBN: 978-989-758-320-9

249

ciples in other ﬁelds: for example, the ability to work

in an iterative and incremental way can be considered

transversal to many disciplines, and also to everyday

life.

Nevertheless, bringing SE principles to end-users

(and therefore also in K-12) sets a number of challen-

ges to EUSE’s researchers (Chimalakonda and Nori,

2013). For example, end-users often do not under-

stand the usefulness of learning SE principles, and are

focused exclusively on their speciﬁc objective (i.e.,

solving a speciﬁc problem). In this regard, the EUSE

approach is to respect end-users goals and working

habits, without aiming to transform them into profes-

sional software engineers with ad-hoc courses (Bur-

nett and Myers, 2014).

In this work, we describe a didactic module in

which we leverage the activities usually carried out

in the existing study programme to bring SE prin-

ciples inside the classroom. The module does not

shift students’ attention from their main objectives

and does not introduce additional lectures on soft-

ware engineering. This aspect is of paramount im-

portance in non-vocational schools. In these schools,

infact, on one hand one wants to create a mindset that

could improve the quality of any software produced

in the future; on the other hand, additional lectures on

SE would not be perceived as “useful”, especially by

those students who are less inclined to STEM.

We describe the results of the ﬁrst edition of the

module that involved 17 students in a trilingual in-

ternational high school in the city of Bolzano (Italy).

The results are promising and allow us to formulate

hypotheses for further work, such as extending our

approach to other activities and observing if and when

students will develop a “software engineering mind-

set”, even without developing software.

Section 2 describes the state of the art of EUSE

in primary and secondary schools; Section 3 descri-

bes the rationale of the proposed didactic module, and

Section 4 details its structure. Section 5 describes

the ﬁrst edition of the module, and Section 6 shows

its results. Section 7 discusses our results and draws

conclusions from this work, also proposing possible

directions for future work.

2 EUSE IN K-12: STATE OF THE

ART

The ﬁeld of End-User Software Engineering is quite

recent (Burnett, 2009), and only a few existing stu-

dies in the ﬁeld are dedicated to the speciﬁc case of

primary and secondary schools.

Meerbaum and Hazzan presented a mentoring

methodology on Agile for high schools (Meerbaum-

Salant and Hazzan, 2010).

In 2015, Fronza et al. designed and implemented

a course, in which the phases of the software develop-

ment process are leveraged to promote computational

thinking learning (Fronza et al., 2015).

The work of Bollin et al. underlined the need and

feasibility of teaching SE principles in K-12. Ac-

cording to the authors, SE can be a valuable means

to exercise a set of skills that are needed nowadays.

These capabilities include: group dynamics, psycho-

logy, communication skills, logic, planning, model-

ling, and computational thinking as an ability to solve

problems (Bollin et al., 2016).

In 2016, Kastl et al. achieved greater ﬂexibility

in software development projects in three secondary

schools in Germany, by applying Agile methods in

class (Kastl et al., 2016). Fronza et al., in 2017, fo-

cused on teaching SE to end-users, by proposing a

framework in which a series of Agile practices have

been adapted to the context of middle schools to teach

computational thinking (Fronza et al., 2017).

Teixeira Monteiro et al. have analyzed how the

technology used in their programme can introduce SE

elements in the software created by the participants

(Monteiro et al., 2016).

In this work we describe a didactic module that we

have designed to bring Software Engineering princi-

ples inside the classroom in the ﬁrst year of a non-

vocational high school. In order to respect end-users

goals and working habits, the module fosters software

engineering concepts by focusing only on the process

side and we do not introduce additional lectures on

software engineering.

3 RATIONALE OF THE

DIDACTIC MODULE

One of the challenges in the End-User Software Engi-

neering (EUSE) research ﬁeld is to identify the most

suitable software development process for each speci-

ﬁc type of end-user (Chimalakonda and Nori, 2013).

In this regard, Burnett and Myers recommend to re-

spect end-users’ goals and working style, which is

preferably opportunistic and incremental (Burnett and

Myers, 2014), collaborative (Costabile et al., 2008),

and by trial-and-error phases (Burnett and Myers,

2014).

This description brings back to mind the phi-

losophy of Agile software development, which favors

a ﬂexible, iterative approach, and focuses more on the

product than on the production of unnecessary docu-

mentation.

ICSOFT 2018 - 13th International Conference on Software Technologies

250

Recently, the idea of introducing Agile in the edu-

cational context has attracted researchers’ and edu-

cators’ attention, and some works have been produ-

ced to report some experiences in this direction (see

Section 2). However, these works confront an en-

vironment (school and university) in which the wa-

terfall development model has been for a long time

the most adopted (and taught) development strategy

(Kropp and Meier, 2013; Kastl et al., 2016). Adop-

ting an Agile approach, in fact, would require a con-

siderable effort to switch to an environment in which

the process by which students arrive at the product is

taken into consideration even more than the ﬁnal pro-

duct itself (Stegh

ofer et al., 2016).

This shift would provide, among its advanta-

ges, the chance of introducing SE principles even in

schools where students are less gifted at STEM sub-

jects. This would allow us to reach a larger number of

students, which is in turn important: in the current la-

bour market, indeed, there is a high probability to face

the need of creating software in a number of different

careers (Ye and Fischer, 2007).

The challenge is understanding how to leverage

existing curricular activities (that do not have soft-

ware development as a main objective) to foster SE,

without introducing speciﬁc lessons on the topic, thus

respecting the students’ objectives.

In this work we describe a didactic module that

we have designed to foster software engineering prin-

ciples in the ﬁrst year of a non-vocational high school.

The proposed module covers six hours of curricu-

lar activity, and leverages activities that are usually

carried out in the existing study programme (and do

not include software development). Therefore, follo-

wing the EUSE guidelines (Burnett and Myers, 2014),

our module does not shift the students’ attention from

their main objective and does not introduce additional

lectures on software engineering.

3.1 Methodologies and Practices

Extreme Programming (XP) is an Agile methodology

that integrates practices related both to project mana-

gement and to development process, by focusing on

continuous communication and programming practi-

ces (Beck, 2000). Our didactic module adopts XP as

a methodology, for two main reasons:

• it doesn’t require end-users to radically change

their work habits (see the introductive part of this

section);

• it helps end-users to organize their process by in-

troducing a series of light practices.

The positive aspect of XP is that it provides a set

of principles and practices to guide the development

process. Depending on the speciﬁc context and ob-

jectives, only a limited set of practices might be se-

lected. However, it is important to take into account

the existence of hidden dependencies among these

practices. For example, the application of collective

ownership of the code in isolation can lead to a cha-

otic situation (Fronza et al., 2018), which can be mi-

tigated by adopting other practices, such as pair pro-

gramming.

In the speciﬁc case of our didactic module, which

focuses on the process aspect, it is suggested to ap-

ply together the following XP practices (Fronza et al.,

2018):

• On-site Customer: the customer is always present

during the development process to provide conti-

nuous and direct feedback.

• Testing: different types of testing strategies are

possible, such as acceptance testing (to allow con-

tinuous customer’s feedback), and test-ﬁrst (to

test as soon as possible and thus minimize the cost

of long-term testing).

• User Stories: the objective of these informal pro-

totypes is to describe requirements in a language

that is understood both by the team and the custo-

mers.

• Small Releases: decomposition of software deve-

lopment activities in short iterations in order to

obtain timely and continuous feedback.

The next section illustrates how we have struc-

tured our didactic module in order to promote these

practices while performing one of the activities of the

existing syllabus, namely the creation of a set of sli-

des for a presentation. It should be noted that, for this

purpose, we do not move the students’ attention away

from their main objective, and we do not provide ad-

ditional lessons on SE.

4 STRUCTURE OF THE

DIDACTIC MODULE

The task of creating a set of slides for a presentation

(usually at the end of a project or activity) is often

considered a pure exercise of computer literacy; at the

end, the teacher evaluates the quality of the presen-

ted slides (i.e., the product), but the process needed

to create these slides is almost ignored. Being a very

common task, and trasversal to many disciplines, we

considered this task as a good candidate to be the fo-

cus of our didactic module.

End-User Software Engineering in K-12 by Leveraging Existing Curricular Activities

251

The initial requirement needs to be deliberately

vague (e.g., “prepare a presentation about the topic

X”), so as to require students (as in the case of soft-

ware engineering) to make an effort to understand the

problem and formulate a solution.

In total, this activity covers six hours (for example,

four blocks of 90 minutes). The remaining part of

this section details the structure of the module and the

assessment strategy.

4.1 First Part

The ﬁrst part includes the following activities:

1. Creation of a mind map (paper based exercise) to

better organize ideas within the topic of the pre-

sentation (for example: what sub-topics can be

discussed in the presentation?), and to identify

their relevance, strength, and impact, as well as

to describe the relationships between ideas. This

activity requires 20 minutes, and the relevant XP

practice is user stories.

2. Revision of mind maps, together with teachers.

This activity requires 15 minutes, and fosters the

following XP practices: on-site customer, small

releases.

3. Searching the necessary information (e.g., online)

in order to expand the topics in the mind map.

This activity requires 20 minutes, and the relevant

XP practice is small releases.

The second and the third step are repeated twice

(i.e., two iterations are performed).

4.2 Second Part

The second part includes the following activities:

1. Preparation of a set of slides about at least two of

the topics in the mind map. This activity requires

15 minutes, and the relevant XP practice is small

releases.

2. Teachers’ feedback. This activity requires 10 mi-

nutes, and the relevant XP practices are on-site cu-

stomer and testing.

3. Continuing the preparation of the set of slides.

This activity requires 20 minutes, and the relevant

XP practice is small releases.

4. Teachers’ feedback for 10 minutes. The relevant

XP practices are on-site customer and testing.

The third and the fourth step are repeated twice

(i.e., two iterations are performed).

4.3 Third Part

This part is entirely dedicated to teacher’s feedback.

Students are asked to present a “working prototype”

in order to receive the last feedback before the presen-

tation (during the fourth part). The teacher explains

the assessment criteria (see Section 4.5) and provides

speciﬁc feedback for each criterion. The relevant XP

practices are on-site customer and testing.

4.4 Fourth Part

At the end of the activity, each student presents her/his

set of slides in front of the class. The conformance

with the initial requirements and mind map are chec-

ked. Therefore, relevant XP practices are user stories

and testing. Moreover, the presentation provides an

opportunity for peer feedback.

4.5 Assessment Criteria

For the evaluation of the ﬁnal product (i.e., the set of

slides), we consider the following three criteria:

1. structure: general organization of the slides;

2. content: correctness and completeness of the re-

ported information;

3. citation of sources: this aspect is considered very

relevant in K-12, in order to teach students the im-

portance of giving credit to the creators of the ori-

ginal material.

Even if our didactic module focuses on the pro-

cess of preparation of slides, one single didactic mo-

dule does not allow us to assess the development of a

“software engineering mindset”. For this reason, for

the process side, we limit our assessment to observing

students’ behaviour. These observations, indeed, will

serve to the creation of an assessment framework for

the process part in our future modules.

5 FIRST EDITION OF THE

DIDACTIC MODULE

We have performed a ﬁrst case study in a trilingual in-

ternational high school in the city of Bolzano (Italy).

For the CS ﬁeld, this non-vocational high school in-

cludes in its curriculum:

• two hours per week of ICT in the ﬁrst and second

year, where students learn to evaluate, choose, and

use different tools in order to solve a problem;

ICSOFT 2018 - 13th International Conference on Software Technologies

252

• two hours per week of Computer Science in the

third, fourth and ﬁfth year. At the ﬁnal exam, stu-

dents must show the ability to analyze and inter-

pret data from different sources in order to explain

a socio-economic event. Computer science lectu-

res teach programming to achieve this goal.

Therefore, according to the classiﬁcation provided

by Ye and Fischer (Ye and Fischer, 2007), the students

of this type of school are going to be end-users who

program with a language speciﬁc to their application

domain. This category, in the range introduced by Ye

and Fischer, approaches the professional software de-

veloper; thus, there is a clear need to introduce soft-

ware engineering principles into this school curricu-

lum.

In our long-term vision, the peculiarity of this high

school allows us to verify how fostering software en-

gineering concepts by focusing only on the process

side (which means, in the ﬁrst two years) can beneﬁt

the students when they start programming (which me-

ans, during the third, fourth, and ﬁfth year). For this

reason, we have involved in our case study the ﬁrst-

year students (17 students - 12 F, 5 M), during the ICT

lectures.

In the ﬁrst year’s ICT programme, one of the ﬁrst

topics in the syllabus is the “deﬁnition of informa-

tion and communication technologies”. In the per-

spective of learning-by-doing, in agreement with the

ICT teacher, we have proposed the following activity:

“prepare a presentation about ICT”. The module was

organized in four weekly blocks of 90 minutes, and

students worked individually.

6 RESULTS

At the end of the didactic module, all the 17 stu-

dents presented their set of slides about ICT, which

all fulﬁlled the initial requirements. The number of

ICT-related topics included in the presentations varied

from student to student, ranging from a minimum of

two topics to a maximum of four. The most covered

topics in the presentations are listed in Table 1.

As detailed in Section 4.5, for product assessment

we used three criteria: structure, content, and citation

of sources. As shown in Figure 1, the structure of

12 presentations was sufﬁciently good, while 5 pre-

sentations were almost sufﬁcient because of some is-

sues, such as the absence of the title in some slides or

the excessive presence of text. Six presentations had

fully sufﬁcient content and two were insufﬁcient (i.e.,

the content was just superﬁcially mentioned). Only

three presentations did not cite the sources of infor-

mation. In general, the ﬁnal evaluation of the presen-

tations was better than the evaluation obtained during

the third lesson.

Regarding the process, it should be noted that the

students did not understand the iterative model im-

mediately. The majority of students, in fact, at the

ﬁrst request to submit a ﬁrst result after 20 minutes

tried to complete the entire assignment, without un-

derstanding that it was enough to submit a ﬁrst ver-

sion on which they could then have feedback to con-

tinue the rest of the work. Following the guidelines

of the End-User Software Engineering ﬁeld, we did

not interrupt our activities to provide additional expla-

nations; instead, we tried to let the students perceive

(during the ﬁrst iterations) the advantage of having

feedback on their prototypes. After a ﬁrst phase of

“adjustment”, we noticed that our students started to

organize their activities in order to be able to present,

during the next meeting with the teachers, the parts

on which they needed more support. We consider this

as an indicator that students started understanding the

difference between a moment of evaluation and a mo-

ment of feedback.

If the iteration frequency appeared initially as so-

mething “stressful”, at a later stage the students star-

ted asking for each task: “what time do we have to

show a ﬁrst prototype?”. Finally, the iterative model

has allowed even the slowest students to conclude the

didactic module with a minimal, but still sufﬁcient,

presentation (i.e., two sub-topics).

The perceived usefulness of mind maps (imple-

mentation of user stories practice) emerged during a

discussion with the students at the end of the acti-

vities. Students perceived mind maps as a support

tool to avoid “getting lost on the Internet in the large

amount of information” that they could ﬁnd there.

Therefore, the design phase of the presentation hel-

ped them to be more focused, while allowing them

to change the design at a later stage to introduce new

ideas.

Table 1: Topics covered in the presentations about ICT.

Topic Number

of presen-

tations

% of pre-

sentations

ICT deﬁnition 12 70.6

Areas of application 11 64.7

Examples of applicati-

ons in the educational

environment

8 47.1

Historical notes 6 35.3

ICT objectives 5 29.4

Positive / negative as-

pects

5 29.4

End-User Software Engineering in K-12 by Leveraging Existing Curricular Activities

253

Structure Content Sources

Number of presentations

Evaluation criteria

Insufficient

Almost sufficient

Sufficient

Figure 1: Assessment of the ﬁnal product.

7 DISCUSSION AND

CONCLUSION

In this work, we describe a didactic module in which

we leverage a typical activity of the existing study

programme (i.e., preparing a set of slide) in order to

foster software engineering principles. The module

does not shift the students’ attention from their main

objective and does not introduce additional lectures

on software engineering. Paying attention to this last

characteristic is of paramount importance, especially

in non-vocational schools: in these schools, indeed,

the goal is to foster a mindset that could be fundamen-

tal in the future career of students, who at the moment

would not perceive additional lectures on SE as use-

ful.

We performed a ﬁrst classroom-based experimen-

tation of this didactic module in a ﬁrst class of an

international trilingual high school. The ﬁrst results

show that, although no additional explanations were

provided, students have adapted rather quickly to the

new organization of the work process, by taking ad-

vantage of the frequent iterations and of the obtained

feedback.

In the short term, we plan to design other modu-

les that we will experiment with the same group of

students. This will allow us to observe if and when

students will develop a “software engineering mind-

set”, even without developing software. The results

of this effort could conﬁrm the beneﬁts of working

in the EUSE perspective in different disciplines, in-

cluding non-STEM ones. Moreover, further experi-

ments would help in developing an assessment pro-

tocol for the process aspect, which is now only eva-

luated through observations. In future modules, we

plan to include teamwork activities, which beneﬁts

the most of an XP approach, and to support them with

speciﬁc practices (e.g., stand-up meeting).

In the long term, our goal is to verify how foste-

ring software engineering concepts by focusing only

on the process side can be beneﬁcial to students when

they start programming. Results in this direction

would demonstrate the effectiveness of the activities

carried out in creating a mindset to be applied also in

the creation of software.

REFERENCES

Beck, K. (2000). Extreme programming explained: em-

brace change. addison-wesley professional.

Bollin, A., Pasterk, S., Antonitsch, P., and Sabitzer, B.

(2016). Software engineering in primary and se-

condary schools-informatics education is more than

programming. In Software Engineering Education

and Training (CSEET), 2016 IEEE 29th International

Conference on, pages 132–136. IEEE.

Burnett, M. (2009). What is end-user software engineering

and why does it matter? In International Symposium

on End User Development, pages 15–28. Springer.

Burnett, M. M. and Myers, B. A. (2014). Future of end-user

software engineering: beyond the silos. In Procee-

dings of the on Future of Software Engineering, pages

201–211. ACM.

Chimalakonda, S. and Nori, K. V. (2013). What makes

it hard to teach software engineering to end users?

some directions from adaptive and personalized lear-

ning. In Software Engineering Education and Trai-

ICSOFT 2018 - 13th International Conference on Software Technologies

254

ning (CSEE&T), 2013 IEEE 26th Conference on, pa-

ges 324–328. IEEE.

Costabile, M. F., Mussio, P., Parasiliti Provenza, L., and

Piccinno, A. (2008). End users as unwitting soft-

ware developers. In Proceedings of the 4th Interna-

tional Workshop on End-user Software Engineering,

WEUSE ’08, pages 6–10, New York, NY, USA. ACM.

Fronza, I., El Ioini, N., and Corral, L. (2015). Students want

to create apps: Leveraging computational thinking to

teach mobile software development. In Proceedings of

the 16th Annual Conference on Information Techno-

logy Education, SIGITE ’15, pages 21–26, New York,

NY, USA. ACM.

Fronza, I., El Ioini, N., Corral, L., and Pahl, C. (2018). Agile

and Lean Concepts for Teaching and Learning, chap-

ter Bringing the beneﬁts of Agile techniques inside the

classroom: a practical guide. Springer. To appear.

Fronza, I., El Ioini, N., Janes, A., Sillitti, A., Succi, G.,

and Corral, L. (2014). If i had to vote on this labora-

tory, i would give nine: Introduction on computational

thinking in the lower secondary school: Results of the

experience. Mondo Digitale, 13(51):757–765.

Fronza, I., Ioini, N. E., and Corral, L. (2017). Tea-

ching computational thinking using agile software en-

gineering methods: A framework for middle schools.

ACM Transactions on Computing Education (TOCE),

17(4):19.

Kastl, P., Kiesm

uller, U., and Romeike, R. (2016). Starting

out with projects: Experiences with agile software de-

velopment in high schools. In Proceedings of the 11th

Workshop in Primary and Secondary Computing Edu-

cation, pages 60–65. ACM.

Kropp, M. and Meier, A. (2013). Teaching agile software

development at university level: Values, management,

and craftsmanship. In Software Engineering Educa-

tion and Training (CSEE&T), 2013 IEEE 26th Confe-

rence on, pages 179–188. IEEE.

Meerbaum-Salant, O. and Hazzan, O. (2010). An agile con-

structionist mentoring methodology for software pro-

jects in the high school. ACM Transactions on Com-

puting Education, 9(4):n4.

Monteiro, I. T., de Castro Salgado, L. C., Mota, M. P., Sam-

paio, A. L., and de Souza, C. S. (2016). Signifying

software engineering to computational thinking lear-

ners with agentsheets and polifacets. Harvard Busi-

ness Review.

Stegh

ofer, J.-P., Knauss, E., Al

egroth, E., Hammouda, I.,

Burden, H., and Ericsson, M. (2016). Teaching agile:

addressing the conﬂict between project delivery and

application of agile methods. In Proceedings of the

38th International Conference on Software Engineer-

ing Companion, pages 303–312. ACM.

Wing, J. M. (2006). Computational thinking. Comm. ACM,

49(3).

Ye, Y. and Fischer, G. (2007). Designing for participation in

socio-technical software systems. Universal Acess in

Human Computer Interaction. Coping with Diversity,

pages 312–321.

End-User Software Engineering in K-12 by Leveraging Existing Curricular Activities

255