Software

Engineering
2023
PTIK - UNS
  3 SKS Teori
 2 Kelas
About  Hari : Jumat
Software  Jam : 09.00 (B) 13.00 (A)

Engineering  Referensi:
 Software Engineering : Practicioner
Edition – Pressman
 Software Engineering : Ian Sommervile
 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.

THESE SLIDES ARE DESIGNED TO ACCOMPANY SOFTWARE ENGINEERING: A PRACTITIONER’S

3
APPROACH, 7/E (MCGRAW-HILL 2009). SLIDES COPYRIGHT 2009 BY ROGER PRESSMAN.
 1. Software is developed or engineered; it is
not manufactured in the classical sense
Software
Characteristics 2. Software doesn’t “wear out.”

3. Although the industry is moving toward

component-based construction, most
software continues to be custom built.
 Wear vs. Deterioration

THESE SLIDES ARE DESIGNED TO ACCOMPANY SOFTWARE ENGINEERING: A PRACTITIONER’S

5
APPROACH, 7/E (MCGRAW-HILL 2009). SLIDES COPYRIGHT 2009 BY ROGER PRESSMAN.
 Wear vs. Deterioration
increased failure
rate due to side effects
Failure
rate

change
actual curve

idealized curve

Time

THESE SLIDES ARE DESIGNED TO ACCOMPANY SOFTWARE ENGINEERING: A PRACTITIONER’S

6
APPROACH, 7/E (MCGRAW-HILL 2009). SLIDES COPYRIGHT 2009 BY ROGER PRESSMAN.
 Software Applications Domains
 System software—a collection of programs written to service other programs. Some
system software (e.g., compilers, editors, and file management utilities) processes
complex, but determinate, information structures. Other systems applications (e.g.,
operating system components, drivers, networking software, telecommunications
processors) process largely indeterminate data.

 In either case, the systems software area is characterized by heavy interaction with
computer hardware; heavy usage by multiple users; concurrent operation that requires
scheduling, resource sharing, and sophisticated process management; complex data

structures; and multiple external interfaces

THESE SLIDES ARE DESIGNED TO ACCOMPANY SOFTWARE ENGINEERING: A PRACTITIONER’S
7
APPROACH, 7/E (MCGRAW-HILL 2009). SLIDES COPYRIGHT 2009 BY ROGER PRESSMAN.
 Software Applications Domains
 Application software—stand-alone programs that solve a specific business
need. Applications in this area process business or technical data in a way
that facilitates business operations or management/technical decision
making. In addition to conventional data processing applications,
application software is used to control business functions in real time (e.g.,
point-of-sale transaction processing, real-time manufacturing process
control)

THESE SLIDES ARE DESIGNED TO ACCOMPANY SOFTWARE ENGINEERING: A PRACTITIONER’S

8
APPROACH, 7/E (MCGRAW-HILL 2009). SLIDES COPYRIGHT 2009 BY ROGER PRESSMAN.
 Software Applications Domains
 Engineering/scientific software—has been characterized by “number
crunching” algorithms. Applications range from astronomy to
volcanology, from automotive stress analysis to space shuttle orbital
dynamics, and from molecular biology to automated manufacturing.
However, modern applications within the engineering/scientific area are
moving away from conventional numerical algorithms. Computer-aided
design, system simulation, and other interactive applications have begun
to take on real-time and even system software characteristics.
THESE SLIDES ARE DESIGNED TO ACCOMPANY SOFTWARE ENGINEERING: A PRACTITIONER’S
9
APPROACH, 7/E (MCGRAW-HILL 2009). SLIDES COPYRIGHT 2009 BY ROGER PRESSMAN.
 Software Applications Domains
 Embedded software—resides within a product or system and is used to
implement and control features and functions for the end user and for the
system itself. Embedded software can perform limited and esoteric functions
(e.g., key pad control for a microwave oven) or provide significant function
and control capability (e.g., digital functions in an automobile such as fuel
control, dashboard displays, and braking systems).

THESE SLIDES ARE DESIGNED TO ACCOMPANY SOFTWARE ENGINEERING: A PRACTITIONER’S

10
APPROACH, 7/E (MCGRAW-HILL 2009). SLIDES COPYRIGHT 2009 BY ROGER PRESSMAN.
 Software Applications Domains
 Product-line software—designed to provide a specific capability for
use by many different customers. Product-line software can focus on a
limited and esoteric marketplace (e.g., inventory control products) or
address mass consumer markets (e.g., word processing, spreadsheets,
computer graphics, multimedia, entertainment, database management,
and personal and business financial applications).

THESE SLIDES ARE DESIGNED TO ACCOMPANY SOFTWARE ENGINEERING: A PRACTITIONER’S

11
APPROACH, 7/E (MCGRAW-HILL 2009). SLIDES COPYRIGHT 2009 BY ROGER PRESSMAN.
 Software Applications Domains
 Web applications—called “WebApps,” this network-centric software category
spans a wide array of applications. In their simplest form, WebApps can
be little more than a set of linked hypertext files that present information
using text and limited graphics. However, as Web 2.0 emerges, WebApps are
evolving into sophisticated computing environments that not only provide
stand-alone features, computing functions, and content to the end user, but
also are integrated with corporate databases and business applications.

THESE SLIDES ARE DESIGNED TO ACCOMPANY SOFTWARE ENGINEERING: A PRACTITIONER’S

12
APPROACH, 7/E (MCGRAW-HILL 2009). SLIDES COPYRIGHT 2009 BY ROGER PRESSMAN.
 Software Applications Domains
 Artificial intelligence software—makes use of nonnumerical
algorithms to solve complex problems that are not amenable to
computation or straightforward analysis. Applications within this area
include robotics, expert systems, pattern recognition (image and voice),
artificial neural networks, theorem proving, and game playing.

THESE SLIDES ARE DESIGNED TO ACCOMPANY SOFTWARE ENGINEERING: A PRACTITIONER’S

13
APPROACH, 7/E (MCGRAW-HILL 2009). SLIDES COPYRIGHT 2009 BY ROGER PRESSMAN.
 Software Applications Domains
 Open-world computing—the rapid growth of wireless networking may soon lead to true pervasive, distributed
computing. The challenge for software engineers will be to develop systems and application software that will
allow mobile devices, personal computers, and enterprise systems to communicate across vast networks

 Netsourcing—the World Wide Web is rapidly becoming a computing engine as well as a content provider. The
challenge for software engineers is to architect simple (e.g., personal financial planning) and sophisticated
applications that provide a benefit to targeted end-user markets worldwide.

 Open source—a growing trend that results in distribution of source code for systems applications (e.g., operating
systems, database, and development environments) so that many people can contribute to its development. The
challenge for software engineers is to build source code that is self-descriptive, but more importantly, to develop
techniques that will enable both customers and developers to know what changes have been made and how those
changes manifest themselves within the software

THESE SLIDES ARE DESIGNED TO ACCOMPANY SOFTWARE ENGINEERING: A PRACTITIONER’S

14
APPROACH, 7/E (MCGRAW-HILL 2009). SLIDES COPYRIGHT 2009 BY ROGER PRESSMAN.
Legacy Software
 As time passes, legacy systems often evolve for one or more of the following reasons:
• The software must be adapted to meet the needs of new computing environments or technology.
• The software must be enhanced to implement new business requirements.
• The software must be extended to make it interoperable with other more modern systems
• The software must be re-architected to make it viable within a network environment.
What is CASE (Computer-Aided Software Engineering)

 Software systems which are intended to provide automated

support for software process activities. CASE systems are often used
for method support
 Upper-CASE
 Tools to support the early process activities of requirements and design

 Lower-CASE
 Tools to support later activities such as programming, debugging and testing
What are the attributes of good software?
 The software should deliver the required functionality and performance
to the user and should be maintainable, dependable and usable
 Maintainability
 Software must evolve to meet changing needs

 Dependability
 Software must be trustworthy

 Efficiency
 Software should not make wasteful use of system resources

 Usability
 Software must be usable by the users for which it was designed
What are the key challenges facing software engineering?
 Coping with legacy systems, coping with increasing diversity and coping with demands for
reduced delivery times
 Legacy systems
 Old, valuable systems must be maintained and updated

 Heterogeneity
 Systems are distributed and include a mix of hardware and software

 Delivery
 There is increasing pressure for faster delivery of software
Software Engineering
The IEEE definition:
 Software Engineering: (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).

19
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.

20
A Generic View of Software Engineering
 Regardless of the entity to be engineered, the following questions must be asked and answered:
• What is the problem to be solved?
• What characteristics of the entity are used to solve the problem?
• How will the entity (and the solution) be realized?
• How will the entity be constructed?
• What approach will be used to uncover errors that were made in the design
and construction of the entity?
• How will the entity be supported over the long term, when corrections, adaptations, and

enhancements are requested by users of the entity.

 A Layered
Technology

Tools: CASE preferred

Methods: technical “how to’s”

Process model: the “framework”

A quality focus: the “bedrock”

THESE SLIDES ARE DESIGNED TO ACCOMPANY SOFTWARE ENGINEERING: A PRACTITIONER’S

22
APPROACH, 7/E (MCGRAW-HILL 2009). SLIDES COPYRIGHT 2009 BY ROGER PRESSMAN.
 A Process Framework
Process framework
Framework activities
work tasks
work products
milestones & deliverables
QA checkpoints
Umbrella Activities

THESE SLIDES ARE DESIGNED TO ACCOMPANY SOFTWARE ENGINEERING: A PRACTITIONER’S

23
APPROACH, 7/E (MCGRAW-HILL 2009). SLIDES COPYRIGHT 2009 BY ROGER PRESSMAN.
Framework Activities
 Communication
 Planning
 Modeling
 Analysis of requirements
 Design
 Construction
 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
 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
The Essence of Practice
1. Understand the problem (communication and analysis).
2. Plan a solution (modeling and software design).
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and quality assurance).

27
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?
Plan the 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?
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?
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?
Hooker’s General Principles
 1: The Reason It All Exists
 2: KISS (Keep It Simple, Stupid!)
 3: Maintain the Vision
 4: What You Produce, Others Will Consume
 5: Be Open to the Future
 6: Plan Ahead for Reuse
 7: Think!
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 very well exist, but is it used? Are software practitioners aware of its
existence? Does it reflect modern software engineering practice? Is it complete? Is it adaptable? Is it
streamlined to improve time-to-delivery while still maintaining a focus on quality? In many cases, the
answer to all of these questions is “no.”

Myth: If we get behind schedule, we can add more programmers and catch up (sometimes called the
“Mongolian horde” concept).

Reality: Software development is not a mechanistic process like manufacturing. In the words of Brooks
[Bro95]: “adding people to a late software project makes it later.” At first, this statement may seem
counterintuitive. However, as new people are added, people who were working must spend time educating
the newcomers, thereby reducing the amount of time spent on productive development effort. People can
be added but only in a planned and well-coordinated manner.

Myth: If I decide to outsource the software project to a third party, I can just relax and let that firm
build it.

Reality: If an organization does not understand how to manage and control software projects internally, it
will invariably struggle when it outsources software projects.
Customer Myth
Myth: A general statement of objectives is sufficient to begin writing
programs—we can fill in the details later.
Reality: Although a comprehensive and stable statement of requirements is not
always possible, an ambiguous “statement of objectives” is a recipe for disaster.
Unambiguous requirements (usually derived iteratively) are developed only
through effective and continuous communication between customer and
developer.
Myth: Software requirements continually change, but change can be easily
accommodated because software is flexible.
Reality: It is true that software requirements change, but the impact of change
varies with the time at which it is introduced. When requirements changes are
requested early (before design or code has been started), the cost impact is
relatively small. However, as time passes, the cost impact grows rapidly—
resources have been committed, a design framework has been established, and
change can cause upheaval that requires additional resources and major design
modification
Practicioner Myth
Myth: Once we write the program and get it to work, our job is done.

Reality: Someone once said that “the sooner you begin ‘writing code,’ the longer it’ll take you
to get done.” Industry data indicate that between 60 and 80 percent of all effort expended on
software will be expended after it is delivered to the customer for the first time.

Myth: Until I get the program “running” I have no way of assessing its quality.

Reality: One of the most effective software quality assurance mechanisms can be applied from
the inception of a project—the technical review. Software reviews (described in Chapter 15)
are a “quality filter” that have been found to be more effective than testing for finding certain
classes of software defects.

Myth: The only deliverable work product for a successful project is the working
program.

Reality: A working program is only one part of a software configuration that includes many
elements. A variety of work products (e.g., models, documents, plans) provide a foundation for
successful engineering and, more important, guidance for software support.

Myth: Software engineering will make us create voluminous and unnecessary

documentation and will invariably slow us down.

Reality: Software engineering is not about creating documents. It is about creating a quality
product. Better quality leads to reduced rework. And reduced rework results in faster delivery
times.
End of Chapter 1