1. Sept. 4, 2003CS 509 - WPI1 CS 509 Design of Software Systems Fuller Labs, Room 311 Thursday Evenings 6 - 9pm Instructor: Diane Kramer

2. Sept. 4, 2003CS 509 - WPI2 §Attendance, Add/Drop, etc. §Handouts: l General Course Info & Syllabus l Term Project – Meeting Coordinator §Other administrivia: l Student survey l Assign groups for MC project §Lecture #1: Intro to Software Engineering Class Format for Today

3. Sept. 4, 2003CS 509 - WPI3 General Course Info §Course Web Site: http://www.cs.wpi.edu/~cs509/f03 l lecture slides, handouts, announcements, etc. §Prerequisites, grading, project journal §Academic Integrity: l Work in groups, no sharing across groups! l Cheating = not acknowledging the contributions of others

4. Sept. 4, 2003CS 509 - WPI4 Syllabus §Reading order: arranged by need §Lecture topics include book chapters plus additional material: l Functional Specifications (YES) l Rationale Management (NO) l Test & Development Plans (YES) §May have more peer reviews if time permits

5. Sept. 4, 2003CS 509 - WPI5 Term Project – Meeting Coord. §Project Plan §Reviews & group evaluations §Development Schedule §Description of project §Learning more about requirements - write down questions as you think of them!

6. Sept. 4, 2003CS 509 - WPI6 The Nature of this Course §Simulate a workplace environment l How is it similar, different? §Take an active role in learning process §Confused about something? l Interrupt me, ask questions! §Requirements are not laws or absolute truths §Help define the work you will accomplish §Take responsibility for scheduling: l Keep track of your time - No Surprises!

7. Sept. 4, 2003CS 509 - WPI7 Administrivia §Student surveys – this is not a test! §Group assignments – after the break âYou will be doing a lot of group work this term. Get your group together briefly (tonight, after class) to decide on a weekly meeting time.

8. Sept. 4, 2003CS 509 - WPI8 Lecture #1: Introduction §What is Software Engineering? §What is Engineering in general? §How does engineering apply to software development? §Why do we need it? §What problems does it solve?

9. Sept. 4, 2003CS 509 - WPI9 What is Software Engineering? §Managing Software Development §Process and Planning §Engineering in general? a: the application of science and mathematics by which the properties of matter and the sources of energy in nature are made useful to people b: the design and manufacture of complex products --Merriam-Webster On-line Dictionary

10. Sept. 4, 2003CS 509 - WPI10 Why is SW Eng. Useful? §Computer Science used to be obsessed with Algorithms l Why? Why has this changed? §Now more concerned with process l Complexity of SW systems l Correctness, Reliability l Ease of use (HCI)

11. Sept. 4, 2003CS 509 - WPI11 Text Book Definition §Modeling §Problem Solving §Knowledge Acquisition §Rationale Management

12. Sept. 4, 2003CS 509 - WPI12 What is Modeling? §Dealing with complexity through Abstraction §Focus on only the relevant details l Problem Domain Understanding of environmental factors Description of relevant aspects of “real-world” l Solution Domain Understanding of trade-offs Descriptions of alternative possible solutions

13. Sept. 4, 2003CS 509 - WPI13 Problems & Knowledge §Problem Solving l Search for solution l Driven by experimentation §Knowledge Acquisition l Collect data l Organize into information l Formalize into knowledge l What does it mean to be “nonlinear”?

14. Sept. 4, 2003CS 509 - WPI14 Rationale Management §Capture decision context §Document issues that go into decision making §Implications of proposed change §Useful when revisiting a decision §Used throughout software development §Ideal: Rationale doc is produced and maintained §Realistic: Rationale is kept in mind, documented wherever possible (e.g. as comments in code)

15. Sept. 4, 2003CS 509 - WPI15 Software Engineering Concepts §Participants and Roles §Systems and Models §Work Products §Activities, Tasks, and Resources §Goals, Requirements, and Constraints §Notations, Methods, and Methodologies

16. Sept. 4, 2003CS 509 - WPI16 Software engineering concepts, depicted as a UML class diagram (OMG, 1998). consumes Activity Work ProductResourcesTask EquipmentParticipantDocument Model System is produced by * * ** Project Time Figure 1-1, Page 11 “contains” “zero or more” “is a” “relationship”

17. Sept. 4, 2003CS 509 - WPI17 Participants and Roles §Who is involved in Software Development? l Client, end user l Developer l Project Manager §What responsibilities are involved? l Each set of tasks constitutes a role l The same participant can fulfill multiple roles

18. Sept. 4, 2003CS 509 - WPI18 Systems, Models, Work Product §The System is the underlying Reality §A Model is an Abstraction §A Work Product is an Artifact l Internal/External Documents Functional Specification User Guide l Source/Executable code Deliverables defined in advance

19. Sept. 4, 2003CS 509 - WPI19 Activities, Tasks, Resources §An Activity is a set of Tasks l A Role may define the Activities §A Task is an Atomic Unit of work l Small enough to be manageable §Resources are Assets used by Tasks l Examples: time, equipment, labor, etc.

20. Sept. 4, 2003CS 509 - WPI20 Goals, Req’s, Constraints §Goals define important Attributes l Examples: Safe, Reliable, Fast, etc. l Goals sometimes conflict, require trade-offs §Requirements define Features of a system §Constraints typically limit features and requirements l Examples: time, cost, platform, etc.

21. Sept. 4, 2003CS 509 - WPI21 Notations & Methodologies §Notation = Graphical (or textual) representation of a Model l Examples: Alphabet, UML, Set Notation §Method = Repeatable problem-solving technique l Examples: Recipe, Algorithm, etc. §Methodology = Collection of methods for solving a class of problems l Typically involves decomposition

22. Sept. 4, 2003CS 509 - WPI22 Development Activities §Requirements Analysis §Functional Specifications §System & Object Design §Test Planning §Implementation & Testing §QA: What’s the best way to produce Quality Software?

23. Sept. 4, 2003CS 509 - WPI23 Requirements §Elicitation of requirements from client l Define Purpose of system l Describe Problem(s) to be solved l Determine Goals and Constraints §Work Product: description of system in terms of Actors and Use Cases l External entities that interact with system l Sequences of events describing interactions

24. Sept. 4, 2003CS 509 - WPI24 Functional Specifications §How problems will be solved §What will be done to solve problems §Describe high-level implementation from Client or End User perspective: l Assume they don’t know programming l No algorithms, pseudo-code or techno-babble l Often includes Mock-up or Prototype – why?

25. Sept. 4, 2003CS 509 - WPI25 System & Object Design §Define goals of system §Decomposition into smaller subsystems §Strategy decisions l Examples: Hardware/Software platforms, data management, control flow §What objects are needed in the system? §Formalize interfaces between objects

26. Sept. 4, 2003CS 509 - WPI26 Test Planning §Strategy for verifying correctness of implementation §Unit tests, System tests, Regression tests §Design activity – testability built in l Can’t be retro-fitted after implementation §OO Classes make testing easier - how?

27. Sept. 4, 2003CS 509 - WPI27 Implementation & Testing §Translate development models into source code & run experiments to verify correct functionality §This is the easy part!

28. Sept. 4, 2003CS 509 - WPI28 Quality Assurance §How is QA usually done? l Write the code l Get someone else to test it l Testing is the last bottleneck before shipping l QA often blamed for defects §Does this produce Quality software? §How can we build quality into the process of Software Development?

29. Sept. 4, 2003CS 509 - WPI29 Managing Software Development §Communication §Rationale Management §Testing §Software Configuration Management §Project Management §Software Life Cycle

30. Sept. 4, 2003CS 509 - WPI30 Communication §Critical and time-consuming l Exchange of ideas - models, documents, etc. l Status reporting l Raising, negotiating & resolving issues §Why is it difficult? §How can we make it easier? l Conventions: everyone must agree to use them!

31. Sept. 4, 2003CS 509 - WPI31 Rationale Management §Justification of decisions: l Problems addressed, alternatives considered, evaluation criteria, etc. §Often exists only in our heads l Not accessible to others l Sometimes we forget! §Complex information, difficult to record, update and maintain

32. Sept. 4, 2003CS 509 - WPI32 Testing §Strategies: l Uncover defects l Verify correct functionality §Types of testing (unit, integration, etc.) §Variety of input data §Useful to have someone else test our code l Why?

33. Sept. 4, 2003CS 509 - WPI33 Configuration Management §Source Code or Revision control §Provides control over Builds & Releases §Enables historical tracking, recovery of known state §Allows branching for customization §Powerful SCC systems allow multi-user access: sharing, diff, merge, etc.

34. Sept. 4, 2003CS 509 - WPI34 Project Management §Oversight activities, attempt to ensure delivery of high-quality system l On time l Within budget §Planning, scheduling, budgeting, hiring, organizing, and monitoring status §Requires knowledge of SW dev processes §Requires flexibility - things change!

35. Sept. 4, 2003CS 509 - WPI35 Software Life Cycle §Modeling the software development process §Usually not linear §More about life cycles in Chapt. 12 l Levels of maturity l Types of Models E.g. Waterfall, “V” model, Spiral, etc.

36. Sept. 4, 2003CS 509 - WPI36 Discussion: Process & Planning §What are the Processes in SW Engineering? l What purpose does each serve? l What tasks are involved? §How do we plan software development? l How long do things take? (Keep track!) l Scheduling: Make a guess Improve accuracy with experience §Metrics - measuring how we’re doing

37. Sept. 4, 2003CS 509 - WPI37 Preview - Requirements §Handout – Requirements Documentation §Download sample from course web site §Handout – Sample use case §Start thinking about requirements for MC l Bring questions for next time