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

Final Review Summer 2003 1

ICS 52: Introduction to Software Engineering

Lecture Notes for Summer Quarter, 2003

Michele RousseauFinal Review


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.


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


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


Software Lifecycle Models

You should know different life cycles and the differences between them.

Know the Fundamental Activities of a software lifecycle


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?


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


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.


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.


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


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?


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


V-Model of Development and Testing

Develop Acceptance TestsAcceptance Test Review

Requirements ReviewDevelop Requirements Execute System Tests

Develop Integration TestsIntegration Tests Review

Design ReviewDesign Execute Integration Tests

Develop Unit TestsUnit Tests Review

Code ReviewCode Execute Unit Tests


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?


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?


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?


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?


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


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?


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


Equivalence Partitioning

You should know.. What is it? What is a basis? How to construct a testing matrix and

what it is good for..


Regression Testing

You should know…• Why do we do it?• What is selective regressing testing


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


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.


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


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.


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.


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!


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


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


ISO9000 and CMM compared

CMM ISO 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

Final Review Summer 2003

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


PSP Evolution

PSP0Current processTime recording

Defect recordingDefect type standard

PSP1Size estimating

Test report

PSP2Code reviews

Design reviews

PSP3Cyclic development

PSP2.1Design templates

PSP1.1Task planning

Schedule planning

PSP0.1Coding standard

Size measurementProcess improvement

proposal (PIP)

Baseline Personal Process

Cyclic Personal Process

Personal Quality Management

Personal Planning Process


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


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


PSP/TSP/CMM


Thank you!

Documents

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