Software Construction

and Management
CSE-2073
Lecture 2 & 3

Dr. Muhammad Adeel

dr.muhammad.adeel.ntu@gmail.com
What Is Software Construction?
 Developing computer
software can be a
complicated process,
and in the last 25
years, researchers have
identified numerous
distinct activities that
go into software
development.
 They include
What we will cover?
Specific tasks involved in construction

Here are some of the specific tasks involved in

construction:
■ Verifying that the groundwork has been laid so that
construction can proceed successfully
■ Determining how your code will be tested
Designing and writing classes and routines
■ Creating and naming variables and named constants
■ Selecting control structures and organizing blocks of
statements
Unit testing, integration testing, and debugging your own
code
■ Reviewing other team members’ low-level designs and
code and having them
review yours
■ Polishing code by carefully formatting and commenting it
■ Integrating software components that were created
separately
■ Tuning code to make it faster and use fewer resources
Why Is Software Construction
Important?
 Is a large part of software development
 Is the central activity in software development
 With a focus on construction, the individual programmer's
productivity can improve enormously
 Construction's product, the source code, is often the only
accurate description of the software
 Construction is the only activity that's guaranteed to be
done
The power of metaphors (representation)
 The chemist Kekulé had a dream
in which he saw a snake grasp
its tail in its mouth.
 When he awoke, he realized that
a molecular structure based on a
similar ring shape would
account for the properties of
benzene.
 Further experimentation
confirmed the hypothesis
Software Metaphors
 Metaphors have the virtue (good quality/feature) of an expected behaviour
that is understood by all.  
 unnecessary communication and misunderstanding are minimized,
 allows for quicker learning and a higher level of abstraction for the problem at
hand.
 A software metaphor
 is more like a searchlight than a road map.
 it doesn't tell you where to find the answer;
 it tells you how to look for it.
 A metaphor serves more as a heuristic (experimental) than it does as an
algorithm.
 a heuristic process.
 This will tell you how to look for a solution, not where to find
 an algorithm process.
 Gives you specific directions for a solution, and where to look to find the solution.
Heuristic vs. algorithm
 The main difference
 the level of indirection from the solution
 example: Getting to someone's house
 Heuristic
 Find the last letter we mailed you.
 Drive to the town in the return address.
 When you get to town, ask someone where our house is.
 Everyone knows us—someone will be glad to help you.
 If you can't find anyone, call us from a public phone, and we'll come get
you.
 Algorithm
 Gives you the instructions directly – GPS
Common Software Metaphors (1)
 Software Penmanship: Writing Code
 looks at writing software the same way that most people think that an author writes a
book.  You just sit down and start writing from start all the way through to the finish.
 along with starting from scratch, just as in writing a story, expect to take at least one
version of your program and completely through it away.
 this works great if you are working for yourself, however, most employers like to see
productive work, not work you throw away.
 implies a software-development process that's too simple and rigid to be healthy
Common Software Metaphors (2)
 Software Farming: Growing a System
 like planting seeds and growing crops
 You design a piece, code a piece, test a piece, and add it to the system a little bit at
a time. By taking small steps, you minimize the trouble you can get into at any one
time
 a good technique is described with a bad metaphor
 its suggestion that you don't have any direct control over how the software
develops.
Common Software Metaphors (3)
 Software Oyster Farming: System
Accretion
 like a oyster gradually adding coats of calcium
carbonate to a pebble to reduce the irritation.
 make the simplest possible version of the
system that will run 
 it doesn't have to perform realistic manipulations
on data, it doesn't have to produce realistic output
 however, once the version is complete, we
slowly add small working components to the
system and test them.  
 will eventually lead to a fully functioning system
by slowly over time adding little bits of working
code to make the operation smooth and pretty.
Common Software Metaphors (4)
 Software Construction: Building Software
 The image of "building" software is more useful than that of "writing" or
"growing" software.
 It's compatible with the idea of software accretion and provides more detailed
guidance.
 Building software implies various stages of planning, preparation, and execution
that vary in kind and degree depending on what's being built.
Building houses vs. building software
 In building a house, you won't try to build things you can buy
already built.
 You'll buy a washer and dryer, dishwasher, refrigerator, and freezer.
 Unless you're a mechanical wizard, you won't consider building them
yourself.
 You'll also buy prefabricated cabinets, counters, windows, doors, and
bathroom fixtures.
 If you're building a software system, you'll do the same thing.
 You'll make extensive use of high-level language features rather than
writing your own operating-system-level code.
 You might also use prebuilt libraries of container classes, scientific
functions, user interface classes, and database-manipulation classes.
 It generally doesn't make sense to code things you can buy ready-made.
The Intellectual Toolbox
 A good craftsman
 knows the right tool for the job and knows how to use it
correctly.
 A good programmer
 The software practices and techniques that work become the
toolbox.  
 add what worked as well as what didn't work to the toolbox to
make it more effective
Prerequisites to Construction
 Before beginning construction of a house, a builder reviews
blueprints, checks that all permits have been obtained, and surveys
the house's foundation.
 A builder prepares for building a skyscraper one way, a housing
development a different way, and a dog-house a third way.
 No matter what the project, the preparation is tailored to the project's
specific needs and done conscientiously before construction begins.
 As with building construction, much of the success or failure of the
project has already been determined before construction begins.
 If the foundation hasn't been laid well or the planning is inadequate, the
best you can do during construction is to keep damage to a minimum.
 The importance of these steps cannot be overstated.
 if this process is poorly done, we will still be lucky if the result is even
working, let alone useful
Emphasizing Quality
 At the end of the project
 emphasis is on testing
 In the middle of the project
 emphasis is on good construction practices
 At the beginning
 plan for a high quality product
 Your design limits the end results.
 by the time you start construction, it is too late to correct a weak or
faulty design.
 The best we can do in construction is to recognize that the design
is bad and go back and try again.  
 However, this can be an very expensive proposition, but at times
necessary to actually save money.
Cost to fix defects (1)
Cost to fix defects (2)
Problem-Definition Prerequisite
 The problem definition lays the
foundation for the rest of the
programming process
 you need a clear statement of the
problem before you can even
think of a solution
 the problem definition must also
be general enough that it does
not presuppose a solution
 the definition should be in the
user's language and from the
user's point of view
 the solution may turn out to be
something that is not related to
computers at all
The penalty for failing to define the
problem
Requirements Prerequisite
 Ensure :
 The user's needs are driving the system, not the programmers
 System scope is agreed upon
 Minimal changes will be needed after construction begins
 since requirements are never stable:
 use the checklist on pages 33-34 of your text.
 make sure that the cost of changes is understood
 establish a good "change control" procedure
 use an approach that accommodates changes
 lastly you can always kill the project.
Without good requirements
 you can have the right general problem but miss the mark on specific
aspects of the problem
Architecture Prerequisite
 Buy versus build (market research)
 System architecture
 why was a particular architecture chosen?
 what things did we consider when we made our choices? (Cover your own butt)
 Major data structures
 Functionality
 Key algorithms that are present in the user requirements
 User interface
 Hardware requirements
 Nonfunctional
 Error processing
 Robustness
 Over engineering
 Fault tolerance
 Performance
 usually means the average response time, which is system dependant
 Strategy to handle changes
Without good software architecture
 you may have the right problem but the wrong solution. It may
be impossible to have successful construction
Key Construction Decisions
 Choice of Programming Language
 Programming Conventions
 Your Location on the Technology Wave
 Selection of Major Construction Practices
Choice of Programming Language
Programming Conventions
 Allows for more productive coding between programmers
on projects, as it provides a common platform from which
the system is built.
 Before construction begins, spell out the programming
conventions you'll use. Coding-convention details are at
such a level of precision that they're nearly impossible to
retrofit into software after it's written.
Your Location on the Technology Wave
 Programmers who program "in" a language
 limit their thoughts to constructs that the language directly
supports.
 If the language tools are primitive, the programmer's thoughts
will also be primitive.
 Programmers who program "into" a language
 first decide what thoughts they want to express, and then they
determine how to express those thoughts using the tools
provided by their specific language.
 Most of the important programming principles depend not
on specific languages but on the way you use them
Selection of Major Construction Practices