Software
Construction and
Development
Lecture-01
Software Processes
A Software Process is
A set of activities (e.g. requirements,
analysis, design, coding, testing) combined
and sequenced in a particular fashion to
produce software
Recent trend: Agile Software Development
Customer needs evolve with time
Satisfying customers at delivery time (rather
than at project initiation) is more important
than conforming to initial customer
requirements
Software Development Phases
Requirements
Requirements
What
What needs
needs to
to be
be done
done
Testing
Check
Check that that the
the code
code does
does what
what
itit isis supposed
supposed to to (functionality,
(functionality, Analysis
Analysis
performance,
performance, reliability,
reliability, …)
…) How
How itit should
should be
be done
done
Project
Project Management
Management
Devise
Devise aa plan,
plan, manage
manage
resources,
resources, costs,
costs, time,
time, …
…
Design
Design
Coding
Coding Create
Create aa software
software structure
structure
Fill
Fill in
in the
the software
software (architecture)
structure (architecture) around
around which
which
structure with
with code
code code
code will
will be
be built
built
Software Construction
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
Design
Construction
Testing
Software Construction
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
Software Construction Fundamentals
The fundamentals of software construction include:
Minimizing complexity
Anticipating change
Constructing for verification
Standards in construction
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
Anticipating Change
Software changes over time
Anticipation / hope of change affect how software is
constructed
This can effect
Use of control structures
Handling of errors
Source code organization
Code documentation
Coding standards
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
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
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
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
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
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!
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 (sufficiently) is a
key to project success
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
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
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
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
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 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?
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?
Construction Planning - 12
Construct the Team
For small development efforts Role # / Team*
Lead 1
Self managed
Detailed designer 1 to 4
Everyone is a peer Coder 5 to 10
For mid-size development efforts Integrator 1 to 2
Unit tester Same as coder
Single team
System tester 1
For large development efforts “Build Meister” 1
Multiple teams Configuration manager 1
* Individuals will play multiple roles
Team Composition Table
Languages to Instruct Computer
How to give instructions to computers?
Natural language; such as English, French, and
Chinese etc.
Ambiguous: Same expression describes many
possible actions.
Programming language; such as FORTRAN,
COBOL, C, C++, Java, Python etc.
needs to be precise
needs to be concise
needs to be expressive
needs to be at a high-level (lot of abstractions)
High level Abstraction to
Low level Details
Write a program using a programming language.
High-level Abstract Description
Microprocessors talk in assembly language
Low-level Implementation Details
Levels of Programming
languages
Three levels of programming languages:
High-level Languages
Middle-level Languages
Low-level Languages
High-level Languages
These are platform-independent or portable languages.
Examples: C, C++, Java, Fortran, etc.
Easier to understand and maintain
Size of code is small
Example, statement a = b + c;
More powerful
One HLL instruction corresponds to one or more
than one MLL or LLL instruction.
Middle-level Languages
These are machine-specific, e.g., Assembly
language
Each machine has its own assembly language.
Use mnemonics for the instructions.
Lie between HLL and LLL
Size of code is large
Example, mov AX, a
mov BX, b
mov CX, c
add BX, CX
load AX, BX
One MLL instruction corresponds to exactly one LLL
instruction
Low-level Languages
These are machine-specific, also called machine
language
Hard to understand and maintain
Use sequences of 0’s and 1’s.
Size of code is large
One to one correspondence between instructions
of MLL and LLL
Why use HLL?
Understandability & Readability
Naturalness
Portability (machine-independent)
Efficient to use (in terms of development time)
separation of data and instructions
typing
data-structures such as arrays, linked list, stack,
queue, etc.
blocks
program-flow primitives such as loops, labels, goto,
labels etc.
subroutines
Disadvantages of HLL
Need to compile the code.
Does not give the programmer a
complete control over hardware.
Portable
Compiled HLL programs are less
efficient.
Slow execution time.
MLL and LLL can directly play with CPU
and can make optimum use of processing
time and memory.
Classification of HLL
Imperative Languages
Structured languages, e.g., Cobol, Fortran
Block-structured languages
Allow blocks and their nesting, e.g., Pascal, C++, Modula-2
Object-Oriented Languages
C++, Java, C#, Eiffel, Ada
Declarative Languages
Do not write procedures, e.g., SQL queries, Prolog
Functional Languages
Use functions, no loops or conditions, e.g., LISP, ML
Translation between HLL
and LLL
Translators are used:
Assemblers
Interpreters
Compilers
Assemblers
Convert assembly language program into machine
language.
Computer cannot understand assembly language, hence
it has to be converted it to computer’s native language.
They are also called low-level language translators.
Interpreters
Translate and execute the programs line by line.
Interpreter stops at the first error it encounters,
hence translation and error checking is done
simultaneously during execution:
Interpreted programs are less efficient.
By translating and executing each line, the
execution gets slower.
Interpreted programs are more portable.
PERL- interpreted language.
Interpreter
Compilers
Translate HLL program to LLL program.
Check the program for errors and
translate the program into machine code.
Error listing is done at the end of
compilation.
Do not execute the translated program.
Compiled programs are more efficient but
less portable:
After compiling, we get machine code which is
not portable.
Formal Definition of Compiler
A software that translates a HLL
program into a LLL program.
Input = program in HLL
Output = machine code
Primary function of compiler is to
translate HLL to LLL; secondary is
to check errors in the program,
Most programming languages use
compilers because of efficiency.
Compile once, use many times.
Design of a Compiler
input COMPILER Output
Source Object
code code
may or may not
Error listing
Internal Structure of
Compiler
input
Front End Error
listing
Intermediate code
Back End
output
Front End
Depends on source language.
Varies from language to language.
Independent of target machine for which the
machine code is to be generated.
Can be used for different platforms.
Does all error checking for the source code.
Produces error list, if any errors are
encountered.
Converts source program into Intermediate
code.
Intermediate Code
Closer to generic assembly language.
There is no standard form for the intermediate code; its
form is decided by the compiler writers.
Intermediate code will have as many instructions as
machine code.
Machine-independent.
Back End
Reads the intermediate code and converts it into
machine code.
Depends on the target machine / hardware.
For each machine, we need a different back-end.
Independent of source language.
Reusability
Reusability is the main reason behind
two components of the compiler, i.e.,
front-end and back-end.
For example, we want to develop 3
compilers for 3 different languages.
Same back-end can be used, but front-
ends will be rewritten for each source
language.
Back-end is reused.
C++ VB Java
Front End-1 Front End-2 Front End-3
Intermediate code Intermediate code Intermediate code
Back End Back End Back End
Machine code Machine code Machine code
Reusability contd…
For example, we want to develop a C language compiler
for 3 different machines.
Same front-end for C can be used, but back-ends will be
rewritten for each machine
Front-end is reused.
C C C
Front End Front End Front End
Intermediate code Intermediate code Intermediate code
Back End Back End Back End
for M1 for M2 for M3
Machine code Machine code Machine code
for M1 for M2 for M3
