End-User Software Engineering

1. End-User Software Engineering Andrew Rosene

2. Introduction • End-User Software Engineering… • is an activity that has been around for a while. • is continually growing in usage. • is very misunderstood and stereotyped.

3. Topics outline • Define Key Terminology • How End-User Software Engineering is different from Professional Software Engineering • Why Researching End-User Software Engineering is Important • Tools that can aid End-User Software Engineering • Conclusion

4. Defining Key Terminology Topic 1 of 5

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

6. Program • There are many different definitions for a program. • According to Dictionary.coma 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 self-contained 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]

7. 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].

8. 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].

9. 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.

10. How is EUSE different from Professional Se Topic 2 of 5

11. 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 Developing programs that support some goal that exists in there domain of expertise [5]. In other words, End-User Programmers develop program to make some task easier for THEMSELF. • Seeking payment for developing and maintaining programs over time • In other words, the programs being developed are being created to make a task easier for someone else. NOT THEMSELVES.

12. 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.

13. 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

14. Requirements Gathering Professional Software Engineers 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 • 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.

15. Design and Design Specification Professional Software Engineers 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. • 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.

16. Testing and Verification Professional Software Engineers 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. • 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.

17. Debugging Professional Software Engineering 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. • 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.

18. Why is Researching End-User Software Engineering important? Topic 3 of 5

19. 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?

20. 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.

21. Coding Sample Before Editing This is the sample code that the bank employee found on the internet.

22. Coding sample after editing As you can see above, the bank employee has made the changes but has made one crucial mistake.

23. 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.

24. 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.

25. Bash Script written by the User The above code has one crucial error.

26. Error The error is in the lack of error checking.

27. 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.

28. Tools that Aid in EUSE Topic 4 of 5

29. 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: • Topes • What You See Is What You Test(WYSIWYT) • Whyline

30. 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].

31. 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.

32. 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].

33. 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.

34. 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.

35. 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.

36. Conclusion Topic 5 of 5

37. 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 Whylinethen these risks will continue to go unchecked.

38. 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.

39. 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 Human-Centric 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

40. 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). +.

41. 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 Human-Centric Computing (pp. 215–222). • [19] (2012) Retrieved from http://eusesconsortium.org/screenshots/WYSIWYT-XL-Quinnbk1.gif • [20] (2012) Retrieved from http://www.cs.cmu.edu/~marmalade/images/whyline.jpg

42. Questions?