The COS 333 Project. Robert M. Dondero, Ph.D. Princeton University

Transcription

1 The COS 333 Project Robert M. Dondero, Ph.D. Princeton University 1

2 Overview A simulation of reality In groups of 3-5 people... Build a substantial three tier software system 2

3 Three-Tier Systems "Three tier" system 1.User interface (usually graphical) 2.Storage/data management (usually database) 3.Processing in the middle ("business logic") 3

4 Three-Tier Systems Examples: Many web-based services Amazon, Ebay, other web stores News, information services, bots, mashups , chat, search, code tools, maps,... Many smart phone systems Your system should be similar But smaller, simpler, defined by your interests or the needs of others 4

5 Decisions User interface Browser, desktop, phone, API,... HTML/CSS, JavaScript, jquery, Flash, Java Applets,... Main language(s) Java, Python, C, C++, C#, Perl, PHP, Ruby, Objective C,... Server CS, OIT, your own computer, Google App Engine, hosting service, 5

6 Decisions Database MySQL, SQLite, Postgres, flat files,... Data exchange formats text, XML, JSON, REST/Atom,... Development tools and frameworks Django, Rails, Google Web Toolkit, XCode, Eclipse, Visual Studio,... 6

7 Decision Making Strategies Do informal thinking and exploring early So you have time to let ideas gel Do many simple experiments early So you learn what works or doesn't Make "large grain" decisions before "small grain" decisions 7

8 Decision Making Strategies Think about risks What could go wrong? What are you dependent on that might not work out? 8

9 Getting Started Right now, if not sooner! Think about potential projects Talk to course instructors Look at previous projects Check out the external project ideas page Look around you Form a team OK to use the listserv for match-making 9

10 Deliverables All are graded See "Schedule" Web page for due dates First deliverable Initial meeting with lead instructor To be sure your project idea is generally ok You should have one pretty firm consensus idea, not several vague ones 10

11 Deliverables Early-project deliverables: Initial Web site Elevator speech Project overview document 11

12 Deliverables Mid-project deliverables: Project timeline document Updated weekly Weekly status meetings Attendance mandatory Be prepared to describe what you accomplished, what you didn't, what you plan to do next 12

13 Deliverables Late-project deliverables: Demonstration of prototype Demonstration of alpha version Demonstration of beta version Presentation and final demonstration (Continued on next slide) 13

14 Deliverables Late-project deliverables (cont.) Final Web site User's guide document Design document Compressed source code file Final report document Working system 14

15 Process Use an orderly process This is NOT a process: Talk about the software at dinner Hack some code together Test it a bit Do some debugging Fix the obvious bugs Repeat until the semester ends 15

16 Process Classic "waterfall" model Overkill for 333, but some process is essential specification requirements architectural design detailed design coding integration testing delivery 16

17 An Informal Process Step 0: Choose a leader Goal: Make system work like the product of a single mind but with multiple developers Implication: Everyone has to pull together; someone has to be in charge Successful software development projects are not democracies 17

18 An Informal Process Step 1: Determine requirements (who) Who are the users? Decide what user need(s) will the system fulfill? Involve users, if possible Conduct interviews 18

19 An Informal Process Step 2: Determine functionality (what) What should the system do? Create scenarios Blackboard sketches, screens, story boards Low fidelity early; maybe high fidelity later Involve users, if possible Show scenarios 19

20 An Informal Process Step 3: Determine design (how) How will the system work? Decide pervasive design issues: languages, dev environment, database, Resolve issues of connectivity, access to information, software, etc. Partition into major subsystems Specify interfaces between subsystems Make "build versus buy" decisions 20

21 An Informal Process Step 4: Code Involve all team members Code in stages Every team member must do a significant part of the coding Do not build something that requires a "big bang" where nothing works until everything works Always be able to declare success and walk away 21

22 An Informal Process Step 5: Test Integrated with Code step Make sure it always works Fix bugs before adding features Additional distinct step at the end Involve users, if possible 22

23 An Informal Process Step 6: Document Integrated with previous steps Additional distinct step at the end Internal doc, Web page, presentation, final report, 23

24 Process Suggestions Count on iteration Try to revisit requirements, functionality, design infrequently Iterate between coding and testing frequently 24

25 Process Suggestions Use version code control system for everything CVS or Subversion or equivalent is mandatory 25

26 An Informal Process Leave lots of room for "overhead" activities Testing: build quality in from the beginning Documentation: you have to provide written material Deliverables: you have to package your system for delivery (Continued on next slide) 26

27 An Informal Process Leave lots of room for "overhead" activities (cont.) Changing your mind: decisions will be reversed and work will be redone Disaster: lost files, broken hardware, overloaded systems,... Sickness: you will lose time for unavoidable reasons Health: there is more to life than this project! 27

28 Design: Interfaces Interface The "public" part of a module A module's "advertisement" to clients A module's contract with clients What are the inputs? What is the transformation? What are the outputs? Who manages resources? Who detects/reports errors? 28

29 Design: Interfaces Suggestion: Hide design & implementation decisions behind interfaces So they can be changed later without affecting the rest of the program Database system, data representations, file formats Algorithms Visual appearance 29

30 Design: Interfaces Common comment: "I wish we had done interfaces better" Less common comment: "We thought hard about the interfaces so it was easy to make changes without breaking anything" Try to stay friends! 30

31 Design: Build vs. Buy OK to use modules/code from elsewhere E.g., copy or adapt open source Identify what you have used, and where it came from Overall project design must be your own So does selection and assembly of components So does the bulk of the work 31

32 Working with Instructors You will run your project We will help TA: first-level "manager" More mentoring and monitoring It's your project, not the TA's Lead instructor: second-level "manager" Again, more mentoring and monitoring 32

33 My Preference Option 1: Develop a system to fulfill your needs or interests A simulation of reality Option 2: Develop a system to fulfill the needs of someone else Reality! I recommend option 2 See "Project Ideas" Web page 33