Introduction to software engineering concepts and process models

1. 1

3. Biggest Software Failures
• 1. Hackers Target Indian Debit Cards : total loss of Rs 1.3 crores in
fraudulent transactions
• 2. The BlueCross BlueShield Association System Failure
:resulting in almost 25,000 consumers being enrolled with incorrect
health insurance
• 3 Bangladesh Banks Heist :$81 million of Bangladesh’s money was
siphoned off by hackers that remain unknown. they caused about
$870 million in transfers to be canceled.
• 4. Satellite Failure Sends Global Software for a Toss :All over the
world, GPS systems were thrown off for several hours before the
operations were once again restored to normalcy.
• 5. Yahoo! Data Theft :The first was in September, which ended
up affecting over 500 million Yahoo
• 6.Hive Thermostat App Sets Users’ Homes to 32° C (90° F)
• 7. Mark Zuckerberg Hack , Foxmeyer , Hershey …….

4. 1.Introduction To Software Engineering and
Process Models
• Nature of Software, Software Engineering, Software
Process, Capability Maturity Model (CMM)
• Generic Process Model
• Prescriptive Process Models:
• The Waterfall Model,
• V-model, Incremental Process Model, Prototype Model
• Evolutionary Process Models,: RAD , Spiral
• Concurrent Model
• Agile process, Agility Principles,
• Extreme Programming (XP),
• Scrum,
• Kanban model

5. What is software?
• Computer programs and associated documentation
• Software products may be developed for a particular
customer or may be developed for a general market
• Software products may be
• Generic - developed to be sold to a range of different
customers
• Bespoke (custom) - developed for a single customer
according to their specification

6. What is software engineering?
Software engineering is an engineering discipline which
is concerned with all aspects of software production
Software engineers should
• adopt a systematic and organised approach to their work
• use appropriate tools and techniques depending on
• the problem to be solved,
• the development constraints and
• the resources available

7. Why Software Engineering?
Used w. extensive rework,
but later abandoned 20%
Used as delivered 2%
Usable w. rework 3%
9 software projects totaling $96.7 million: Where The Money Went??
Delivered, but never
successfully used
45%
Paid for, but
not delivered
30%

8. What is the difference between software engineering and
computer science?
Computer Science Software Engineering
is concerned with
 theory
 fundamentals
 the practicalities of developing
 delivering useful software

9. Nature of Software : Wear vs. Deterioration
9
Hardware
curve
Bathtub Curve

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

11. Umbrella Activities
• Software project management
• Formal technical reviews
• Software quality assurance
• Software configuration management
• Work product preparation and production
• Reusability management
• Measurement
• Risk management
11

12. SOFTWARE PROCESS MODEL

13. Software engineering models
13
“There are two ways of constructing a
software design: One way is to make it
so simple that there are obviously no
deficiencies, and the other way is to
make it so complicated that there are
no obvious deficiencies. The first
method is far more difficult.”

15. Software Process
• Process consists of activities/steps to be carried out in a
particular order
• Software process deals with both technical and
management issues
• Consists of different types of process
• Process for software development: produces software as
end-result

16. Software Process Model
The software engineers has five choices for the selection of software process
models. The models are :
• Linear Sequential Model (LSM)
• V-model
• The Prototype Model (PRM)
• The Rapid Application Development Model (RAD)
• The Incremental Model (INS)
• The Boehm Spiral Model (BMS)
• Concurrent Models
• Agile Methodology
In all models , core activities are Analysis, Design , Code, Test are common .
However their execution differs from model to model.

17. The Linear Sequential Model (LSM)
• It is one of the earliest development models.
• In this approach ,the process of software development is
represented by a sequence of steps.
• The sequential phases are what make this model linear, simple
and systematic in nature.
• Each phase must be completed before you can move to next
phase.
• This model is also known as the Waterfall Model or classical
life cycle .

18. Phases of Linear Sequential Model
Analysis
•Functional
req. doc
Designing •Req. Transform
into detail design
Coding •Implementation
Testing •Test the
system
Maintenan
ce
•Maintain System ,post
implementation

19. Advantages of Linear Sequential Model
The Linear Sequential model offers the following
advantages:
• It is easy to understand and implement.
• It prohibits skipping any phase in the sequence.
• It is ideal for small projects and when the requirements and
goals of the project are well established in advance.

20. Disadvantages of Linear Sequential Model
The following are the disadvantages using Linear sequential
model:
• The working version of the software is available to the customer
after testing. Therefore, if there is any major error during the
coding it will till end of the testing.
• Due to linear nature is any phase is not completed , the software
analyst and developers cannot proceed further.

21. Incremental Model (INM)
• The incremental model is the combination of the features
of linear sequential model and the iterative approach of the
prototyping model.
• The software is developed and delivered in small
increments and the linear sequential model is applied to
each increment.
• In an incremental model ,the prototyping methodology is
applied to each process flow of each increment.
• In the case of the incremental model , the first increment
that is delivered is the core product.
• The core product addresses the primary needs of the final
product.
• It is evaluated and reviewed by the client.

22. Incremental Model (INM)
1-1 1-2 1-4 Final System1-3
Basic process
1 Increment process S/w Solution
Design
Req.
Analysis
CodingCoding Test
Next Increment

24. This model has following advantages:
• Compared to RAD, it requires less human resources,
especially for the first few increments.
• It guarantees early delivery of the final products each
increment leads to the development of the software.
• The incremental model is therefore ideal for those projects
in which sufficient manpower is not available to meet
difficult project deadlines.
Advantages of using the Incremental
Model (INM)

25. Prototyping Model
• In this model the developer and client interact to established the
requirements of the software.
• Define the broad set of objectives.
• This is follow up by the quick design, in which the visible
elements of the software, the input and the output are designed.
• The quick design stresses the clients view of the software .
• The final product of the design is a prototype.
• The client the evaluates the prototype and provides its
recommendations and suggestion to the analyst.
• The process continues in an iterative manner until the all the
user requirements are met.

26. Phases of Prototyping Model

27. Advantages of Prototyping Model
The following are the advantages of Prototyping model:
• Due the interaction between the client and developer right from
the beginning , the objectives and requirements of the software
is well established.
• Suitable for the projects when client has not clear idea about his
requirements.
• The client can provide its input during development of the
prototype.
• The prototype serves as an aid for the development of the final
product.

28. Disadvantages of Prototyping Model
The prototyping model has the following disadvantages.
• The quality of the software development is compromised in the
rush to present a working version of the software to the client.
• The client look at the working version of the product at the
outset and expect the final version of the product to be deliver
immediately. This cause additional pressure over the developers
to adopt shortcut in order to meet the final product deadline.

29. Rapid Application Development:
• RAD is a high speed version of linear sequential model. It is
characterized by a very short development life cycle, in which
the objective is to accelerate the development.
• The RAD model follows a component based approach.
• In this approach individual components developed by different
people are assembled to develop a large software system.

30. 31

31. Phases of Rapid Application Development:
The RAD model consist of the following phases.
• Business Modeling:
In this phase, define the flow of information within the
organization, so that it covers all the functions. This helps
in clearly understand the nature, type ,source and process
of information.
• Data Modeling:
In this phase, convert the component of the information
flow into a set of data objects. Each object is referred as an
Entity.

32. Phases of Rapid Application
Development:
• Process Modeling:
In this phase, the data objects defined in the previous phase
are used to depict the flow of information . In addition adding ,
deleting, modifying and retrieving the data objects are included
in process modeling.
• Application Designing:
In this phase, the generation of the application and coding take
place.
• Testing:
In this phase, test the new program components.

33. Advantages of Using RAD Model:
The RAD has following advantages:
• Due to emphasis on rapid development , it results in the
delivery of fully functional project in short time period.
• It encourages the development of program component
reusable.

34. Disadvantages of Using RAD Model:
The RAD model has following disadvantages :
• It requires dedication and commitment on the part of the
developers as well as the client to meet the deadline..
• It is not suitable for the applications that have a high degree of
technical risk.
• It is not suitable for the large projects because they require more
manpower for creating multiple RAD groups.

35. V- Model
36

36. Advantages of the V-Model
• This is a highly-disciplined model and Phases are
completed one at a time.
• Works well for smaller projects where
requirements are very well understood.
• Simple and easy to understand and use.
• Easy to manage due to the rigidity of the model.
Each phase has specific deliverables and a
review process.
37

37. Disadvantages of the V-Model
• High risk and uncertainty.
• Not a good model for complex and object-
oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements
are at a moderate to high risk of changing.
• Once an application is in the testing stage, it is
difficult to go back and change a functionality.
• No working software is produced until late during
the life cycle.
38

38. The Spiral Model
• The spiral model developed by Boehm combines the philosophy
of INM,RAD and LSM models with the use of prototyping.
• The spiral model is recommended where the requirements and
solution call for developing full-fledge , large, complicated
system with lots of features and facilities from the scratch.
• It is used when experimenting on technology , trying out new
skills and when the user is not able to offer requirements in clear
terms.
• It emphasis at the quick development of the software, which is
released in increments.

39. The Spiral Model
This model consists of a number of activities called task
regions.
The number of task regions varies from three to six.
A spiral model consist of the following task regions.
• Communication
• Planning
• Risk analysis
• Engineering
• Construction and release
• Evaluation

40. 41

41. Advantages of Using Spiral Model
The spiral model has the following advantages :
• This model is more in tune with large real-life project
development.
• Prototyping can be applied at any level in evaluation process.
• This helps to reduce technical risk.
• It is suitable for application that can be use an object oriented
approach to develop software.

42. Disadvantages of Using Spiral Model
The spiral model has the following disadvantages:
• It requires considerable experience in risk management for the
project to be successful.
• It requires a lot of patience and time in years before this model’s
effectiveness can be assessed accurately.

43. Concurrent Model
• Early in the project the communication
activity has completed its first iteration
and exists in the awaiting changes
state.
• The modeling activity which existed in
the none state while initial
communication was completed now
makes a transition into
underdevelopment state.
• If, however, the customer indicates the
changes in requirements must be
made, the modeling activity moves from
the under development state into the
awaiting changes state.
45
Under review
Baselined
Done
Under
revision
Await ing
changes
Under
development
none
Modeling act ivit y
represents the state
of a software engineering
activity or task

44. Advantages & Disadvantages of the concurrent
development model
• This model is applicable to all types of software
development processes.
• It is easy for understanding and use.
• It gives immediate feedback from testing.
• It provides an accurate picture of the current state of a
project.
• It needs better communication between the team
members. This may not be achieved all the time.
• It requires to remember the status of the different
activities.
46

45. Agile Development
47

46. traditional approach
to software development
REQUIREMENTS
DESIGN
DEVELOPMENT
TESTING
MAINTENANCE
Waterfall Development is
another name for the more
Waterfall Development

47. Waterfall Development (contd..)
You complete one phase (e.g. design) before moving
on to the next phase (e.g. development)
You rarely aim to re-visit a ‘phase’ once it’s
completed. That means, you better get whatever
you’re doing right the first time!

48. This approach is highly risky, often more costly and
generally less efficient than Agileapproaches
REQUIREMENTS
DESIGN
DEVELOPMENT
TESTING
MAINTENANCE
Takes too long
Changes
SkippedYou don’t realize any value until
the end of the project
You leave the testing until the end
You don’t seek approval from the
stakeholders until late in the day
But…

49. AGILEIterative
AdaptableRapid
Cooperative
Quality-driven
Not a process, it's a philosophy or set of values

50. What is “Agility”?
• Effective (rapid and adaptive) response to
change
• Effective communication among all
stakeholders
• Drawing the customer onto the team
• Organizing a team so that it is in control
of the work performed
Yielding …
• Rapid, incremental delivery of software 52

51. Agile Process Models
• Extreme Programming (XP)
• Adaptive Software Development (ASD)
• Dynamic Systems Development Method
(DSDM)
• Scrum
• Crystal
• Feature Driven Development (FDD)
• Agile Modeling (AM)

52. Individuals and interactions over
processes and tools
Working software over comprehensive
documentation
Customer collaboration over
contract negotiation
Responding to change over
following a plan
Agile Manifesto

53. Agile Umbrella
Agile
Crystal
XP
Scrum
DSDM
FDDKanban
RUP
and few more…

54. Extreme Programming (XP)
• The most widely used agile process,
originally proposed by Kent Beck
• XP Planning
• Begins with the creation of “user stories”
• Agile team assesses each story and assigns a
cost
• Stories are grouped to for a deliverable
increment
• A commitment is made on delivery
date
56

55. Extreme Programming (XP)
57
unit t est
cont inuous int egrat ion
accept ance t est ing
pair
programming
Release
user st ories
values
accept ance t est crit eria
it erat ion plan
simple design
CRC cards
spike solut ions
prot ot ypes
refact oring
software increment
project velocity computed

56. Extreme Programming (XP)
• XP Design
– Follows the KIS principle
– Encourage the use of CRC cards (class responsibility collaborator)
– For difficult design problems, suggests the creation of —a design prototype
• XP Coding
– Encourages “pair programming”
• XP Testing
– All unit tests are executed daily
– “Acceptance tests” are defined by the customer and executed to assess
customer visible functionality
58

57. ScrumA light-weight agile process tool
Split your organization
into small, cross-functional, self-
organizing teams.
Split your work into a list of small, concrete deliverables.
Sort the list by priority and estimate the relative effort of each
item.
Scrum Team
Scrum Master
Product/ Project
Owner

58. Split time into short fixed-length iterations/ sprints (usually 2 – 4
weeks), with potentially shippable code demonstrated after each
iteration.
Scrum (contd..)
January May
Optimize the release plan and update priorities in
collaboration with the customer, based on insights gained by
inspecting the release after each iteration.
Optimize the process by having a retrospective after each
iteration.

59. Scrum vs. Waterfall
REQUIREMENTS
DESIGN
DEVELOPMENT
TESTING
MAINTENANCE

60. Iterative Scrum

61. Things we do in Scrum
The project/ product is described as a list of features: the backlog.
The features are described in terms of user stories.
The scrum team estimates the work associated with each story.
Features in the backlog are ranked in order of importance.
Result: a ranked and weighted list of product features, a
roadmap.
Daily scrum meeting to discuss What did you do y’day? What
will you do today? Any obstacles?
a.k.a Scrum terminologies

62. Scrum in a nutshell
So instead of a large group spending a long time building a
big thing, we have a small team spending a short time
building a small thing.
But integrating regularly to see the whole.

63. KANBANJust-in-time (JIT)
Visualize the
Work
Measure & Manage Flow
Signboard
Limit Work-In-Progress
Visual Card

64. KanbanLean approach to agile development
Similar to Scrum in the sense that you focus on features as
opposed to groups of features – however Lean takes this
one step further again.
You select, plan, develop, test and deploy one
feature (in its simplest form) before you select, plan,
develop, test and deploy the next feature.
Aim is to eliminate ‘waste’ wherever possible…

65. Kanban (contd…)
Visualize the workflow
Limit WIP (work in progress)
Split the work into pieces, write each
item on a card and put on the wall
Use named columns to illustrate where
each item is in the workflow
Assign explicit limits to how many items may be in progress at each stage
Measure the lead time (average time to complete one item,
sometimes called “cycle time”)
Optimize the process to make lead time as small and predictable as possible

66. Kanban Board Illustration - I

67. Kanban Board Illustration - II

68. Resources
• Agile 101
http://agile101.net/2009/09/08/the-difference-between-waterfall-iterative-
waterfall-scrum-and-lean-in-pictures/
• Kanban and Scrum - making the most of both
http://www.infoq.com/minibooks/kanban-scrum-minibook
• Kanban kick-start example
http://www.limitedwipsociety.org/tag/kanban-board/

69. Introduction to Software
Capability Maturity Model

70. Outline
 Why CMM matters
 What is CMM ?
 How you can use CMM
 Details about CMM
 Problems with CMM

71. Why CMM matters…
 It is the most widespread and detailed software
development model
 It is a standard for much DoD work, which is a
lot of software projects
 It is being used by many non-DoD businesses

72. Background
 Begun in 1986 by DoD to help improve
government software contractors.
 Work started at Mitre, then at Software
Engineering Institute (SEI) at Carnegie Mellon
Univ.
 Watts Humphrey was initial author, then Mark
Paulk, Bill Curtis, and others.
 Borrows heavily from general Total Quality
Management (TQM) and work of Philip Crosby.

73.  Describes an evolutionary improvement path for
software organizations from an ad hoc, immature
process to a mature, disciplined one.
 Provides guidance on how to gain control of
processes for developing and maintaining software
and how to evolve toward a culture of software
engineering and management excellence.
What is CMM?

74. What are the CMM Levels?
(The five levels of software process
maturity)
Maturity level indicates level of process capability:
 Initial
 Repeatable
 Defined
 Managed
 Optimizing

76. 80

77. What is CMM?
 In the same way, high-quality SW organizations
are different from low-quality orgs.
 CMM tries to capture and describe these
differences.
 CMM strives to create software development
organizations that are “mature”, or more mature
than before applying CMM.
 Describes five levels of SW process maturity.
 Includes lots of detail about each level

78. Summary of levels
 Level 1 – Initial. Anything at all. Ad-hoc and
chaotic. Will have some successes, but will also
have failures and badly missed deadlines.
 Level 2 – Repeatable. SW processes are
defined, documented, practiced, and people are
trained in them. Groups across an organization
may use different processes.

79. Summary of levels
 Level 3 – Defined. SW processes are consistent
and known across the whole organization.
 Level 4 – Managed. SW processes and results
are measured quantitatively, and processes are
evaluated with this data.
 Level 5 – Optimizing. Continuous process
improvement. Experimenting with new methods
and technologies. Change processes when find
something that works better.

80. Level 1: Initial
 Initial : The software process is characterized
as ad hoc, and occasionally even chaotic. Few
processes are defined, and success depends
on individual effort.
 At this level, frequently have difficulty making
commitments that the staff can meet with an orderly
process
 Products developed are often over budget and
schedule
 Wide variations in cost, schedule, functionality and
quality targets
 Capability is a characteristic of the individuals, not
of the organization

81. Level 2: Repeatable
 Basic process management processes are
established to track cost, schedule, and
functionality. The necessary process
discipline is in place to repeat earlier
successes on projects with similar
applications.
 Realistic project commitments based on results
observed on previous projects
 Software project standards are defined and
faithfully followed

82. Level 3: Defined
 The software process for both management and
engineering activities is documented, standardized, and
integrated into a standard software process for the
organization.
 All projects use an approved, tailored version of the
organization’s standard software process for developing
an maintaining software.

83. Level 4: Managed
 Detailed measures of the software process
and product quality are collected. Both the
software process and products are
quantitatively understood and controlled.
 Narrowing the variation in process performance to
fall within acceptable quantitative bounds
 When known limits are exceeded, corrective
action can be taken
 predictable
 predict trends in process and product quality

84. Level 5: Optimizing
 Continuous process improvement is enabled by
quantitative feedback from the process and from
piloting innovative ideas and technologies.
 Goal is to prevent the occurrence of defects
 Causal analysis
 Data on process effectiveness used for cost
benefit analysis of new technologies and
proposed process changes

85. Level 2 KPAs
 Requirements Management
 Establish common understanding of customer
requirements between the customer and the
software project
 Requirements is basis for planning and managing
the software project
 Not working backwards from a given release date!
 Software Project Planning
 Establish reasonable plans for performing the
software engineering activities and for managing
the software project

86. Key Process Areas(KPA)
91

87. Level 2 KPAs
 Software Project Tracking and Oversight
 Establish adequate visibility into actual progress
 Take effective actions when project’s performance
deviates significantly from planned
 Software Subcontract Management
 Manage projects outsourced to subcontractors
 Software Quality Assurance
 Provide management with appropriate visibility into
 process being used by the software projects
 work products

88. Level 2 KPAs
 Software Configuration Management
 Establish and maintain the integrity of work products
 Product baseline
 Baseline authority

89. Level 3 KPAs
 Organization Process Focus
 Establish organizational responsibility for software
process activities that improve the organization’s
overall software process capability
 Organization Process Definition
 Develop and maintain a usable set of software
process assets
 stable foundation that can be institutionalized
 basis for defining meaningful data for quantitative process
management

90. Level 3 KPAs
 Training Program
 Develop skills and knowledge so that individual
can perform their roles effectively and efficiently
 Organizational responsibility
 Needs identified by project
 Integrated Software Management
 Integrated engineering and management activities
 Engineering and management processes are
tailored from the organizational standard
processes
 Tailoring based on business environment and
project needs

91. Level 3 KPAs
 Software Product Engineering
 technical activities of the project are well defined
(SDLC)
 correct, consistent work products
 Intergroup Coordination
 Software engineering groups participate actively
with other groups
 Peer Reviews
 early defect detection and removal
 better understanding of the products
 implemented with inspections, walkthroughs, etc

92. Level 4 KPAs
 Quantitative Process Management
 control process performance quantitatively
 actual results from following a software process
 focus on identifying and correcting special causes
of variation with respect to a baseline process
 Software Quality Management
 quantitative understanding of software quality
 products
 process

93. Level 5 KPAs
 Process Change Management
 continuous process improvement to improve quality,
increase productivity, decrease cycle time
 Technology Change Management
 identify and transfer beneficial new technologies
 tools
 methods
 processes
 Defect Prevention
 causal analysis of defects to prevent recurrence

94. What are the benefits ?
 Helps forge a shared vision of what software
process improvement means for the
organization
 Defines set of priorities for addressing software
problems
 Supports measurement of process by providing
framework for performing reliable and consistent
appraisals
 Provides framework for consistency of
processes and product

95. Questions
• Describe in brief SDLC.
• Comparison of any two models.
• Short note on Agile development. (May 2018)
• What is Agility in context with software engineering?
Explain XP with suitable diagram. (May 2017)
• What is agile process and its advantages. Explain any
one agile process in detail. (May 2016)
• Write suitable application for different software models.
(May 2015)
• What is Agile methodology? Explain it with the principles
used and give example of any such software model. (May
2015)
100

96. Software Applications
101

97. 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 102

98. Hookers General Principles for Software Engineering
Practice: important underlying law
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.
103

99. 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
104

100. 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.
105

101. FAQ about software engineering
106
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 software? Good software should deliver the required functionality 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
engineering and computer science?
Computer science focuses on theory and fundamentals;
software engineering is concerned with the practicalities of
developing and delivering useful software.
What is the difference between software
engineering and system engineering?
System engineering is concerned with all aspects of computer-
based systems development including hardware, software and
process engineering. Software engineering is part of this more
general process.

102. Essential attributes of good software
107
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.