NUCES – CS 303 Software Engineering Nauman [email protected] http://csrdu.org/nauman Based on lecture slides by Pressman. http://csrdu.org/nauman.

Download Report

Transcript NUCES – CS 303 Software Engineering Nauman [email protected] http://csrdu.org/nauman Based on lecture slides by Pressman. http://csrdu.org/nauman.

NUCES – CS 303 Software Engineering
Nauman
[email protected]
http://csrdu.org/nauman
Based on lecture slides by Pressman.
http://csrdu.org/nauman
Software Engineering

Let’s begin by describing what a software itself
is before we can discuss engineering it!
2
http://csrdu.org/nauman
What is Software?






an information transformer that produces,
manages, acquires, modifies, displays, or
transmits information
both a product and a vehicle for delivering a
product
the basis for the control of the computer (OS), the
communication of information (networks), the
creation and control of other programs (S/W
tools)
instructions (computer programs) that when
executed provide desired function and
performance
data structures that enable the programs to
adequately manipulate information
3
documents that describe the operation
and use of
http://csrdu.org/nauman
What is Software?
Software is a set of items or objects
 that form a “configuration” that
 includes

 programs
 Documents
 data ...
4
http://csrdu.org/nauman
Software’s Dual Role

Software as a product:
 Transforms information - produces, manages,
acquires, modifies, displays, or transmits
information
 Delivers computing potential of hardware and
networks

Software as a vehicle for delivering a product:
 Controls other programs (operating system)
 Effects communications (networking software)
 Helps build other software (software tools &
environments)
5
http://csrdu.org/nauman
Software Applications
system software
 application software
 engineering/scientific software
 embedded software
 product-line software
 web applications
 AI software

6
http://csrdu.org/nauman
Hardware vs. Software
Hardware
Software
Manufactured
Wears out
Built using
components
Relatively simple
Developed/
engineered
Deteriorates
Custom built
Complex
7
http://csrdu.org/nauman
Manufacturing vs. Development
Once a hardware product has been
manufactured, it is difficult or impossible to
modify. In contrast, software products are
routinely modified and upgraded.
 In hardware, hiring more people allows you to
accomplish more work, but the same does not
necessarily hold true in software engineering.
 Unlike hardware, software costs are
concentrated in design rather than production

8
http://csrdu.org/nauman
Software Failure Curve
Failure Rate
Increased failure rates
due to side effects
Actual Curve
Change
Idealized Curve
Time
9
http://csrdu.org/nauman
Component Based vs. Custom Built
 Hardware
products typically employ many
standardized design components.
 Most software continues to be custom built.
 The software industry does seem to be
moving (slowly) toward component-based
construction.
10
http://csrdu.org/nauman
Scope of Software Engineering
Why does it take so long to get software
finished?
 why are development costs so high?
 why can’t we find all the errors before we give
to customers?
 why do we continue to have difficulty in
measuring progress as software is being
developed?

 Why
cannot bridge-building techniques be
used to build operating systems?
11
http://csrdu.org/nauman
Bridge Collapse vs. S/W Failure

Maintenance
 bridges: with restricted maintenance activities
 software: more than 50% of the source codes
rewritten over 5 years
 usually changed due to the changes of customers’
needs

Complexity
 bridges: continuous (analog) systems (time-variant)
 software: discrete systems (state transition)
12
http://csrdu.org/nauman
What is software engineering?
technologies that make it easier, faster, and
less expensive to build high-quality computer
programs
 a discipline aiming to the production of faultfree software, delivered on time and within
budget, that satisfies the users’ needs
 an engineering like activity in software
production
 the philosophy and paradigm of established
engineering disciplines to solve what are
termed software crisis

13
http://csrdu.org/nauman
Some areas in Software Engineering








Software life cycle
Project Management
Requirements Engineering & Process
System Models
Formal Specification
Design Issues
Verification & validation activity
Management
 Quality
 Cost Estimation
 Process Improvement

…
14
http://csrdu.org/nauman
Changing Legacy Software





It must be fixed to eliminate errors.
It must be enhanced to implement new functional and
non-functional requirements
Software must be adapted to meet the needs of new
computing environments or technology.
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.
15
http://csrdu.org/nauman
The Cost of Change
16
http://csrdu.org/nauman
Software Myths

Normally
 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
17
http://csrdu.org/nauman
Management Myths
We already have a book that’s full of standards
and procedures for building s/w, won’t that
provide my people with everything they need to
know?
2. My people have state-of-the-art software
development tools, after all, we buy them the
newest computers.
3. If we get behind schedule, we can add more
programmers and catch up.
4. If I decide to outsource the software project to a
third party, I can just relax and let that firm build
it.
18
1.
http://csrdu.org/nauman
Customer Myths
 “A general
statement of objectives is
sufficient to begin writing programs - we
can fill in the details later …”
 “Project
requirements continually change
but this change can easily be
accommodated because software is
flexible …”
19
http://csrdu.org/nauman
Practitioner’s Myths
1.
Once we write the program and get it to work,
our job is done.
 Fact: the sooner you begin writing code, the longer it
will take you to get done.
Until I get the program “running,” I have no way
of assessing its quality.
3. The only deliverable work product for a
successful project is the working program.
4. Software engineering will make us create
voluminous and unnecessary documentation
and will invariably slow us down.
2.
20
http://csrdu.org/nauman