1. Jan. 19, 2004CS 509 - WPI1 CS 509 Design of Software Systems General Dynamics, Needham Mondays 4 – 8 pm Instructor: Diane Kramer

2. Jan. 19, 2004CS 509 - WPI2 §Review General Course Info & Syllabus §Term Project: l Overview handout l Project Journal §Lecture #1: l Intro to Software Engineering (Chapter 1) l Requirements (Chapter 4) §Requirements Discussion – Marketing Magic Class Format for Today

3. Jan. 19, 2004CS 509 - WPI3 General Course Info §Course Web Site: http://www.cs.wpi.edu/~cs509/s04 l Lecture slides, handouts, announcements, etc. §Prerequisites, grading, project journal §Academic Integrity: l Collaboration work on project, not for quizzes l Cheating = not acknowledging the contributions of others

4. Jan. 19, 2004CS 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 Testing (Will discuss but won’t implement) §In class activities include reviews & status §Quiz schedule for reading topics

5. Jan. 19, 2004CS 509 - WPI5 Term Project – CTS Overview §Project Plan §Development Schedule §Description of project l Review preliminary requirements during break §Learning more about requirements: l Write down questions as you think of them! l Use email to get answers as needed

6. Jan. 19, 2004CS 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. Jan. 19, 2004CS 509 - WPI7 Contact Info §Pass around sign-up sheet l Print name (neatly) l Print email address l Phone number & best time to contact §Send email to class list §Later we will discuss working in groups

8. Jan. 19, 2004CS 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. Jan. 19, 2004CS 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. Jan. 19, 2004CS 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. Jan. 19, 2004CS 509 - WPI11 Text Book Definition §Modeling §Problem Solving §Knowledge Acquisition §Rationale Management

12. Jan. 19, 2004CS 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. Jan. 19, 2004CS 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. Jan. 19, 2004CS 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. Jan. 19, 2004CS 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. Jan. 19, 2004CS 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. Jan. 19, 2004CS 509 - WPI17 Participants and Roles §Who is involved in Software Development? l Client, end user l Developer l Project Manager l Others? §What responsibilities are involved? l Each set of tasks constitutes a role l The same participant can fulfill multiple roles

18. Jan. 19, 2004CS 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. Jan. 19, 2004CS 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. §All of these need to be planned & managed

20. Jan. 19, 2004CS 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. Jan. 19, 2004CS 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. Jan. 19, 2004CS 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. Jan. 19, 2004CS 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. Jan. 19, 2004CS 509 - WPI24 Analysis §Produce model of system that is correct, complete, consistent and unambiguous §“Object” model, in the problem domain §Uncover ambiguities and inconsistencies §System model annotated with attributes, operations and associations

25. Jan. 19, 2004CS 509 - WPI25 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?

26. Jan. 19, 2004CS 509 - WPI26 System & Object Design §Define goals of system §Produce models in the solution domain §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

27. Jan. 19, 2004CS 509 - WPI27 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?

28. Jan. 19, 2004CS 509 - WPI28 Implementation & Testing §Translate development models into source code & run experiments to verify correct functionality §This is the easy part!

29. Jan. 19, 2004CS 509 - WPI29 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?

30. Jan. 19, 2004CS 509 - WPI30 Managing Software Development §Communication §Rationale Management §Testing §Software Configuration Management §Project Management §Software Life Cycle

31. Jan. 19, 2004CS 509 - WPI31 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!

32. Jan. 19, 2004CS 509 - WPI32 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

33. Jan. 19, 2004CS 509 - WPI33 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?

34. Jan. 19, 2004CS 509 - WPI34 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.

35. Jan. 19, 2004CS 509 - WPI35 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!

36. Jan. 19, 2004CS 509 - WPI36 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.

37. Jan. 19, 2004CS 509 - WPI37 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

38. Jan. 19, 2004CS 509 - WPI38 Preview - Requirements §Handout – Requirements Documentation §Download sample from course web site §Handout from Marketing Magic §Start thinking about requirements for CTS l Bring questions after the break

39. Jan. 19, 2004CS 509 - WPI39 Short Break Review Preliminary Requirements for CTS

40. Jan. 19, 2004CS 509 - WPI40 Questions? §Lecture from Chapter 1 §About Marketing Magic document §Anything else? §More time to discuss requirements later

41. Jan. 19, 2004CS 509 - WPI41 Intro. to Requirements §Define Requirements: l What are they? l What goes into a requirements document? §Why do we need requirements? What purpose do they serve? §What can go wrong without them? §Why do we write Requirements documents?

42. Jan. 19, 2004CS 509 - WPI42 Requirements Elicitation Chapter 4

43. Jan. 19, 2004CS 509 - WPI43 Requirements Activities §Identify Actors §Identify Participating Objects §Identify Scenarios §Identify Use Cases §Identify relationships among use cases §Identify nonfunctional requirements

44. Jan. 19, 2004CS 509 - WPI44 Participating Objects §Actors l Who will use the system? l What parts of the system are used by which actor? §Other participating objects l Main concepts in application domain l Glossary of terminology: define terms same concept always has same name different concepts always get different names

45. Jan. 19, 2004CS 509 - WPI45 Scenarios & Use Cases §Scenarios are concrete, focused descriptions of a single feature of the system §A scenario is an instance of a Use Case §Use Cases are generalizations of scenarios §A Use Case captures all possible scenarios for a given piece of functionality

46. Jan. 19, 2004CS 509 - WPI46 Heuristics §What are Heuristics? §How do they differ from an Algorithm? §See box on top of page 139.

47. Jan. 19, 2004CS 509 - WPI47 Use Case Relationships §Communication relationships - indicate flow of information §Extend relationships - used for exceptional, optional or seldom-occurring cases §Include relationships - used for sub-cases which are shared by two or more use cases §Do you need these relationships in your Requirements document?

48. Jan. 19, 2004CS 509 - WPI48 Nonfunctional Requirements §User-visible aspects of the system §Not directly related to functional behavior §Have impact on design, development and cost of the system §See bullet list on page 147 in textbook

49. Jan. 19, 2004CS 509 - WPI49 Objectives & Success Criteria §What are typical objectives of a SW system? l Fast execution – how fast is fast enough? l Small in storage requirements – how small? l User friendly l Other examples? §What are success criteria? l How do you determine whether you’ve met an objective?

50. Jan. 19, 2004CS 509 - WPI50 Other notes about RAD §See outline on page 152. §2 sections for terminology: 1.4, 4. l Use what seems applicable §Sample Requirements Doc on course web site l Functional requirements could be expanded l Scenarios section incomplete – needs more work l Use Cases only just started

51. Jan. 19, 2004CS 509 - WPI51 Requirements Exercises

52. Jan. 19, 2004CS 509 - WPI52 Exercise #1 - Definitions (From textbook, exercise #11, page 170) §Get out a clean sheet of paper §Write down a brief definition for the term “menu” §Pass your papers up to the front §Compare definitions l Are there differences? If so, what are they? l Discuss.

53. Jan. 19, 2004CS 509 - WPI53 Exercise #2 - Features Design and build a “chair” §Definition - what is a chair? l What is its purpose? l What are its salient characteristics? §Design decisions: l What choices are there? l Who decides?

54. Jan. 19, 2004CS 509 - WPI54 Exercise #3 – Elicitation Collaboration Tool Suite §What are various parts of the system? §Review requirements for these parts l Ask questions §Assignments for Phase 1 l Which part(s) are you interested in working on?

55. Jan. 19, 2004CS 509 - WPI55 For Next Time §Turn in Phase 1 assignment: Requirements §Turn in project journal §Read chapters 1, 2, 4, 5 l Quiz will be on chapters 1, 2, 4 §We will review chapters 2 & 5 l Modeling with UML l Analysis