Analysis = Initial Design Phase

1. Analysis = Initial Design Phase Building a computer program that solves a problem is complex, time-consuming and too often unsuccessful. This document attempts to encourage students to use a sensible design methodology to promote success. The examples presented here are very brief and are not representative of a complete solution. Students using this for the International Baccalaureate Dossier should consult the following documents for more information and more realistic examples: Guidance: http://ibcomp.fis.edu/projects/DossierBook/dossierOverviewE.pdf Sample SL Dossier : http://ibcomp.fis.edu/projects/quizTacToeDocs.pdf Sample HL Dossier : http://ibcomp.fis.edu/Projects/StudentSample2007.pdf

2. Programming – a Misconception Computer Science students learn to write programs. They learn to create software by typingcommands in a programming language like Java. This leads to a misconception – that starting from a blank screen, a student would be able to create a usable program from scratch, just by typing. Usable software rarely results from just typing.It starts with a good design with sensible goals.

3. The Problem Consider a common database problem – takingattendance (register) in a classroom. The problem is that a teacher must record a list of students who are present and absent – then share the list with the office.

4. Existing Paper Solution Most problems are not new, and they already have a solution. For attendance, a piece of paper (register) has been used in classrooms for many years. Why change? Passing paper around is messy and time-consuming Data must be copied (by hand) from the teacher’s register into a central record. This copying process is time-consuming and unreliable. Paper does not connect well with other systems.

5. Computerized Improvements A computer system promises improvements.But what improvements are we hoping for? No more paper and pencil copying of data Data moves automatically from teacher to office Data can be exchanged with other computer systems Other improvements will probably arise “naturally”. If a commercial application exists, it might be the best choice, as it will include lots of extra features. But if there are special needs, then writing a custom program makes sense.

6. How do we get from there to here? From Problem to Solution JAVA BufferedReader double catch StringBuffer Object void private String parseInt There is no clear connection between a real-world problem and the commands in a programming language.We want a systematic method that leads clearly from the problem to a solution.

7. From Solution to Problem? Here, use thisspreadsheetfor attendance. Whatta ya want … PERFECTION??! Too often, programmers start by writing a program. Then they try out the program, figure out what’s wrong, and then fix the program. Unfortunately, this rarely produces a good solution, unless the problem is a “standard” problem where the needs are obvious. But it doesn’t have my students’ names listed….

8. Top-Down Design AttendanceSystem Rather than starting with a solution, students should start with the problem, analyse it, and then designa good solution – one that meets the needsof the intended user(s). Traditional software engineeringprinciples call for a top-down decomposition of the problem into smaller and smaller pieces. Each piece in this solution represents a need. Lower needs supportthose above. Take attendance Record att.centrally Check names Writemissing names Send tooffice Copy namesto bigbook

9. Investigate and Understand Before starting to design a solution, the developer (student) must understand the problem. That usually involves an investigation. For most problems, the best place to get information is from the intended user, because: they know more about the problem than a student they know what they want and need (hopefully) students can just ask questions and get answers they will help you set goals Goals are an essential part of the design process. BEFORE you start designing, TALK TO THE USER!

10. Talk to the User Choose a specific intended user - ONE user – that’s the best chance for success. Discuss the problem you wish to solve – don’t start with a solution. Talk about the job the user wants to accomplish. Then talk about what tasks they must perform.After that, start talking about how computerautomation might make their job easier. Suggest automation that will support the user’s tasks. Avoid ideas that replace difficult tasks. If the user is having trouble doing something, you probably cannot program a replacement. Take notes documenting your conversations.

11. User Stories Manyusers will be imprecise about their wishes. They won’t know what is possible, so asking them “what do you need” won’t bring useful answers.Investigate the problem. Ask them about what they already do and what problems they have. Ask them to tell you a story. They should describe their daily work. They should show you sample data to clearly illustrate the scope of their problems. Encourage them to include wishes in their stories.Write down the user-stories and the sample data. If you can get sample data as a photocopy, that’s great. Otherwise, write it down.

12. User Stories and Sample Data Some Sample Data Teacher’s attendance register page: Office’s central record book: A couple sample stories: Each teacher must take attendance each class. Sometimes they forget. They complain that it is a waste of time. The vice-principal wastes a lot of time counting absences for a few “trouble-makers”. If the computer could do the counting, that’d be great! Every month a teacher loses their register book. We don’t know how, but it happens.

13. AttendanceSystem Decomposition Take attendance Review att.centrally Check names Mark missingnames Saveabsencescentrally Retrievenames Search,count,alerts,reports After collecting user stories,it’s easier to expand our top-down design. Moving down the tree,tasks become moreand more specific. Some formerlyhuman taskschange to computer tasks. Choosea class Displaystudentnamesfor class Acceptcheck-marks Attendance Data-files Schedulingdatabase

14. AttendanceSystem SYSTEM Systematic Method JOBS Take attendance Review att.centrally TASKS TASKS Check names Mark missingnames Saveabsencescentrally Retrievenames Search,count,alerts,reports How do we know what belongs in the tree?Genericconceptsmight help. Consider the general categoriesshown here. Processes Choosea class Displaystudentnamesfor class Acceptcheck-marks Attendance Data-files Schedulingdatabase Modules

15. Showing Your Ideas Attendance System * Take attendance * Review Centrally Attendance System * Take attendance - Check names - Mark absent students - Save absences * Review Centrally Attendance System * Take attendance - Check names .. Choose a class .. View student names - Mark absent students - Save absences * Review Centrally - Retrieve names - Sort names - Count days absent - Filter grade levels - Print reports Attendance System * Take attendance - Check names .. Choose a class .. View student names - Mark absent students - Save absences Att Data-Files * Review Centrally - Retrieve names  from Att Data-files - Sort names - Count days absent - Filter grade levels - Print reports Designers need to showtheir ideas to other people,especially the intended usersand the programmers. Diagrams are attractive, but difficult to fit onto a page. Another possibility is an outline, as shown here. The outline can be developedin stages, becoming more detailed in each iteration. Click on outline to see iterations.

16. Showing Your Ideas to a User Outlines are a good thing to show to a programmer, but users are not impressed by outlines. They want action! They want to know what it’s going to look like, and how they will use it.The best way to show your ideas to the user is with a prototype (mock-up). This shows the user-interface, with some simple indication of what will happen when the real program is running. Users don’t want to know about storage modules and algorithms. They are going to use the program, not create it.PowerPoint is a good tool for creating a prototype. The following sample is very brief – far too short for a real project. Here is a better example: http://ibcomp.fis.edu/projects/newproj/TicTacToePrototype.ppt

17. Attendance System Prototype 1 Teacher 29 Feb 2012 SAVE Einstein, A Present Absent • Choose a Class –Math 9aMath 9bPhysics 10a • Math HL yr 2 Math HL yr 1 Alexander, A Beuaford, B Botox, B Killian, K Kim, K Lawrence, L Martin, M Clark, C Piotry, P Teacher Module – Take Attendance in Class Physics 10a Kim, K When the teacher clicks on a class, the list of students appears in PRESENT.Clicking on a present name moves the name to ABSENT. Clicking on an absent name moves it back to PRESENT. The teacher must click [SAVE] when they are finished.

18. Attendance System Prototype 2 29 Feb 2012 Print Daily Summaries Exit Absences Clark, C Einstein, A Physics 10a unexcused Clark, C Merkel, A Political Sci 10 unexcused …. Piotry, P Einstein, A Physics 10a Field Trip Piotry, P Pele, P Phys Ed 10 Field Trip Piotry, P Animal, A Biology 10 Field Trip …. Office Daily Module – Reviewing Daily Absences unexcusedSick Field Trip ….. Displays all the absence records for one day. Secretary can enter excusesby clicking on a student name, then choosing an excuse from a list.

19. Attendance System Prototype 3 Search 29 Feb 2012 Students All Absence Records …. Cho, M Clark, C Clark, E Dixon, D …. 2012.02.29 Clark, C Einstein, A Physics 10a unexcused 2012.02.29 Clark, C Merkel, A Political Sci 10 unexcused 2012.02.28 Clark, C Merkel, A Political Sci 10 Sick 2012.02.28 Clark, C Euler, S Math 10b Sick 2012.01.29 Clark, C Einstein, A Physics 10a Field Trip …. …. Clark, C Office Review Module – Reviewing All Records All student names appear in the Students list. The Secretary can click on a name to see all the attendance records for that student (for the entire year). She can click on an entry in the list to change the excuse or delete the record.The [Search] button allows searching for a first name or a partial name –e.g. searching for “Park” will find “Park” and “Parkinson”.

20. User Consultation After creating a prototype, the designer should present it to the user, explain it, and discuss changes and improvements with the user, because: it ensures that the programmer will not waste time writing a program that is incorrect or unusable it reassures the user that something good is coming it clarifies the needs and goals The user will probably suggest changes. The designer should redesign the prototype and present it again, repeating until the user and the designer agree on the design.

21. End of Initial Design Phase Agreement on the prototype and the goals completes the initial design phase – also called the Analysis. Armed with complete and clear goals and intentions, the designer can move on to the Internal Design, where the data-structures, algorithms and modules are designed. After that, the programmer can proceed to quickly produce a usable program.