1. Ivan Marsic Rutgers University LECTURE 1: Introduction Lecture time: 1 hr. 20 min.

2. Course Information Web: http://www.ece.rutgers.edu/~marsic/Teaching/SE Lecture Notes: http://www.ece.rutgers.edu/~marsic/books/SE Textbooks (see more on the course website) –Bruegge & Dutoit: Object-Oriented Software Engineering: Using UML, Patterns and Java, Third Edition, Prentice Hall, 2010. | ISBN 0-13-6061257 –Miles & Hamilton: Learning UML 2.0, O’Reilly Media, 2006. ISBN: 0-596-00982-8 Teaching Assistant: Swapnil Mhaske 2

3. Team Projects Form teams of 6 (± 1?) students DEADLINE: Friday, January 25, 2013 After that, teams assigned randomly Project Ideas: http://www.ece.rutgers.edu/~marsic/books/SE/projects No more than two (2) groups working on the same project One (1) new project allowed Email your project idea ASAP, before proposal is due, for feedback 3

4. Personal Health Monitoring Devices 4 Available budget: $500 To do: 1. Search the Web for devices and apps that you would like to work with 2. Email the components list with costs+websites

5. Project Deliverables 5 ItemDue date I t e r a t. #1 1. ProposalProposalJanuary 29 2. First report (Specification only) Part 1 (Statement of Work & Requirements) Part 2 (Functional Requirements Spec & UI) Full Report #1First report February 12 February 18 February 22 3. Second report (Design only) Part 1 (Interaction Diagrams) Part 2 (Class Diagram and System Architecture) Full Report #2Second report March 1 March 8 March 15 4. First demoFirst demoApril 2 ►... I t e r #2 5. Third report (All reports collated)Third reportApril 27 6. Second demoSecond demoMay 1 ►... 7. Electronic Project ArchiveElectronic Project ArchiveMay 3

6. Team Project Grading 35 pts 26 pts 12 p 100 Team 3 21 p 50 pts 70 Team 2 30 pts 100 Team 1 30 pts 30 pts Earned points Project grade 21 pts Team Project grade Member ID Earned points Adjusted points Normalized points T1T1 100% M 1,1 30 (30/35 * 100) = 86 M 1,2 30 (30/35 * 100) = 86 M 1,3 30 (30/35 * 100) = 86 T2T2 70% M 2,1 21(21 * 0.7) = 14.7(14.7/35 * 100) = 42 M 2,2 50(50 * 0.7) = 35100 T3T3 100% M 3,1 21 (19/35 * 100) = 60 M 3,2 12 (12/35 * 100) = 34 M 3,3 35 100 M 3,4 26 (26/35 * 100) = 74

7. Introduction: Software is Complex Complex  complicated Complex = composed of many simple parts related to one another Complicated = not well understood, or explained

8. Complexity Example: Scheduling Fence Construction Tasks Setting posts [ 3 time units ] Cutting wood [ 2 time units ] Painting [ 5 time units for uncut wood; 4 time units otherwise ] Nailing [ 2 time units for unpainted; 3 time units otherwise ] Setting posts  Nailing, Painting Cutting  Nailing …shortest possible completion time = ? 8 [  “simple” problem, but hard to solve without a pen and paper ]

9. More Complexity Suppose today is Tuesday, November 29 What day will be on January 3? [ To answer, we need to bring the day names and the day numbers into coordination, and for that we may need again a pen and paper ]

10. The Role of Software Engg. (1) Customer Programmer A bridge from customer needs to programming implementation First law of software engineering Software engineer is willing to learn the problem domain (problem cannot be solved without understanding it first) 10

11. The Role of Software Engg. (2) 11

12. Example: ATM Machine Understanding the money-machine problem: 12

13. How ATM Machine Might Work Domain model created with help of domain expert 13

14. Cartoon Strip : How ATM Machine Works 14

15. Software Engineering Blueprints  Specifying software problems and solutions is like cartoon strip writing  Unfortunately, most of us are not artists, so we will use something less exciting: UML symbols  However … 15

16. Second Law of Software Engineering Software should be written for people first –( Computers run software, but hardware quickly becomes outdated ) –Useful + good software lives long –To nurture software, people must be able to understand it 16

17. Software Development Methods  Method = work strategy  The Feynman Problem-Solving Algorithm: (i) Write down the problem (ii) think very hard, and (iii) write down the answer.  Waterfall  Unidirectional, finish this step before moving to the next  Iterative + Incremental  Develop increment of functionality, repeat in a feedback loop  Agile  User feedback essential; feedback loops on several levels of granularity 17

18. Waterfall Method 18 Unidirectional, no way back finish this step before moving to the next

19. UML – Language of Symbols 19 UML = Unified Modeling Language Online information: http://www.uml.org

20. Understanding the Problem Domain System to be developed Actors –Agents external to the system Concepts/ Objects –Agents working inside the system Use Cases –Scenarios for using the system 20

21. ATM: Gallery of Players Actors (Easy to identify because they are visible!) 21

22. Gallery of Workers + Things Concepts (Hard to identify because they are invisible/imaginary!) 22

23. Use Case: Withdraw Cash 23

24. How ATM Machine Works (2) Domain Model (2) Alternative solution

25. How ATM Machine Works (3) Domain Model (3) Alternative solution Which solution is the best or even feasible?

26. Rube Goldberg Design 26 Garage door opener

27. Actual Design 27

28. Software Measurement What to measure? –Project (developer’s work), for budgeting and scheduling –Product, for quality assessment 28

29. Formal hedge pruning 29

30. Sizing the Problem (1) Size( ) = 10 Size(  ) = 7 Size(  ) = 4 Size(  ) = 3 Size( ) = 4 Size(  ) = 2 Size(  ) = 4 Size(  ) = 7 Step 2: Estimate relative sizes of all parts Step 1: Divide the problem into small & similar parts

31. Sizing the Problem (2) Step 3: Estimate the size of the total work Total size =   points-for-section i (i = 1..N) Step 4: Estimate speed of work (velocity) Step 5: Estimate the work duration Travel duration = Path size Travel velocity

32. Sizing the Problem (3) Advantages: –Velocity estimate may need to be adjusted (based on observed progress) –However, the total duration can be computed quickly (provided that the relative size estimates of parts are accurate – easier to achieve if the parts are small and similar-size)

33. Exponential Cost of Estimation Estimation cost Estimation accuracy 100%  Improving accuracy of estimation beyond a certain point requires huge cost and effort (known as the law of diminishing returns)  In the beginning of the curve, a modest effort investment yields huge gains in accuracy 33

34. Estimation Error Over Time Time Estimation error CompletionStart The cone of uncertainty starts high and narrows down to zero as the project approaches completion. RequirementsDesignImplementation

35. Agile Project Effort Estimation 35

36. Measuring Quality of Work 36

37. Concept Maps PropositionConceptRelationConcept 1.Ihavefriend 2.friendengages incoding 3.codingconstructs aprogram 4.programisnew SENTENCE: “My friend is coding a new program” translated into propositions Search the Web for Concept Maps 37 Useful tool for problem domain description

38. Case Study: Home Access Control Objective: Design an electronic system for: –Home access control Locks and lighting operation –Intrusion detection and warning 38

39. Case Study – More Details 39

40. Know Your Problem Mortise Lock Parts 40

41. Concept Map for Home Access Control 41

42. States and Transition Rules lockedunlocked IF validKey THEN unlock IF pushLockButton THEN lock IF timeAfterUnlock ≥ max{ autoLockInterval, holdOpenInterval } THEN lock IF validKey AND holdOpenInterval THEN unlock 42 … what seemed a simple problem, now is becoming complex