Software Engineering

Textbook
Recommended only:
• Software Engineering - A Practitioner's Approach -
Pressman (McGraw Hill)
 The Nature of Software
• Software is a set of items or objects that form a
“configuration” that includes:
– Programs
– Documents
– Data
• Software products may be developed for a particular
customer (bespoke) or for a general market (generic)
• Software Characteristics:
– Software is developed or engineered, rather than being
manufactured
– Although the industry is moving toward component-based
assembly, most software continues to be custom built.
– Software doesn’t wear out
– Software is complex
 Characteristics of today’s software
development

• Development of large & complex systems

• Software systems must fulfill the requirements of a
client
• Number of persons involved in the development > 1
• Software systems are expected to live long and be
used by many people
Systematic approach to creation & ownership of software

• Systematic approach to the development, operation,

maintenance & retirement of software.

• Software

– Source code of a program, documentation, etc.

• Engineering

– Application of a systematic approach (based on

scientific & mathematical principles) toward the

production of a structure, machine, process or system

 ?What is Software Engineering

• The practical application of scientific knowledge to the

design and construction of computer programs and the
associated documentation required to develop, operate,
and maintain them [Boehm].
• The systematic approach to the development, operation,
maintenance, and retirement of software [IEEE].
• The establishment and use of sound engineering
principles (methods) in order to obtain economically
software that is reliable and works on real machines
[Bauer].
• Multi-person construction of multi-version software
[Parnas].
• “Software from womb to tomb.”
 ?What is a software process

• A set of activities whose goal is the development or evolution

of software
• Generic activities in all software processes are:
– Specification - what the system should do and its
development constraints
– Development - production of the software system
– Validation - checking that the software is what the
customer wants
– Evolution - changing the software in response to
changing demands
 ?Why study Software Engineering

• Building software without discipline is crazy

• Software is critical to society
• Building a large complete software project is hard
• There is a perceived crisis in our ability to build
software
• to get away from ad hoc and unpredictable software
development towards a systematic, understood one...
• Discipline of software engineering emerged
because people involved in software development
efforts in 60s & 70s were wrong in estimates of
time, effort & cost
• Estimates usually spectacularly wrong !
• Reliability & maintainability were serious
problems
Other forces behind emergence of software
engineering:

• Changes in ratio of hardware to software costs

• Increasingly important role of maintenance

• Advances in both hardware & software

• Increased demands for software

• Demand for larger & more complex software

 Software
• Information content andApplications
determinacy determine the nature of a
software application.
– Content – meaning and form of incoming and outgoing
information.
– Determinancy refers to constant vs arbitrary ordering timing of
messages or event.
• system software – written to service other programs
• application software – standalone, solve specific business need
• engineering/scientific software – number crunching algorithms
CAD
• embedded software – intelligent products
• product-line software – specific capability for many customers
(spreadsheet)
• WebApps (Web applications) – hypertext to e-commerce
• AI software – nonnumerical algorithms
 Software—New Categories

• Ubiquitous computing—wireless networks

• Netsourcing—the Web as a computing engine
• Open source—”free” source code open to the computing
community (a blessing, but also a potential curse!)
• Also … (see Chapter 32)
– Data mining
– Grid computing
– Cognitive machines
– Software for nanotechnologies
 Legacy Software
Why must it change?
• software must be adapted to meet the needs of new
computing environments or technology.
• software must be enhanced to implement new
business requirements.
• software must be extended to make it interoperable
with other more modern systems or databases.
• software must be re-architected to make it viable
within a network environment.
– Problem is that it is usually poor quality.
 E-Type Systems

• E-Type Systems:
Software that has been implemented in a real-
world computing context and will therefore
evolve over time
 Software Evolution
• The Law of Continuing Change (1974): E-type systems must be continually
adapted else they become progressively less satisfactory.
• The Law of Increasing Complexity (1974): As an E-type system evolves its
complexity increases unless work is done to maintain or reduce it.
• The Law of Self Regulation (1974): The E-type system evolution process is self-
regulating with distribution of product and process measures close to normal.
• The Law of Conservation of Organizational Stability (1980): The average effective
global activity rate in an evolving E-type system is invariant over product lifetime.
• The Law of Conservation of Familiarity (1980): As an E-type system evolves all
associated with it, developers, sales personnel, users, for example, must maintain
mastery of its content and behavior to achieve satisfactory evolution.
• The Law of Continuing Growth (1980): The functional content of E-type systems
must be continually increased to maintain user satisfaction over their lifetime.
• The Law of Declining Quality (1996): The quality of E-type systems will appear to
be declining unless they are rigorously maintained and adapted to operational
environment changes.
• The Feedback System Law (1996): E-type evolution processes constitute multi-
level, multi-loop, multi-agent feedback systems and must be treated as such to
achieve significant improvement over any reasonable base.
 Software Myths

• Affect managers, customers (and other non-

technical stakeholders) and practitioners
• Are believable because they often have
elements of truth,
but …
• Invariably lead to bad decisions,
therefore …
• Insist on reality as you navigate your way
through software engineering
 Customer Myths

• All you need is a general statement of what I

want to start programming.
• Requirements change but SW can
accommodate change easily since it is flexible.
 Practitioner’s Myths

• Once we get the program to run we are done.

• Until the program is running, I don’t have any
idea how good it really is.
• The only deliverable is the working program.
• SE causes massive and unnecessary
documentation that will only slow us down.
 Management Myths

• The book of standards and procedures for

building SW will provide developers with
everything they need to know.
• If we get behind we can add more people.
• We can outsource it to a third party and relax
and let them handle it.
 ?What is a software process model
• A simplified representation of a software process, presented from
a specific perspective
• Examples of process perspectives are
– Workflow perspective - sequence of activities
– Data-flow perspective - information flow
– Role/action perspective - who does what
• Generic process models
– Waterfall
– Evolutionary development
– Formal transformation
– Integration from reusable components
 Software Costs
• Software costs often dominate system costs
• The costs of software on a PC are often greater than
the hardware cost
• Software costs more to maintain than it does to
develop
• For systems with a long life, maintenance costs may
be several times development costs
• Software engineering is concerned with cost-
effective software development
?What are the costs of software engineering
• Roughly 60% of costs are development costs, 40%
are testing costs. For custom software, evolution
costs often exceed development costs
• Costs vary depending on the type of system being
developed and the requirements of system attributes
such as performance and system reliability
• Distribution of costs depends on the development
model that is used
 The Cost of
Change 60­100x

1.5­6x
1x

Definition Development After release

The Life of Software
 Aims of Software Engineering

• To produce quality software

• At low cost
• On time
 Software Quality
• The software should deliver the required functionality to the
user and should be:
• Maintainable
– Software must evolve to meet changing needs
• Dependable
– Software must be reliable
• Efficient
– Software should not make wasteful use of system
resources
• Usable
– Software must be usable by the target users
• Software engineering is concerned with producing quality
software
 What do we mean by Quality Software?
• No simple answer - depends on who is answering it !
 Software Life Cycle
• Software has childhood, adulthood & retirement ...
• Childhood
– Software developed & tested.
– Activities taken together form the software development cycle.
• Adulthood
– Often known as: Operational & Maintenance phase
– Additional functions can be added & refinements made during
this phase.
• Retirement
– Reasons for retiring a piece of software:
– Software becomes functionally obsolete.
– Old software replaced by software which performs same
functions better.
– Hardware constraints
– Retirement can come to software during its childhood - Up to
25% of large software projects are abandoned before delivery.
 Some Problems
• Customer has only a vague idea of what is required.
• Developer is often willing to proceed with the "vague
idea" on the assumption that "we'll fill in the details
as we go".
• Customer keeps changing the requirements.
• Developer responds to these changes, making errors
in specification and development. and so it goes ...
 Software Applications
• Approaches to developing software (even the entire
Software Engineering process, people, tools,
management and estimation techniques) depend on the
application:
– System software
– Real-time software
– Business software
– Engineering and scientific software
– Embedded software
– Personal computer software
– Web-based software
 Software Development Cycle

• Requirements Analysis & Specifications

• Design
• User Interface Design
• Preliminary Design
• Detailed Design
• Implementation
– Coding
– Unit Testing
– Integration
• Testing
• Delivery & Installation.