1 18CS54 _Software Engineering and Testing _Introduction to CO PO _Syllabus and UNIT 1_PPT.pptx

SOFTWARE ENGINEERING & TESTING
COURSE CODE: 18CS54
1
INTRODUCTION TO OBJECT
ORIENTED SOFTWARE
ENGINEERING

 Software Engineering and Testing By Dr.MK Jayanthi Kannan
COURSE NAME : SOFTWARE ENGINEERING &
TESTING
COURSE CODE: 18CS54
No of Credits : 03
L-T-P : 3-0-0
Total No of Modules : 05
Total No of Contact Hours : 60 Sessions
2
Staff Room: 324- 8.
Office Hours : 8.30 AM -4 PM
Department of Computer Science
and Engineering,
FET Block.
By
Dr. M.K. Jayanthi Kannan, M.E.,MS.,MBA.,
M.Ph.D.,
Professor,
Faculty of Engineering & Technology,
JAIN Deemed To-Be University,
Bengaluru.

18CS54 SOFTWARE ENGINEERING AND TESTING By Dr.MK Jayanthi Kannan
3
COURSE NAME :SOFTWARE ENGINEERING & TESTING
COURSE CODE : 18CS54
CREDITS : 3 CREDITS
OUTLINE
 Introduction
 Learning Objectives(Course Objectives)
 Syllabus
 Learning Outcomes (Course Outcomes)
 Program Outcomes
 Program Specific Outcomes
 Course Articulation Matrix (CO-PO mapping)
 Target
 Assessment Process

COURSE SPECIFICATION
4

PREREQUISITE AND COURSE
OBJECTIVES
5

CO : COURSE OUTCOMES
6

COURSE OUTCOMES – PROGRAM OUTCOME
MAPPING ( H/M/L)
7

8
SYLLABUS
MODULE 1
NO OF HOURS : 12

SYLLABUS MODULE 2
HOURS: 9 SESSIONS
9

SYLLABUS MODULE 3
HOURS: 8 SESSIONS
10

SYLLABUS MODULE 4
11

SYLLABUS MODULE 5
12

SYLLABUS MODULE 1 TO 5 HOURS : 60 SESSIONS
13

Text Books:
14

Reference Books:
15

MODULE : 1
INTRODUCTION TO OBJECT ORIENTED SOFTWARE ENGINEERING AND
REQUIREMENTS ENGINEERING:
 Nature of the Software,
 Types of Software,
 Software Engineering Projects,
 Software Engineering Activities,
 Software Quality,
 Introduction to Object Orientation,
 Software Process Models-Waterfall Model,
 Opportunistic Model ,
 Phased Released Model, Spiral Model,
 Evolutionary Model, Concurrent Engineering Model.
 Domain Analysis, Problem Definition and Scope,
 Requirements Definition, Types of Requirements,
 Techniques for Gathering and Analyzing Requirements,
 Requirement Documents,
 Reviewing, Managing Change in Requirements.
 Time : 12 Sessions (12 Hours )
 COURSE OUTCOMES : CO1, CO2, CO3
 PROGRAM OUTCOMES : PO1, PO2,PO3,PO4,PO5,PO6,PO7,PO8,PO12
16

17
PROGRAM OUTCOMES

18
PROGRAM OUTCOMES

19

20
ASSESSMENT PROCESS
 Three Internal Assessments will be conducted which
includes 5 marks of MCQ.
 The average of best two is taken and will be scaled to 30
marks
 Semester end examination is conducted for 70 marks.
 To pass in the course as per the regulations of University,
students shall secure a minimum of 40 marks (IA and SEE
together) provided SEE marks>=28
Assessment of Course Outcome is shown below

21
SUMMARY
 Learning Objectives were set from the Faculty
perspective
 Learning Outcomes were set from the Students
perspective
 Course Articulation Matrix (CO-PO mapping)
was defined
 Target was set for the Current Academic Year for
the course Database systems
 Assessment Process was discussed

22

23

 ..1. SE&T Syllabus, LP, CDS17CS54-SET-
SYLABUS.pdf
 ..1. SE&T Syllabus, LP, CDS17CS54 _Lesson
Plan.pdf
24

COURSE OUTCOMES
CO-1 Understand the basic concept of object oriented software
engineering and software development life cycle.
CO-2 Exhibit the knowledge in software project from requirement
gathering to implementation.
CO-3 Focus on the fundamentals of modeling a software project
using UML
CO-4 Ability to apply software engineering principles and
techniques to develop large-scale software systems.
25

SOFTWARE ENGINEERING AND TESTING
MODULE 1 TOPICS
 Software Engineering Basics
 Need & Characteristics of Software
Engineering
 Nature of Software Engineering
 Types of Software
 Software Engineering Projects & Activities
 Software Quality
 Introduction to Object-Orientation
 Software Process Models
26

27
SOFTWARE & TYPES OF SOFTWARE

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

TYPES OF SOFTWARE
 Three types of software:
(a) Custom Software:
 For a specific customer/single customer.
 Software for managing the specialized finances of large
organizations.
 It accommodate customer’s particular expectations.
 Examples like:
(i) Hospitals: Maintain health record, Keep patients blood group
and billing.
(ii) Education: Maintain student admission details, Transfer
certificates, Examination records, etc.
(iii) Retail: Billing is the common use of custom software.
 Advantage: Most efficient system for specific needs.
 Dis-advantage: Time & Cost.
29

TYPES OF SOFTWARE
(b) Generic Software:
 Software readily available to the public.
 Perform many different tasks and is not limited to one particular
application.
 Sold on open market to perform the functions that many people need,
and to run on general purpose computers.
 Often called as COTS ( Commercial Off The Shelf).
 Examples like:
(i) Spreadsheet: is generic because it is useful for multiple purposes
without modification, such as a calculating tool for engineers or a
finance tool for accountants.
(ii) consider the data structure called a stack. A stack is a collection of
data, all of the same type, which implements a Last In, First Out
concept. Multiple items may be “pushed” onto the stack. When a value
is “popped” off the stack the value returned is the most recent value
“pushed” onto the stack. 30

TYPES OF SOFTWARE (CONTD.)
(c) Embedded Software:
 Built into hardware.
 Hard to change.
 Eg: washing machines, DVD players, microwave ovens and
automobiles.
31
DIFFERENCE BETWEEN CUSTOM, GENERIC & EMBEDDED SOFTWARE
Custom Generic Embedded
Number of copies in use low medium high
Total processing power devoted to
running this type of software
low high medium
Worldwide annual
development effort
high medium low

TYPES OF SOFTWARE (CONTD.)
(d) Real-Time Software:
 Must react immediately (Faster).
 Safety is taken care
 Eg: Control & monitoring systems - pushing of buttons by the user,
or a signal from a sensor
(e) Data-Processing Software:
 Used to run business.
 Accuracy & Security of data are key.
 Some software has both real-time and data processing aspects.
For example: a telephone system has to manage phone calls in
real time, but billing for those calls is a data processing activity.
32

33
SOFTWARE ENGINEERING BASICS

SOFTWARE ENGINEERING
 Software is more than just a program code.
 A program is an executable code, which serves some
computational purpose.
 Software is considered to be collection of executable
programming code, associated libraries and
documentations.
 Software, when made for a specific requirement is
called software product.
 Engineering on the other hand, is all about developing
products, using well-defined, scientific principles and
methods. 34

SOFTWARE ENGINEERING
 Software Engineering is an engineering branch associated
with development of software product using well-defined
scientific principles, methods and procedures.
 The outcome of software engineering is an efficient and
reliable software product.
35

WHAT IS SOFTWARE ENGINEERING?
 The term Software Engineering is defined as following 4
key points:
 solving customers’ problems.
 systematic development and evolution.
 large, high-quality software systems.
 cost, time and other constraints.
 The process of solving customers’ problems by the
systematic development and evolution of large, high-
quality software systems within cost, time and other
constraints.
36

SOFTWARE ENGINEERING PARADIGMS
 Software paradigms refer to the methods and steps, which
are taken while designing the software.
 Programming paradigm is a subset of Software design
paradigm which is further a subset of Software development
paradigm. 37

SOFTWARE ENGINEERING PARADIGMS (CONTD.)
 Software Development Paradigm: It includes various
researches and requirement gathering which helps the software
product to build. It consists of :
 Requirement gathering
 Software design
 Programming
 Software Design Paradigm: This paradigm is a part of
Software Development and includes :
 Design
 Maintenance
 Programming
 Programming Paradigm: This paradigm is related closely to
programming aspect of software development. This includes:
 Coding
 Testing
 Integration
38

NEED OF SOFTWARE ENGINEERING
 The need of software engineering arises because of higher rate of
change in user requirements and environment on which the
software is working.
 Large software: As the size of software become large, engineering
has to step to give it a scientific process.
 Scalability: If the software process were not based on scientific and
engineering concepts, it would be easier to re-create new software
than to scale an existing one.
 Cost: As hardware industry has shown its skills and huge
manufacturing has lower down he price of computer and electronic
hardware. But the cost of software remains high if proper process is
not adapted.
 Dynamic Nature: If the nature of software is always changing, new
enhancements need to be done in the existing one. This is where
software engineering plays a good role.
 Quality Management: Better process of software development
provides better and quality software product. 39

CHARACTERISTICS OF GOOD SOFTWARE
 A software product can be judged by what it offers and how well it
can be used.
 Any software must satisfy on the following three parameters:
(a) Operational: How well the software works based on the
measures like – Budget, Usability, Efficiency, Correctness,
Functionality, Security, Safety.
(b) Transitional: Important when software is moved from one
platform to another based on – Portability, Reusability,
Adaptability.
(c) Maintenance: How well a software is maintained itself based on
the capabilities like: Modularity, Maintainability, Flexibility,
Scalability.
40

NATURE OF SOFTWARE ENGINEERING
 Software Engineers design software systems. But the
software differs in important ways from the types of artifacts
produced by other types of engineers like:
System Software
Application Software
Engineering & Scientific Software
Embedded Software
Product-like Software
Web-applications
Artificial intelligence Software
41

NATURE OF SOFTWARE ENGINEERING (CONTD.)
 Software is largely intangible – you cant feel the shape of a
piece of software and its design can be hard to visualize. So, its
difficult for people to assess its quality and hard to understand
development effort.
 Mass-production of duplicate pieces of software – Engineers
are very concerned about the cost of each item and labour to
manufacture it.
 Untrained people can hack something together - It is too
easy for an inadequately trained software developer to create a
piece of software that is difficult to understand and modify.
 Software is easy to modify - because of its complexity but it is
very difficult to make changes that are correct.
 Software is easy to reproduce – Cost is in its development
42

STAKEHOLDERS IN SOFTWARE ENGINEERING
Four major roles:
1. Users - Those who use the software.
2. Customers - Those who pay for the software.
3. Software developers – design, testing, maintenance,
etc.
4. Development Managers – keep the team on track daily
basis, responsible for project delivery.
All four roles can be fulfilled by the same person.
43

44
SOFTWARE ENGINEERING PROJECTS

SOFTWARE ENGINEERING PROJECTS
 Software engineering work is normally organized into projects.
 For a small software system, there may only be a single team of
three or four developers working on the project.
 For a larger system, the work is usually subdivided into many
smaller projects.
 Software projects are divided into three major categories:
1) those that involve modifying an existing system;
2) those that involve starting to develop a system from scratch, and
3) those that involve building most of a new system from existing
components, while developing new software only for missing details.
45

SOFTWARE ENGINEERING PROJECTS (CONTD.)
 Most projects are:
(a) Evolutionary or maintenance projects – modifying an
existing system.
(b) Green-field projects
(c) Projects that involve building on a framework or a set of
existing components.
46

(a) Evolutionary or maintenance projects
 Corrective projects: fixing defects.
 Adaptive projects: changing the system in response to
changes in environment:
 Operating system
 Database
 Rules and regulations
 Enhancement projects: adding new features for users
 Reengineering or perfective projects: changing the system
internally so it is more maintainable.
47

(b) Green-field projects
Development of entirely new software system from scratch are less.
 New development
 The minority of projects
 not constrained by the design decisions and errors
 lot of work to build a complex system from scratch.
48

(c) Projects that involve building on a framework or a set of
existing components.
 The framework is an application that is missing some important
details.
 E.g. Specific rules of this organization.
 Some projects:
 Involve plugging together components that are:
 Already developed.
 Provide significant functionality.
 Benefit from reusing reliable software.
 Provide much of the same freedom to innovate found in
green field development.
49

50
SOFTWARE ENGINEERING ACTIVITIES

ACTIVITIES COMMON TO SOFTWARE ENGINEERING
Seven Major Activities:
(i) Requirement & Specification
(ii) Design
(iii) Modeling
(iv) Programming
(v) Quality Assurance
(vi) Deployment
(vii) Managing the Process
51

(i) Requirement & Specification:
 Includes
 Domain analysis
 Defining the problem
 Requirements gathering
 Obtaining input from as many sources as possible
 Requirements analysis
 Organizing the information
 Requirements specification
 Writing detailed instructions about how the software
should behave
52

(ii) Design:
 Deciding how the requirements should be implemented, using
the available technology
 Includes:
 Systems engineering: Deciding what should be in
hardware and what in software
 Software architecture: Dividing the system into
subsystems and deciding how the subsystems will interact
 Detailed design of the internals of a subsystem
 User interface design
 Design of databases
53

(iii) Modeling:
 Creating representations of the domain or the software
 Use case modeling
 Structural modeling
 Dynamic and behavioural modeling
(iv) Programming:
 Integral part of software engineering.
 It involves the translation of higher-level designs into
particular programming languages.
(v) Quality Assurance:
 Reviews and inspections
 Testing 54

(vi) Deployment:
 Deployment involves distributing and installing the software and
any other components of the system such as databases, special
hardware etc.
 It also involves managing the transition from any previous
system.
(vii) Managing the Process:
 Managing software projects is considered an integral part of
software engineering.
 Estimating the cost of the system.
 Planning.
55

56
SOFTWARE QUALITY

SOFTWARE QUALITY
 Software Quality is the degree of conformance to explicit or
implicit requirements and expectations.
 Explicit – clearly defined & documented.
Implicit – Not clearly defined and documented but indirectly
suggested.
57

SOFTWARE QUALITY
Software Quality Five important attributes:
 Usability: Users can learn it, fast and get their job done easily.
 Efficiency: It doesn’t waste resources such as CPU time and
memory.
 Reliability: It does what it is required to do without failing.
 Maintainability: It can be easily changed.
 Reusability: Its parts can be used in other projects, so
reprogramming is not needed.
58

SOFTWARE QUALITY (CONTD.)
 what quality means to each of the stakeholders?
59
QUALITY
SOFTWARE
Developer:
easy to design;
easy to maintain;
easy to reuse its parts
User:
easy to learn;
efficient to use;
helps get work done
Customer:
solves problems at
an acceptable cost in
terms of money paid and
resources used
Development manager:
sells more and
pleases customers
while costing less
to develop and maintain

SOFTWARE QUALITY (CONTD.)
 The different qualities can conflict
 Increasing efficiency can reduce maintainability or reusability.
 Increasing usability can reduce efficiency.
 Setting objectives for quality is a key engineering activity
 You then design to meet the objectives.
 Avoids ‘over-engineering’ which wastes money.
 Optimizing is also sometimes necessary
 E.g. obtain the highest possible reliability using a fixed budget.
 Internal Quality Criteria:
 Characterize aspects of the design of the software.
 Have an effect on the external quality attributes.
 E.g: The amount of commenting of the code.
The complexity of the code. 60

SHORT TERM VS. LONG TERM QUALITY
 Short term:
 Does the software meet the customer’s immediate needs?
 Is it sufficiently efficient for the volume of data we have today?
 Long term:
 Maintainability
 Customer’s future needs
61

DIFFICULTIES & RISKS IN SOFTWARE ENGINEERING
 Complexity and large numbers of details
 Uncertainty about technology
 Uncertainty about requirements
 Uncertainty about software engineering skills
 Constant change
 Deterioration of software design
 Political risks
62

63
INTRODUCTION TO OBJECT
ORIENTATION

INTRODUCTION TO OBJECT ORIENTATION
 The procedure of identifying software engineering
requirements and developing software specifications in
terms of a software system’s object model, which comprises
of interacting objects.
 The primary tasks in object-oriented analysis (OOA) are:−
 Identifying objects.
 Organizing the objects by creating object model diagram.
 Defining the internals of the objects, or object attributes.
 Defining the behavior of the objects, i.e., object actions.
 Describing how the objects interact.
64

BASIC CONCEPTS OF OBJECT-ORIENTED
(a) Classes
(b) Objects
(c) Inheritance
(d) Polymorphism
(e) Data Abstraction
(f) Data Encapsulation
65
OOP
Features
Objects
Classes
Inheritance
Polymorphism
Data
Abstraction
Data
Encapsulation

 User-defined data types on which objects are created.
 Objects with similar properties & methods are grouped
together to join a class.
 Example:
66
(A) CLASSES
Book
S/w
Engineering S/w Testing S/w Quality
Object 1 Object 2 Object 3
Class
Class Name:
Book
Attributes:
Book Title: String
Language: English
Author Name: String
Operations:
addbook( )
deletebook( )
updatebook( )
view( )

NAMING CLASSES
 Use capital letters
 E.g. BankAccount not bankAccount
 Use singular nouns
 Use the right level of generality
 E.g. Municipality, not City
 Make sure the name has only one meaning
 E.g. ‘bus’ has several meanings
67

 Run-time entities that may represent a person, place or any
item.
 Each object contains data & code to manipulate the data.
 Data represents the attributes of that object and functions
represent the behaviour of that object.
 Objects take up space in memory and have an associated
add like structure in C.
68
(B) OBJECTS
Data
Attributes
Functions
Data
Code

 When a program is executed the object interact by sending
messages to one another.
69
(B) OBJECTS (CONTD.)
Object 1
Data
&
Functions
Object 2
Data
&
Functions
Object 3
Data
&
Functions

Class Object
Class is a data type. Object is an instance of class.
It generate objects. It gives life to class by adding
features.
Class doesn’t occupy memory
location.
Objects occupy memory
locations.
Class cannot be manipulated
since it is not available in
memory.
Objects can be manipulated.
70
DIFFERENCE B/W CLASS & OBJECT

 Each derived class inherits the attributes of its base class & its
process is known as inheritance.
 The existing classes are called the base classes/parent
classes/super-classes, and the new classes are called the derived
classes/child classes/subclasses.
 Example:
71
(C) INHERITANCE
Class Name: Member
Attributes:
ID: long
Name: String
DOB: Date
Phone: long
addmem( )
deletemem( )
updatemem( )
view( )
Student
Rollno.:
School:
Faculty
ID.:
School:
Employee
ID.:
Division:

 Inheritance is the process by which object of one class
acquire the properties of object of another class.
 We can add additional features to an existing class without
modifying it.
 The advantage of inheritance is:
 It express commonality among class/objects.
 Allows code reusability.
 Highlights relationships.
 Helps in code organization.
72
(C) INHERITANCE (CONTD.)

ORGANIZING CLASSES INTO INHERITANCE
 Superclasses
 Contain features common to a set of subclasses.
 Inheritance hierarchies
 Show the relationships among superclasses and subclasses
 A triangle shows a generalization.
 Inheritance
 The implicit possession by all subclasses of features defined in its
superclasses.
73

EX: INHERITANCE HIERARCHY OF MATHEMATICAL OBJECTS
Rectangle
Quadrilateral
Circle
Ellipse Polygon Plane
Line
Shape3D
Shape2D
Matrix
Shape Point
MathematicalObject
74

 Poly means ‘Many’, morphism means ‘forms’.
 Representing any item in many forms.
 Two types: compile-time & run-time.
 Requires that there be multiple methods of the same name.
75
(D) POLYMORPHISM

INHERITANCE, POLYMORPHISM & VARIABLES
76

OBJECT ORIENTATED PARADIGMS
Two different paradigms:
Procedural paradigm
Object-oriented paradigm
 An approach to the solution of problems in which all
computations are performed in the context of objects.
 The objects are instances of classes, which:
 are data abstractions.
 contain procedural abstractions that operate on the objects.
 A running program can be seen as a collection of objects
collaborating to perform a given task.
77

OBJECT ORIENTATION PARADIGMS
Procedural paradigm:
 Software is organized around the notion of procedures
 Procedural abstraction
 Works as long as the data is simple
 Adding data abstractions
 Groups together the pieces of data that describe some entity
 Helps reduce the system’s complexity.
 Such as Records and structures
Object-oriented paradigm:
 Organizing procedural abstractions in the context of data
abstractions
78

A VIEW OF TWO PARADIGMS
79
Procedural paradigm Object-oriented paradigm

80
SOFTWARE PROCESS MODELS

o A simplified representation of a software process, presented from
a specific perspective.
 Examples of process perspectives:
• Workflow perspective - represents inputs, outputs and
dependencies.
 Data-flow perspective - represents data transformation
activities.
 Role/action perspective - represents the roles/activities of
the people involved in software process.
 A structured set of activities required to develop a
software system:
 Specification
 Design
 Validation
 Evolution
 A software process model is the sequence of phases for the
entire lifetime of a product.
81

(a) Waterfall Model
(b) Opportunistic Model
(c) Phased Released Model
(d) Spiral Model
(e) Evolutionary Model
(f) Concurrent Engineering Model
82

(A) WATERFALL MODEL
 Separate and distinct phases of specification and development.
83

(A) WATERFALL MODEL (CONTD.)
 Requirements gathering and analysis
 System’s services, constraints, and goals are established by
consultation with system user.
 Specification & System design
 Partitions the requirement to either hardware or software system.
 Establish the overall system architecture.
 Software design involves in identifying the fundamental software system
abstractions and their relationships.
 Implementation and unit testing
 Software design is realized as a set of programs or program units.
 Unit testing involves verifying that each unit meets its specification.
 Integration and deployment
 Individual program/s are integrated and tested as a complete system to
ensure that the product is deployed/released into the market.
 Operation and maintenance
 There are some issues which come up in the client environment. To
fix those issues, patches are released.
84

 Inflexible partitioning of the project into distinct stages.
 This makes it difficult to respond to changing customer
requirements.
 Therefore, this model is only appropriate when the
requirements are well-understood.
Waterfall model describes a process of stepwise
refinement
 Based on hardware engineering models.
 Widely used in military and aerospace industries.
85
The drawback of the waterfall model is the
difficulty of accommodating change after the
process is underway.

Advantages of waterfall model:
 Simple & Easy to understand and use.
 Easy to manage.
 Phases are processed & completed one at a time.
 Requirements are very well understood.
 Clearly defined stages.
86

Dis-advantages of waterfall model:
 Once an application is in the testing stage, it is very difficult
to go back and change something that was not well-thought
out in the concept stage.
 No working software is produced until late during the life
cycle.
 High amounts of 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.
87

 Examples: Waterfall model was used to develop enterprise
applications like:
 Customer Relationship Management (CRM) systems,
 Human Resource Management Systems (HRMS),
 Supply Chain Management Systems,
 Inventory Management Systems,
 Point of Sales (POS) systems for Retail chains etc.
 Development of Department Of Defense (DOD), military and
aircraft programs followed Waterfall model in many organizations.
 This is because of the strict standards and requirements that
have to be followed.
88

(B) OPPORTUNISTIC MODEL
 Opportunistic model is what occurs when an organization does
not follow good engineering practices.
 It does not acknowledge the importance of working out the
requirements and the design before implementing a system.
 There is no explicit recognition of the need for systematic testing
and other forms of quality assurance.
 The above problems make the cost of developing and maintaining
software very high.
 Since there are no plans, there is nothing to aim towards this
approach, so it’s a bad approach mode.
89

(C) PHASED - RELEASE MODEL
 It introduces the notion of incremental development.
 After requirements gathering and planning, the project should
be broken into separate subprojects, or phases.
 Each phase can be released to customers when ready.
 Parts of the system will be available earlier than when using a
strict waterfall approach.
 It continues to suggest that all requirements be finalized at
the start of development.
90

(C) PHASED - RELEASE MODEL (CONTD.)
91

(D) SPIRAL MODEL
 It explicitly embraces prototyping and an iterative approach to
software development.
 Start by developing a small prototype.
 Followed by a mini-waterfall process, primarily to gather
requirements.
 Then, the first prototype is reviewed.
 In subsequent loops, the project team performs further
requirements, design, implementation and review.
 The first thing to do before embarking on each new loop is risk
analysis.
 Maintenance is simply a type of on-going development.
92

(D) SPIRAL MODEL(CONTD.)
93

Advantages of Spiral model:
 High amount of risk analysis hence, avoidance of Risk is
enhanced.
 Good for large and mission-critical projects.
 Strong approval and documentation control.
 Additional Functionality can be added at a later date.
 Software is produced early in the software life cycle.
Disadvantages of Spiral model:
 Can be a costly model to use.
 Risk analysis requires highly specific expertise.
 Project’s success is highly dependent on the risk analysis phase.
 Doesn’t work well for smaller projects. 94
(D) SPIRAL MODEL(CONTD.)

(E) EVOLUTIONARY MODEL
 It shows software development as a series of hills, each
representing a separate loop of the spiral.
 Shows that loops, or releases, tend to overlap each other.
 Makes it clear that development work tends to reach a peak, at
around the time of the deadline for completion.
 Shows that each prototype or release can take
 different amounts of time to deliver,
 differing amounts of effort.
95

(E) EVOLUTIONARY MODEL (CONTD.)
96
Validation
Final
version
Development
Intermediate
versions
Specification
Initial
version
Outline
description
Concurrent
activities

 Problems
 Lack of process visibility
 Systems are often poorly structured
 Special skills (e.g. in languages for rapid prototyping) may be
required
 Applicability
 For small or medium-size interactive systems
 For parts of large systems (e.g. the user interface)
 For short-lifetime systems
97

Advantages:
 In evolutionary model, a user gets a chance to experiment
partially developed system.
 It reduces the error because the core modules get tested
thoroughly.
Disadvantages:
 Sometimes it is hard to divide the problem into several versions
that would be acceptable to the customer which can be
incrementally implemented and delivered.
98

(F) CONCURRENT ENGINEERING MODEL
 It explicitly accounts for the divide and conquer principle.
 Each team works on its own component, typically following a
spiral or evolutionary approach.
 There has to be some initial planning, and periodic integration.
99

Module 1 Part 1 : Summary
So far in this Module 1 _Part 1, we discussed the followin
concepts..
 Software Engineering Basics
 Need & Characteristics of Software Engineering
 Nature of Software Engineering
 Types of Software
 Software Engineering Projects & Activities
 Software Quality
 Introduction to Object-Orientation
 Software Process Models
100

101
Be Courageous..
“ My message especially to
young peoples is
to
have courage to think
differently, courage to
invent, to travel the
unexplored path, courage
to discover the impossible
and to conquer the
problems and succeed ”.
Dr. A.P.J. Abdul Kalam
(1931 – 2015)

102

1 18CS54 _Software Engineering and Testing _Introduction to CO PO _Syllabus and UNIT 1_PPT.pptx

Recommended

Recommended

More Related Content

Similar to 1 18CS54 _Software Engineering and Testing _Introduction to CO PO _Syllabus and UNIT 1_PPT.pptx

Similar to 1 18CS54 _Software Engineering and Testing _Introduction to CO PO _Syllabus and UNIT 1_PPT.pptx (20)

More from Jayanthi Kannan MK

More from Jayanthi Kannan MK (11)

Recently uploaded

Recently uploaded (20)

1 18CS54 _Software Engineering and Testing _Introduction to CO PO _Syllabus and UNIT 1_PPT.pptx