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