01 fse software&sw-engineering

B. Computer Sci. (SE) (Hons.)

CSEB233: Fundamentals
of Software Engineering
Software & Software Engineering

Lesson Objectives
 Define


‗Software‘

Discuss issues related to Software

 Define

‗Software Engineering‘ (SE)
 Describe Polya‘s Four Essence of SE
Practices
 Explain Hooker‘s Seven SE Principles
 Discuss several myths of SE

Software & Software
Engineering
What is Software?

What is Software?
 Software

is developed or engineered, it is not
manufactured in the classical sense
 Software does not "wear out"
 Although the industry is moving toward
component-based
construction,
most
software continues to be custom-built

Software Applications
 System

software
 Application software
 Engineering/scientific software
 Embedded software
 Product-line software
 WebApps (Web applications)
 AI software

Software — New Categories


Open world computing




pervasive, distributed
computing





wireless networks

Netsourcing
the Web as a computing
engine

Open source


Ubiquitous computing








―free‖ source code open
to the computing
community
a blessing, but also a
potential curse!

Also





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

Characteristics of WebApps - I


Network Intensiveness




Concurrency




A large number of users may access the WebApp at one time

Unpredictable load




A WebApp resides on a network and must serve the needs of
a diverse community of clients

The number of users of the WebApp may vary by orders of
magnitude from day to day

Performance


If a WebApp user must wait too long (for access, for serverside processing, for client-side formatting and display), he or
she may decide to go elsewhere

Characteristics of WebApps - II


Availability




Data driven




The primary function of many WebApps is to use hypermedia to
present text, graphics, audio, and video content to the end-user.

Content sensitive




Although expectation of 100 percent availability is
unreasonable, users of popular WebApps often demand access on
a ―24/7/365‖ basis.

The quality and aesthetic nature of content remains an important
determinant of the quality of a WebApp.

Continuous evolution


Unlike conventional application software that evolves over a series
of planned, chronologically-spaced releases, Web applications
evolve continuously.

Characteristics of WebApps - III


Immediacy




Security




Although immediacy—the compelling need to get
software to market quickly—is a characteristic of many
application domains, WebApps often exhibit a time to
market that can be a matter of a few days or weeks
Because WebApps are available via network access, it
is difficult, if not impossible, to limit the population of
end-users who may access the application

Aesthetics


An undeniable part of the appeal of a WebApp is its look
and feel

Software & Software
Engineering
What is Software Engineering?

Software Engineering
 Some






realities:

a concerted effort should be made to
understand the problem before a software
solution is developed
design becomes a pivotal activity
software should exhibit high quality
software should be maintainable

The Seminal Definition
 Software


engineering is

The establishment and use of sound
engineering principles in order to obtain
economically, software that is reliable and works
efficiently on real machines

The IEEE Definition
 Software




Engineering

The
application
of
a
systematic, disciplined, quantifiable approach to
the development, operation, and maintenance of
software; that is, the application of engineering
to software
The study of approaches as described above

A Layered Technology

tools
methods
process model
a “quality” focus


A Process Framework
 Framework






activities

work tasks
work products
milestones & deliverables
QA checkpoints

 Umbrella

Activities

Framework Activities
Communication
 Planning
 Modeling








Construction





Analysis of requirements
Design
Code generation
Testing

Deployment

Umbrella Activities
 Software

project management
 Formal technical reviews
 Software quality assurance
 Software configuration management
 Work product preparation and production
 Reusability management
 Measurement
 Risk management

Adapting a Process Model
the overall flow of activities, actions, and tasks
and the interdependencies among them
 the degree to which actions and tasks are
defined within each framework activity
 the degree to which work products are identified
and required
 the manner which quality assurance activities
are applied
 the manner in which project tracking and control
activities are applied


Adapting a Process Model
 the

overall degree of detail and rigor with
which the process is described
 the degree to which the customer and other
stakeholders are involved with the project
 the level of autonomy given to the software
team
 the degree to which team organization and
roles are prescribed

Software & Software
Engineering
Four Essence of SE Practices

The Essence of SE Practices
 Polya








suggests:

Understand the problem
♦ communication and analysis
Plan a solution
♦ modeling and software design
Carry out the plan
♦ code generation
Examine the result for accuracy
♦ testing and quality assurance

1. Understand the Problem


Who has a stake in the solution to the problem?




What are the unknowns?




What data, functions, and features are required to
properly solve the problem?

Can the problem be compartmentalized?




Who are the stakeholders?

Is it possible to represent smaller problems that may
be easier to understand?

Can the problem be represented graphically?


Can an analysis model be created?

2. Plan the Solution


Have you seen similar problems before?





Has a similar problem been solved?




If so, are elements of the solution reusable?

Can sub-problems be defined?




Are there patterns that are recognizable in a potential
solution?
Is there existing software that implements the
data, functions, and features that are required?

If so, are solutions readily apparent for the subproblems?

Can you represent a solution in a manner that leads to
effective implementation?


Can a design model be created?

3. Carry Out the Plan
 Does


the solution conform to the plan?

Is source code traceable to the design model?

 Is

each component part of the solution
provably correct?


Has the design and code been reviewed, or
better, have correctness proofs been applied to
algorithm?

4. Examine the Result
 Is

it possible to test each component part of
the solution?


Has a reasonable testing strategy been
implemented?

 Does

the solution produce results that
conform to the data, functions, and features
that are required?


Has the software been validated against all
stakeholder requirements?

Software & Software
Engineering
Seven General Principles of SE

Hooker’s General Principles
 The

Reason It All Exists
 KISS (Keep It Simple, Stupid!)
 Maintain the Vision
 What You Produce, Others Will Consume
 Be Open to the Future
 Plan Ahead for Reuse
 Think!

1. The Reason It All Exists
 Software

exists to provide value to its users
 All decisions should be made with this in
mind

2. Keep It Simple (KISS)
 There

are many factors to consider in any
design effort
 Thus, all software design should be as simple
as possible but not simpler to ease
understanding and maintenance of the
software

3. Maintain the Vision
A

clear vision is essential to the success of a
software project
 Compromising the architectural vision of a
software system weakens and break even
well-designed systems


4. What You Produce, Others Will Consume
 Consume


use, maintain, document or depend on

 Always

specify, design, and implement
knowing others will have to understand what
you are doing

5. Be Open to the Future
 True

―industrial-strength‖ software must
endure long lifetime
 Hence, design the software to:






solve the general problem, not just the specific
one,
be ready to adapt to changes (in
hardware, computing platform etc.), and
be reused

6. Plan Ahead for Reuse
 Reuse

reduces the cost and increases the
value of the reused components and the
systems into which they are incorporated

7. Think
 When

you think about something (placing
clear, complete thought before action), you
are more likely to do it right (more
importantly, the first time).

Software & Software
Engineering
Software Myths

Software Myths
Software myths – erroneous beliefs about
software and the process that is used to build it
 Misleading attitudes that have caused serious
problems for managers and practitioners
 Classifications of software myths:







Management
Customer
Practitioner

Software Myths
Management


Myth:





We already have a book that‘s full of standards and
procedures for building software
Won‘t that provide my people with everything they
need to know?

Reality:





The book of standards may exist, but is it used?
Are practitioners‘ aware of its existence?
Does it reflect modern SE practices?
Is it complete? Is it adaptable?

Software Myths
Customer


Myth:




Software requirements continuously change, but change
can be easily accommodated because software is
flexible

Reality:




The impact of change varies with the time at which it is
introduced
The cost of impact of changes in early stage of software
project is relative small
However, changes introduced at a later development
stage may require a lot of resources and major design
modification

Software Myths
Practitioner
 Myth:


―Once we write the program and get it work, our
job is done.‖

 Reality:


Somebody once said the ―the sooner you begin
‗writing the code‘, the longer it‘ll take you to get
done.‖

How It all Starts


Every software project is precipitated by some
business need





the need to correct a defect in an existing
application;
the need to adapt a ‗legacy system‘ to a changing
business environment;
the need to extend the functions and features of an
existing application, or
the need to create a new product, service, or
system.

Summary
Definitions of software and software engineering
 Software deteriorates but never wear out
 Several software application domain – system
software, engineering/scientific software, AI
software, embedded software, etc.
 The Polya‘s Four Essence of SE Practices




Understand the problem; Plan a solution; Execute
the plan; Examine the result for accuracy

Summary
 Seven


SE Principles

The Reason It All Exists; KISS; Maintain the
Vision; What You Produce, Others Will
Consume; Be Open to the Future; Plan Ahead
for Reuse; Think!

 Software

myths have caused
problems for the software industry

serious

01 fse software&sw-engineering

Recommended

More Related Content

What's hot (20)

Viewers also liked (10)

Similar to 01 fse software&sw-engineering (20)

Recently uploaded (20)

01 fse software&sw-engineering