The COS 333 Project Robert M. Dondero, Ph.D. Princeton University 1
Overview A simulation of reality In groups of 3-5 people... Build a substantial three tier software system 2
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
Three-Tier Systems Examples: Many web-based services Amazon, Ebay, other web stores News, information services, bots, mashups Email, 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
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
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
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
Decision Making Strategies Think about risks What could go wrong? What are you dependent on that might not work out? 8
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
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
Deliverables Early-project deliverables: Initial Web site Elevator speech Project overview document 11
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
Deliverables Late-project deliverables: Demonstration of prototype Demonstration of alpha version Demonstration of beta version Presentation and final demonstration (Continued on next slide) 13
Deliverables Late-project deliverables (cont.) Final Web site User's guide document Design document Compressed source code file Final report document Working system 14
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
Process Classic "waterfall" model Overkill for 333, but some process is essential specification requirements architectural design detailed design coding integration testing delivery 16
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
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
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
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
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
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
An Informal Process Step 6: Document Integrated with previous steps Additional distinct step at the end Internal doc, Web page, presentation, final report, 23
Process Suggestions Count on iteration Try to revisit requirements, functionality, design infrequently Iterate between coding and testing frequently 24
Process Suggestions Use version code control system for everything CVS or Subversion or equivalent is mandatory 25
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
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
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
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
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
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
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
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