Module IV - Construction

CSDP Preparation Course
Module IV: Software

Construction
Specifications
The exam specific topics covered in this module are listed
below, and are the basis for the outline of its content
A. Construction Planning
B. Code Design
C. Data Design and Management
D. Error Processing
E. Source Code Organization
F. Code Documentation
G. Construction Quality Assurance
H. System Integration and Deployment
I. Code Tuning
J. Construction Tools
Module IV - Software Construction 2

Objectives
After completing this module, you should be able to
Define the software construction
Discuss how to plan for software construction
Examine the factors that effect the size, cost, and schedule
for software construction
Discuss software construction quality factors and quality
assurance
List and describe software construction tools
Describe how to design and document code
Describe what is meant by code tuning and how to do it
Describe error processing
Define the various types of system integration

Organization
The organization of information for each specification topic is as
follows:
Topic Content Slides - detail the important issues concerning
each topic and support the module objectives
Topic Reference Slides - detail the sources for the topical
content and provides additional references for review
Topic Quiz Slides - allow students to prepare for the exam

Introduction
Definition of Software Construction:
Detailed creation of working, meaningful software through a
combination of coding, verification, unit testing,
integration testing, and debugging
Software construction closely tied to

Software design
Software testing
Design
Construction
Testing

Introduction - 2
More on Construction
Significant detailed design occurs during construction
Low-level (e.g. unit and module integration) testing occurs
during construction
Construction produces high volume of configuration items
Thus construction linked to configuration management
Construction is tool intensive
Quality (or lack thereof) is very evident in the construction
products
Construction highly related to Computer Science due to
Use of algorithms
Detailed coding practices

Introduction - 3
Software Construction Fundamentals
The fundamentals of software construction include:
Minimizing complexity
Anticipating change
Constructing for verification
Standards in construction
The following slides discuss each of these fundamentals

Introduction - 4
Minimizing Complexity
Humans are severely limited in our ability to hold complex
information in our working memories
As a result, minimizing complexity is one the of strongest
drivers in software construction
Need to reduce complexity throughout the lifecycle
As functionality increases, so does complexity
Accomplished through use of standards
Examples:
J2EE for complex, distributed Java applications
UML for modeling all aspects of complex systems
High-order programming languages such as C++ and
Java
Source code formatting rules to aid readability

Introduction - 5
Anticipating Change
Software changes over time
Anticipation of change affect how software is constructed
This can effect
Use of control structures
Handling of errors
Source code organization
Code documentation
Coding standards

Introduction - 6
Constructing for Verification
Construct software that allows bugs to be easily found and fixed
Examples:
Enforce coding standards
Helps support code reviews
Unit testing
Organizing code to support automated testing
Restricted use of complex or hard-to-understand language
structures

Introduction - 7
Standards in Construction
Standards which directly affect construction issues include:
Programming languages
E.g. standards for languages like Java and C++
Communication methods
E.g. standards for document formats and contents
Platforms
E.g. programmer interface standards for operating
system calls, J2EE
Tools
E.g. diagrammatic standards for notations like the Unified
Modeling Language

References
[IE04] IEEE Computer Society, Guide to the Software
Engineering Body of Knowledge (SWEBOK), IEEE
Computer Society Press, Los Alamitos, CA 20001, June
2004

A. Construction Planning
What is Construction Planning?
Laying out the work plan (i.e. schedule) to design,
implement, debug, and unit test the software
Construction planning major concerns:
Coders are typically not planners
Schedules will be difficult to maintain unless a good
architecture design is in place
Many organizations to not collect project data on which to
plan future projects
Many managers consider planning to be a waste of time
and therefore dont encourage it
Project plans may be limited to the construction plans
Many organizations and projects do not use systematic
cost estimating methods such as models

A. Construction Planning - 2
Improving Software Economics
Consider reducing development costs by planning to:
Reduce the size and/or complexity
Improve the development process
Use more highly skilled people and build better teams
Use better tools
Reduce quality thresholds
Some actions include
Use an object-oriented approach
Use COTS components
Use an iterative approach
Provide training to development team
Automate tedious tasks with tools

Construction Prerequisites
As with building construction, much of the success or failure
of the project already determined before construction begins
Upstream activities such as project planning, requirements,
architecture, and design are crucial to success
Typical high-risk areas
Project planning
Requirements
Architecture
Preparation is a way to reduce these risks

Problem Definition Prerequisite
The problem being solved via the application must be well
defined
Common names for the document containing the problem
statement:
Product Vision
Vision Statement
Product Definition
Defines the problem without reference to potential solutions
Helps avoid solving the wrong problem!

Requirements Prerequisite
Requirements describe in detail what a system is supposed
to do, therefore are invaluable for construction
Explicit requirements:
Help ensure the user drives system functionality
Rather than the programmer
Reduce the number of construction debates
Help minimize changes after development begins
Specifying requirements adequately is a key to project
success

Architecture Prerequisite
Quality of the architecture determines the conceptual
integrity of the system
A proper architecture:
Gives structure to maintain conceptual integrity
Provides guidance to programmers
Partitions work
Architecture-level problems are much more costly to fix than
are coding errors
Good architecture can make construction easy
Bad architecture makes construction difficult

Regarding Upstream Prerequisites
Time budgeted for requirements and architecture work
10 to 20 percent of manpower
20 to 30 percent of schedule
If requirements are unstable
Do not ignore, spend time to fix
The analyst should fix if a formal project
Can be fixed by the programmer for informal projects
Use same heuristics for problems with the architecture

Choose an Approach
Many software development approaches have been tried
over the years
Some examples (not mutually exclusive):
Functional
Object-Oriented
Iterative
Waterfall
Agile
Data-centric
The construction team must follow some approach
Chosen approach must be appropriate for the task at hand

Choose a Programming Language
Programming language choices affect
Productivity
Code quality
Programmers more productive using a familiar language
High-level languages provided higher quality and better
productivity
Some languages better at expressing programming concepts
than others
The ways in which a programmers express themselves are
affected by the chosen language

Choose Construction Practices
Questions to answer regarding practices:
How detailed will the design be?
What are the coding conventions for names, comments,
layout, etc.?
How will the architecture be enforced?
Is the projects use of technology ahead of or behind the
power curve, and is this appropriate given the
circumstances?
What is the integration procedure, how often is it done,
and who participates?
Will developers program individually, in pairs, or some
combination of this?
Where and when will builds occur?

Choose Tools
Modern programming tools
Are essential to maintain programmer productivity
Reduce tedious and redundant tasks
Must be appropriate for the task at hand
Tools preparation checklist:
Are all product licenses current?
Are all products at current, supported revision level?
Have all programmers received proper training on the tools?
Does the project have a configuration management tool?
Does the project have a tool to track change requests?
Do project team members have sufficient workstations?
Does the project have sufficient test environments?
Does the project have sufficient build environments?

Construct the Team
For small development efforts
Self managed
Everyone is a peer
For mid-size development efforts
Single team Role # / Team*
For large development efforts Lead 1

Detailed designer 1 to 4
Multiple teams Coder 5 to 10
Integrator 1 to 2
Unit tester Same as coder
System tester 1
Buildmeister 1
Configuration manager 1
* Individuals will play multiple roles
Table 1: Team Composition

A. References
2004
[RS04] IBM Rational Software, The Rational Unified
Process v2003.06.13, 2004
[RT03]
[SM04] S. McConnell, Code Complete: A Practical
Handbook of Software Construction, Second Edition,
Microsoft Press, 2004.
[WR01] Walker Royce, Software Project Management, A
Unified Framework, Addison-Wesley, Boston, MA, 2001

A. Quiz 1
According to this lesson, construction planning involves creating
a schedule for all except which of the following:
a) Design
b) Implement
c) Integrate
d) Unit test
1) a
2) b
3) c
4) d

A. Quiz 2
Which are valid ways to reduce development costs:
a) Reduce the number of requirements
b) Reduce quality
c) Use more highly skilled people
1) a
2) b
3) c
4) None are valid
5) All are valid

A. Quiz 3
The name given to the document that contains the problem
statement is
a) Product Vision
b) Vision Statement
c) Product Definition
1) a
2) b
3) c
4) All of the above

A. Quiz 4
After the completion of construction, problems discovered with
the architecture are typically
a) More costly to fix than coding errors
b) Less costly to fix than coding errors
c) Due to incorrect requirements
d) Due to missing requirements
1) a
2) b
3) c
4) d

A. Quiz 5
Up to 30 percent of the schedule should be allocated to
requirements and architecture activities.
1) True
2) False

B. Code Design
Software Design
The process of defining the software architecture,
components, modules, interfaces, test approach, and
data for a software system to satisfy specified
requirements.
IEEE Standard 729-1983

B. Code Design - 2
Importance of Managing Complexity
Most technical issues are due to high complexity
Users are demanding more functionality
Frequent source of complexity
Software Crisis: Ability to produce suitable applications is
not keeping pace with demand
Causing systems to be unreliable, slow, insecure, buggy
Separation of concerns is one method to overcome
complexity

B. Code Design - 3
How to Overcome Complexity
Ineffective designs come from three sources:
A complex solution to a simple problem
A Simple, incorrect solution to a complex problem
An inappropriate, complex solution to a complex problem
2 ways to manage complexity:

Minimize the amount of essential complexity
Keep accidental complexity from proliferating

B. Code Design - 4
Desirable Design Characteristics
Steve McConnell suggests achievement of the following:
1. Minimal complexity
2. Ease of maintenance
3. Loose coupling
4. Extensibility
5. High fan-in
6. Low-to-medium fan-out
7. Portability
8. Leanness
9. Stratification
10. Standard techniques

B. Code Design - 5
Desirable Design Characteristics (cont.)
Minimal complexity
KISS: Keep it simple, stupid!
Ease of maintenance
Use common programming constructs and
consistent naming conventions
Loose coupling
Reduce interdependencies within the code
Extensibility
Minimal ripple effect when changes are made
Reusability
Modules, components, & subsystems can be and
are reused

B. Code Design - 6
Desirable Design Characteristics (cont.)
High fan-in
Highly utilized classes
Low to medium fan-out
Call tree not to large
Portability
Able to be redeployed in a different environment
Leanness
No extra parts
Stratification
Consistent levels of abstraction across subsystems
Standard techniques
Stay with the tried and true

B. Code Design - 7
Levels of Design
5 levels of abstraction in software design:
Level 1 Software System

Level 2 Subsystems
Level 3 Classes
Level 4 Routines
Level 5 Internal Routine Design

B. Code Design - 8
Level 1 Software System
The entire system
Concern of the architect, not detailed designer
Unless system is extremely small

B. Code Design - 9
Level 2 Subsystems
Identify all major subsystems
I.e. identity the architectural layers and the contents in
each layer
Major design activities at this level are
1. Partition the program into major subsystems
2. Define subsystem interfaces

B. Code Design - 10
Level 3 Classes
Identify all classes by subsystem
Define class relationships
Generalizations
Dependencies
Associations
For each class, define its interface

B. Code Design - 11
Level 4 Routines
Define the routines for each class
Previously defined interfaces will help
Need to also identify internal routines
Level 4 activities may necessitate a return to Level 3 to
further define the interface
This is normal and encouraged in an iterative
development approach

B. Code Design - 12
Level 5 Internal Routine Design
Lay out the detailed functionality of each routine
Closest activity to programming
This includes:
Deciding program flow, perhaps by writing pseudocode
Choosing algorithms
Determining program calls
Determining return points
Inserting programming constructs such as loops and
case statements

B. Code Design - 13
Design Techniques
Find Real-World Objects
Form Consistent Abstractions
Encapsulate Implementation Details
Apply Inheritance
Hide Internal Information
Identify Areas Likely to Change
Ensure Loose Coupling
Apply Design Patterns

B. Code Design - 14
More Techniques
Aim for Strong Cohesion
Build Hierarchies
Formalize Class Contracts
Assign Responsibilities
Design for Test
Avoid Failure
Choose Binding Time Consciously
Make Central Points of Control
Consider Using Brute Force
Draw a Diagram
Keep Your Design Modular

B. Code Design - 15
Design Approaches
Iterate
Dont stagnate in any one activity
Instead, cycle through activities and return to the
beginning
Build on previous work
Divide and Conquer
Divide problem into more manageable chunks
Prototype
Create a quick and dirty version of the application
Provides insight into the problem
Collaborative Design
Two (or more) heads is better than one
Can be formal or informal

B. References
2004
[SM04] S. McConnell, Code Complete: A Practical
Handbook of Software Construction, Second Edition,
Microsoft Press, 2004.

B. Quiz 1
The issues related to the software crisis include:
a) Ineffective development practices
b) Inherent complexities of application development
c) Poor application quality
1) a & b
2) a & c
3) a
4) All of the above

B. Quiz 2
Levels of design deal with the:
a) Levels of abstraction within an application
b) Levels of abstraction within a subsystem
c) Levels of abstraction within a class
d) Levels of abstraction within a routine
1) a
2) b
3) c
4) d

B. Quiz 3
Subsystems are synonymous with architecture layers.
a) True
b) False

B. Quiz 4
Level 5 - Internal Routine Design includes:
a) Deciding program flow
b) Coding algorithms
c) Writing pseudocode
1) a
2) b
3) c
4) a & c

C. Data Design And Management
What is Data Design?

A method used to define and analyze data requirements
needed to support the business functions of an enterprise.
These data requirements are recorded as a conceptual data
model with associated data definitions. Data Design defines
the relationships between data elements and structures.
What is Data Management?

The act of ensuring database integrity, security, performance,
and recovery of data.

C. Data Design And Management - 2
Stages of Data Modeling
The data model evolves through three stages
1. Conceptual
High level key entities and their relationships
2. Logical
Refinement of the conceptual model into more
detailed logical entities
3. Physical
Detailed and optimized phyiscal database table
designs

Conceptual Data Modeling
Initial stage of database design
High-level definition of persistent data and its storage
Business model provides business and system entities
Starting point in the evolution of the data model
Can be represented by an Entity-Relationship (ER) model
Graphically via ER diagrams

Logical Data Modeling
Provides idealized view of key logical data entities and
relationships
Independent of any software or database implementation
Useful for modeling data structures to be shared across
applications
Obtain buy-in from relevant stakeholders in order to get
it right
Reduces risk
Not always necessary, especially for small data needs
Can skip the conceptual and logical model and start with
physical

Physical Data Design
Define the detailed physical design of the database
Tables
Views
Stored procedures
Steps to create the physical data model:
1. Define domains
2. Create initial physical database design elements
3. Define reference tables
4. Create primary key and unique constraints
5. Define data and referential integrity enforcement rules
6. De-normalize database design
7. Optimize data access
8. Define storage characteristics
9. Design stored procedures

Define Domains
A domain is used to enforce data type standards
Definitions of user-defined data types
Enhances interoperation across applications
Example:
day_of_week column defined as:
MON, TUE, WED, THU, FRI, SAT, SUN
A domain would limit possible values in this column to
these values

Create Initial Elements
Initial elements are tables and relationships
Columns are defined for each table
Logical entities from logical data model can be used as
starting point for creating tables
Or, persistent classes from the design model
CustID Name Phone Email Zip

2332 Mary Martin (931) 488-2384 mmartin01@sbcnet.com 23993
4048 Joe Denver (231) 821-8322 jd23@aol.com 64412
6301 Peg Thrush (721) 239-2001 thrushpa@hotmail.com 49921
4893 Amy Meyer (818) 291-8113 meyer34@spint.com 83845
2943 Curt Sanchez (319) 455-8638 csanch5@gteconnect.com 73814

Define Reference Tables
Reference table: Frequently-accessed tables whose data
changes infrequently
Used to optimize access to data in the database
Examples:
Standard product codes
2 character U.S. state codes
Conversion rates
Postal codes
Reference tables can reduce disk I/O and and increase
database performance

Create Primary Key & Unique Constraints
Purpose of primary keys:
Define the one or more columns that uniquely identify a
row in the table
Purpose of unique constraint:
Define constraints on columns that guarantee the
uniqueness of the data or collection of data
One primary key per table
Choose a non-meaningful, non-user-entered column, if
possible
A unique constraint designates that the data in the column is
unique per row.
A Customer_ID column frequently has a unique
constraint to ensure unique IDs

Define Rules
Purpose: To ensure the integrity of the database
Data integrity rules also know as constraints
Ensure data values are within allowed ranges
Foreign key is one or more columns in a table that map to
the primary key in another table
One table could have many foreign keys
Each foreign key maps to a different table
Each foreign key maps to a primary key in a different
table

De-normalize Database
De-normalizing optimized the data structures to increase
performance
Reduces number of table joins the DBMS has to do by
combining certain tables
Reduces access time but can increase update time

Optimize Data Access
Use indexing and database views for better data access
Indexing
Requires knowledge of how data will be accessed
Can have large impact on performance
Views
A virtual table
Contains data from multiple tables
Decreases time to select data
Especially for heavily queried tables
Can increase security by restricting access to data

Define Storage Characteristics
Design space allocation
Design disk page organization
Tablespaces
Take advantage of block disk I/O
Allow specification of physical data layout

Design Stored Procedures
Stored procedure: Executable code that runs on the
database server
Performs database-related actions on the server
Without having to transfer data across a network
Triggers are a special case of stored procedures
Triggers invoked implicitly based on some event

Review Results
The final step in a data design iteration
Assesses the completeness and quality of work to date
Ensure that the data model and physical implementation are
in sync
Discrepancies and other issues are noted and fixed
If the fixes are deferred, the issue should be tracked as a
change request

C. References
[RS04] IBM Rational Software, The Rational Unified Process
v2003.06.13, 2004
[UT04] University of Texas at Austin, Introduction to Data

Modeling, http://www.utexas.edu/its/windows/database/ -
datamodeling, 2004

C. Quiz 1
Which of the following is not part of data management?
a) Data integrity
b) Security
c) User access
d) Performance
e) Data recovery
1) a
2) b
3) c
4) All are aspects of data management

C. Quiz 2
The 3 stages of data modeling include:
a) Conceptual
b) Preliminary
c) Detailed
d) Logical
e) Physical
1) b, c, & e
2) b, c, & d
3) a, d, & e
4) a, b, & c

C. Quiz 3
Entity Relationship Diagrams are useful for which data modeling
stage?
a) Preliminary
b) Detailed
c) Logical
1) a & b
2) b only
3) c only
4) All stages

C. Quiz 4
A database domain is used for what purpose?
a) Enforce data standards
b) Group frequently used tables
c) Logically group tables
d) Define client access
1) a
2) b
3) c
4) d

C. Quiz 5
The benefit of a de-normalized database is:
a) Reduce update time
b) Reduce access time
c) Reduce number of tables
1) a
2) b
3) a & c
4) b & c

D. Error Processing
Software error: A human action that results in software
containing a fault [ANSI/IEEE Standard 729-1983]
Software fault:
1. An accidental condition that causes a functional unit to fail
to perform its required function
2. A manifestation of an error in software [ANSI/IEEE
Standard 729-1983]
Software failure:
1. The inability of a system or system component to perform
a required function within specified limits. A failure may be
produced when a fault is encountered.
2. A departure of program operation from program
requirements.

D. Error Processing - 2
Debugging
Debugging: The Process of correcting syntactic and logical
errors detected during coding.
-- With the primary goal of obtaining and executing a
piece of code, debugging shares the testing of certain
techniques and strategies but differs in its usual ad hoc
application and local scope. [FIPS Publication 101, 1983]
The Process of locating, analyzing, and correcting suspected
faults. Sometimes synonymous with unit testing.
A bug is an euphemism for fault (error)
Debugging is associated with coding in that it is normally
done by the coder who built the code
Therefore, debugging is the search for faults, i.e. testing
Testing is the process of executing a computer program for
the purpose of finding faults

D. Error Processing - 3
Learning how to debug a computer program
General methods
-- Learn in-depth how the program you are working on
operates
-- Learn the kinds of mistakes you typically make
-- Learn how to solve software problems
Solving software problems

-- Stabilize the error : Otherwise it is almost impossible to fix
-- Locate the source of the error : Through creative testing
-- Fix the error : Determine the impact on other areas of the
program
-- Test the fix : Use regression testing
-- Look for similar errors : They probably exist

D. References
McConnell, Steve, Code Complete: A Practical Handbook of
Software Construction, Microsoft Press, Redmond, WA,
1983, Chapter 26, pp. 623-649.
ANSI/IEEE Standard 729-1983
FIPS Publication 101, 1983

D. Quiz
1) The simplest type of construction language is
a) Programming language
b) Toolkit language
c) Configuration language
d) Formal language
2) The language in which software engineers choose from a

limited set of predefined options to create new or custom
software installations is
a) Formal language
b) Configuration language
c) Toolkit language
d) Programming language

E. Source Code Organization
Code that needs order
Order counts if the statement must be executed in a
particular order
-- For example, if there is a need to read a record before it
can be written
Make order obvious through:
-- Naming the routines so order is obvious
-- Use routine parameters to reflect the execution order
Document the dependency between parts of the code
The strongest principle for organizing straight-line code is
order dependencies
Dependencies should be made obvious through the use of
good routine names, parameter lists and comments.

E. Source Code Organization - 2
Other reasons for organizing code
Keep related statements together

-- That operate on the same data
-- That perform similar tasks
-- That depend on each other being performed in order
Assign variables close to where they will be used
Keep variables live for as short a time as possible
-- Measure the live time of a variable
-- A short live time makes your code more readable
Make sure readability is consistent from top to bottom

E. References
McConnell, Steve, Code Complete: A Practical Handbook of
Software Construction, Microsoft Press, Redmond, WA,
1983. Chapter 13, Pages 302-309

E. Quiz
1) How many forms of testing does construction involves?
a) 4
b) 3
c) 2
d) 1
2) The purpose of _________ testing is to reduce the gap

between the time at which faults are inserted into the code
and the time those faults are detected?
a) Unit testing
b) Construction testing
c) Integration testing
d) Design testing

F. Code Documentation
Types of Documentation
Good documentation is a sign of professional pride by the

programmer (coder)
Documentation might be inside or outside the source code
Outside (external) documentation is classically a:
-- Users manual
-- Operators manual (most recently combined with Users
manuals)
-- Maintenance manual
Outside documentation tends to be of the high-level (more
abstract) type
Inside documentation tend to be of the low-level (more
concrete) type

F. Code Documentation - 2
Inside documents are of two types:

-- Online help manuals
-- Commented code
Outside documents are a number of different types, two of

which are:
-- Software design documents (SDD) A design specification
which can be based on IEEE Standard 1016-1998
-- Unit development folder -- Based on work by Frank
Ingrassia originally written in 1977

Detailed Design Documentation
Detailed design can be a high-level design document

(architectural design) or a low-level design document
(detailed design document):
Detailed design documents contain:

--Identification The name of the design entity.
-- Type A description of the kind of design entity
-- Purpose A description of why the design entity exists
-- Function A Statement of what the design entity does
-- Subordinates The identification of all entities composing
this design entity

Detailed design documents contain (continued)
-- Dependencies A description of the relationships of this
design entity with other entities
-- Interface A description of how other entities interact with
this design entity.
-- Resources A description of the elements used by the
design entity that are external to the design
-- Processing A description of the rules used by the design
entity to achieve its function.
-- Data A description of data elements internal to the
design entity
Although not required by the standard, the software designer

name or identification should be entered with each entity.

Unit [software] Development Folders (UDF)
Definition UDF:
-- A collection of material pertinent to the development of a
given software module or subsystem.
-- Contents typically include the requirements, design,
technical reports, code listings, test plans, test results,
problem reports, schedules, and notes for the module or
subsystem
Definition of a unit:
-- In recent definition, a unit is a work package specification
-- A work package specification is the amount of work that
can be done by 3-4 people in 2-3 weeks
A UDF provides low-level management control over low-level
software units, tasks, work packages, or modules

Unit Development Folders (UDF) (continued)
Provides an orderly and consistent approach in the

development of each unit of the project
Provides a uniform and visible collection point for all unit

documentation and code
Aids in the establishment and attainment of unit-level

milestones
Provides first-level management visibility and hands-on

control over the development process.

Commenting Code
Useful comments:
-- Summary of the code module
-- Description of the codes intent
-- Use commenting styles that dont breakdown or
discourage modification; any style that is too fancy is
annoying to maintain
-- Outline the code (using PDL) in comments
-- Avoid cryptic comments
-- Place comments about undocumented features or error
work around
-- Place comments with: dimensions with numerical data,
allowable numeric variables, the use of numbers to pass a
meaning, global data, etc.

F. References
McConnell, Steve, Code Complete, Microsoft Press,
Redmond, WA, 1993, pp. 453-454, 463-478
F.S. Ingrassia , The unit Development Folder (UDF): A Ten
year Perspective, In Richard H. Thayer (ed.), Software
Engineering Project Management, IEEE Computer Society
Press, Los Alamitos, CA 1997. (Also see: McConnell, p.454)
IEEE Std 1016-1998, IEEE Recommended Practice for
Software Design Descriptions, IEEE, Inc., Piscataway NJ,
1998

F. Quiz
1) The only two kinds of comments that are acceptable for
completed code are:
a) Repetitious and Explanatory comments
b) Marker and Summary comments
c) Intent and Summary comments
d) Intent and Marker comments

G. Construction QA
Definitions: Software Quality
Software quality assurance: A planned and systematic

pattern of all actions necessary to provide adequate
confidence that the software and the delivered
documentation conforms to established technical
requirements [ANSI/IEEE Standard 729-1983]
Construction quality assurance (QA) : Those QA
techniques necessary assure that coding is being done
according to coding standards
Quality attributes: A requirement that specifies the degree
of an attribute affecting qualities that the software must
possess; e.g. correctness, reliability, maintainability,
portability

G. Construction QA -2
Software quality:
1. The totality of features and characteristics of a software
product that affects its ability to satisfy given needs (for
example, to conform to specifications)
2. The composite characteristics of software that determine
the degree to which the software will meet the expectations
of the customer [ANSI/IEEE Standard 729-1983]
3. Attributes of software that affect its perceived value, for
example, correctness, reliability, maintainability, and
portability
4. Software quality includes fitness for purpose, reasonable
cost, reliability, ease of use in relation to those who use it,
design of maintenance and upgrade characteristics, and
compares well against reliable products

G. Construction QA -3
Internal Quality Attributes of Code
Maintainability: Average effort to locate and fix a software

failure
Flexibility: Effort to extend the software missions, functions,
or data to satisfy other requirements
Portability: Effort to convert the software for use in other
operating environments
Reusability: Effort to convert a software component for use
in another application
Readability: Effort to be able to read and understand source
code
Verifiability: Effort to verify the delivered operations and
performance of the code.

G. Construction QA - 4
Techniques for improving code quality
To improve the quality of the product you must improve the

quality of the process [#1 rule of software engineering]
Institute a set of coding guidelines (standards) for the
development of code
Institute code walkthroughs or inspections
Institute a verification and validation (V&V) process to verify
code
Use external audits when necessary
Develop a reward structure that rewards the good
producers of code rather that the error prone producers of
code

Defect Detection Rates
Detection Technique Lowest Rate Model Rate Highest Rate

(%) (%) (%)
Personal checking of design documents 15 35 70
Informal group design reviews 30 40 60
Formal design inspections 35 55 75
Formal code inspections 30 60 70
Modeling or prototyping 35 65 80
Personal desk-checking of code 20 40 60
Unit testing (single routine) 10 25 50
Function testing (Related routine) 20 35 55
Integration testing (Complete system) 25 45 60
Field testing (live data) 34 50 65
Cumulative effect of complete series 93% 99% 99%

Defect Detection Rates (continued)
Model defect rates are not above 65% of any single

technique
Code inspections found a 60% model defect rate
The model defect rate for [the popular] unit testing is only
25%
Code reading detected more interface defects; functional
testing detected more control defects
To improve defect detection use more than one technique
The earlier a defect is caught, the cheaper it is to fix
Approximately 50% of the construction phase is spent
debugging finished code and finding errors

The Primary techniques used for construction include

[SWEBOK Chapter 4]
a) Unit testing and integration testing
b) Test-first development
c) Code stepping
d) Use of assertions
e) Debugging
f) Technical reviews
g) Static analysis

G. References
ANSI/IEEE Standard 729-1983
Software: A vital key to UK Competitiveness, ACARD
Working Group, 1986
Software Quality management for distributed systems,
RADC-TR-83-175 (Also McConnell, pp, 557-559), 1983.
McConnell, Steve, Code Complete, Microsoft press,
Redmond, WA, 1993, pp. 560-561
Basili, Victor R, Richard W. Shelby, and David H. Hutchens,
Experiments in Software Engineering. IEEE Transactions
on Software Engineering, SE-12 No pp. 733-743 (Also
McConnell, pp. 564

G. Quiz
1) ________ is a planned and systematic program of activities
designed to ensure that a system has the desired
characteristics?
a) Software Testing
b) Software Construction
c) Software Quality Assurance
d) Software Maintenance
2) In Software Quality Assurance, the best place to focus is on
the
a) Product
b) Process
c) Project
d) People

H. System Integration and
Deployment
System Integration I [RT04, p. 6-53-59]
System Integration:
The act of merging a software element or elements with
another element
The act of merging a hardware component or
components with another hardware component
The act of merging software configuration items with
hardware configuration items in order to produce a total
system which satisfies customer requirements
Types of Integration techniques
All in one integration (a.k.a. the big bang integration)
Incremental integration
Top-down integration
Bottom-up integration
Sandwich integration

Deployment 2
System Integration II
The Big Bang Integration
All components, modules, and subsystems are combined
and integrated at one time
This is called the big bang because it frequently blows up
If (and when) the system fails to integrate, it is next to

impossible to determine the cause
This is called the smoke test in the hardware world

Lets put the power to it and see where the smoke rises
Unfortunately there is no smoke to indicate a fault in

software
Deployment 3
System Integration III
Incremental Integration
Incremental integration:
1. Develop a small core of the system
2. Test and debug it
3. Design, code, test, and debug another part (module,
routine, etc.)
4. Integrate the new part with the core
5. Ensure that the new partial system works
6. Repeat steps 3 through 5 until finished

Deployment 4
System Integration IV
Benefits of Incremental Integration
Errors are easy to locate The last integration is probably at
fault
Incremental integration provides early evidence that
progress is being made (better status information)
Planning (scheduling) is more accurate
Components are tested more fully and frequently
Improves the development schedule by work being done in
parallel
Development and testing are more easily distributed
Integration can be done beginning at the top or the bottom
(called top-down integration an d bottom up integration)

Deployment 5
System Integration V
Top-Down Integration
Identify the order of
development such that:
When developing a
routine, all higher routines
are completed
Harder problems are
attacked first; easier
problems are delayed
Test stubbing is easiest

Deployment 6
System Integration VI
Top-Down Integration (continued)
The order of development depends on the type of project
Control oriented: Calling routines are higher than called
routines
Data oriented: Routines that primarily set data higher
than routines that primarily use data
Requirements oriented: Routines least sensitive to
requirements or design choices are ranked higher than
more sensitive routines
Test oriented: Routines critically needed for testing of
other routines are higher ranked than routines not
needed for testing
Difficulty oriented: Harder routines are ranked higher
than easier routines (This is the order that is illustrated)

Deployment 7
System Integration VII
Top-Down vs. Bottom-Up
Integration

Deployment 8
Software Deployment [RT04, p. 6-60]
Software deployment is the delivery and implementation of a
software system, usually to the customer who purchased the
system
Deployed systems have been factory (alpha) tested
Deployment may be on a try it and see basis (called a beta
test) or for permanent installation
Deployed systems are placed under external configuration
management
Deployed systems may be maintained by either the original
developer or a third party

H. References
[RT04] Thayer, Richard, 2004 Certified Software
Development Professional (CSDP) Preparation Course,
Chapter 6: Software Construction

H. Quiz
1. Which of the following is not a benefit of incremental
integration?
A. Errors are easier to locate because the last integration is

probably at fault.
B. Integration can be done beginning at the top or the bottom.
C. It requires less test planning than the big bang integration.
D. Components are tested more fully and frequently.

I. Code Tuning
Definition
Code tuning is the practice of modifying correct code to

make it run more efficiently
Code tuning is the enemy if code reliability
Code efficiency focuses on the following:
Program design
Module and routine design
Operating-system interactions
Code compilations
Hardware
Code tuning [RT04, p.6-40]

I. Code Tuning 2
Elements of Code Tuning [RT04, p. 6-41]
Measures the performance or size to find the trouble
(inefficient) areas
Measures must be precise
Small parts of the program can take a disproportionate share
of the run time (80-20 rule)
Iteration Repeat the optimization process to continue
receiving efficiency improvements
Some areas of inefficiency
Input/output operations
Paging
System calls

I. Code Tuning 3
In Summary [RT04, p. 6-42]
1. Develop the software using a good design with highly
modular code that is easy to understand and modify
2. If performance is poor, measure the system to find the
trouble spots
3. Determine whether the real performance comes form:
design, data structures, or algorithms and whether code
tuning is appropriate
4. Tune the bottleneck identified
5. Measure each improvement; remove it of it does not work
6. Repeat steps 1-5

I. References

I. Quiz
1. Which of the following is least likely to be considered a
source of inefficiency with respect to code tuning?
A. Lines of code
B. System calls
C. Paging
D. Input/output operations

J. Construction Tools
Defined [RT04, p. 6-24]
Construction tools are used to improve productivity and
software quality
Construction tools include:
Source-code tools
Editing
Browsing
Analyzing code quality
Restructuring source code
Data dictionaries
Executable-code tools
Code creation
Debugging
Testing
Code tuning

J. Construction Tools 2
Design Tools [RT04, p. 6-25]
Most design tools involve graphic development and drawing
tools
These tools support one or more of the new technologies, for
example:
Object-oriented design (OOD)
Structured design
Design entity-relationship diagrams (ERD)
The tools take on the housekeeping task (CASE TOLS)
For example, keeping the process connected in a bubble
chart when a new level is defined

Source Code Tools [RT04, p. 6-26]
EditorsSupport for adding, eliminating, and moving items

in a document
File comparatorsCompares two files and identifies areas
that are different
Source-code beautifiersImprove the look of code so that it
appears consistent
TemplatesDevelop macro steps to save time and improve
quality
BrowsersUseful for finding and modifying coding elements
(strings)
Cross-reference toolsLists variables, routines, and each
place they are used

Analyzing Code Quality Tools [RT04, p. 6-27]
Call-structure generatorsProduces information about

routines that call each other
Picky syntax and semantics checkerDoes a more thorough
job than the compiler
Metrics reporters Report on selected quality and quantity
metrics
RestructurersConvert spaghetti code to structured code
Code translatorsTranslate code form one language to
another
Data dictionaryA database of variable names with
descriptions

Executable-Code Tools [RT04, p. 6-28]
LinkersSupports the connecting and compacting of object
files
Code librariesPrepackaged software systems
Code generatorsTools that write code from design inputs..
Also used to develop prototypes
Macro preprocessorsAllow the creation of simple named
constants with no run-time penalty
DebuggersAssist in finding system errors
Execution profilersWatch code while running, tabulating
how many times each statement is executed and/or how
much time the program spends on each statement
Assembler listingConverts assembler code to the machine
code that the computer can use

J. References

J. Quiz
1. Which of the following considered a source code tool?
A. File comparators
B. Restructurers
C. Code-translators
D. Debuggers

Module IV - Construction

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Module IV - Construction

Încărcat de

Drepturi de autor:

Formate disponibile

CSDP Preparation Course

Module IV: Software

Module IV - Software Construction 2

Module IV - Software Construction 3

Module IV - Software Construction 4

Software construction closely tied to

Module IV - Software Construction 5

Module IV - Software Construction 6

The following slides discuss each of these fundamentals

Module IV - Software Construction 7

Module IV - Software Construction 8

Module IV - Software Construction 9

Module IV - Software Construction 10

Module IV - Software Construction 11

Module IV - Software Construction 12

Module IV - Software Construction 13

Module IV - Software Construction 14

Module IV - Software Construction 15

Module IV - Software Construction 16

Module IV - Software Construction 17

Module IV - Software Construction 18

Module IV - Software Construction 19

Module IV - Software Construction 20

Module IV - Software Construction 21

Module IV - Software Construction 22

Module IV - Software Construction 23

For large development efforts Lead 1

Table 1: Team Composition

Module IV - Software Construction 24

Module IV - Software Construction 25

Module IV - Software Construction 26

Module IV - Software Construction 27

Module IV - Software Construction 28

Module IV - Software Construction 29

Module IV - Software Construction 30

IEEE Standard 729-1983

Module IV - Software Construction 31

Module IV - Software Construction 32

2 ways to manage complexity:

Module IV - Software Construction 33

Module IV - Software Construction 34

Module IV - Software Construction 35

Module IV - Software Construction 36

Level 1 Software System

Module IV - Software Construction 37

Module IV - Software Construction 38

Module IV - Software Construction 39

Module IV - Software Construction 40

Module IV - Software Construction 41

Module IV - Software Construction 42

Module IV - Software Construction 43

Module IV - Software Construction 44

Module IV - Software Construction 45

Module IV - Software Construction 46

Module IV - Software Construction 47

Module IV - Software Construction 48

Module IV - Software Construction 49

Module IV - Software Construction 50

What is Data Design?

What is Data Management?

Module IV - Software Construction 51

Module IV - Software Construction 52

Module IV - Software Construction 53