1. B. Computer Sci. (SE) (Hons.)
CSEB233: Fundamentals of
Software Engineering
Software Implementation
& Coding

2. Objectives
 Explain
what is software construction and why it is
important
 Describe good programming principles/practices
 Explain the concept of ‗defensive programming‘
 Describe software inspection as a static method to
discover defects, errors or problems
 Explain the concepts, benefits and problems of
software reuse

3. What is Software Construction?
 ‗Construction‘ refers
to the hands-on part of creating
something
 Include implementation/coding and debugging; and
verification and validation
 Generally focus at coding, debugging, some
detailed design and some testing (esp. unit testing)
 Quality of construction substantially affects the
quality of the software

4. What is Software Construction?

According to McConnell (1993), construction may
involve:
Verifying that the groundwork has been laid so that
construction can proceed successfully
 Designing and writing routines and modules
 Selecting and creating data types and naming identifiers
 Selecting control structures and organizing blocks of
statements
 Finding and fixing errors


5. What is Software Construction?
 According
involve:
to McConnell (1993), construction may
Reviewing other team members‘ design and code and
having them review yours
 Polishing the code – formatting and writing comments
(i.e. internal documentation)
 Integrating software components (if built separately)
 Tuning the code – make it more efficient, smaller and
faster


6. Why is Software Construction
Important?

Depending on the size of project, construction may take
30% - 80% of the total project time

The larger the time spent, the bigger the work affect the
success of the project
Construction is the pivotal activity in software
development
 With a focus on construction, there is a great potential
for the average programmer‘s productivity to improve
(McConnel, 1993)


7. Why is Software Construction
Important?
Requirements document and design documents can go
out of date, but construction‘s by product, the source
code, is always up to date
 Ideally software project goes through requirements
engineering and modeling activities before construction
begins


Construction is the only activity that‘s guaranteed to be done!
(McConnel, 1993)

8. Coding Principles
 Coding
principles and concepts are closely aligned
programming style, programming languages, and
programming methods
 Before you write one line of code, be sure you:
Understand of the problem you‘re trying to solve
 Understand basic design principles and concepts


9. Coding Principles
 Before
you write one line of code, be sure you:
Pick a programming language that meets the needs of
the software to be built and the environment in which it
will operate
 Select a programming environment that provides tools
that will make your work easier
 Create a set of unit tests that will be applied once the
component you code is completed


10. Coding Principles
 As
you begin writing code, be sure you:
Constrain your algorithms by following structured
programming practice
 Consider the use of pair programming
 Select data structures that will meet the needs of the
design
 Understand the software architecture and create
interfaces that are consistent with it
 Keep conditional logic as simple as possible


11. Coding Principles
 As
you begin writing code, be sure you:
Create nested loops in a way that makes them easily
testable
 Select meaningful variable names and follow other local
coding standards
 Write code that is self-documenting
 Create a visual layout (e.g., indentation and blank lines)
that aids understanding


12. Coding Principles
 After
you‘ve completed your first coding pass, be
sure to:
Conduct a code walkthrough when appropriate
 Perform unit tests and correct errors you‘ve uncovered
 Refactor the code

■
reorganization technique that simplifies the code without
changing its function or behaviour

13. Good Programming Practices

Start with a good design.



The program under development should be functioning at all
times


Update the design documents regularly
Create additional design documents before adding new major
features or functionality
The development process consists of adding new functionality
without breaking existing functionality
Work has to be divided into small incremental steps that can
be typically accomplished and code-reviewed in one day.

Even large-scale rewrites should be made incremental

14. Good Programming Practices

Every line of code written or modified undergoes peer review


The smallest team must contain at least two programmers so that
they can code-review each other's changes
Always attempt to work top-down in:



Design—start with high level objects
Implementation—create top-level objects using low-level stubs
Modification—change the top-level objects and the overall flow of
control first. If necessary, use stubs, or fake new functionality
using old implementation
(Source: http://relisoft.com/practice.html)

15. Good Programming Practices
 Be
consistent with formatting
 Be consistent with naming conventions
 Use global [identifiers] sparingly
 Don‘t assume output formats
 Add comment to your code – explain what and why
(Source: Kim Moser at http://relisoft.com/practice.html )

16. Good Programming Practices
 Provide
useful error messages
 Recover (or fail) gracefully
 Push interface up and implementation down
 Know what you don't know – prepare for changes
(Source: Kim Moser at http://relisoft.com/practice.html )

17. Defensive Progamming
 Defensive
programming is when the programmer
makes necessary assumptions and creates code
that anticipates potential problems and specification
changes
 A good defensive programmer is sufficiently
confident in his/her abilities to ignore the traditional
belief that ―If it isn‘t broke, don‘t fix it.‖

18. Defensive Progamming

Defensive programming involves:
finding problems in the existing code by identifying code
inconsistencies and understanding typical uses of the
software
 anticipating – and preempting – both potential problems with
the existing specifications as well as likely changes in user
behavior and design specifications, and
 streamlining the code to aid readability and simplify
maintainability
(Mehta, 2009)


19. Software Inspections
 An
‗old school‘ approach
 A process to review, analyze and check static
system representations such as requirements
document, design document, and program source
code to look for errors and problems

Static – need not run the software on a computer
 Generally,
focus at source code

20. Software Inspections
 Sometime
also known as peer reviews or program
/code inspections
 Inspections can check conformance with a specification but not conformance with the customer‘s real
requirements
 But, inspections cannot check non-functional characteristics such as performance, usability, etc.

21. Program/Code Inspection Process
 Focus
at detecting defects - logical errors and
anomalies in the code
 Program inspections are very effective in
discovering defects
 A formal process that involve team of several
members

Fagan originally developed this method at IBM in the
1970s with four suggested roles – author, reader, tester
and moderator

22. Advantages of Inspection over
Testing
A
single inspection session can discover many
errors

During program testing, errors can mask (hide) other
errors
 Incomplete
versions of a software can be inspected
without additional costs

To test an incomplete program, specialized test is
needed to test the parts that are available
(Sommerville, 2004)

23. Advantages of Inspection over
Testing
 Inspections
can search for program defects and
other quality attributes of a program

e.g., compliance to standard, maintainability, portability,
efficiency, etc.
(Sommerville, 2004)

24. Drawbacks/Issues related to
Inspections
Difficult to introduce formal inspections into software
development organizations
 Software engineers (programmers) with experience are
sometimes reluctant to accept that inspections can be
more effective for detecting defects (errors) than testing
 Managers may be sceptical as inspections require
extra costs during modelling and construction
 Inspections may take time to arrange and appear to
slow down the development process


25. Software Reuse
In most engineering disciplines, systems are designed
by composing existing components that have been
used in other systems
 Software engineering has been more focused on
original development
 It is now recognised that to achieve better software
quickly at lower cost, we need to adopt a design
process that is based on systematic reuse rather than
ad-hoc reuse

(Sommerville, 2004)

26. Reuse-based Software Engineering

Application system reuse


Component reuse


The whole of an application system may be reused either by
incorporating it without change into other systems (COTS
reuse) or by developing application families
Components of an application from sub-systems to single
objects may be reused
Object and function reuse

Software components that implement a single well-defined
function may be reused

27. Requirements for Reuse
 It
must be possible to find appropriate reusable
components
 The reuser of the component must be confident that
the components will be reliable and will behave as
specified
 The components must be documented so that they
can be understood and, where appropriate,
modified.

28. Benefits of Reuse

Increased dependability
Software/components/functions have been tried and tested
in working systems
 They should be more dependable than new software


Reduced process risk


Less uncertainty in development costs especially if large
software components are reused
Effective use of specialists
Reuse components instead of people
 The specialist can create reusable components


29. Benefits of Reuse
 Standards

compliance
Standards such as UI standard (e.g., drop-down menu)
can be implemented as reusable components to
improve dependability as users are less likely to make
mistake
 Accelerated

development
Avoid original development, speed-up production and
hence able to market product early

30. Reuse Problems
 Increased
costs
in understanding whether the application/component/
function is suitable for reuse
 in testing it to ensure its dependability and in maintaining
the reused item

 Lack
of CASE tool support
 Maintaining a component library can be expensive

31. Reuse Problems
 Not-invented-here

syndrome
Some software engineers may think that writing original
software is seen as more challenging than reusing other
people‘s software.
 Finding
and adapting reusable components

32. Summary
 You
have been introduced to:
good programming principles/practices
 the concept of ‗defensive programming‘
 software inspection as a static method to discover
defects, errors or problems
 the concepts, benefits and problems of software reuse


33. THE END
Copyright © 2013 Mohd. Sharifuddin Ahmad, PhD
College of Information Technology