SOFTWARE CONSTRUCTION

LECTURE-12
MANAGING CONSTRUCTION
 Construction Models
 Construction Planning
 Construction Measurement
CONSTRUCTION MODELS

 Linear construction view

 Construction only after significant pre-requisite
work is complete
 Coding is main focus of construction

 Iterative
 Construction occurs at the same time as other
development activities
 Combination of activities all considered
construction
MANAGING CONSTRUCTION

 Encouraging Good Coding

 Configuration Management
 Estimating a Construction Schedule
 Measurement
 Treating Programmers as People
 Managing Your Manager
CONSTRUCTION PLANNING
 How are we going to build it?
 Affects prerequisite activities
 Extent to which they are performed
 Order in which they are performed
 Degree to which they are expected to be complete before
construction begins
 Affects project’s ability to minimize complexity,
anticipate change, and construct for verification
 Defines the order in which components are created and
integrated, QA management process, allocation of task
assignments, etc.
CONSTRUCTION MEASUREMENT
 What aspects are being measured?
 Code developed (LOC)
 Code reused
 Code modified
 Code complexity
 Code inspection statistics
 Defects found
 Defects fixed
 Effort
 Scheduling
 Story points (velocity)
 Why do we need to measure construction?
PRACTICAL CONSIDERATIONS
 Construction Design
 Construction Languages
 Coding
 Construction Testing
 Reuse
 Construction Quality
 Integration
CONSTRUCTION DESIGN

 Design done before construction will be

incomplete
 Detailed design same as overall design but at a
smaller scale
CONSTRUCTION LANGUAGES

 Anyway that a human can specify execution

instructions to a computer
 Configuration Languages

 Toolkit Languages

 Programming Languages
CODING
 Understandable source code
 Use of classes, enumerated types, variables,
named constants, etc
 Control structures
 Error handling
 Prevention of code-level security breaches
 Resource usage
 Source code organization
 Code documentation
 Code tuning
CONSTRUCTION TESTING

 Goal: to reduce the time between defect

creation and default detection
 Subset of overall testing types performed by
the engineer who wrote the code
 Unit testing
 Integration testing
REUSE

 Reuse processes and activities must be

formalized into the software life cycle
 Selection of what to reuse

 Evaluation of code or test reusability

 Reporting of reuse information on new code

CONSTRUCTION QUALITY
 Common Techniques
 Unit and integration testing
 Test-first development
 Code stepping
 Use of assertions
 Debugging
 Technical reviews
 Static analysis

 Focus on code and not overall project

INTEGRATION

 Plan the sequence in which components will be

integrated
 Creation of scaffolding and stubs to support
interim versions
 Determining the degree of testing done on
components before they are integrated
 Determine when interim versions of the
software are tested
 You can expect some of these benefits from careful integration:
 Easier defect diagnosis
 Fewer defects
 Less scaffolding
 Shorter time to first working product
 Shorter overall development schedules
 Better customer relations
 Improved morale
 Improved chance of project completion
 More reliable schedule estimates
 More accurate status reporting
 Improved code quality
 Less documentation
 INTEGRATION FREQUENCY—PHASED OR
INCREMENTAL?

 Programs are integrated by means of either the phased or the

incremental approach.
 Until a few years ago, Phased integration was the
norm(standard) . It follows these well-defined steps, or
phases:
1- Design, code, test, and debug each class. This step is called
“unit development.”
2. Combine the classes into one whopping-big system (“system
integration”).
3. Test and debug the whole system. This is called “system dis-
integration.”
INCREMENTAL INTEGRATION
In incremental integration, you write and test a program in small
pieces and then combine the pieces one at a time. In this one-
piece-at-a-time approach to integration, you follow these steps:

 1. Develop a small, functional part of the system. It can be the

smallest functional part, the hardest part, a key part, or some
combination. Thoroughly test and debug it. It will serve as a
skeleton on which to hang the muscles, nerves, and skin that make
up the remaining parts of the system.
 2. Design, code, test, and debug a class
 3. Integrate the new class with the skeleton. Test
and debug the combination of skeleton and new
class. Make sure the combination works before
you add any new classes. If work remains to be
done, repeat the process starting at step 2.
INCREMENTAL INTEGRATION STRATEGIES
 With phased integration, you don’t have to plan the order in which
project components are built. All components are integrated at the
same time, so you can build them in any order as long as they’re all
ready by D-day.
 With incremental integration, you have to plan more carefully. Most
systems will call for the integration of some components before the
integration of others. Planning for integration thus affects planning
for construction; the order in which components are constructed has
to support the order in which they will be integrated.
 Integration-order strategies come in a variety of shapes and sizes,
and none is best in every case. The best integration approach varies
from project to project, and the best solution is always the one that
you create to meet the specific demands of a specific project.
INTEGRATION STRATEGIES

 Top-Down Integration
 Bottom-Up Integration

 Sandwich Integration
Reading Assignment
+
Quiz
 Risk-Oriented Integration Book: Page No
694-702
 Feature-Oriented Integration

 T-Shaped Integration
 Thank You