ICS 52 Introduction to Software Engineering Lecture Notes

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

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

Exam coverage l l Final Review 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 Summer 2003 3

Software Engineering l l l 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. . • • Final Review What went wrong. . What have you learned that could have avoided some of these problems Summer 2003 4

Software Lifecycle Models l l Final Review You should know different life cycles and the differences between them. Know the Fundamental Activities of a software lifecycle Summer 2003 5

Requirements l l l Final Review 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? Summer 2003 6

Requirements l l 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 l How can we verify requirements? • Reviews, prototyping, test-cases, consistency analysis Final Review Summer 2003 7

Architectural Design l l l Final Review 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. Summer 2003 8

Module Design l l Final Review 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. Summer 2003 9

OO design l l Final Review 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 Summer 2003 10

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

Testing Levels l l l 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 • Defined at Design -> Run after Module Testing • Defined at Design -> Run after Unit Testing • Defined at Implementation -> Run after Implementation of each unit Integration Testing Module Testing Unit Testing Regression Testing (testing after Change) • Final Review Defined throughout the process -> Run after modifcations Summer 2003 12

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

Verification and Validation l l You should know… What are V&V? • • • l Has two principal objectives • • l Final Review 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 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? Summer 2003 14

Quality Assurance l l 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? Final Review Summer 2003 15

Testing l l Final Review 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? Summer 2003 16

Integration Testing l l 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? Final Review Summer 2003 17

Unit Testing l l 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 Final Review Summer 2003 18

Testing l l You should know… how to test a program for failures • Using white-box testing (structural/glass-box) • Using black-box testing (functional/specification based) l 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? Final Review Summer 2003 19

Flow Graphs l l l l 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 • 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 The difference between coverage criterias Subsumption. . Challenges: • • Final Review Summer 2003 20

Equivalence Partitioning l l Final Review You should know. . What is it? What is a basis? How to construct a testing matrix and what it is good for. . Summer 2003 21

Regression Testing l You should know… • Why do we do it? • What is selective regressing testing Final Review Summer 2003 22

Process improvement l l You should know. . CMM/ISO 9000/PSP • What are they? How do the differ? • CMM- focused on process improvement » From CMU • ISO 9000 -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 Final Review Summer 2003 23

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

CMM l l l 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 Final Review Summer 2003 25

Characteristics of Immaturity l l l 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. Final Review Summer 2003 26

Characteristics of Maturity l l l l 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. Final Review Summer 2003 27

ISO 9000 – What is it? l l l ISO 9000 is primarily concerned with "quality management". Driven by quality manual – headers defined by ISO 9000 guidelines. Adherence to the manual! Final Review Summer 2003 28

ISO vs CMM l l l 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 has little explicit support for continuous improvement Final Review Summer 2003 29

ISO vs CMM (2) l l l 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 Final Review Summer 2003 30

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

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

PSP Evolution Cyclic Personal Process PSP 3 Cyclic development PSP 2 Personal Quality Management Code reviews Design reviews PSP 1 Personal Planning Process Baseline Personal Process Final Review Size estimating Test report PSP 0 Current process Time recording Defect type standard Summer 2003 PSP 2. 1 Design templates PSP 1. 1 Task planning Schedule planning PSP 0. 1 Coding standard Size measurement Process improvement proposal (PIP)

Overview of CMM and PSP l l Final Review 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 Summer 2003 34

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

PSP/TSP/CMM Final Review Summer 2003 36

Thank you! Final Review Summer 2003 37