Construction Planning


MNP1163 (Software Construction)

SDLC and Construction Models

Construction Planning

Construction Measurement

Need, wish, policy, law




Acceptance Test

Operational systems


Test Execution



Global Design

Detail Design


Systems Test


Integration Test

System Test



Test Execution


Test Execution


Phase 1 Phase 2 Phase 3

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

 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

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

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!

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

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

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

Many software development approaches have been tried over the years

Some examples:

 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

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

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

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?

 For small development efforts

 Self managed

 Everyone is a peer

For mid-size development efforts

 Single team

For large development efforts

 Multiple teams

[IE04] IEEE Computer Society, Guide to the Software

Engineering Body of Knowledge (SWEBOK), IEEE

Computer Society Press, Los Alamitos, CA 20001, June


[RS04] IBM Rational Software, The Rational Unified

Process v2003.06.13, 2004


[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,