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
Module IV - Software Construction
3
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
Module IV - Software Construction
4
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
Module IV - Software Construction
5
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
Module IV - Software Construction
6
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
Module IV - Software Construction
7
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
Module IV - Software Construction
8
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
Module IV - Software Construction
9
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
Module IV - Software Construction
10
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
Module IV - Software Construction
11
References
• [IE04] IEEE Computer Society, Guide to the Software
Engineering Body of Knowledge (SWEBOK), IEEE
Computer Society Press, Los Alamitos, CA 20001, June
2004
Module IV - Software Construction
12
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 don’t 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
Module IV - Software Construction
13
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
Module IV - Software Construction
14
A. Construction Planning - 3
•
•
•
•
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
Module IV - Software Construction
15
A. Construction Planning - 4
•
•
•
•
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!
Module IV - Software Construction
16
A. Construction Planning - 5
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
Module IV - Software Construction
17
A. Construction Planning - 6
•
•
•
•
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
Module IV - Software Construction
18
A. Construction Planning - 7
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
Module IV - Software Construction
19
A. Construction Planning - 8
•
•
•
•
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
Module IV - Software Construction
20
A. Construction Planning - 9
•
•
•
•
•
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
Module IV - Software Construction
21
A. Construction Planning - 10
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 project’s 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?
Module IV - Software Construction
22
A. Construction Planning - 11
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?
Module IV - Software Construction
23
A. Construction Planning - 12
Construct the Team
• For small development efforts
• Self managed
• Everyone is a peer
• For mid-size development efforts
Role
• Single team
• For large development efforts Lead
Detailed designer
• Multiple teams
Coder
# / Team*
1
1 to 4
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
Module IV - Software Construction
24
A. References
• [IE04] IEEE Computer Society, Guide to the Software
Engineering Body of Knowledge (SWEBOK), IEEE
Computer Society Press, Los Alamitos, CA 20001, June
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
Module IV - Software Construction
25
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
Module IV - Software Construction
26
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
Module IV - Software Construction
27
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
Module IV - Software Construction
28
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
Module IV - Software Construction
29
A. Quiz – 5
Up to 30 percent of the schedule should be allocated to
requirements and architecture activities.
1) True
2) False
Module IV - Software Construction
30
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
Module IV - Software Construction
31
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
Module IV - Software Construction
32
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
Module IV - Software Construction
33
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
Module IV - Software Construction
34
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
Module IV - Software Construction
35
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”
Module IV - Software Construction
36
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
Module IV - Software Construction
37
B. Code Design - 8
Level 1 – Software System
• The entire system
• Concern of the architect, not detailed designer
• Unless system is extremely small
Module IV - Software Construction
38
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
Module IV - Software Construction
39
B. Code Design - 10
Level 3 – Classes
• Identify all classes by subsystem
• Define class relationships
• Generalizations
• Dependencies
• Associations
• For each class, define its interface
Module IV - Software Construction
40
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
Module IV - Software Construction
41
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
Module IV - Software Construction
42
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
Module IV - Software Construction
43
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
Module IV - Software Construction
44
B. Code Design - 15
Design Approaches
Iterate
• Don’t 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
Module IV - Software Construction
45
B. References
• [IE04] IEEE Computer Society, Guide to the Software
Engineering Body of Knowledge (SWEBOK), IEEE
Computer Society Press, Los Alamitos, CA 20001, June
2004
• [SM04] S. McConnell, Code Complete: A Practical
Handbook of Software Construction, Second Edition,
Microsoft Press, 2004.
Module IV - Software Construction
46
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
Module IV - Software Construction
47
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
Module IV - Software Construction
48
B. Quiz – 3
Subsystems are synonymous with architecture layers.
a) True
b) False
Module IV - Software Construction
49
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
Module IV - Software Construction
50
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.
Module IV - Software Construction
51
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
Module IV - Software Construction
52
C. Data Design And Management - 3
•
•
•
•
•
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
Module IV - Software Construction
53
C. Data Design And Management - 4
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
Module IV - Software Construction
54
C. Data Design And Management - 5
•
Physical Data Design
Define the detailed physical design of the database
• Tables
• Views
• Stored procedures
• Steps to create the physical data model:
1.
2.
3.
4.
5.
6.
7.
8.
9.
Define domains
Create initial physical database design elements
Define reference tables
Create primary key and unique constraints
Define data and referential integrity enforcement rules
De-normalize database design
Optimize data access
Define storage characteristics
Design stored procedures
Module IV - Software Construction
55
C. Data Design And Management - 6
•
•
•
•
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
Module IV - Software Construction
56
C. Data Design And Management - 7
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
Module IV - Software Construction
57
C. Data Design And Management - 8
•
•
•
•
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
Module IV - Software Construction
58
C. Data Design And Management - 9
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
Module IV - Software Construction
59
C. Data Design And Management - 10
•
•
•
•
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
Module IV - Software Construction
60
C. Data Design And Management - 11
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
Module IV - Software Construction
61
C. Data Design And Management - 12
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
Module IV - Software Construction
62
C. Data Design And Management - 13
Define Storage Characteristics
• Design space allocation
• Design disk page organization
Tablespaces
• Take advantage of block disk I/O
• Allow specification of physical data layout
Module IV - Software Construction
63
C. Data Design And Management - 14
•
•
•
•
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
Module IV - Software Construction
64
C. Data Design And Management - 15
•
•
•
•
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
Module IV - Software Construction
65
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
Module IV - Software Construction
66
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
Module IV - Software Construction
67
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
Module IV - Software Construction
68
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
Module IV - Software Construction
69
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
Module IV - Software Construction
70
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
Module IV - Software Construction
71
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.
Module IV - Software Construction
72
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
Module IV - Software Construction
73
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
Module IV - Software Construction
74
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
Module IV - Software Construction
75
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
Module IV - Software Construction
76
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.
Module IV - Software Construction
77
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
Module IV - Software Construction
78
E. References
• McConnell, Steve, Code Complete: A Practical Handbook of
Software Construction, Microsoft Press, Redmond, WA,
1983. Chapter 13, Pages 302-309
Module IV - Software Construction
79
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
Module IV - Software Construction
80
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
-- Operator’s manual (most recently combined with User’s
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
Module IV - Software Construction
81
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
Module IV - Software Construction
82
F. Code Documentation - 3
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
Module IV - Software Construction
83
F. Code Documentation - 4
• 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.
Module IV - Software Construction
84
F. Code Documentation - 5
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
Module IV - Software Construction
85
F. Code Documentation - 6
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.
Module IV - Software Construction
86
F. Code Documentation - 7
Commenting Code
Useful comments:
-- Summary of the code module
-- Description of the code’s intent
-- Use commenting styles that don’t 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.
Module IV - Software Construction
87
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
Module IV - Software Construction
88
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
Module IV - Software Construction
89
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
Module IV - Software Construction
90
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
Module IV - Software Construction
91
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.
Module IV - Software Construction
92
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
Module IV - Software Construction
93
G. Construction QA - 5
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%
Module IV - Software Construction
94
G. Construction QA - 6
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
Module IV - Software Construction
95
G. Construction QA - 7
• 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
Module IV - Software Construction
96
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
Module IV - Software Construction
97
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
Module IV - Software Construction
98
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
Module IV - Software Construction
99
H. System Integration and
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
• “Let’s put the power to it and see where the smoke rises”
• Unfortunately there is no smoke to indicate a fault in
software
Module IV - Software Construction
100
H. System Integration and
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
Module IV - Software Construction
101
H. System Integration and
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)
Module IV - Software Construction
102
H. System Integration and
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
Module IV - Software Construction
103
H. System Integration and
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)
Module IV - Software Construction
104
H. System Integration and
Deployment – 7
System Integration – VII
Top-Down vs. Bottom-Up
Integration
Module IV - Software Construction
105
H. System Integration and
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
Module IV - Software Construction
106
H. References
• [RT04] Thayer, Richard, 2004 Certified Software
Development Professional (CSDP) Preparation Course,
Chapter 6: Software Construction
Module IV - Software Construction
107
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.
Module IV - Software Construction
108
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]
Module IV - Software Construction
109
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
Module IV - Software Construction
110
I.
1.
2.
3.
4.
5.
6.
Code Tuning – 3
In Summary… [RT04, p. 6-42]
Develop the software using a good design with highly
modular code that is easy to understand and modify
If performance is poor, measure the system to find the
trouble spots
Determine whether the real performance comes form:
design, data structures, or algorithms and whether code
tuning is appropriate
Tune the bottleneck identified
Measure each improvement; remove it of it does not work
Repeat steps 1-5
Module IV - Software Construction
111
I.
References
• [RT04] Thayer, Richard, 2004 Certified Software
Development Professional (CSDP) Preparation Course,
Chapter 6: Software Construction
Module IV - Software Construction
112
I. Quiz
1. Which of the following is least likely to be considered a
source of inefficiency with respect to code tuning?
A.
B.
C.
D.
Lines of code
System calls
Paging
Input/output operations
Module IV - Software Construction
113
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
Module IV - Software Construction
114
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
Module IV - Software Construction
115
J. Construction Tools – 3
Source Code Tools [RT04, p. 6-26]
• Editors—Support for adding, eliminating, and moving items
in a document
• File comparators—Compares two files and identifies areas
that are different
• Source-code beautifiers—Improve the look of code so that it
appears consistent
• Templates—Develop macro steps to save time and improve
quality
• Browsers—Useful for finding and modifying coding elements
(strings)
• Cross-reference tools—Lists variables, routines, and each
place they are used
Module IV - Software Construction
116
J. Construction Tools – 4
Analyzing Code Quality Tools [RT04, p. 6-27]
• Call-structure generators—Produces information about
routines that call each other
• Picky syntax and semantics checker—Does a more thorough
job than the compiler
• Metrics reporters – Report on selected quality and quantity
metrics
• Restructurers—Convert “spaghetti code” to “structured code”
• Code translators—Translate code form one language to
another
• Data dictionary—A database of variable names with
descriptions
Module IV - Software Construction
117
J. Construction Tools – 5
•
•
•
•
•
•
•
Executable-Code Tools [RT04, p. 6-28]
Linkers—Supports the connecting and compacting of object
files
Code libraries—Prepackaged software systems
Code generators—Tools that write code from design inputs..
Also used to develop prototypes
Macro preprocessors—Allow the creation of simple named
constants with no run-time penalty
Debuggers—Assist in finding system errors
Execution profilers—Watch code while running, tabulating
how many times each statement is executed and/or how
much time the program spends on each statement
Assembler listing—Converts assembler code to the machine
code that the computer can use
Module IV - Software Construction
118
J. References
• [RT04] Thayer, Richard, 2004 Certified Software
Development Professional (CSDP) Preparation Course,
Chapter 6: Software Construction
Module IV - Software Construction
119
J. Quiz
1. Which of the following considered a source code tool?
A.
B.
C.
D.
File comparators
Restructurers
Code-translators
Debuggers
Module IV - Software Construction
120