333 Project • a simulation of reality – building a substantial system – in groups of 3 to 5 people • "three-tier" system for any application you like • 3 major pieces – graphical user interface ("presentation layer") – processing in the middle ("business logic") – storage / data management • examples: many web-based services – Amazon, Ebay, other web stores – news, information services, bots, mashups – email, chat, search, code tools, maps, ... – cellphone systems are often like this too • your project – make something of roughly this structure – but smaller, simpler, defined by your interestsSome local examples • Point • PTX • Events • Rooms • ICE • TigerFinderitrans.infoChoices (a small and incomplete list) • user interface – browser, desktop, phone, game console, API, ... – HTML/CSS, Javascript, Flash, Jquery, Java, ... • main languages – C++, Java, C#, Perl, Python, PHP, Ruby, Objective C, ... • server – own machine, OIT, CS, App Engine, Amazon EC2, hosting service, ... • database – MySQL, SQLite, Postgres, flat files, ... • information exchange formats – text, XML, JSON, REST, ... • development tools and frameworks – Django, Rails, Google Web Toolkit, XCode, Eclipse, Visual Studio, ...Getting started • right now, if not sooner – think about potential projects; form a group talk to TA's & bwk; look at previous projects; look around you; check out the external project ideas page • by Fri Mar 9: short meeting with bwk (earlier is desirable) – to be sure your project idea is generally ok – you should have one pretty firm consensus idea, not several vague ones • Fri Mar 16: design document draft (before break) – ~3 pages of text, pictures, etc. a template will be posted – overview, initial web page, elevator speech project name / title, paragraph on what it is, one person as project manager – components & interfaces major design choices: web vs. standalone, languages, tools, environment, … major pieces, how they fit together – milestones: clearly defined pieces either done or not – risks • should be based on significant thought and discussion • don't throw it together at the last minute – all components of the project are gradedProcess: organizing what to do • use an orderly process or it won't work • 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 from the top until the semester ends • classic "waterfall" model: a real process specification requirements architectural design detailed design coding integration testing delivery • this is overkill for 333, but some process is essential …Informal process • conceptual design – roughly, what are we doing? make sketches, scenarios, screenshots • requirements definition ("what") – precise ideas about what it should do – explore options & alternatives on paper – specify more carefully with written docs – this should not change a lot once you start • architecture / design ("how") – map out structure and appearance with diagrams, prototypes – partition into major subsystems or components – specify interactions and interfaces between components – decide pervasive design issues: languages, environment, database, ... – make versus buy decisions and what you can use from elsewhere – resolve issues of connectivity, access to information, software, etc. • implementation ("what by when") – make prototype – deliver in stages, so that each does something and still works – test as you go: if your system is easy to break, it gets a lower grade“Make versus buy” • you can use components and code from elsewhere – copy or adapt open source • overall project design has to be your own • so does selection and assembly of components • so does the bulk of the work • it's fine to build on what others have done – identify what you have used, where it came fromInterfaces • the boundary between two parts of a program • a contract between the two parts • what are the inputs and outputs? • what is the transformation? • who manages resources, especially memory and shared state? • hide design & implementation decisions behind interfaces, so they can be changed later without affecting the rest of the program – database system, data representations and file formats – specific algorithms – visual appearance • "I wish we had done interfaces better" is one of the most common comments – less often: "We thought hard about the interfaces so it was easy to make changes without breaking anything."Deciding what to do • informal thinking and exploring early, so you have time to let ideas gel • make big decisions first, to narrow the range of uncertainty later – "large grain" decisions before "small grain" (McConnell) – web/standalone/phone? Unix/Windows/Mac/iPhone? framework (GWT, Django, Rails) or roll your own? GUI in Java or .NET or IB or ...? what kinds of windows will be visible? what do individual screens and menus look like? – Java or PHP or Perl or C# or ...? mix & match, or all the same? • think through decisions at each stage so you know enough to make decisions at next stage • but this is still very iterative – don't make binding decisions until you are all fairly comfortable with them – do simple experiments to test what works or doesn't – what do users see and do? scenarios (storyboards, "use cases"), sketches of screen shots diagrams of how information, commands, etc., will flow – what data is stored and retrieved how is it organizedOther ways to think about it • "elevator pitch" – what would you say if you were alone in an elevator with Bill Gates for 60 seconds? short attention-grabbing description without big words but good buzzwords • 5-7 slides for a 5-10 minute talk or a poster session – what would be the titles and 2-3 points on each slide? • 1 page advertisement –