Software Construction and Maintenance

Software Construction Fundamentals

and
Managing Construction
3
 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
 Process of Construction

Design

Construction

Testing

5
 Importance of Software Construction

• Takes large part of software development process

• Efficient programming techniques produce better quality

software

• Source code describes, represents and documents

software, while other artifacts might be out of date

• Construction cannot be dropped.

6
 Contd..,

• Construction is a large part of software development

• Construction is the central activity in software
development
• Construction’s product, the source code, is often the
only accurate description of the software.
• Construction is the only activity that’s guaranteed to be
done.

7
 Software Construction Tasks
• Verifying that the groundwork has been laid so that
construction can proceed successfully
• Determining how your code will be tested
• Designing and writing classes and routines
• Creating and naming variables and named constants
• Selecting control structures and organizing blocks of
statements
• Unit testing, integration testing, and debugging your own
code
 Software Construction Tasks
• Reviewing – Design and Code
• Polishing code by carefully formatting and commenting
it
• Integrating software components that were created
separately
• Tuning code to make it faster and use fewer resources
 Relevance of Software Construction
• Significant detailed design occurs during construction. Although some
detailed design may be performed prior to construction, much design
work is performed within the construction activity itself. Thus the
software construction activity is closely linked to the software design
activity.
• 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
10
Breakdown of topics for SW Construction

11
Breakdown topics for Software Construction Contd.

12
 Software Construction Fundamentals

• The fundamentals of software construction includes:

• Minimizing complexity
• Anticipating change
• Constructing for verification
• Standards in construction

13
 Minimizing Complexity
• Limited ability of people to hold complex structures and information in their
working memories.
• Minimizing complexity : Strongest drivers in Software construction
• Achieved by creating code that is simpler and readable.
• Avoid redundancy, ambiguity, lines of code (LOC)
• To make complex structure to simpler
• Implement modularity, GUI using templates
• Need to reduce complexity throughout the lifecycle
• Examples:
– J2EE for complex, distributed Java applications
– UML for modeling all aspects of complex systems
– High-order programming languages such as C++ and Java
– As functionality increases, so does complexity accomplished through use of
standards.
14
 Minimizing Complexity

• Accomplished by :
1. Standards in Construction
2. Modular design
3. Coding Specific techniques
4. Construction Quality - Construction focused quality
techniques

15
 Coding

The following considerations apply to the software construction coding activity:

• Techniques for creating understandable source code, including naming and

source code layout

• Use of classes, enumerated types, variables, named constants, and other similar
entities

• Use of control structures

• Handling of error conditions—both planned errors and exceptions (input of

bad data, )
16
 Coding
• Prevention of code-level security breaches (buffer overruns or array
index overflows, for example)
• Resource usage via use of exclusion mechanisms and discipline in
accessing serially reusable resources (including threads or database
locks)
• Source code organization (into statements, routines, classes, packages,
or other structures)
• Code documentation
• Code tuning
17
 Construction Quality

Numerous techniques exist to ensure the quality of code as it is constructed.

The primary techniques used for construction Include:
• Unit testing and integration testing
• Test-first development
• Code stepping
• Use of assertions
• Debugging
• Technical reviews
• Static analysis

18
 Practice of Programming
There is more to writing a program than getting the syntax right, fixing the bugs,
and making it run fast enough.
1. Style:
1.1 Name: A name should be informative, concise, memorable, and pronounceable if possible
Use descriptive names for global, short names for locals.
Global --> int npending = 0; // current length of input queue

Local --> nPoints rather than numberOfPoints

Ex:
X for (theElementIndex = 0; theElementIndex < number0fElements;
theElementIndex++)
elementArray[theElementIndex] = theElementIndex;

 for (i = 0; i < nelems; i++)

elem[i] = i ;
19
 Some more..,

There are many naming conventions and local customs

 Pointers – Start or End with p
 Ex: nodep
 Global – Start with capitals
 Ex: Global s
 Constants – All capitals
 CONSTANT
 Pch – Pointers to Characters

 strTo ,strFrom – strings to be read and written

Naming conventions make it easier to understand your own code. as well as code written
by others.

20
 Style - Name
Be Consistent
 Related things related names that show the relationship and highlight the differences
Ex:
X class UserQueue {
int noOfItemsInQ, frontOfTheQueue, queuecapacity;
public int noOfUsersInQueue() {…}
3

• The word "queue" appears as Q. Queue and queue. But since queues can only be accessed from a variable of
type UserQueue, member names do not need to mention "queue" at all; context suffices, so

 Queue.queueCapacity - Redundant

 class UserQueue
 {
int nitems, front,capacity;
public int nusers() {...}
3
 queue.capacity++;
 n=queue.nusers();
21
 Style - Name
Use active names for functions.
 Function names should be based on active verbs, perhaps followed by nouns:
now = date .getTime() ;
putchar('\nl) ;
 Functions that return a boolean (true or false) value should be named so that the
return value is unambiguous. Thus
X if(checkoctal(c))
does not indicate which value is true and which is false, while
 if (isoctal (c)) . . .
makes it clear that the function returns true if the argument is octal and false if not.

22
 Style - Name

Be Accurate

• A name not only labels, it conveys information to the reader. A misleading

name can result in mystifying bugs.

X #define isoctal(c) ((c) >= '0' && (c) <= '8')

 #define isoctal(c) ((c) >= '0' && (c) <= ‘7')

23
 Style – Expression & Statement
1.2 Expressions & Statements:
Indent to show structures

Ex: Bad Format

X for( n++ ;n<100; field[n++]='\0');
X *i='\0';return('\n');
Reformatting,
 for (n++; n < 100; n++)
field[n] = '\0';
*i = '\O';
return '\n';

24
 Style – Expression & Statement

Use the Natural form for Expression

• Conditional expressions that include negations are always hard to understand:

X i f (! (block-id < actblks) | | ! (block-id >= unblocks))
.....
 i f ((block-id >= actblks) | | (blockkid < unblocks))

25
 Style – Expression & Statement

Parenthesize to resolve Ambiguity

• leap_year = y % 4 == 0 && y % 100 != 0 || y % 400 == 0;

• they make it easier to understand:
leap_year =((y%4==0)&&(y%100!=0))||(y%400==0)

26
 Style – Expression & Statement

Break Up Complex Expressions

*x+=(*xp=(2*k<(n-m)?c[k+1]:d[k--]));

It's easier to grasp when broken into several pieces

if(2*k < n-m)
*xp= c[k+1];
Else
*xp= d[k--];
*x+=*xp;

27
 Style – Expression &Statement

Be Careful with Side effects

• Multiple Assignments
x str[i++]= str[i++]=‘ ‘;
 str[i++]= ‘ ‘;
 Str[i++]=‘ ‘;

28
 Consistency & Idioms

Use consistent Indentation and brace style

 if (month==FEB) {
X i f (month==FEB) {
if (year%4 == 0){
if (day > 29)
i f (year%4 == 0)
legal = FALSE;
if (day > 29)
}else{
legal = FALSE;
if (day > 28)
else
legal = FALSE;
if (day > 28)
}
legal = FALSE;
}

29
 Consistency & Idioms

Use else –ifs for multi way decisions

30
 Consistency & Idioms
 switch (c) {
case '-':
sign = -1;
/* fall through */
• switch (c) {
case '+' :
case '-': sign = -1;
c = getchar();
case '+': c = getchar();
break;
case '.': break;
case ' . ' :
default: if (!isdigit(c))
break;
return 0;
default :
}
if (!isdigit(c))
return 0;
break;
}
31
 Style - Comments

Do not belabor the obvious

/*
n default
*/
default:
break;
/*n return SUCCESS */
return SUCCESS;
zerocount++; /n Increment zero entry
counter */
/* Initialize "total" to "number-
received" */
node->total = node->number-recei ved ;
32
 Style - Comments

Comment functions and global data

 Comments can be given to functions, global variables, constant

definitions, fields in structures , classes etc..,
Ex:
/* Random : returns an integer in the range [0..r-1]*/
Int Random (int r)
{
Return (int)(Math.floor(Math.random()*r);
}

33
 Style - Comments

Don’t comment bad code, review it

 Comment anything unusual or potentially confusing.

 If comments overweighs a code..it needs a fix..
 // if “result” is 0 a match was found so return true(non-zero). Otherwise
,”result” is non –zero so return false(zero)//

#ifdef DEBUG
Printf(“*** isword returns !result=%d\n”, ! Result);
Fflush (stdout);
#endif
Return (!result)

34
 Style - Comments

Don’t contradict the Code

• Code evolves , comment didn’t : • time (&now);

time(&now);
Strcpy( date, ctime(&now));
/*get rid of trailing new line
character copied from ctime*/
i=0;
While(date[i]>=‘ ‘)i++;
date[i]=0 ;
Strcpy( date, ctime(&now));
/*get rid of trailing newline
character copied from
ctime*/
For(i=0; date[i]!=‘\n’;i++)
date[i]=‘\0’;

35
 Style - Comments
Improved Code

• time(&now);
strcpy(date,ctime(&now));
/*ctime() puts newline at end of string; delete it*/
date[strlen (date)-1]=‘\0’;

36
 Style - Comments
Clarify don’t confuse
Int strcmp(char *s1, char *s2)
/* string comparison routine returns -1 if S1 is above S2 in an
ascending order list, 0 if equal 1 if S1 below S2*/
{
While (*S1==S2)
{
If(*S1==‘\0’) retrun (0);
S1++;
S2++;
}
If(*S1>*S2) return (1);
Return (-1);
} 37
 Function Macros

Avoid Function Macros

• c=s+s/5;
• #define sr(s) s+s
main()
{
....
...
int c;
c=sr(10)/5;
}

38
 Function Macros

Parenthesize the macro body and arguments

• # define square(x) (x)*(x) • #define square ((x) * (x))

• 1/ (x) * (x)

39
 Anticipating Change 
• Most software will change over time, and the
anticipation of change drives many aspects of software
construction
• Changes in the environments in which software
operates also affect software in diverse ways.
• Anticipating change helps software engineers build
extensible software, which means they can enhance a
software product without disrupting the underlying
structure
 Anticipating Change 
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
Supported by
Coding -Specific techniques

41
 Constructing for Verification
• Building a software in such a way that faults can figured
out readily by the programmers during independent
testing and operational testing
• Specific Techniques that support constructing for
verification include following
– coding standards to support code reviews and unit testing,
organizing code to support automated testing, and restricting
the use of complex or hard-to-understand language
structures
 Reuse
• Reuse refers to using existing assets in solving different
problems.
• In software construction, typical assets that are reused
include libraries, modules, components, source code, and
commercial off-the-shelf (COTS) assets
• Reuse is best practiced systematically, according to a well-
defined, repeatable process.
• Systematic reuse can enable significant software
productivity, quality, and cost improvements.
 Reuse
Reuse has two closely related facets
• Construction for reuse: Create reusable software
resource

• Construction with reuse: Reuse software benefits in the

construction of a new solution
 Standards in Construction
• Standards that directly affect construction issues includes:
– Use of External Standards
• Object Management Group (OMG) and international organizations
such as the IEEE or ISO.
– Use of Internal Standards
• Organizational level
• Project level

45
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

46
Managing Construction

47
 Managing Construction

1. Construction Models

2. Construction Planning

3. Construction Measurement

48
 1.Construction Models
 Construction Models:
– Numerous Models:
– Emphasizes more on Construction than any other
– Linear / Waterfall and Staged delivery Models
» These models treat construction as an activity that occurs only after
significant prerequisite work has been completed
» Construction as a distinct activity
» Coding
– Iterative
» Evolutionary Prototyping Models and agile development
» Combination of activities
• Consequently, what is considered to be “construction” depends to some degree on the life
cycle model used.
• Software construction is mostly coding and debugging, but it also involves construction
planning, detailed design, unit testing, integration testing, and other activities.
49
 Determine the kind of Software You are working on !!

• By research,
– Gathering requirements - 40 different methods

– Software designs – 50 different variations

– Testing – 30 kinds

– For projects more than 700 programming languages

• Every project is unique, but fall in general development styles:

50
Development Styles

51
Development Styles

52
53
 Development Styles

• Business Systems – Iterative Approach - planning, requirements, and

architecture are interleaved with construction, system testing and quality
assurance activities.
– Less focus on prerequisites

• Life Critical Systems – Sequential Approach – Requirement Stability for

high level reliability.
– Staged delivery

54
 How Iterative differs form sequential

• Firstly , Average defect Correction cost will be lesser.

• Second, total cost will be similar but it won’t seem as high because the
price will have been paid in small installments over the course of the
project rather than paid all at once at the end.
• FACT:
– It isn’t practical to specify 100%of the requirements or design up front,
but most projects find value in identifying at least the most critical
requirements and architectural elements up front.

55
 Solution
• One realistic approach is to plan to specify about 80 percent of the
requirements up front, allocate time for additional requirements to be
specified later, and then practice systematic change control to accept only
the most valuable new requirements as the project progresses.

56
 Sequential Vs Iterative
Sequential
 The requirements are fairly stable
 The design is straightforward and fairly
well understood
 The development team is familiar with
the applications area
 The project contains little risk
 Long-term predictability is important
 The cost of changing requirements,
design, and code downstream is likely to
be high
Iterative
 The requirements are not well
understood or you expect them to be
unstable for other reasons
 The design is complex, challenging, or
both
 The development team is unfamiliar
with the applications area
 The project contains a lot of risk
 Long-term predictability is not
important
 The cost of changing requirements,
design, and code downstream is likely
to be low
57
 Other ways..,
 Encouraging Good Coding
 Software projects operate as much on an “expertise hierarchy” as on
an “authority hierarchy.”
 Considerations in Setting Standards
 Reduce arbitrary variance in the project.
 Few alternatives: flexible guidelines, a collection of suggestions rather than
guidelines, or a set of examples.
 Several techniques for achieving good coding practices
 Assign two people to every part of the project-at least two people think
it works and is readable
 Review every line of code
 Require code sign-offs
 Route good code examples for review
 Emphasize that code listings are public assets
 Reward good code
 One easy Standard 58
 2. Construction Planning
• Choice of construction method – Key aspect
• Construction method affects
– the extent to which construction prerequisites are
performed.
– the order in which they are performed.
– the degree to which they are expected to be completed
before construction work begins
 2. Construction Planning
Construction planning also defines :
• the order in which components are created and
integrated, the integration strategy (phased or
incremental integration)
• the software quality management processes.
• the allocation of task assignments to specific software
engineers
• the other tasks according to the chosen method
 2. Construction Planning
• What is Construction Planning?
Laying out the work plan (i.e. schedule) to design, implement,
debug, and unit test the software
• Construction planning major concerns:
– Coders are typically not planners
– Schedules will be difficult to maintain unless a good
architecture design is in place
– Many organizations to not collect project data on which to
plan future projects
 Many managers consider planning to be a waste of time and therefore don’t
encourage it

 Project plans may be limited to the construction plans

– Many organizations and projects do not use systematic cost estimating

methods such as models

62
Improving Software Economics
• Improvements in the area of software development have been difficult to
achieve and also difficult to measure and substantiate.
• Five basic areas on which to focus are listed here, in order of priority:
(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

63
 Some actions include
Size/complexity Tools
• Use an object oriented approach • Use integrated tools
• Focus on reuse • Use open (as opposed to propriety) systems
• Look for opportunities to use commercial off- • Use appropriately sized hardware
the-shelf (COTS) components • Automate tedious tasks such as
coding (where possible)
Process
documentation
• Use an iterative approach testing
• Improve the process maturity metrics collection & analysis
• Focus on architecture early in the life cycle Quality
People/teams • Ensure appropriate hardware platform
performance
• Provide appropriate training
• Use a demonstration-based assessment
• Encourage teamwork approach
• Create a win-win culture • Use statistical quality control

64
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

65
 Construction Prerequisites cntd….
• Best practice for building high-quality software emphasizes quality throughout the software
development lifecycle. Since construction is in the middle of a software project, by the time
you get to construction, the earlier parts of the project have already laid some of the
groundwork for success or failure. During construction, however, you should at least be able
to determine how good your situation is and to back up if you see problems.

• The overall goal of preparation is risk reduction – a good project planner identifies and
resolves major risks as early as possible so that the bulk of the project can proceed as
smoothly as possible.

• Be far, the most common project risks in software development are poor requirements, poor
architecture, and poor project planning. As such, it is crucial that construction preparation
include an assessment of these areas.
66
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!

67
• The first prerequisite before beginning construction is a
clear statement of the problem that the system is supposed
to solve. This is sometimes called “product vision,” “vision
statement,” or, as used here, “product definition.”
• A problem definition defines what the problem is without
any reference to possible solutions.
• The problem definition should be in user language, and the
problem should be described from a user's point of view. It
usually should not be stated in technical computer terms.
• Without a good problem definition, you might put effort
into solving the wrong problem.
68
• The Rational Unified Process names the product definition the “Vision” and provides

the following explanation:

• The Vision defines the stakeholders view of the product to be developed, specified in

terms of the stakeholders key needs and features. Containing an outline of the

envisioned core requirements, it provides the contractual basis for the more detailed

technical requirements.

• The Vision captures the "essence" of the envisaged solution in the form of high-

level requirements and design constraints that give the reader an overview of the

system to be developed from a behavioral requirements perspective. It

communicates the fundamental "why and what" for the project and is a gauge

against which all future decisions should be validated

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

70
• Requirements describe in detail what a software system is supposed to do, and they
are the fist step toward a solution.
• The requirements activity is also known as “requirements development,”
“requirements analysis,” “analysis,” “requirements definition,” “software
requirements specification,” and “functional specification”
• Explicit requirements help ensure that the user, rather than the programmer, drives
the system’s functionality.
• Explicit requirements help to avoid arguments
• Attention to requirements helps minimize changes to a system after development
begins.
• Specifying requirements adequately is a key to project success
71
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

• Software architecture is the high-level part of software design, the frame that
holds the more detailed parts of the design

72
• Architecture is also known as “system architecture,” and “top-level
design.”

• The architecture is described in a single document referred to as the

“architecture specification”.

• Architecture is a prerequisite to construction because the quality of

the architecture determines the conceptual integrity of the system.

• A well-thought-out architecture provides the structure needed to

maintain a system’s conceptual integrity from the top levels down to
the bottom.
73
• It provides guidance to programmers. It partitions the work so that
multiple developers or multiple development teams can work
independently.

• Good architecture can make construction easy. Bad architecture makes

construction difficult.

• Architectural changes are expensive to make during construction or

later.

• The time needed to fix an error in a software architecture is on the

same order as that needed to fix a requirements error, and both are
more timely than fixing coding errors.
Regarding Upstream Prerequisites
• The amount of time to spend on problem definition, requirements, and
software architecture varies according to the needs of your project
• Time budgeted for requirements and architecture work
– 10 to 20 percent of manpower/Effort
– 20 to 30 percent of schedule to requirements, architecture, and up-front
planning
• 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

75
• If requirements are unstable and you're working on a large, formal project,
you'll probably have to work with a requirements analyst to resolve
requirements problems that are identified early in construction. Allow time to
consult with the requirements analyst and for the requirements analyst to
revise the requirements before you'll have a workable version of the
requirements.

• If requirements are unstable and you're working on a small, informal project,

you'll probably need to resolve requirements issues yourself. Allow time for
defining the requirements well enough that their volatility will have a minimal
impact on construction.

76
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

78
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

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

80
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?
81
Construct the Team
• For small development efforts
Medium sized projects
– Self managed
– Everyone is a peer Role # / Team*
Lead 1
• For mid-size development efforts Detailed designer 1 to 4

– Single team Coder 5 to 10

Integrator 1 to 2
• For large development efforts Unit tester Same as coder

– Multiple teams
System tester 1
“Buildmeister” 1
Configuration manager 1
* Individuals will play multiple roles

82
 3.Construction Measurement
• Purpose of Measurement:

• Managing Construction

• Ensuring quality during Construction and

• Improving the Construction process

83
 Construction Measurement

• Activities or Artifacts that can be measured:

• code developed,
• code modified,
• Code reused,
• code destroyed,
• code complexity,
• code inspection
• statistics,
• fault-fix & fault-find rates,
• effort & scheduling

84
 Uses of Measurement

• Measurement helps us to understand

– Makes the current activity visible
– Measures establish guidelines
• Measurement allows us to control
– Predict outcomes and change processes
• Measurement encourages us to improve
– When we hold our product up to a measuring stick, we can establish
quality targets and aim to improve

85
 Measures, Metrics and Indicators
• Measure – An appraisal or ascertainment by comparing to a standard. E.g.
Joe’s body temperature is 99° fahrenheit
• Metric – A quantitative measure of the degree to which an element (e.g.
software system) given attribute.
– E.g. 2 errors were discovered by customers in 18 months (more
meaningful than saying that 2 errors were found)
• Indicator – A device, variable or metric can indicate whether a particular
state or goal has been achieved. Usually used to draw someone’s attention
to something.
– E.g. A half-mast flag indicates that someone has died

86
 Reliability and Validity of Measurements
• Reliability – Refers to the consistency of a number of measurements taken
using the same measurement method
• Validity – Refers to whether the measurement or metric really measures
what we intend it to measure.

87
Measuring Software

88
 What makes quality software?

• Cheap?
• Reliable?
• Testable?
• Secure?
• Maintainable?

89
 What makes quality software?

• There is not clear-cut answer

• It depends on:
– Stakeholders
– Type of system
– Type of users
–…
• Quality is a
multifaceted concept

90
 Different Quality Scenarios

• Online banking system

– Security
– Correctness
– Reliability
• Air Traffic Control System
– Robustness
– Real Time Responses
• Educational Game for Children
– Userfriendliness

91
 The 3 Ps of Software Measurement

With regards to software, we can measure:

• Product
• Process
• People

92
 Measuring the Product

• Product refers to the actual software system, documentation and other

deliverables
• We examine the product and measure a number of aspects:
– Size
– Functionality offered
– Cost
– Various Quality Attributes

93
 Measuring the Process

• Involves analysis of the way a product is developed

• What lifecycle do we use?
• What deliverables are produced?
• How are they analysed?
• How can the process help to produce products faster?
• How can the process help to produce better products?

94
 Measuring the People

• Involves analysis of the people developing a product

• How fast do they work?
• How much bugs do they produce?
• How many sick-days do they take?
• Very controversial. People do not like being turned into numbers.

95
 The Measuring Process

Measurement
Programme
Non-intrusive
Modifications
Data Collection
Products

Results, Trends,
Reports, etc

Processes

People 96
 Collecting Software Engineering Data

• Challenge: Make sure that collected data can provide useful information
for project, process and quality management without being a burden on
the development team.
• Try to be as unintrusive as possible
• Try to make data collection automatic
• Can expensive
– Sometimes difficult to convince management

97
 Collecting Software Engineering Data
A possible collection methodology:
1. Establish the goal of data collection
2. Develop a list of questions of interest
3. Establish data categories
4. Design and test data collection forms/programs
5. Collect and validate data
6. Analyse data

98
 Examples of Metrics Programmes
Motorola
• 7 Goals
– Improve Project Planning
– Increase defect containment
– Increase software reliability
– Decrease defect density
– Improve customer service
– Reduce the cost of non-conformance
– Increase software productivity
• Various Measurement Areas
– Delivered defects, process effectiveness, software reliability, adherence to
schedule, time that problems remain open, and more…
99
 Useful Measurements

Size Defect Tracking

• Total lines of code written
• Total comment lines
• Total number of classes or routines
• Total data declarations
• Total blank lines
• Severity of each defect
• Location of each defect (class or routine)
• Origin of each defect (requirements, design, construction,
test)
• Way in which each defect is corrected
• Person responsible for each defect
• Number of lines affected by each defect correction
• Work hours spent correcting each defect
• Average time required to find a defect
• Average time required to fix a defect
• Number of attempts made to correct each defect
• Number of new errors resulting from defect correction

100
 Contd..,
Productivity
• Work-hours spent on the project
• Work-hours spent on each class or routine
• Number of times each class or routine changed
• Dollars spent on project
• Dollars spent per line of code
• Dollars spent per defect
• Overall Quality
• Total number of defects
• Number of defects in each class or routine
• Average defects per thousand lines of code
• Mean time between failures Compiler-detected errors
Maintainability
• Number of public routines on each class
• Number of parameters passed to each routine
• Number of private routines and/or variables on each
class
• Number of local variables used by each routine
• Number of routines called by each class or routine
• Number of decision points in each routine
• Control-flow complexity in each routine
• Lines of code in each class or routine
• Lines of comments in each class or routine
• Number of data declarations in each class or routine
• Number of blank lines in each class or routine
• Number of gotos in each class or routine
• Number of input or output statements in each class or
routine
101