Transcript Module 1 Introduction to Software Engineering CSEB233 Fundamentals of Software Engineering Badariah Solemon 2010 Objectives • To define SE-related terminologies: ‘software’, ‘software engineering’, etc. • To explain several.

Module 1
Introduction to Software Engineering
CSEB233
Fundamentals of
Software Engineering
Badariah Solemon 2010
Objectives
• To define SE-related terminologies: ‘software’,
‘software engineering’, etc.
• To explain several software application
domain.
• To describe the four Polya’s essence of SE
practices.
• To explain the seven Hooker’s SE principles.
• To describe several software myths.
Badariah Solemon 2010
What is ‘software’?
• Software is:
– (1) instructions (computer programs) that when
executed provide desired features, function, and
performance;
– (2) data structures that enable the programs to
adequately manipulate information; and
– (3) documentation that describes the operation
and use of the programs.
Badariah Solemon 2010
Example Software
Badariah Solemon 2010
Software …
• Is developed or engineered, it is not
manufactured in the classical sense.
– How things are manufactured?
– How software are developed or engineered?
• Software doesn't "wear out" but it deteriorates
because of errors do occur in software due to
errors in requirements, design, construction or
through out the development process.
• Most software continues to be custom-built,
although the industry is moving toward
component-based construction.
Badariah Solemon 2010
Wear vs. Deterioration
Badariah Solemon 2010
Software Application Domain
 System software
 Application software
 Engineering/scientific software
 Embedded software
 Product-line software
 Web applications (WebApps)
 AI software
Badariah Solemon 2010
Software Application Domain
Matrix
Domain
Characteristic
Example Software
System Software
•
•
•
•
•
•
•
•
Application Software
Generally, programs written to
service other programs
Heavy interaction with
computer hardware
Heavy usage by multiple users
Concurrent operation that
requires scheduling
Resource sharing and
sophisticated process
management
Complex data structures
Multiple external interfaces
•
•
•
•
•
OS – MS Windows, Linux
Ubuntu
Drivers – printer driver
Networking software wireless networking
software
Telecommunication
software – messaging
system such as sms, mms
Compilers – Borland C++,
Turbo C
Point-of-sale (POS)
Badariah Solemon 2010
Software Application Domain
Matrix (cnt’d)
Domain
Characteristic
Example Software
Engineering/Scientific
Software
•
Flight simulator
Embedded Software
•
Software to control
robots’ movement
Production-line
Software
•
Ms Word
WebApps
•
Uniten Online Application
System
AI Software
•
Expert system –
Diagnostic Medical expert
system
Badariah Solemon 2010
New Software Domain
 Open world computing—pervasive, distributed
computing
 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!)
 Data mining
 Grid computing
 Cognitive machines
 Software for nanotechnologies
Badariah Solemon 2010
The realities..
 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.
Badariah Solemon 2010
What is ‘Software Engineering’?
• IEEE:
– (1) The application of a systematic, disciplined,
quantifiable approach to the development,
operation, and maintenance of software; that is,
the application of engineering to software.
– (2) The study of approaches as in (1).
Badariah Solemon 2010
SE realities …
• SE is a join effort should be made to
understand the problem before a
software solution is developed.
• Design, which is a crucial activity.
• Software should exhibit high
quality.
• Software should be maintainable.
Badariah Solemon 2010
Layers in SE
tools
methods
process model
a “quality” focus
Badariah Solemon 2010
Layer: Process Model
• Software process is a collection of
activities, actions, and tasks that are
performed to develop or maintain a
software product.
• Framework activities:
– generic activities that are applicable to all
software projects, regardless of their size or
complexity.
• Umbrella activities:
– complementary activities applied
throughout a software project and help
manage and control progress, quality,
change, and risk.
Badariah Solemon 2010
process model
Essential SE Practices
• Polya suggests:
1. Understand the problem (communication and
modeling).
2. Plan a solution (planning and design).
3. Carry out the plan (construction and
deployment).
4. Examine the result for accuracy (testing and
quality assurance).
Badariah Solemon 2010
Understand the problem
• Who has a stake in the solution to the
problem? That is, who are the
stakeholders?
• What are the unknowns? What data,
functions, and features are required to
properly solve the problem?
• Can the problem be compartmentalized? 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?
Badariah Solemon 2010
Plan a solution
• Have you seen similar problems before? Are
there patterns that are recognizable in a
potential solution? Is there existing software
that implements the data, functions, and
features that are required?
• Has a similar problem been solved? If so, are
elements of the solution reusable?
• Can subproblems be defined? 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?
Badariah Solemon 2010
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?
Badariah Solemon 2010
Examine the result for
accuracy
• 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?
Badariah Solemon 2010
Hooker’s General SE Principles
1.
2.
3.
4.
5.
6.
7.
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!
Badariah Solemon 2010
1. The Reason It All Exists
• software exists to provide value to
its users and all decision should be
made with this in mind.
Badariah Solemon 2010
2. 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/system.
Badariah Solemon 2010
3. Maintain the Vision
• because a clear vision is essential to
the success of a software project.
• Compromising the architectural
vision of a software systems
weakens and break even welldesigned systems.
Badariah Solemon 2010
4. What You Produce, Others
Will Consume
• Consume - (use, maintain,
document or depend on)
• So, always specify, design, and
implement knowing others will have
to understand what you are doing.
Badariah Solemon 2010
5. Be Open to the Future
• True “industrial-strength” software
systems must endure long lifetime.
• Hence, design the software systems:
– to solve the general problem (not just
the specific one),
– to be ready to adapt to changes (in
hardware, computing platform etc),
and
– to be reused.
Badariah Solemon 2010
6. Plan Ahead for Reuse
• because reuse reduces the cost and
increases the value of the reused
components and the systems into
which they are incorporated.
Badariah Solemon 2010
7. Think
• Because when you think about
something (placing clear, complete
thought before action), you are
more likely to do it right (more
importantly, the first time).
Badariah Solemon 2010
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 myths
– Customer myths
– Practitioner myths
Badariah Solemon 2010
Management Myth
• 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?
Badariah Solemon 2010
Customer Myth
• Myth:
Software requirements continually 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 requires a
lot of resources and major design
modification.
Badariah Solemon 2010
Practitioner Myth
• Myth:
“Once we write the program and get it
work, our job is done.”
• Reality:
– Some once said the “the sooner you
begin ‘writing code’, the longer it’ll
take you to get done.”
Badariah Solemon 2010
Summary
• You have learned about:
– 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 essence of SE practices – understand the problem,
plan a solution, execute the plan and examine the result for
accuracy.
– SE 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!
– Software myths have caused serious problems for the software
industry.
Badariah Solemon 2010
References and credit:
• Contents in the slides are adopted from the
book and the slides that accompanied the
book by R.S. Pressman, Software Engineering:
A Practitioner’s Approach, 7th. Edition,
McGraw Hill, 2009.
Badariah Solemon 2010