END-USER SOFTWARE ENGINEERING
Andrew Rosene
INTRODUCTION
End-User Software Engineering…
1. is an activity that has been around for a while.
2. is continually growing in usage.
3. is very misunderstood and stereotyped.
TOPICS OUTLINE
1. Define Key Terminology
2. How End-User Software Engineering is different from Professional Software
Engineering
3. Why Researching End-User Software Engineering is Important
4. Tools that can aid End-User Software Engineering
5. Conclusion
DEFINING KEY TERMINOLOGY
Topic 1 of 5
DEFINITIONS
To fully understand this topic it is essential that these terms have there common
definition broadened:
Program
Software Engineering
End-User Programming
End-User Software Engineering
PROGRAM
There are many different definitions for a program.
According to Dictionary.com a program is “the precise sequence of instructions enabling a
computer to solve a problem.” [14]
According to the Computer Dictionary, a program is “a single, complete and more-or-less selfcontained list of instructions, often stored in a single file.” [16]
The definition we will be using is that a program is “a collection of specifications that may
take variable inputs and that can be executed (or interpreted by a device with computational
capabilities.” [5]
SOFTWARE ENGINEERING
There are many definitions for Software Engineering. Therefore, the definition that
we will be using is that of the IEEE (the Institute of Electrical and Electronics Engineers)
which defines Software Engineering as…
“the application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software; that is, the application of
engineering to software” [3].
END-USER PROGRAMMING
End-User
 Anyone who uses a computer [5].
End-User Programmer
 Programming done by anyone using a computer.
End-User Programming
 Programming to achieve the result of a program primarily for personal, rather than public use” [5].
END-USER SOFTWARE ENGINEERING (EUSE)
The only way to properly define End-User Software Engineering is to note it is a form
of Software Engineering
 Because of this, end-user programmers face many of the same software engineering challenges.
However, there are many differences that clearly separate EUSE from Professional
Software Engineering.
HOW IS EUSE DIFFERENT FROM
PROFESSIONAL SE
Topic 2 of 5
EUSE VS. PROFESSIONAL SE
The main difference between End-User SE and Professional SE is their goals.
Goal of Professional Engineer
Goal of End-User Software Engineer
Seeking payment for developing and
maintaining programs over time
Developing programs that support
some goal that exists in there domain
of expertise [5].
 In other words, the programs being developed
are being created to make a task easier for
someone else. NOT THEMSELVES.
 In other words, End-User Programmers
develop program to make some task easier
for THEMSELF.
EUSE VS. PROFESSIONAL SE, CONTINUED
It is obvious that many different people participate
in EUSE.
The only condition that must be met is that the intent
of the programming must be that of accomplishing
a PERSONAL GOAL.
•
Even expert programmers can fall under this
category.
People who participate in EUSE
Activity Performing
Secretaries
Excel Tables
Accountants
Excel Tables
Teachers
Excel Tables
Scientists
MATLAB Scripts
EUSE VS. PROFESSIONAL SE, CONTINUED
Intent is not the only difference between End-User Software Engineering and
Professional Software Engineering. To fully separate these two we need to examining
the actions taken during different phases of the software development lifecycle.
The areas we will be focusing on are:
• Requirements Gathering
• Design and Specification
• Testing and Verification
• Debugging
REQUIREMENTS GATHERING
Professional Software Engineers
• Perception of Requirements
• Gathering requirements is crucial to the success
of the program.
• If not thorough it is almost impossible to build not only the
system right, but the right system.
• Source of Requirements
• Customer
• Time spent
• Tons of time is spent in gathering
requirements.
End-User Software Engineers
• Perception of Requirements
• Requirements are not gathered, or recorded.
• They are more easily understood
• Source of Requirements
• Themselves
• Time Spent
• No time spent gathering requirements
DESIGN AND DESIGN SPECIFICATION
Professional Software Engineers
• Perception of Design and Design
Specification
• The purpose of design specifications is to specify
the systems internal behavior.
• Also, allows you to determine what
implementation constraints exist.
• Uses for Design Specifications
• Design specifications are used to lay out the
implementation strategy for ensuring that the
system metes all of the requirements.
• Done by assigning appropriate priorities to each requirement
so that the highest priority requirements are taken care of
before the low priority ones.
End-User Software Engineers
• Perception of Design and Design
Specification
• This phase is difficult for End-Users because they
often are unable to translate their requirements
into a working program.
• This is because they don’t have the training or experience
• Uses for Design Specification
• They often see little to no benefit to it.
• Once again, this is do to there lack of experience and
training.
• Often come to realize what constraints exist
on their programs’ implementations while
they write it.
TESTING AND VERIFICATION
Professional Software Engineers
• Perception of Testing and Verification
• It is an essential part of the Software
Development Lifecycle
• It is the way in which SE’s ensure the proper
execution of the program.
• How is this implemented?
• JUnit tests, regression testing, embedded test
cases, etc.
• By running these tests it helps in bug identification and in
verifying proper execution of the program.
End-User Software Engineers
• Perception of Testing and Verification
• Testing is intermingled with debugging, if it is
done at all.
• How is it implemented?
• It is done by way of trial and error.
• Reason for this?
• The priorities of the end-user programmer
frequently lead to overconfidence in their
programs correctness.
• To no one’s surprise, studies show that in spite of high error
rates in spreadsheets, the developers of the spreadsheets are
carelessly confident about its correctness.
DEBUGGING
Professional Software Engineering
• Perception of Debugging
• It is an essential activity to ensure requirements
are being met.
• Time Spent Debugging
• Debugging is the most time consuming activity
undergone.
• To be successful requires a high level of
understanding of the code. It allows you
to identify areas that could have
caused the problem.
End-User Software Engineering
• Perception of Debugging
• End-Users frequently prioritize their external
goals over software reliability, they often rely
on debugging strategies such as making code
changes until it appears to work as expected.
• Time Spent Debugging
• Debugging may not even be possible for
many end-users.
• This is because end-user programmers often lack
accurate knowledge and understanding about their
programs execution. Therefore the root-cause is very
hard for them to conceive.
WHY IS RESEARCHING END-USER
SOFTWARE ENGINEERING IMPORTANT?
Topic 3 of 5
IMPORTANCE OF FURTHER RESEARCH
• Increase in the number of end-users using EUSE to achieve personal goals comes an
increase in the risk of an error
• This is a direct result of the lack of quality procedures.
• How bad can a bug in an End-Users program be?
EXAMPLE 1: MYSQL ERROR
An employee working at a big bank firm is responsible, on a daily basis, for
removing entries in the bank’s MySQL database that reference loans that have been
sold to other banks. Noticing that all of the records that need to be removed have
two things in common the employee begins to explore possible ways in which this
process can be automated. After scouring the internet the employee discovers a bit
of code that, based on the attached documentation, appears to be to complete the
goal with only slight modification.
CODING SAMPLE BEFORE EDITING
This is the sample code that the bank
employee found on the internet.
CODING SAMPLE AFTER EDITING
As you can see above, the bank
employee has made the changes but
has made one crucial mistake.
ERROR
In MySQL the first line of this will
execute because it is valid. It will
terminate at the end of this line
resulting the database table with the
given name having all of its tables
dropped.
EXAMPLE 2: BASH SCRIPT MISTAKE
An experienced Linux user decides to change the organization of his/her pictures. To
save time the user decides to write a script. The script is fairly simple, it moves into a
directory and copies all of the files into another directory. After having copied all of
the files, the script then deletes the folder.
BASH SCRIPT WRITTEN BY THE USER
The above code has one crucial
error.
ERROR
The error is in the lack of error
checking.
EXAMPLE 3: EXCEL ERROR
An employee for a Texas oil and gas company is responsible for performing
spreadsheet calculations to determine whether it is cost effective to acquire another
company. After performing the operations it is determined that the acquisition would
be very lucrative. Based on this determination, they went ahead with the acquisition.
Soon afterwards it was discovered that this acquisition was a huge mistake. The
company lost millions of dollars due to an error in the spreadsheet.
TOOLS THAT AID IN EUSE
Topic 4 of 5
TOOLS
There are many tools available whose main purpose is integrating software quality
principles used by professional software engineers into end-user software
engineering.
The tools that will be discussed are:
1. Topes
2. What You See Is What You Test(WYSIWYT)
3. Whyline
TOPES
What is topes?
 Topes is a model and supporting system with the purpose of supporting validation and reuse of small,
human readable data in programs created by end-users
 More specifically, users define string-based data types which can then be used to verify the validity of both data and operations in the
programming languages that store information as strings.
By support the design of custom data types, end-user programmers are able to easily process
and validate information.
Topes is a model and supporting system with the purpose of supporting validation and reuse
of small, human-readable data in programs created by end-user programmers’ [1]. More
specifically, users define string-based data types which can then be used to verify the validity
of both data and operations in programming languages that store information as strings [5].
By supporting the design of custom data types, end-user programmers are able to easily
process and validate information [5].
TOPES, CONTINUED
Users create a “tope” that describes the rules for recognizing and formatting a
specific kind of data, such a birth date, phone numbers, etc and then associate a
tope with spreadsheet cells, or other String fields.
The values are then automatically checked and transformed at runtime.
Studies have shown that end-users are capable of validating data more rapidly and
precisely with Topes than with other existing tools.
WHAT YOU SEE IS WHAT YOU TEST(WYSIWYT)
What is the purpose of WYSIWYT?
 To help users test their spreadsheets while they are in the process of creating them, in an incremental
and systematic fashion.
How is this done?
 At any point in the development process of the spreadsheet, the end-user can validate any value that
he/she observes as accurate [1].
 Each validation done by the end-user is processed, in the background, and used to measure the
quality of the testing being done in terms of a test adequacy criterion that is based on data
dependencies [5].
 The measurements are then projected to the user by means of several different visual devices to assist
in directing their testing activities [5].
WHAT YOU SEE IS WHAT YOU TEST,
CONTINUED
As shown above. You check the boxes
to validate the data that you have
entered as correct. Based on the a
testing percentage is displayed.
WHYLINE
What is Whyline?
 Whyline is a debugging tool that allows the end-user programmer to ask a question of the type “Why
did” and “Why didn’t” regarding outputs generated by their program.
 The program chooses from a set of questions that are automatically generated by Whyline, through
the use of static and dynamic analysis, and Whyline is then able to provide different answers in terms
of the runtime events that could have caused the desired result.
WHYLINE, CONTINUED
•
Whyline was originally prototyped in the Alice
Programming environment.
•
Results of studies done measuring the amount of
time users spent debugging using Whyline
compared to those who did not use Whyline
produced startling results.
•
End-user programmers using Whyline where able to
debug the same bug as end-user programmers not using
Whyline in one eighth of the time [1].
Based on the results of this study it is not only clear
that this tool has profound benefits to the end-user
programmer, but that the benefits are in the form
of higher software quality.
CONCLUSION
Topic 5 of 5
CONCLUSION
• The number of end-users participating in end-user software engineering is continuing
to rapidly increase.
• As the number of end-users participating in EUSE increases so does the probability
that an issue will occur resulting from lacking quality processes.
• If more research isn’t done into and awareness isn’t raised about tools like Topes,
WYSIWYT, and Whyline then these risks will continue to go unchecked.
REFERENCES
[1] Aung, H. (2011, November 29). Resources on End-User Software Engineering. End Users
Shaping Effective Software. Retrieved October 29, 2012, from
http://eusesconsortium.org/resources.php
[2] Fischer, G., & Giaccardi, E. (2006). Meta-design: A framework for the future of end-user
development. End User Development Empowering People to Flexibily Employ Advanced Information
and Communication Technology, 427–457.
[3] Guide to the software engineering body of knowledge 2004 version : SWEBOK. (2004). Los
Alamitos, Calif: IEEE Computer Society Press.
[4] Hendry, D. G., & Green, T. R. G. (1994). Creating, comprehending, and explaining
spreadsheets: A cognitive interpretation of what discretionary users think of the spreadsheet
model. International Journal of Human Computer Studies, 40(6), 1033–1066.
[5] Ko, A. J., Abraham, R., Beckwith, L., Blackwell, A., Burnett, M., Erwig, M., Scaffidi, C., et al.
(2011). The state of the art in end-user software engineering. ACM Computing Surveys (CSUR),
43(3), 21.
REFERENCES, CONTINUED
[6] Ko, A. J., DeLine, R., & Venolia, G. (2007). Information needs in collocated software
development teams. Proceedings of the International Conference on Software Engineering (pp. 344–
353).
[7] Lawrence, J., Clarke, S., Burnett, M., & Rothermel, G. (2005). How well do professional
developers test with code coverage visualizations? An empirical study. Proceedings of the IEEE
Symposium on Visual Languages and Human-Centric Computing (pp. 53–60).
[8] Leventhal, L. M., Teasley, B. E., & Rohlman, D. S. (1994). Analyses of factors related to positive
test bias in software testing. International Journal of Human-Computer Studies, 41(5), 717–749.
[9] Myers, B., Park, S., Nakano, Y., Mueller, G., & Ko, A. J. (2008). How designers design and
program interactive behaviors. Proceedings of the IEEE Symposium on Visual Languages and HumanCentric Computing (pp. 177–184).
[10] Panko, R. (1995). Finding spreadsheet errors: Most spreadsheet models have design flaws
that may lead to long-term miscalculations. Information Week, May(100). Retrieved from
http://www.informationweek.com/529/29uwfw.htm
REFERENCES, CONTINUED
[11] Panko, R. (1998). What we know about spreadsheet errors. Journal of Organizational
and End User Computing (JOEUC), 10(2), 15–21.
[12] Panko, R. (2000). Spreadsheet Errors: What We Know. What we think we can do.
Proceedings of the Spreadsheet Risk Symposium.
[13] Petre, M., & Blackwell, A. F. (2007). Children as unwitting end-user programmers.
Proceedings of the IEEE Symposium on Visual Languages and Human-Centric Computing (pp.
239–242).
[14] Program. Dictionary.com. Retrieved October 29, 2012, from
http://dictionary.reference.com/browse/program
[15] Segal, J. (2007). Some problems of professional end user developers. Proceedings of the
IEEE Symposium on Visual Languages and Human-Centric Computing (pp. 111–118). +.
REFERENCES, CONTINUED
[16] Software. (2002, July 21).Computer Dictionary Online. Retrieved October 29,
2012, from http://www.computer-dictionary-online.org/index.asp?q=software
[17] Teasley, B., & Leventhal, L. (1994). Why software testing is sometimes
ineffective: Two applied studies of positive test strategy. Journal of Applied
Psychology, 79(1), 142.
[18] Wiedenbeck, S. (2005). Facilitators and inhibitors of end-user development by
teachers in a school environment. IEEE Symposium on Visual Languages and HumanCentric Computing (pp. 215–222).
[19] (2012) Retrieved from http://eusesconsortium.org/screenshots/WYSIWYT-XLQuinnbk1.gif
[20] (2012) Retrieved from
http://www.cs.cmu.edu/~marmalade/images/whyline.jpg
QUESTIONS?