COMS W3156: Software Engineering, Fall 2001

1. COMS W3156:Software Engineering, Fall 2001 Lecture #1: The Smorgasboard Janak J Parekh janak@cs.columbia.edu

2. Software Engineering’s about software developers, right?

3. The power of *1 • Software Engineering is a course that deals with reality • Accordingly, I’m going to pepper the course with real anecdotes (where * appears) • If you don’t get them from class, you won’t get them at all (more on class participation later) 1 The * is actually a powerful concept in CS

4. Who I am, or more importantly, how to call me • Don’t call me Professor or Dr.* Parekh; my dad is that • Janak is probably best, actually • PhD student in the Computer Science department • I’ve been doing Software Tools research for almost 5 years • janak@cs.columbia.edu as per the first slide

5. What is Software Engineering? (I) • Schach: “Software engineering is a discipline whose aim is the production of fault-free software, delivered on time and within budget, that satisfies the user’s needs.” • From the bulletin: “Software management, requirements analysis, human factors, functional specification, software architecture, design methods, programming for reliability and maintainability, team programming, testing methods, and configuration management, with special topics as time permits.” • So, what’s the point?

6. What is Software Engineering? (II) • In Intro to CS and Data Structures, you learned the mechanics of programming, i.e. Java (or other) syntax, how to create data structures and store information in them, etc. • Usually, however, the design of a program wasn’t the concern: you were given an assignment and told to implement it • What if you weren’t given the design? • What if no one knows what the assignment is?

7. Intent of this class (I) • Cover classic and modern software engineering practices • Specifying, analyzing, designing, implementing, and testing software • Examine the influence of OO and OO techniques on software design • Learn about team practices and actually work in a team environment, simulating a real-world environment to a limited extent

8. Intent of this class (II) • Prepare you for the “higher” CS classes in the department • Advanced Programming skills • Languages (C, C++) • Networking (basics, sockets) • Concurrency (threads, mutexes, semaphores) • etc. • Design patterns • Conceptual solutions to common design problems

9. Who should take this course? • Students who have taken Data Structures and are ready to go to the next level • Warning: this course is not easy, but it’s rewarding • Valuable job skills, such as networking, XML and UML • Students for whom it’s a requirement • Prerequisites: • CS W3137 or W3139 • If not, see me first; you must have a working knowledge of Java

10. It’s a 4-credit class! • This is a 4-credit course  approximately 33% more work than a 3-credit course • Recitations • Unfortunately, we can’t “require” them, since the registrar never added any • Strongly recommended, however; questionnaire will allow you to select preferred times

11. Work breakdown • “675-point course”: • 4 homeworks x 25pts = 100 points • Final exam (no midterm!) = 100 points • Project = 400 points (to be subdivided later) • Group evaluation = 75 points • Extra credit = up to 25 points; structure TBD

12. Class participation • I do want you to show up for classes—I’m a believer in making classes interesting; not by gimmick, but by making them relevant • Class participation is not required, but by making yourself “known” to me it makes a difference come grade-time • As mentioned shortly, there will be “lecture-only” material, and you’re responsible for them (make friends with others in the class!) • You will learn in these lectures

13. The Reasonable Person Principle1 • If you miss a lecture, you’re expected to obtain the material covered in the lecture from other sources • Neglect to explain an answer (on homeworks, projects, or exams) at your risk • A reasonable person doesn’t cheat (groups notwithstanding, more on that shortly) 1Credits to Prof. J.L. Gross, gross@cs.columbia.edu

14. Groups! • Finally, a course where you can work in groups… but it’s more complex to do so than you think • Groups of 5, you can pick or have us assign • We’re not doing this today*, so relax • No cross-group participation without my explicit permission • Groups are intended only for the group project, not the homework • A few notes on plagiarism and catching it* • Group evaluations • The significance of groups is highly underestimated*

15. Course website • http://softe.cs.columbia.edu (or http://www.softe.cs.columbia.edu) • Syllabus and slides will be posted here (slides will hopefully be posted the morning of each class, so you can print them out for notes)—today’s will be up soon • Discussion forum available from the website

16. Books for the course • There are three textbooks* (duck) • See website for info • Seriously, two (MMM and UML) of them are small, and you can share those two if cost is a factor • On the other hand, you’ll find the MMM* and UML books to be valuable references

17. The Other Section • As you probably know, the other section is rather crowded (99 students were registered this weekend) • The other instructor is Phil Gross, a good friend of mine (and co-worker) • We’re synchronizing the lectures/syllabus, homeworks, and project (no, not exams)

18. The Other Section (II) • TA’s are “pooled” between the two sections • This means it is possible to form a group between sections—this is a bit more work for you, but we’re OK with it • The website and other resources are the same • NB: don’t try to do a cross-class cheat, we’ll figure it out

19. Differences between the two sections • Unlike Phil, it doesn’t bother me if you fall asleep once in a while.. I did it back in my ugrad days too • If everyone falls asleep, it’s a sign that I’m immensely boring* • I philosophically believe in open-book exams—note that this doesn’t mean easier! • Phil hates this background

20. Teaching Assistants • There are currently 5 for both classes: • Suhit Gupta (head TA and recitation instructor), suhit@cs.columbia.edu • Daniel Medina (possibly 2nd recitation instructor), medina@cs.columbia.edu • Bethe Gordon, bg171@columbia.edu • Marek Marcinkiewicz, mom7@columbia.edu • Shen Li, sl697@columbia.edu

21. Office hours • My office hours are Wednesday 2pm-4pm in 608 CEPSR (building between Pupin and Mudd) && I’m a nice guy* • If you can’t make it: • Make an appointment with me • Visit a TA instead • If a curriculum question, crash Phil’s office hours • TA office hours are TBD, to be posted on class website

22. Homework 0 • Don’t worry, it’s simple • You need to fill out a questionnaire from http://softe.cs.columbia.edu by next Monday • Helps us to understand everyone’s background better, create our own active mailing list, discussion board accounts, and schedule recitations • Will be up by 2pm Wednesday (sorry!)

23. Syllabus • On Excel sheet for now; will be on webpage by tomorrow • Yes, this is a fast-paced course • Two sections of the course: • Software Engineering/Advanced Programming – about 75-80% – closely follows Schach, but with relevant material from MMM and UML Distilled interspersed (note project deadline) • Design Patterns/Advanced Programming – about 20-25% – to be discussed in more detail later

24. Class format • Two “halves” for most classes, as per syllabus • Not necessarily explicit • The Advanced Programming sublectures are designed to prepare you for the project you will be working on, and to tie in Software Engineering topics to actual tools and implementations

25. The homeworks • Apart from homework 0, there will be 4 smallish homeworks to review the topics covered in Schach, MMM, and UML • Will avoid long, ambiguous essay-type questions • Late policy for homework: 3 “late” days can be applied to one homework, or spread across several, with the exception of the last homework—no late days for HW 4

26. The project (I) • We’ll cover this in much more detail the next few classes, and when you receive your requirements document • Basically, you (in groups) will design a (almost) massively-multiplayer game • Everquest, Asheron’s Call are examples • Good foundation for networking and GUI code • Not another e-commerce application • Actually more like a microscopically multiplayer on-line role playing game

27. The project (II) • There will be five major milestones in the project (details later) • Specifications (100pts.) • Design (100pts.) • Implementation (100pts.) • Review/Analysis (50pts.) • Presentation/Demo (50 pts.) • NO lateness allowed on these without my approval, the timelines are too tight • Note implementation is not last, and not the only important step

28. Next class • The next class will be a “open” class, to allow synchronization with Phil’s class, which has only one lecture this week • I’ll probably focus on case studies and open up the class to the discussion, “Why do we need to engineer software so painstakingly?” • Let’s start now…

29. Software is widely misunderstood • The average manager has no idea of how software needs to be implemented, and he himself only has a vague idea of what he wants: “build me an order system”* • Therefore, the average layperson assumes anything can be done with software • Schach: Can you rotate a bridge 90 degrees? • Going beyond original intentions

30. You never have enough time • Software is often underbudgeted, and Marketing always wants it out tomorrow • “Why can’t you add feature X? It sounds so simple!” • “I thought it would take a week. Honest.” • “We’ve got to get it out next week. Hire 5 more programmers.”

31. No, you can’t do everything yourself • “Write an operating system.” • What do I start? • I don’t know how to write drivers! • Do we have time to integrate a browser into the OS? Should we? • How do I fix this BSOD error?

32. Software is complex • If not, it becomes complex • Feature bloat • Patching • Windows NT • NT 3.1 had 6 million lines of code • NT 3.5 had 9 million • NT 4.0 had 16 million • Windows 2000 has 30-60 million!

33. Things are not getting better: RISKS Digest • http://catless.ncl.ac.uk/Risks • People contribute reports and anecdotes about failures in systems due to poor planning, execution, testing, etc. • Endless

34. You will need these skills • You will invariably end up in a group, sooner or later, where there is little, faulty, or no organization • Even a basic application of software engineering skills has been shown to improve efficiency by orders of magnitude • Can you say raise or promotion?