2. Software Engineering
• Total lectures: 40
• Credit hours: 3 hrs
• Mentors:
– Pre Mid Sem: Dr. Sonali Agarwal
– Post Mid Sem: Prof. O.P. Vyas
2
3. Course Objective
• This course gives a comprehensive analysis of software
engineering techniques and the applications. Topic
includes Software Development Life Cycle, Software
processes management, requirement engineering,
analysis and design, developing and testing of software
integration, verification, validation, pattern based reuse,
reliability and project management principles,
techniques.
3
5. Software Crisis
It was in late 1960’s.
Many software projects failed.
Many software projects late, over budget, providing unreliable
software that is expensive to maintain.
Many software projects produced software which did not satisfy
the requirements of the customer.
Complexities of software projects increased as hardware
capability increased.
5
6. Software Crisis
• Larger software system is more difficult and expensive to
maintain.
• Demand of new software increased faster than ability to
generate new software.
• All the above attributes of what was called a ‘Software
Crisis’.
• So the term ‘Software Engineering’ first introduced at a
conference in late 1960’s to discuss the software crisis.
6
8. Why software engineering?
Once the need for software engineering was identified and software
engineering recognized as a discipline--
• The late 1970’s saw the widespread evolution of software
engineering principles.
• The 1980’s saw the automation of software engineering and
growth of CASE (Computer Aided Software Engineering).
8
9. Why software engineering
• The 1990’s have seen increased emphasis on the
‘management’ aspects of projects and the use of
standard quality and ‘process’ models like ISO 9001 and
the Software Engineering Institute’s Software Capability
Maturity Model (CMM).
• These models help organizations put their software
development and management processes in place
9
11. What is software Engineering?
• In1969 Fritz Bauer defined software eng. as, ‘the establishment
and use of sound engineering principles in order to obtain,
economically, software that is reliable and works efficiently on real
machines’.
• According to Boehm, software engineering involves, ‘the practical
application of scientific knowledge to the design and construction
of computer programs and the associated documentation required
developing, operating and maintaining them’
11
12. What is software Engineering?
• IEEE, in its standard 610.12-1990, defines software engineering
as:
(i) The application of a systematic, disciplined, quantifiable
approach to the development, operation and maintenance of
software; that is, the application of engineering to software.
(ii) The study of approaches as in (i).
• By combining all the above definition we can define software
engineering as, ‘Software engineering is the technological and
managerial discipline concerned with systematic production and
maintenance of software products that are developed and
modified on time and within cost estimates.’
12
14. Goal of software engineering
The primary goals of software engineering are:
• To improve the quality of the software products.
• To increase the productivity &
• To give job satisfaction to the software engineers.
14
15. Foundation of Software engineering
Software engineering is a technological discipline
distinct from, but based on the foundation of the
following disciplines:
• Computer Science
• Management Science
• Economics
• System Engineering &
• Communication Skills
15
17. The relationship of software engineering
with other disciplines
• Computer Science gives the scientific foundation to the
software as electrical engineering relies on physics.
• Management Science provides the foundation for software
project management. Since software engineering is labor
intensive activity, it requires both technical and managerial
control.
• Economics provides the foundation for resource estimation
and cost control. Since, computing system must be developed
and maintained on time and within cost estimates; thus
economics plays an important role.
17
18. The relationship of software
engineering with other disciplines
• System Engineering is the field concerned with
studying complex systems. Software is often a
component of a much larger system. For example, the
software in a factory monitoring system or the flight
software on an airplane; is just the component of more
complex system. System engineering techniques can be
applied to study of such systems
18
19. The relationship of software
engineering with other disciplines
• Good oral, written and interpersonal communication
skills are crucial for the software engineers, because
software engineering activities occur within an
organizational context, and a high degree of
communication is required among customers, managers,
software engineers, hardware engineers and other
technical workers.
19
21. Difference of s/w eng. with traditional
engineering
• Software is intangible. It has no mass, no volume, no color, no
odor--- no physical properties. Source code is merely a static
image of computer program, and while the effects produced by a
program are often observable, the program itself not.
• Software doesn’t degrade with time as hardware does. Software
failures are caused by design and implementation error, not by
degradation over time
• There is always an obscurity in the interface between software
modules. It is difficult to design a software system so that all the
control and interfaces among modules are explicit, and so that the
modules do not interact to produce unexpected side effects when
they invoked one another.
21
22. …. difference
• In classical engineering disciplines, the engineer is
equipped with tools and the mathematical maturity to
specify the properties of the product separately from
those of design. The typical software engineering relies
much more on experience and judgment rather than
mathematical formula. While experience and judgment
are necessary, formal analysis are also essential in the
practice of engineering.
22
24. The role of software engineer
The evolution of software engineering field has defined the role
the software engineer. A software engineer should have the
following qualities:
• Should be a good programmer, be well-versed in data
structures and algorithms, and be fluent in one or more
programming languages.
• Should be familiar with several design approaches, be able to
translate vague requirements and desires into precise
specifications and be able to converse with the use of a
system in terms of applications.
• Needs the ability to move among several levels of abstraction
at different stages of the project, from specific application
procedures and requirements, to abstraction for software
systems, to a specific design for system and finally to the
detailed coding level. 24
25. What are the characteristics of
software engineer
25
26. The characteristics of software engineer
• Should be able to build and use a model of the
application to guide choices of the many trade-offs that
he or she will face. The model is used to answer
questions about both the behavior of the system and its
performance.
• Needs communication skills and interpersonal skills. He
also needs the ability to schedule work both of his own
and that of others.
26
28. What is well engineered software?
If the software system does what the user wants, and
can be made to continue to do what the user wants,
it is well engineered .
• Any well engineered software system should have
the following attributes:
• Be easy to maintain
• Be reliable
• Be efficient
• Provides an appropriate user interface
The development of software must make trade-offs
between these attributes. 28
30. Distribution of software effort
The typical life-span for a typical software product is 1 to 3 years in
development and 5 to 15 years in use. The distribution of effort between
development and maintenance has been variously reported depending on
the type of software as 40/60, 30/70 and 10/90.
Maintenance:
• Corrective: Even with the best quality of software, it is likely that customer
will uncover defect in software. Corrective maintenance changes the
software to correct the defects.
• Adaptive: Over time, the original environment (CPU, OS, business rules,
external product character etc.) for which the software was developed may
change. Adaptive maintenance results in modification to the software to
accommodate the change to its environment.
• Perfective: As the software is used, the customer / user will recognize
additional function that will provide benefit. Perfective maintenance
extends the software beyond its original functional requirements.
30
32. The software product
The objective of software engineering is to produce software
products. Computer software is the product that software
engineers design and built. software products are software
systems delivered to a customer with the documentation which
describes how to install and use the system.
Software products fall into two broad classes:
• Generic products: These are stand alone systems which are
produced by a software development organizations/firms and
sold on the open market to any customer who is able to buy
them.
• Customized products: These are systems which are
commissioned by a particular customer. The software is
developed specially for that customer by some developer.
32
33. …. Software products
• Until the 1980’s, the vast majority of software systems which were
sold that were customized and specially designed systems which
run on large computers. They are expensive because all the
development cost had to be met by a single client.
• After the development of PCs, this situation has completely
changed. The PC market is totally dominated by software products
produces by companies such as Microsoft. These account for the
vast majority of software sales. These are usually relatively cheap
because their development cost is spread across hundred or
thousands of different customers.
33
35. Difference between generic and customized software
• The generic software product specifications are
produced internally by the marketing department of the
product company. They reflect what they think will sell.
They are usually flexible and non-prescriptive.
• For customized systems are often the basis for the
contract between customer and developer. They are
usually defined in detail and changes have to be
negotiated and carefully costed.
35
37. Software product attributes
The attributes of a software product are the
characteristics displayed by the product, once it is
installed and put in use. They are not the services
provided by the product. Rather, they are
concerned with the products dynamic behavior and
the use made of the product. Examples of these
attributes are therefore, efficiency, reliability,
maintainability, robustness, portability and so on.
The relative importance of these characteristics
obviously varies from system to system.
37
38. … product attributes
Product Description
characteristics
Maintainability It should be possible to evolve software to meet the changing
needs of the customer.
Dependability 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.
Efficiency Software should not make wasteful use of system resources
such as memory and processor cycle
Usability Software should have an appropriate user interface and
documentation
38
39. ..product attributes
Optimizing the above attribute is difficult as some are
exclusive. For example, providing a better user
interface may reduce system efficiency. The
relationship between cost and improvement in each of
the attribute is not linear one. Small improvement in
any of these attributes may be devoted to optimizing
particular attribute.
39
40. Importance of the course
• For the development of Successful software
– Correct identification of Requirement and Estimation is
important.
40
41. Unit 1: Introduction to Software
Engineering [ 2 Hours]
• Role of Software Engineering, Software Evolution,
Legacy system structures, Legacy system design,
Legacy System Assessment, Software Development
Life Cycle.
41
42. Unit 2: Software Process Models
[6 Hours]
• Software process models, Software Specification,
Software design and implementation, Software
validation, Automated process support, Prescriptive
Models, The Waterfall Model, Incremental Process
Models, Evolutionary Process Models, Specialized
process models, Extreme Programming, Agile
Methodology, Scrum, The Unified Process.
42
43. Unit 3: Project Management and
Requirement Engineering [ 5 Hours]
• Project Planning and Scheduling, Risk Management,
Functional and Non Functional Requirements, Users
Requirement, System Requirements, SRS Document
Generation, Feasibility Studies, Types of Feasibilities,
Requirement Analysis, Requirement Validation,
Requirement Management, Software Measurement
and Matrices.
43
44. Unit 4: System Modeling and
Prototyping. [5 Hours]
• Context models, Behavioral models, Data models,
Object models, CASE Workbenches, Prototyping in
the Software Process, Rapid Prototyping Techniques,
Interface Specification, Behavioral Specification
44
45. Unit 5: Design Engineering.
[ 6 Hours]
• Architectural Design, System Structuring, Control
Models, Modular Decomposition, Domain-Specific
Architectures, Object Oriented Design Process, Design
with Reuse, Component-Based Development,
Application Families, Design Patterns, User interface
Design Principles, User interaction, Information
presentation.
45
46. Unit 6: Verification and validation.
[6 Hours]
• Verification and Validation Planning, Software
Inspections, Clean room Software Development,
Software Testing, Black Box Testing, White Box
Testing, Integration Testing, Object-Oriented Testing,
Writing test cases, Testing tools, Configuration
Management and Version control
46
47. Recommended Books
Text Book
• Software Engineering, Ian Sommerville
• Software Engineering, A Practitioner’s Approach,
Roger S. Pressman
Reference Books
• An Integrated Approach to Software Engineering –
Pankaj Jalota
• Journals and Papers
47
48. FAQs about software engineering
• What is software?
• What is software engineering?
• What is the difference between software engineering
and computer science?
• What is the difference between software engineering
and system engineering?
• What is a software process?
• What is a software process model?
48
49. FAQs about software engineering
• What are the costs of software engineering?
• What are software engineering methods?
• What is CASE (Computer-Aided Software
Engineering)
• What are the attributes of good software?
• What are the key challenges facing software
engineering?
49
51. What is software?
• Computer programs and associated documentation such as
requirements, design models and user manuals.
• 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 e.g. PC
software such as Excel or Word.
– Custom - developed for a single customer according to their specification.
• New software can be created by developing new programs,
configuring generic software systems or reusing existing software.
51
53. What is software engineering?
• Software engineering is an engineering discipline that
is concerned with all aspects of software production.
• Software engineers should adopt a systematic and
organised approach to their work and use appropriate
tools and techniques depending on the problem to be
solved, the development constraints and the resources
available.
53
54. Software engineering
• The economies of ALL developed nations are
dependent on software.
• More and more systems are software controlled
• Software engineering is concerned with theories,
methods and tools for professional software
development.
54
55. What are the main ingredients of
Software Engineering.
55
56. What are the main ingredients of
Software Engineering
• Principle
• Methods and Techniques
• Methodology
• Tools
• How above are correlated…
56
58. What is the difference between software
engineering and computer science?
58
59. What is the difference between software
engineering and computer science?
• Computer science is concerned with theory and
fundamentals; software engineering is concerned with
the practicalities of developing and delivering useful
software.
59
60. What is the difference between software
engineering and system engineering?
60
61. 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 process concerned with
developing the software infrastructure, control,
applications and databases in the system.
System engineers are involved in system
specification, architectural design, integration and
deployment.
61
63. What is a software process?
A set of activities whose goal is the development or
evolution of software.
Generic activities in all software processes are:
◦ Specification - what the system should do and its
development constraints
◦ Development - production of the software system
◦ Validation - checking that the software is what the customer
wants
◦ Evolution - changing the software in response to changing
demands.
63
65. What is a software process model?
• A simplified representation of a software process, presented from
a specific perspective.
• Examples of process perspectives are
– Workflow perspective - sequence of activities;
– Data-flow perspective - information flow;
– Role/action perspective - who does what.
• Generic process models
– Waterfall;
– Iterative development;
– Component-based software engineering.
65
67. 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.
67
68. What are the costs of software
engineering?
Roughly 60% of costs are development costs, 40%
are testing costs. For custom software, evolution costs
often exceed development costs.
Costs vary depending on the type of system being
developed and the requirements of system attributes
such as performance and system reliability.
Distribution of costs depends on the development
model that is used.
68
69. What are software engineering
methods?
• Structured approaches to software development which include
system models, notations, rules, design advice and process
guidance.
• Model descriptions
– Descriptions of graphical models which should be produced;
• Rules
– Constraints applied to system models;
• Recommendations
– Advice on good design practice;
• Process guidance
– What activities to follow.
69
70. What is CASE (Computer-Aided
Software Engineering)
70
71. What is CASE (Computer-Aided
Software Engineering)
• Software systems that are intended to provide automated support
for software process activities.
• 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.
71
73. 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 acceptable.
• Maintainability
– Software must evolve to meet changing needs;
• Dependability
– Software must be trustworthy;
• Efficiency
– Software should not make wasteful use of system resources;
• Acceptability
– Software must accepted by the users for which it was designed. This means
it must be understandable, usable and compatible with other systems.
73
74. What are the key challenges facing
software engineering?
74
75. What are the key challenges facing
software engineering?
• Heterogeneity, delivery and trust.
• Heterogeneity
– Developing techniques for building software that can cope with
heterogeneous platforms and execution environments;
• Delivery
– Developing techniques that lead to faster delivery of software;
• Trust
– Developing techniques that demonstrate that software can be trusted by its
users.
75
77. Phases of Software Engineering
1. System identification
2. System modelling
3. System integration
4. System installation
5. System growth
6. System decommissioning
77
78. What is a system?
• A purposeful collection of inter-related components
working together to achieve some common objective.
• A system may include software, mechanical, electrical and
electronic hardware and be operated by people.
• System components are dependent on other
system components
• The properties and behaviour of system components are
inextricably inter-mingled
78
79. System categories
• Technical computer-based systems
– Systems that include hardware and software but where the
operators and operational processes are not normally
considered to be part of the system. The system is not self-
aware.
• Socio-technical systems
– Systems that include technical systems but also operational
processes and people who use and interact with the
technical system. Socio-technical systems are governed by
organisational policies and rules.
79
80. Systems engineering
• Specifying, designing, implementing, validating,
deploying and maintaining socio-technical systems.
• Concerned with the services provided by the system,
constraints on its construction and operation and the
ways in which it is used.
80
81. System modelling
• An architectural model presents an abstract view of the
sub-systems making up a system
• May include major information flows between sub-
systems
• Usually presented as a block diagram
• May identify different types of functional component in
the model
81
82. System integration
The process of putting hardware, software and
people together to make a system.
Should be tackled incrementally so that sub-systems
are integrated one at a time.
Interface problems between sub-systems are usually
found at this stage.
May be problems with uncoordinated deliveries
of system components.
82
83. System installation
• After completion, the system has to be installed in the
customer’s environment
– Environmental assumptions may be incorrect;
– May be human resistance to the introduction of
a new system;
– System may have to coexist with alternative
systems for some time;
– May be physical installation problems (e.g.
cabling problems);
– Operator training has to be identified.
83
84. System growth
• Large systems have a long lifetime. They must evolve to meet
changing requirements.
• Evolution is inherently costly
– Changes must be analysed from a technical and business perspective;
– Sub-systems interact so unanticipated problems can arise;
– There is rarely a rationale for original design decisions;
– System structure is corrupted as changes are made to it.
84
85. System decommissioning
• Taking the system out of service after its useful
lifetime.
• May require removal of materials (e.g. dangerous
chemicals) which pollute the environment
– Should be planned for in the system design by
encapsulation.
• May require data to be restructured and converted to
be used in some other system.
85
86. A Software Process is
A structured set of activities
required to develop a software
system
86
87. Ad hoc Software Development
• Developing software without planning for each phase,
and without specifying tasks, deliverables, or time
constraints.
• Relies entirely on the skills and experience of the
individual staff for performing the work.
• The software process is constantly changed or
modified as the work progresses.
87
88. Software Process Model
A Software process Model which is
“an abstract representation of a process. It presents a
description of a process from some particular
perspective.”
It provides guidelines to organize how software process
activities should be performed and in what order.
88
89. SW Process Models
• Waterfall model
• Evolutionary models
• Component-based development model
• Iterative Model
89
90. The Waterfall Model
• Oldest model, it’s been around since 1970.
• Called “Linear Sequential Model”.
• Most widely used model for SW engineering
• Documentation is produced at each stage.
90
91. Phases
1. Requirements analysis and definition
2. System and software design
3. Implementation and unit testing
4. Integration and system testing
5. Operation and maintenance
91
93. Disadvantages
• Inflexible partitioning of the project into distinct stages
makes it difficult to respond to changing customer
requirements.
• Only appropriate when the requirements are well-
understood and changes will be fairly limited during
the design process.
• The waterfall model is mostly used for large systems
engineering projects.
93
95. The Exploratory Model
Objective is to work with customers and evolve a
final system from an initial outline specification.
Should start with well-understood requirements
and add new features as proposed by the
customer.
95
96. The Exploratory Model
Concurr ent
activities
Initial
Specification version
Outline Intermedia te
description Development versions
Final
Valida tion version
96
97. The Exploratory Model
• Problems
– Lack of process visibility;
– Systems are often poorly structured;
• Applicability
– For small or medium-size interactive systems;
– For parts of large systems (e.g. the user interface);
– For short-lifetime systems.
97
98. The Prototyping Model
When a customer defines a set of general objectives
for a software but does not identify detailed input,
processing, or output requirement.
It consists of the iterating phases:
1. Requirements gathering
2. Design and build SW prototype
3. Evaluate prototype with customer
4. Refine requirements
98
100. The Prototyping Model
• Advantages
– Users get a feel for the actual system
– Developers get to build something immediately
– Specifications can be developed incrementally
• Disadvantages
– The developer may make implementation compromises in
order to get a prototype working quickly.
– The process in not visible (few documents that reflect every
version of the system)
– Systems poorly structured
100
101. Component Based Software
Engineering (CBSE)
• Based on systematic reuse where systems are
integrated from existing components.
• Process stages
– Component analysis;
– Requirements modification;
– System design with reuse;
– Development and integration.
• This approach is becoming increasingly used as
component standards have emerged.
101
102. Component Based Software
Engineering (CBSE)
Requirements Component Requirements System design
specification analy sis modification with reuse
Development Sy stem
and integ ration validation
102
103. Component Based Software
Engineering (CBSE)
• Advantages:
– Reduce amount of software to be developed
– Reduce costs and risks
– Faster delivery
• Disadvantages:
– Requirements compromises, system does not meet real
needs of users
– Limited features
103
105. The Incremental Model
Rather than deliver the system as a single delivery, the
development and delivery is broken down into
increments with each increment delivering part of the
required functionality.
User requirements are prioritised and the highest priority
requirements are included in early increments.
Once the development of an increment is started, the
requirements are frozen though requirements for later
increments can continue to evolve.
105
106. The Incremental Model
Define outline Assign requirements Design sy stem
requirements to increments architectur e
Develop sy stem Valida te Integ rate Validate
increment increment increment sy stem
Final
sy stem
Sy stem incomplete
106
107. The Incremental Model
Advantages:
• Customer value can be delivered with each increment so
system functionality is available earlier.
• Early increments act as a prototype to help elicit
requirements for later increments.
• Lower risk of overall project failure.
• The highest priority system services tend to receive the
most testing.
107
108. The Incremental Model
Disadvantages:
• Increments should be relatively small (20,000 lines of
code)
• Can be difficult to map the customer’s requirements
onto increments of the right size
• Hard to identify common functions
108
109. The Spiral Model
• Defined by Barry Boehm in his 1988 article A Spiral
Model of Software Development and Enhancement.
• Process is represented as a spiral rather than as a
sequence of activities with backtracking.
• Each loop in the spiral represents a phase in the
process.
• Suitable for large, expensive and complicated projects
109
110. The Spiral Model
Deter mine objecti ves,
Evalua te alterna tives,
alterna tives and
identify, resolv e risks
constr aints Risk
anal ysis
Risk
anal ysis
Risk
Oper a-
anal ysis
Pr ototype 3 tional
Prototype 2 protoype
Risk
REVIEW anal ysis Proto-
type 1
Requir ements plan Simula tions , models , benchmar ks
Life-cy cle plan Concept of
Oper a tion S/W
requir ements Product
design Detailed
Requir ement design
De velopment
plan valida tion Code
Unit test
Integ ra tion Design
V&V Integ ra tion
and test plan
Plan ne xt phase test
Acceptance
Service test De velop , verify
ne xt-le vel pr oduct
110
111. The Spiral Model
• Objective setting
– Specific objectives for the phase are identified.
• Risk assessment and reduction
– Risks are assessed and activities put in place to reduce the key risks.
• Development and validation
– A development model for the system is chosen which can be any of
the generic models.
• Planning
– The project is reviewed and the next phase of the spiral is planned.
111
112. The Spiral Model
• Risk driven process model
– Different risk patterns can lead to choosing different process
models
• What is a risk?
– Situations or possible events that may cause a project to fail to
meet its goal.
– Example risks:
• Experienced staff leave the project
• Hardware which is essential for the system will not be delivered on
schedule
– (more about risks in Chapter 3)
112
113. The Spiral Model
Advantages:
• Risks are explicitly assessed and resolved throughout
the process.
• Software engineers can start working on the project
earlier rather than wading through a lengthy early
design process.
113
114. The Spiral Model
Disadvantages:
• Requires highly skilled people in risk analysis and
planning
• Requires more time, and is more expensive
• Estimates of budget and time are harder to judge at
the beginning of the project since the requirements
evolve through the process
114