Introduction to Software Engineering

These slides are designed and adapted from slides provided by Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill1
2009) by Roger Pressman and Software Engineering 9/e Addison Wesley 2011 by Ian Sommerville
What is
Software?
The product that software professionals build and then support over
the long term.
Software encompasses:
(1) instructions (computer programs) that when executed provide
desired features, function, and performance;
(2) data structures that enable the programs to adequately store
and manipulate information and
(3) documentation that describes the operation and use of the
programs.

2
Software products
• Generic products
• Stand-alone systems that are marketed and sold to any customer who wishes
to buy them.
• Examples – PC software such as editing, graphics programs, project
management tools; CAD software; software for specific markets such as
appointments systems for dentists.

• Customized products
• Software that is commissioned by a specific customer to meet their own needs.
• Examples – embedded control systems, air traffic control software, traffic
monitoring systems.
Why Software is Important?

• The economies of ALL developed nations are dependent on software.

• More and more systems are software controlled ( transportation,

medical, telecommunications, military, industrial, entertainment,)

• Software engineering is concerned with theories, methods and tools

for professional software development.

• Expenditure on software represents a significant fraction of GNP in all

developed countries.
Software costs

• Software costs often dominate computer system costs. The costs of

software on a PC are often greater than the hardware cost.

• Software costs more to maintain than it does to develop. For

systems with a long life, maintenance costs may be several times
development costs.

• Software engineering is concerned with cost-effective software

development.
Features of Software?
• Its characteristics that make it different from other things human
being build.
Features of such logical system:
• Software is developed or engineered, it is not manufactured in the
classical sense which has quality problem.
• Software doesn't "wear out.” but it deteriorates (due to change).
Hardware has bathtub curve of failure rate ( high failure rate in the
beginning, then drop to steady state, then cumulative effects of dust,
vibration, abuse occurs).
• Although the industry is moving toward component-based
construction (e.g. standard screws and off-the-shelf integrated
circuits), most software continues to be custom-built. Modern
reusable components encapsulate data and processing into software
parts to be reused by different programs. E.g. graphical user
interface, window, pull-down menus in library etc.
Wear vs. Deterioration
increased failure
rate due to side effects
Failure
rate

change
actual curve

idealized curve

Time

7
Software
Applications
• 1. System software: such as compilers, editors, file management utilities
• 2. Application software: stand-alone programs for specific needs.
• 3. Engineering/scientific software: Characterized by “number crunching”algorithms.
such as automotive stress analysis, molecular biology, orbital dynamics etc
• 4. Embedded software resides within a product or system. (key pad control of a
microwave oven, digital function of dashboard display in a car)
• 5. Product-line software focus on a limited marketplace to address mass consumer
market. (word processing, graphics, database management)
• 6. WebApps (Web applications) network centric software. As web 2.0 emerges, more
sophisticated computing environments is supported integrated with remote
database and business applications.
• 7. AI software uses non-numerical algorithm to solve complex problem. Robotics,
expert system, pattern recognition game playing

8
Software Engineering Definition

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: (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).
 Importance of Software
Engineering
• More and more, individuals and society rely on advanced software
systems. We need to be able to produce reliable and trustworthy
systems economically and quickly.

• It is usually cheaper, in the long run, to use software engineering

methods and techniques for software systems rather than just write
the programs as if it was a personal programming project. For most
types of system, the majority of costs are the costs of changing the
software after it has gone into use.
 FAQ about software engineering
Question Answer

What is software? Computer programs, data structures and associated

documentation. Software products may be developed
for a particular customer or may be developed for a
general market.

What are the attributes of good Good software should deliver the required functionality
software? and performance to the user and should be
maintainable, dependable and usable.

What is software engineering? Software engineering is an engineering discipline that

is concerned with all aspects of software production.
What is the difference between software Computer science focuses on theory and
engineering and computer science? fundamentals; software engineering is concerned with
the practicalities of developing and delivering useful
software.
What is the difference between software System engineering is concerned with all aspects of
engineering and system engineering? computer-based systems development including
hardware, software and process engineering.
Software engineering is part of this more general
process.
Essential attributes of good
software
Product characteristic Description

Maintainability Software should be written in such a way so that it can evolve to

meet the changing needs of customers. This is a critical attribute
because software change is an inevitable requirement of a changing
business environment.

Dependability and security Software dependability includes a range of characteristics including

reliability, security and safety. Dependable software should not cause
physical or economic damage in the event of system failure.
Malicious users should not be able to access or damage the system.

Efficiency Software should not make wasteful use of system resources such as
memory and processor cycles. Efficiency therefore includes
responsiveness, processing time, memory utilisation, etc.

Acceptability Software must be acceptable to the type of users for which it is

designed. This means that it must be understandable, usable and
compatible with other systems that they use.
 Social Learning Process
• Software is embodied knowledge that is initially dispersed,
tacit and incomplete.

• In order to convert knowledge into software, dialogues are

needed between users and designers, between designers
and tools to bring knowledge into software.

• Software development is essentially an iterative social

learning process, and the outcome is “software capital”.
Software Engineering

A Layered Technology
tools

methods

process model

a “quality” focus
 Any engineering approach must rest on organizational commitment to quality which fosters a
continuous process improvement culture.
 Process layer as the foundation defines a framework with activities for effective delivery of
software engineering technology. Establish the context where products (model, data, report,
and forms) are produced, milestone are established, quality is ensured and change is
managed.
 Method provides technical how-to’s for building software. It encompasses many tasks
including communication, requirement analysis, design modeling, program construction, testing
and support.
 Tools provide automated or semi-automated support for the process and methods. 14
 Definition of Software Process
• A framework for the activities, actions, and tasks that are required
to build high-quality software.

• SP defines the approach that is taken as software is engineered.

• Is not equal to software engineering, which also encompasses

technologies that populate the process– technical methods and
automated tools.

15
Software Process
• A process is a collection of activities, actions and tasks that are
performed when some work product is to be created. It is not a
rigid prescription for how to build computer software. Rather, it
is an adaptable approach that enables the people doing the
work to pick and choose the appropriate set of work actions
and tasks.

• Purpose of process is to deliver software in a timely manner and

with sufficient quality to satisfy those who have sponsored its
creation and those who will use it.
What / who / why is Process Models?
What: Go through a series of predictable steps--- a road map that
helps you create a timely, high-quality results.
Who: Software engineers and their managers, clients also. People
adapt the process to their needs and follow it.
Why: Provides stability, control, and organization to an activity that
can if left uncontrolled, become quite chaotic. However, modern
software engineering approaches must be agile and demand ONLY
those activities, controls and work products that are appropriate.
What Work products: Programs, documents, and data
What are the steps: The process you adopt depends on the software
that you are building. One process might be good for aircraft avionic
system, while an entirely different process would be used for website
creation.
How to ensure right: A number of software process assessment
mechanisms that enable us to determine the maturity of the software
process. However, the quality, timeliness and long-term viability of the
software are the best indicators of the efficacy of the process you use.
• Communication: communicate with customer to understand objectives and gather
requirements
• Planning: creates a “map” defines the work by describing the tasks, risks and
resources, work products and work schedule.
• Modeling: Create a “sketch”, what it looks like architecturally, how the constituent
parts fit together and other characteristics.
• Construction: code generation and the testing.
• Deployment: Delivered to the customer who evaluates the products and provides
feedback based on the evaluation.

• These five framework activities can be used to all software development regardless
of the application domain, size of the project, complexity of the efforts etc, though
the details will be different in each case.

• For many software projects, these framework activities are applied iteratively as a
project progresses. Each iteration produces a software increment that provides a
subset of overall software features and functionality.

Five Activities of a Generic

Process framework
A Generic Process Model
 Umbrella Activities
Complement the five process framework activities and help team manage and control progress, quality,
change, and risk.

• Software project tracking and control: assess progress against the plan and take actions to maintain the
schedule.

• Risk management: assesses risks that may affect the outcome and quality.

• Software quality assurance: defines and conduct activities to ensure quality.

• Technical reviews: assesses work products to uncover and remove errors before going to the next activity.

• Measurement: define and collects process, project, and product measures to ensure stakeholder’s needs
are met.

• Software configuration management: manage the effects of change throughout the software process.

• Reusability management: defines criteria for work product reuse and establishes mechanism to achieve
reusable components.

• Work product preparation and production: create work products such as models, documents, logs, forms
and lists.
Adapting a Process Model
The process should be agile and adaptable to problems. Process adopted for
one project might be significantly different than a process adopted from another
project. (to the problem, the project, the team, organizational culture). Among
the differences are:

•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
As we discussed before, a generic process framework for software
engineering defines five framework activities-communication,
planning, modeling, construction, and deployment.
In addition, a set of umbrella activities- project tracking and control,
risk management, quality assurance, configuration management,
technical reviews, and others are applied throughout the process.
Next question is: how the framework activities and the actions and
tasks that occur within each activity are organized with respect to
sequence and time? See the process flow for answer.

A Generic Process Model

22
Process Flow
 Process Flow
Linear process flow executes each of the five activities in sequence.
An iterative process flow repeats one or more of the activities before
proceeding to the next.
An evolutionary process flow executes the activities in a circular
manner. Each circuit leads to a more complete version of the
software.
A parallel process flow executes one or more activities in parallel
with other activities ( modeling for one aspect of the software in
parallel with construction of another aspect of the software.
Identifying a Task Set

Before you can proceed with the process model, a key question:
what actions are appropriate for a framework activity given the
nature of the problem, the characteristics of the people and the
stakeholders?

A task set defines the actual work to be done to accomplish the

objectives of a software engineering action.
A list of the task to be accomplished
A list of the work products to be produced
A list of the quality assurance filters to be applied

25
Identifying a Task Set
For example, a small software project requested by one person
with simple requirements, the communication activity might
encompass little more than a phone all with the stakeholder.
Therefore, the only necessary action is phone conversation, the
work tasks of this action are:
1. Make contact with stakeholder via telephone.
2. Discuss requirements and take notes.
3. Organize notes into a brief written statement of requirements.
4. E-mail to stakeholder for review and approval.

26
Example of a Task Set for Elicitation

The task sets for Requirements gathering action for a simple

project may include:
1. Make a list of stakeholders for the project.
2. Invite all stakeholders to an informal meeting.
3. Ask each stakeholder to make a list of features and functions
required.
4. Discuss requirements and build a final list.
5. Prioritize requirements.
6. Note areas of uncertainty.

27
The task sets for Requirements gathering action for a big project may
include:
1. Make a list of stakeholders for the project.
2. Interview each stakeholders separately to determine overall wants and needs.
3. Build a preliminary list of functions and features based on stakeholder input.
4. Schedule a series of facilitated application specification meetings.
5. Conduct meetings.
6. Produce informal user scenarios as part of each meeting.
7. Refine user scenarios based on stakeholder feedback.
8. Build a revised list of stakeholder requirements.
9. Use quality function deployment techniques to prioritize requirements.
10. Package requirements so that they can be delivered incrementally.
11. Note constraints and restrictions that will be placed on the system.
12. Discuss methods for validating the system.

 Both do the same work with different depth and formality. Choose the
task sets that achieve the goal and still maintain quality and agility.

Example of a Task Set for Elicitation

28
 The Essence of Practice
• How does the practice of software engineering fit in the process activities
mentioned above? Namely, communication, planning, modeling,
construction and deployment.
• George Polya outlines the essence of problem solving, suggests:
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).

29
 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 solutions 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?
Help you establish mind-set for solid software engineering practice
(David Hooker 96).
•1: The Reason It All Exists: provide values to users
•2: KISS (Keep It Simple, Stupid! As simple as possible)
•3: Maintain the Vision (otherwise, incompatible design)
•4: What You Produce, Others Will Consume (code with concern for those
that must maintain and extend the system)
•5: Be Open to the Future (never design yourself into a corner as
specification and hardware changes)
•6: Plan Ahead for Reuse
•7: Think! Place clear complete thought before action produces better results.

Hooker’s General Principles for Software

Engineering Practice: important underlying law
 Software Myths

Erroneous beliefs about software and the process that is used to build it.
•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
Software Myths Examples
• Myth 1: Once we write the program and get it to work, our job is done.
• Reality: the sooner you begin writing code, the longer it will take you to get done. 60%
to 80% of all efforts are spent after software is delivered to the customer for the first
time.

• Myth 2: Until I get the program running, I have no way of assessing its quality.
• Reality: technical review are a quality filter that can be used to find certain classes of
software defects from the inception of a project.

• Myth 3: software engineering will make us create voluminous and unnecessary

documentation and will invariably slow us down.
• Reality: it is not about creating documents. It is about creating a quality product. Better
quality leads to a reduced rework. Reduced work results in faster delivery times.

• Many people recognize the fallacy of the myths. Regrettably, habitual attitudes and
methods foster poor management and technical practices, even when reality dictates a
better approach.
•The prescriptive process models stress detailed definition, identification,
and application of process activates and tasks. Intent is to improve system
quality, make projects more manageable, make delivery dates and costs
more predictable, and guide teams of software engineers as they perform
the work required to build a system.
•Unfortunately, there have been times when these objectives were not
achieved. If prescriptive models are applied dogmatically and without
adaptation, they can increase the level of bureaucracy.

•Agile process models emphasize project “agility” and follow a set of

principles that lead to a more informal approach to software process. It
emphasizes maneuverability and adaptability. It is particularly useful when
Web applications are engineered.

Prescriptive and Agile Process Models

37
 Prescriptive Models
• Originally proposed to bring order to chaos.
• Prescriptive process models advocate an orderly approach to software
engineering. However, will some extent of chaos (less rigid) be beneficial
to bring some creativity?

That leads to a few questions …

• If prescriptive process models strive for structure and order (prescribe a
set of process elements and process flow), are they inappropriate for a
software world that thrives on change?
• Yet, if we reject traditional process models (and the order they imply) and
replace them with something less structured, do we make it impossible to
achieve coordination and coherence in software work?

38
 The Waterfall Model

It is the oldest paradigm for SE. When requirements are well

defined and reasonably stable, it leads to a linear fashion.
(problems: 1. rarely linear, iteration needed. 2. hard to state all requirements explicitly.
Blocking state. 3. code will not be released until very late.)

The classic life cycle suggests a systematic, sequential approach

to software development.
39
 A variation of waterfall model
depicts the relationship of
The V-Model quality assurance actions to
the actions associated with
communication, modeling and
early code construction
activates.

Team first moves down the left

side of the V to refine the
problem requirements. Once
code is generated, the team
moves up the right side of the
V, performing a series of tests
that validate each of the
models created as the team
moved down the left side.

40
The Incremental Model

41
 The Incremental Model
• When initial requirements are reasonably well defined, but the
overall scope of the development effort precludes a purely linear
process. A compelling need to expand a limited set of new
functions to a later system release.
• It combines elements of linear and parallel process flows. Each
linear sequence produces deliverable increments of the software.
• The first increment is often a core product with many
supplementary features. Users use it and evaluate it with more
modifications to better meet the needs.

42
 Evolutionary Models
• Software system evolves over time as requirements often change as
development proceeds. Thus, a straight line to a complete end product is
not possible. However, a limited version must be delivered to meet
competitive pressure.
• Usually a set of core product or system requirements is well understood,
but the details and extension have yet to be defined.
• You need a process model that has been explicitly designed to
accommodate a product that evolved over time.
• It is iterative that enables you to develop increasingly more complete
version of the software.
• Two types are introduced, namely Prototyping and Spiral models.

43
 Evolutionary Models:
Prototyping
• When to use: Customer defines a set of general objectives but does not identify
detailed requirements for functions and features. Or Developer may be unsure of the
efficiency of an algorithm, the form that human computer interaction should take.
• What step: Begins with communication by meeting with stakeholders to define the
objective, identify whatever requirements are known, outline areas where further
definition is mandatory. A quick plan for prototyping and modeling (quick design) occur.
Quick design focuses on a representation of those aspects the software that will be
visible to end users. ( interface and output). Design leads to the construction of a
prototype which will be deployed and evaluated. Stakeholder’s comments will be used
to refine requirements.
• Both stakeholders and software engineers like the prototyping paradigm. Users get a
feel for the actual system, and developers get to build something immediately.
However, engineers may make compromises in order to get a prototype working
quickly. The less-than-ideal choice may be adopted forever after you get used to it.

44
Evolutionary Models:
Prototyping
Quick
plan
communication

Modeling
Quick design

Deployment Construction
delivery & of prototype
feedback Construction
of prototype

45
•
Evolutionary Models: The Spiral
It couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall
model and is a risk-driven process model generator that is used to guide multi-stakeholder concurrent
engineering of software intensive systems.
• Two main distinguishing features: one is cyclic approach for incrementally growing a system’s degree of
definition and implementation while decreasing its degree of risk. The other is a set of anchor point
milestones for ensuring stakeholder commitment to feasible and mutually satisfactory system solutions.
• A series of evolutionary releases are delivered. During the early iterations, the release might be a model
or prototype. During later iterations, increasingly more complete version of the engineered system are
produced.
• The first circuit in the clockwise direction might result in the product specification; subsequent passes
around the spiral might be used to develop a prototype and then progressively more sophisticated
versions of the software. Each pass results in adjustments to the project plan. Cost and schedule are
adjusted based on feedback. Also, the number of iterations will be adjusted by project manager.
• Good to develop large-scale system as software evolves as the process progresses and risk should be
understood and properly reacted to. Prototyping is used to reduce risk.
• However, it may be difficult to convince customers that it is controllable as it demands considerable risk
assessment expertise.

46
Evolutionary Models: The
Spiral

47
 Three Concerns on Evolutionary
Processes
• First concern is that prototyping poses a problem to project planning because
of the uncertain number of cycles required to construct the product.
• Second, it does not establish the maximum speed of the evolution. If the
evolution occur too fast, without a period of relaxation, it is certain that the
process will fall into chaos. On the other hand if the speed is too slow then
productivity could be affected.
• Third, software processes should be focused on flexibility and extensibility
rather than on high quality. We should prioritize the speed of the development
over zero defects. Extending the development in order to reach high quality
could result in a late delivery of the product when the opportunity niche has
disappeared.

48
 Concurrent Model
• Allow a software team to represent iterative and concurrent elements of any of the
process models. For example, the modeling activity defined for the spiral model is
accomplished by invoking one or more of the following actions: prototyping, analysis
and design.
• The Figure shows modeling may be in any one of the states at any given time. For
example, communication activity has completed its first iteration and in the awaiting
changes state. The modeling activity was in inactive state, now makes a transition into
the under development state. If customer indicates changes in requirements, the
modeling activity moves from the under development state into the awaiting changes
state.
• Concurrent modeling is applicable to all types of software development and provides
an accurate picture of the current state of a project. Rather than confining software
engineering activities, actions and tasks to a sequence of events, it defines a process
network. Each activity, action or task on the network exists simultaneously with other
activities, actions or tasks. Events generated at one point trigger transitions among the
states.

49
Concurrent Model

50
 Still Other Process Models
• Component based development—the process to apply when
reuse is a development objective ( like spiral model)
• Formal methods—emphasizes the mathematical specification of
requirements ( easy to discover and eliminate ambiguity,
incompleteness and inconsistency)
• Aspect Oriented software development (AOSD)—provides a
process and methodological approach for defining, specifying,
designing, and constructing aspects
• Unified Process—a “use-case driven, architecture-centric, iterative
and incremental” software process closely aligned with the
Unified Modeling Language (UML) to model and develop object-
oriented system iteratively and incrementally.

51
The Unified Process (UP)
elaboration

inception

52
UP Phases

53
UP Work Products

54