1

The COS 333 Project

Robert M. Dondero, Ph.D.Princeton University

2

Overview

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

system

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")

4

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

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, …

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

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

8

Decision Making Strategies

Think about risks What could go wrong? What are you dependent on that might not

work out?

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

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

11

Deliverables

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

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

13

Deliverables

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

14

Deliverables

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

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

16

Process

Classic "waterfall" model Overkill for 333, but some process is essential

specification requirements architectural design detailed design coding integration testing delivery

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

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

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

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

21

An Informal Process

Step 4: Code Involve all team members

Every team member must do a significant part of the coding

Code in stages Do not build something that requires a "big

bang" where nothing works until everything works

Always be able to declare success and walk away

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

23

An Informal Process

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

report, …

24

Process Suggestions

Count on iteration Try to revisit requirements, functionality,

design infrequently Iterate between coding and testing frequently

25

Process Suggestions

Use version code control system for everything CVS or Subversion or equivalent is

mandatory

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)

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!

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?

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

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!

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

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

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