ICS 52: Introduction to Software Engineering

1. ICS 52: Introduction to Software Engineering Lecture Notes for Summer Quarter, 2003 Michele Rousseau Final Review

2. Exam Format • The exam will include: • T/F questions • Multiple choice questions • Short answer/fill-in-the-blank questions • Short essay questions • The exam will be Thursday August 28th, from 2 pm to 4 pm. • The exam is closed book, closed notes.

3. Exam coverage • Lecture topics 1-14, plus slides from LAS and Arianne 5 examples. All these are linked from the course schedule on the web. • Sommerville, chapters 1-3, 4.4,5-12, 14, 19, 20, 25

4. Software Engineering • What is software? • What types of issues does the discipline of S/E address and how does it address them? • You should know the basic principles of software engineering (such as rigor, separation of concerns, abstraction, anticipation of change, generality, incrementality) and know how they apply throughout the software lifecycle. • You should understand the meaning and use of the basic software qualities discussed in class. • Think about Ariane 5 and LAS.. • What went wrong.. • What have you learned that could have avoided some of these problems

5. Software Lifecycle Models • You should know different life cycles and the differences between them. • Know the Fundamental Activities of a software lifecycle

6. Requirements • You should know how to interview a customer to elicit requirements. • You should understand the structure of a requirements document and know the appropriate kinds of information contained with in the document.(what does it describe?) • What is the difference between functional and non-functional requirements?

7. Requirements • Know the challenges of specifying requirements. • Why is it important to get them right? • Adv./Disadv. Of NL requirements? • What are the alternatives? • Structured language, form-based, formal Specifications • How can we verify requirements? • Reviews, prototyping, test-cases, consistency analysis

8. Architectural Design • You should know the models covered in class and the differences (pros/cons) between the architectural styles. • You should understand the difference between architecture and module design. • You should be able to choose an appropriate architectural style for a particular problem.

9. Module Design • You should be able to use provided/exported and required/imported interfaces to define module boundaries. • You should be able to identify and define modules and abstract data types in a design. • You should understand coupling, cohesion, fan-in, and fan-out, information hiding, stepwise refinement. • You should be able to create USES and COMPRISES diagrams.

10. OO design • You should know.. • How to go from a NL requirements to design • How to choose classes/attributes/operations • How to assign responsibilities to the class

11. Implementation • You should know general rules of programming style and clarity • You should be able to implement a design. • Choose a suitable language • Establish coding conventions • Divide the work effort • Implement • Why are these things important?

12. Testing Levels • You should know the different levels of testing – when the are defined and when the are executed. • System Testing • Defined at Requirements -> Run after integration testing • Integration Testing • Defined at Design -> Run after Module Testing • Module Testing • Defined at Design -> Run after Unit Testing • Unit Testing • Defined at Implementation -> Run after Implementation of each unit • Regression Testing (testing after Change) • Defined throughout the process -> Run after modifcations

13. V-Model of Development and Testing Develop Requirements Execute System Tests Requirements Review Develop Acceptance Tests Acceptance Test Review Design Execute Integration Tests Design Review Develop Integration Tests Integration Tests Review Code Execute Unit Tests Code Review Develop Unit Tests Unit Tests Review

14. Verification and Validation • You should know… • What are V&V? • The software should conform to its specification • “are we building the product right?” • OR… • “Are we building the right product?” • The software should do what the customer wants • Has two principal objectives • The discovery of defects in a system • The assessment of whether or not the system is usable in an operational situation. • What is formal Verification?

15. Quality Assurance • What is the goal of QA? • What are the problems with QA? • Eliciting the customer’s intent • Software is complex and QA is difficult to perform • Management Aspects – what are the rewards structures? • QA vs. Developers • Can’t test exhaustively.. Why not?

16. Testing • Terminology • Failure: Incorrect or unexpected output, based on specifications • Fault: Invalid execution state • Error: Defect or anomaly or “bug” in source code • How do these relate to each other?

17. Integration Testing • What are the goals.. And why is it difficult. • What are the approaches? • Top-down • Bottom-up • Which uses drivers, harnesses, stubs.. • Which is better?

18. Unit Testing • You should know.. • Who should execute unit tests? • What are code-walkthroughs? (advs./disadv.) • Static vs. dynamic testing • The difference between static(inspections) and dynamic(testing) verification

19. Testing • You should know… • how to test a program for failures • Using white-box testing (structural/glass-box) • Using black-box testing (functional/specification based) • Fundamental Testing Questions • Test Criteria: What should we test? • equivalence partitioning • Test Oracle: Is the test correct? • Know what a test oracle is… • Test Adequacy: How much is enough? • Metrics, error seeding, independent testing, empiracal assurance • Test Process: Is our testing effective?

20. Flow Graphs • You should know… • Data flow • How to construct a control flow graph • How to define test cases to ensure: • All-statements (All-nodes) • All-branches • All-edges • All-paths • The difference between coverage criterias • Subsumption.. • Challenges: • Structural testing can cover all nodes or edges without revealing obvious faults • Some nodes, edges, or loop combinations may be infeasible • Thoroughness – all-edges ensures all-statements, but may not find as many faults as all statements

21. Equivalence Partitioning • You should know.. • What is it? • What is a basis? • How to construct a testing matrix and what it is good for..

22. Regression Testing • You should know… • Why do we do it? • What is selective regressing testing

23. Process improvement • You should know.. • CMM/ISO9000/PSP • What are they? How do the differ? • CMM- focused on process improvement • From CMU • ISO9000-focused on Quality Management • “say what you do, do what you say” • From international organization of standardization • More popular – not as stringent • PSP – focused on individual improvement

24. CMM • You should know.. • The maturity levels • 1. Initial : • ad hoc process. Success depends on individual effort. • 2. Repeatable : • Basic management processes: cost, schedule and functionality • 3. Defined : • Activities are documented, standardized and integrated into an organization-wide software process. • 4. Managed : • Detailed measures are collected: software and product quality. • 5.Optimizing : • Continuous process improvement: quantitative feedback from the process and from testing new ideas and technologies.

25. CMM • Focused on Process improvement • What is a KPA (Key process area and how do they relate to the different levels of CMM?) • What does maturity provide? (see table in set 14) • Lower costs • Higher quality • Faster production/fewer people

26. Characteristics of Immaturity • Software process improvised during the course of a project. • Even if process is specified, it is not rigorously followed or enforced. • Reactionary, focus on solving immediate crises. • Hard deadlines often mean a compromise in functionality and/or quality. • No objective basis for judging product quality or for solving process problems. • Quality is difficult if not impossible to predict.

27. Characteristics of Maturity • Able to manage software development and maintenance organization/project wide. • There is a prescribed, mandated, and enforced process. • Process is consistent with the way that work actually gets done. • Process is updated and improved as necessary. • Roles and responsibilities within the process are clear. • Quality is measured and monitored, and an objective basis for judgment exists. • The necessary infrastructure for supporting the process exists. • Workers see the value in the process.

28. ISO 9000 – What is it? • ISO 9000 is primarily concerned with "quality management". • Driven by quality manual – headers defined by ISO9000 guidelines. • Adherence to the manual!

29. ISO vs CMM • CMM and the ISO 9000 series of standards share common concerns with quality and process management. • CMM emphasizes continuous improvement • ISO deals with minimum criteria of quality systems • There is a clear correlation between the key processes in the CMM and the quality management processes in ISO 9000 • ISO 9000 has little explicit support for continuous improvement

30. ISO vs CMM (2) • The CMM is more detailed and prescriptive and includes a framework for improvement • An ISO 9001-compliant organization would not necessarily satisfy all of the CMM level 2 key process areas (it would satisfy most of the level 2 goals and many level 3 goals. • Organisations rated as level 2 in the CMM are likely to be ISO 9000 compliant

31. ISO9000 and CMM compared CMMISO 9001 • Specific to software development Intended for most industries • Used in USA, less widely Recognised and accepted in most elsewhere (this is changing) ountries • Provides detailed and specific Specifies concepts, principles and definition of what is required safeguards that should be in place for given levels • Assesses on 5 levels Establishes one acceptable level • CMM Level 2 - 3  ISO 9000 • Relevant to Stabilises the customer - supplier s/w development process relationship • No time limit on certification Certification valid for three years • No ongoing audit Auditors may return for spot checks during the lifetime of the certificate

32. PSP Overview • The PSP is introduced in 7 upward compatible steps (4 levels) • Gather and analyze data on your work • Many standard forms & spreadsheet templates • Use these analyses to improve your work • Note patterns in your work

33. PSP Evolution PSP3 Cyclic development Cyclic Personal Process PSP2.1 Design templates PSP2 Code reviews Design reviews Personal Quality Management PSP1.1 Task planning Schedule planning PSP1 Size estimating Test report Personal Planning Process PSP0.1 Coding standard Size measurement Process improvement proposal (PIP) Baseline Personal Process PSP0 Current process Time recording Defect recording Defect type standard

34. Overview of CMM and PSP • CMM sets out the principal practices for managing the processes in large-scale software development • PSP sets out the principal practices for defining, measuring and analysing an individual’s own processes

35. PSP Evaluation • Humphrey has used in SE courses • Improvements in time-to-compile, quality and productivity • Patchy, but promising use in industry • E.g. Nortel (Atlanta) • Still immature • Requires large overhead for data gathering • Not clear that you should use permanently or continually

36. PSP/TSP/CMM

37. Thank you!