CSDP Preparation Course Module IV: Software Construction

1
CSDP Preparation CourseModule IV Software
Construction
2
Specifications

• The exam specific topics covered in this module
  are listed below, and are the basis for the
  outline of its content
• Construction Planning
• Code Design
• Data Design and Management
• Error Processing
• Source Code Organization
• Code Documentation
• Construction Quality Assurance
• System Integration and Deployment
• Code Tuning
• Construction Tools

3
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

4
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

5
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

6
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

7
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

8
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

9
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

10
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

11
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

12
References

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

13
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

14
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

15
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

16
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!

17
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

18
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

19
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

20
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

21
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

22
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 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?

23
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?

24
A. Construction Planning - 12

• Construct the Team
• For small development efforts
• Self managed
• Everyone is a peer
• For mid-size development efforts
• Single team
• For large development efforts
• Multiple teams

Table 1 Team Composition
25
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

26
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

27
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

28
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

29
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

30
Quiz 5

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

31
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

32
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

33
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

34
B. Code Design - 4

• Desirable Design Characteristics
• Steve McConnell suggests achievement of the
  following
• Minimal complexity
• Ease of maintenance
• Loose coupling
• Extensibility
• High fan-in
• Low-to-medium fan-out
• Portability
• Leanness
• Stratification
• Standard techniques

35
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

36
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

37
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

38
B. Code Design - 8

• Level 1 Software System
• The entire system
• Concern of the architect, not detailed designer
• Unless system is extremely small

39
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
• Partition the program into major subsystems
• Define subsystem interfaces

40
B. Code Design - 10

• Level 3 Classes
• Identify all classes by subsystem
• Define class relationships
• Generalizations
• Dependencies
• Associations
• For each class, define its interface

41
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

42
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

43
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

44
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

45
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

46
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.

47
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

48
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

49
B. Quiz 3

• Subsystems are synonymous with architecture
  layers.
• a) True
• b) False

50
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

51
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.

52
C. Data Design And Management - 2

• Stages of Data Modeling
• The data model evolves through three stages
• Conceptual
• High level key entities and their relationships
• Logical
• Refinement of the conceptual model into more
  detailed logical entities
• Physical
• Detailed and optimized phyiscal database table
  designs

53
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

54
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

55
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
• 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

56
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

57
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

58
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

59
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

60
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

61
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

62
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

63
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

64
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

65
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

66
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

67
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

68
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

69
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

70
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

71
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

72
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.

73
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

74
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

75
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

76
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

77
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.

78
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

79
E. References

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

80
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

81
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

82
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

83
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

84
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.

85
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

86
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.

87
F. Code Documentation - 7

• 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.

88
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

89
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

90
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

91
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

92
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.

93
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 (VV)
  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

94
G. Construction QA - 5

• Defect Detection Rates

95
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

96
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

97
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

98
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

99
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

100
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
• Lets put the power to it and see where the
  smoke rises
• Unfortunately there is no smoke to indicate a
  fault in software

101
H. System Integration and Deployment 3

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

102
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)

103
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

104
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)

105
H. System Integration and Deployment 7

• System Integration VII
• Top-Down vs. Bottom-Up Integration

106
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

107
H. References

• RT04 Thayer, Richard, 2004 Certified Software
  Development Professional (CSDP) Preparation
  Course, Chapter 6 Software Construction

108
H. Quiz

• 1. Which of the following is not a benefit of
  incremental integration?
• Errors are easier to locate because the last
  integration is probably at fault.
• Integration can be done beginning at the top or
  the bottom.
• It requires less test planning than the big bang
  integration.
• Components are tested more fully and frequently.

109
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

110
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

111
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

112
References

• RT04 Thayer, Richard, 2004 Certified Software
  Development Professional (CSDP) Preparation
  Course, Chapter 6 Software Construction

113
Quiz

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

114
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

115
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

116
J. Construction Tools 3

• 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

117
J. Construction Tools 4

• 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

118
J. Construction Tools 5

• 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

119
J. References

• RT04 Thayer, Richard, 2004 Certified Software
  Development Professional (CSDP) Preparation
  Course, Chapter 6 Software Construction

120
J. Quiz

• 1. Which of the following considered a source
  code tool?
• File comparators
• Restructurers
• Code-translators
• Debuggers