Scribd
Upload
24 views15 pages

SE - Unit 1

SE_unit 1.pptx

Uploaded by

saket.internship
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
24 views15 pages

SE - Unit 1

SE_unit 1.pptx

Uploaded by

saket.internship
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 15

Supplementary Slides for

Software Engineering:
A Practitioner's Approach, 6/e
Part 1
copyright © 1996, 2001, 2005
R.S. Pressman & Associates, Inc.

1
Software Engineering: A Practitioner’s Approach, 6/e

Chapter 1
Software and Software Engineering

2
What is Software?
A textbook description of software might take the following form:
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) descriptive information in both hard copy and virtual forms that
describes the operation and use of the programs.

Software engineering is the establishment and use of sound engineering


principles in order to obtain economical software that is reliable and works
efficiently on real machines.

3
What is Software?
Software is a set of items or objects
that form a “configuration” that
includes
• programs
• documents
• data ...

4
Software’s Dual Role
■ Software is a product
■ Delivers computing potential
■ It acts as information transformer because it produces, manages,
acquires, modifies, displays, or transmits information
■ Software is a vehicle for delivering a product
■ Supports or directly provides system functionality
■ Controls other programs (e.g., an operating system)
■ Effects communication (e.g., networking software)
■ Helps build other software (e.g., software tools)

5
Difference between S/W and H/W
■ software is developed or engineered, it is not
manufactured in classical sense
■ software doesn’t wear out
■ software is complex (Although the industry is moving
toward component-based construction, most software
continues to be custom-built.)

6
7
Wear vs. Deterioration

8
Software Application Domains
(Categories of Software)
■ system software
■ application software
■ engineering/scientific software
■ embedded software
■ product-line software
■ WebApps (Web applications)
■ AI software

9
Legacy Software
Legacy software is software that has been around a long time and
still fulfills a business need. It is mission critical and tied to a
particular version of an operating system or hardware model

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.
10
Software Myths
■ Affect managers, customers (and other non-technical stakeholders)
and practitioners
■ Are believable because they often have elements of truth,
■ Software myths—erroneous beliefs about software and the process
that is used to build it—can be traced to the earliest days of
computing
but …
■ Invariably lead to bad decisions,
therefore …
■ Insist on reality as you navigate your way through software
engineering

11
Management myths
■ Managers with software responsibility, like managers in most
disciplines, are often under pressure to maintain budgets, keep
schedules from slipping, and improve quality.
■ 1) 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?
■ 2) If we get behind schedule, we can add more programmers and
catch up
■ 3) If I decide to outsource the software project to a third party, I can
just relax and let that firm build it.

12
Customer Myths
■ A customer who requests computer software may be a
person at the next desk, a technical group down the hall,
the marketing/sales department.
■ 1) A general statement of objectives is sufficient to begin
writing programs—we can fill in the details later
■ 2) Software requirements continually change, but change
can be easily accommodated because software is flexible

13
Practitioner’s myths
■ Myths that are still believed by software practitioners
■ 1) Once we write the program and get it to work, our job
is done.
■ 2) 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

14
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 15

You might also like