SWE 513: Software Engineering

1
SWE 513 Software Engineering
Reliability I
2
Building Dependable Systems
The human mind can encompass only limited
complexity gt Comprehensibility gt
Simplicity gt Partitioning of complexity
3
Principles for Dependable Systems
High-quality has to be built-in gt Each stage
of development must be done well gt Testing and
correction does not lead to quality gt Changes
should be incorporated into the structure
4
Quality Management Processes
Assumption Good processes lead to good
software The importance of routine Standard
terminology (requirements, specification, design,
etc.) Software standards (naming conventions,
etc.) Internal and external documentation Report
ing procedures
5
Factors for Reliable Software
Precise, unambiguous specification
Organization culture that expects quality
Approach to software design and implementation
that hides complexity (e.g., structured design,
object-oriented programming) Use of software
tools that restrict or detect errors (e.g.,
strongly typed languages, source control systems,
debuggers) Programming style that emphasizes
simplicity, readability, and avoidance of
dangerous constructs Incremental validation
6
Quality Management Processes
Change management Source code management and
version control Tracking of change requests and
bug reports Procedures for changing requirements
specifications, designs and other
documentation Release control
7
Process (Plan) Reviews
Objectives To review progress against plan
(formal or informal) To adjust plan
(schedule, team assignments, functionality,
etc.) Impact on quality Good quality systems
usually result from plans that are demanding but
realistic Good people like to be stretched and to
work hard, but must not be pressed beyond their
capabilities.
8
Design and Code Reviews
DESIGN AND CODE REVIEWS ARE A FUNDAMENTAL PART OF
GOOD SOFTWARE DEVELOPMENT Concept Colleagues
review each other's work can be
applied to any stage of software development
can be formal or informal Most effective
when everybody prepares well.
9
Benefits of Design and Code Reviews
Benefits Extra eyes spot mistakes, suggest
improvements Colleagues share expertise
helps with training An occasion to tidy
loose ends Incompatibilities between
components can be identified Helps
scheduling and management control Fundamental
requirements Senior team members must show
leadership Must be helpful, not threatening
10
Review Team (Full Version)
Moderator -- ensures that the meeting moves ahead
steadily Scribe -- records discussion in a
constructive manner Developer -- person(s) whose
work is being reviewed Interested parties --
people above and below in the software
process Outside experts -- knowledgeable people
who have are not working on this project Client
-- representatives of the client who are
knowledgeable about this part of the process
11
Example Program Design
Moderator Scribe Developer -- the design
team Interested parties -- people who created the
system design and/or requirements specification,
and the programmers who will implement the
system Outside experts -- knowledgeable people
who have are not working on this project Client
-- only if the client has a strong technical
representative
12
Process
Preparation The developer provides colleagues
with documentation (e.g., specification or
design), or code listing Participants study the
documentation in advance Meeting The developer
leads the reviewers through the documentation,
describing what each section does and encouraging
questions Must allow plenty of time and be
prepared to continue on another day.