CSDP Preparation Course Module IV: Software Construction - PowerPoint PPT Presentation

1 / 120
About This Presentation
Title:

CSDP Preparation Course Module IV: Software Construction

Description:

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 ... – PowerPoint PPT presentation

Number of Views:167
Avg rating:3.0/5.0
Slides: 121
Provided by: sceUhclE6
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com