MNP1163 (Software Construction)
SDLC and Construction Models
Need, wish, policy, law
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
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:
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
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
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
The construction team must follow some approach
Chosen approach must be appropriate for the task at hand
Programming language choices affect
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
Everyone is a peer
For mid-size development efforts
For large development efforts
[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,