SE_Module1new.ppt

Software Engineering
An engineering approach to develop software.
• It focuses systematic and cost-effective techniques to
software development.
Software engineering is defined as the systematic,
disciplined & quantifiable approach to the
development, operation, maintenance and retirement
of software.
1

Technology Development
Pattern
Art
Craft
Engineering
Esoteric Past
Experience
Systematic Use of Past
Experience and Scientific Basis
Technolog
y
Time
Unorganized Use of
Past Experience
5

Why Study Software Engineering?
• To acquire skills to develop large software products.
• Can effectively handle complexity in a software
development problem.
• Learn techniques of:
– specification, design, interface development,
testing, project management, etc.
• To acquire skills to be a better programmer.
3

Software Crisis
4
• Software products:
-fail to meet user requirements.
-frequently crash.
-expensive.
-difficult to alter, debug, and enhance.
-often delivered late.
-use resources non-optimally.

Programs versus Software Products
11
1)Usually small in size
2)Author himself is
sole user
3)Single developer
4)Lacks proper
documentation
5)Lacks proper
User nterface
6)Adhoc(exploratory)
development
Large
Large number of
users
Team of developers
Well documented &
User-manual prepared
Well-designed
interface
Systematic
development

Emergence of Software Engineering
1) Early Computer Programming (1950s):
– Programs were being written in assembly
language.
– Programs were limited to about a few hundreds
of lines of assembly code.
– Every programmer developed his own style of
writing programs:
• according to his intuition (exploratory
programming – build and fix).
6

2) High-Level Language Programming
(Early 60s)
- High-level languages such as FORTRAN,
ALGOL, and COBOL were introduced:
 This reduced software development efforts
greatly.
- Software development style was still
exploratory.
- Typical program sizes were limited to a few
thousands of lines of source code.
7

3) Control Flow-Based Design (late 60s)
- Size and complexity of programs increased
further:
– exploratory programming style proved to be
insufficient.
- Programmers found:
– very difficult to write cost-effective and
correct programs.
– programs written by others are very difficult
to understand and maintain.
8

Control Flow-Based Design (late 60s)
• To cope up with this problem, experienced
programmers advised:
``Pay particular attention to the design of the
program's control structure.‘’
• A program's control structure indicates:
– the sequence in which the program's
instructions are executed.
9

Control Flow-Based Design (late 60s)
• To help design programs having good control
structure:
– flow charting technique was developed.
• Using flow charting technique:
– one can represent and design a program's
control structure.
• Usually one understands a program:
- by mentally simulating the program's
execution sequence.
10

Control Flow-Based Design (Late 60s)
11
• But, soon it was conclusively proved:
only three programming constructs are
sufficient to express any programming
logic:
𝗌sequence (e.g. a=0;b=5;)
𝗌selection (e.g.if(c=true) k=5 else m=5;)
𝗌iteration (e.g. while(k>0) k=j-k;)

Control-flow Based Design (Late 60s)
• Everyone accepted:
-it is possible to solve any
programming problem without
using GO TO statements.
-This formed the basis of
StructuredProgramming
methodology. 26

Structured programs
13
• Structured programs are:
-Easier to read and understand,
-easier to maintain,
-require less effort and time for
development.

4) Data Structure Oriented Design (Early 70s)
It gives more attention to the design of data
structures of a program than to the design of its
control structure.
• Techniques which emphasize
– designing the data structure
– derive program structure from it
14

Data Structure Oriented Design (Early 70s)
• Example of data structure-oriented design
technique:
– Jackson's Structured Programming(JSP)
methodology
 In JSP methodology:
 a program's data structures are first designed
using notations for
sequence, selection, and iteration.
 Then data structure design is used :
to derive the program structure.
15

5) Data Flow-Oriented Design (Late 70s)
• In Data flow-oriented technique
– the data items input to a system must first be
identified
– processing required on the data items to
produce the required outputs should be
determined.
• Data flow technique identifies:
– different processing stations (functions) in a
system
– the items (data) that flow between processing
stations.
16

Data Flow-Oriented Design (Late 70s)
• Data flow technique is a generic technique:
– can be used to model the working of any
system.
• A major advantage of the data flow technique
is its simplicity.
17

Data Flow Model of a Car
Assembly Unit
Fit
Engine
Paint
& Test
Fit
Wheels
Chassis Store Wheel Store
Engine Store DoorStore
Car
18
Partly
Assembled
Car
Assembled
Car
Chassis with
Engine
Fit
Doors

6) Object-Oriented Design (80s)
• In Object-oriented technique:
– natural objects (such as employees, pay-
roll-register, etc.) occurring in a problem are
first identified.
• Relationships among objects:
– such as composition, reference, and
inheritance are determined.
• Each object essentially acts as
– a data hiding (or data abstraction) entity.
19

Object-Oriented Design (80s)
• Object-Oriented Techniques have gained wide
acceptance:
– Simplicity
– Reuse possibilities
– Lower development time and cost
– More robust code
– Easy maintenance
20

Evolution of Design Techniques
Object-Oriented
Ad hoc
Data flow-based
Data structure- based
Control flow-
based
21

Software Process
A process is the sequence of steps executed to achieve a
goal.
To satisfy different goals while developing software, multiple
processes are needed.
Many of these do not concern software engineering, but they
have impact on software development.
These are nonsoftware processes - Business processes,
social processes, and training processes.
22

Software Process
The processes that deal with the technical and
management issues of software development are collectively
called the software process.
There are two major components in a software process—a
development process and a project management
process.
The development process specifies all the engineering
activities that need to be performed.
The management process specifies how to plan and
control these activities so that cost, schedule, quality, and
other objectives are met.
23

Software Process
 Effective development and project management
processes are the key to achieving the objectives of software
satisfying the user needs, while ensuring high productivity
and quality.
24

Software Development Life cycle
 A software life cycle is a series of identifiable stages that
a software product undergoes during its lifetime.
 Software life cycle is also called Software Development
Life Cycle (SDLC)
 The first stage of life cycle is feasibility study.
 Subsequent stages are – requirement analysis and
specification, design, coding, testing, and
maintenance.
 Each of these stages is called – life cycle phase.
25

Life Cycle Model
54
• A software life cycle model (or process
model):
- a descriptive and diagrammatic model of software life
cycle:
- identifies all the activities required for product
development,
- establishes a precedence ordering among the different
activities,
- Divides life cycle into phases.

Why Model Life Cycle ?
55
• A written description:
- forms a common understanding of activities among
the softwaredevelopers.
Help in identifying redundancies, inconsistencies,
and omissions in the development process.
- Helps in tailoring a process model for specific
projects.

Life Cycle Model (CONT.)
28
• A life cycle model:
defines entry and exit criteria
for every phase.
-
A phase is considered to be
complete only when all its exit
criteria are satisfied.

Life Cycle Model (CONT.)
29
• When a software product is being
developed by a team:
- there must be a precise understanding
among team members as to when to do
what,
- otherwise it would lead to chaos
and projectfailure.

Phases of SDLC
6/10/2020 SITTTR Kalamassery 30

Phases of Software Development
1. Feasibility study
 Aim is to determine whether it would be financially and
technically feasible to develop the product.
 It involves analysis of the problem and collection of all
relevant information related to the product
– input data items,
-Types of processing required,
- the output data
-various constraints nvolved
31

1. Feasibility study
 After data collection, this phase arrives at:
•An abstract problem definition
•Formulation of different strategies for solving problem
•Evaluation of different solution strategies
• examine benefits and shortcomings.
Based on this analysis they pick the best solution
and determine whether the solution is feasible
financially and technically. 32

2. Requirement analysis and specification
 This phase determines exact requirements of customers
and to document them properly.
1. Requirement gathering and analysis –
To collect all relevant information from the customer regarding
the product to be developed and then analysing the gathered
requirements.
The aim of requirement analysis is:
-To remove the incompleteness and inconsistencies in
requirement.
-Identify all ambiguities and contradictions in the
requirements and resolve them
33

. Requirement analysis and specification
2. Requirement specification – The user requirements are
systematically organized into a Software Requirements
Specification(SRS)document/Requirement Specification
Document (RSD),whch is the output of requrement
analysis.
3.Requirement Validation
Ensuring what have been specified in the SRS are
complete and the SRS is of good quality
34

3. Design
 Design transforms the requirements specified in SRS
document into structure suitable for implementation in
programming language.
 During this phase the software architecture is derived
from the SRS document.
Different approaches :
-The traditional design approach
-The object-oriented design approach.
35

3. Design
 The traditional design approach
Consists of two different activities;
 A structured analysis of the SRS is carried out and the
detailed structure of the problem is examined.
 The results of structured analysis are transformed into
the software design.
36

3. Design
 The object-oriented design approach
 In this technique, various objects that occur in the
problem domain and the solution domain are
identified first.
 The different relationships that exist among these
objects are identified. The object structure is further
refined to obtain the detailed design..
37

4. Coding
 It translates the software design into source code.
 This phase is also called Implementation phase.
 Each component of the design is implemented as a
program module.
 End-product of this phase is a set of program modules
that have been individually tested

38

5. Testing
The aim of testing is to identify all defects in a program.
 Testing a program involves providing a program with a set
of test inputs and observing whether the program behaves
as expected.
 Unit testing - testing each module, debugging, and
documenting to determine the correct working of all
the individual modules
 Integration testing - different modules are integrated.
After each step, the resultant module is tested.
.
39

 .System testing - System testing is designed to validate a
fully developed system to assure that it meets its requirements
laid out in the SRS document.
 System testing usually consists of three different kinds of testing
activities:
 α – testing: It is the system testing performed by the
development team.
 β – testing: It is the system testing performed by a friendly
set of customers.
 Acceptance testing: It is the system testing performed by
the customer after the product delivery to determine whether
to accept or reject the delivered product
40

6. Maintenance
 Software needs to be maintained because of the defects
remaining in the system. Developing software with zero
defect is not possible.
1. Corrective maintenance – correcting errors that were not
discovered during development.
2. Perfective maintenance – adding functionalities
according to customer’s requirement.
3. Adaptive maintenance – porting the software to work in a
new environment – new computer platform/operating
system
41

Life Cycle Models
A life cycle model explains the different activities that
needed to be carried out to develop a software product and
sequencing of these activities.
A process model specifies a general process, usually
- as a set of stages in which a project should be divided,
- the order in which the stages should be executed,
- and any other constraints and conditions on the
execution of stages.
42

Life Cycle Models
1. Waterfall Model
2. Prototyping Model
3. Iterative Model
4. Spiral Model
5. Agile Process
43

1. Waterfall Model
The simplest process model is the waterfall model, in this
the phases are organized in a linear order.
In this model, a project begins with feasibility analysis.
Upon successfully demonstrating the feasibility of a project,
the requirements analysis and project planning begins.
The design starts after the requirements analysis is
complete.
Coding begins after completion of design.
After coding completed, the code is integrated and testing
is done.
After successful completion of testing, the system is
installed.
After this, the operation and maintenance of the system
takes place. 44

The idea behind the phases is separation of tasks- each
phase deals with a distinct and separate set of tasks.
The large and complex task of building the software is
broken into smaller tasks of specifying requirements.
Separating the tasks and focusing on a few in a phase gives
a better handle to the engineers and managers in dealing
with the complexity of the problem.
46
1. Waterfall Model

The requirements analysis phase is mentioned as
“analysis and planning.”
Planning is a critical activity in software development.
A good plan is based on the requirements of the system and
should be done before later phases begin.
To clearly identify the end of a phase and the beginning of
the next, some certification mechanism has to be employed
at the end of each phase.
This is done by some verification and validation means, that
will ensure that the output of a phase is consistent with its
input. 47
1. Waterfall Model

The outputs of the earlier phases are often called work
products and are usually in the form of documents like the
requirements document or design document.
For the coding phase, the output is the code.
The following documents generally produced in each
project:
Requirements document
Project plan
Design documents (architecture, system, detailed)
Test plan and test reports
Final code
Software manuals (e.g., user, installation, etc.) 48
1. Waterfall Model

Advantages
1.Simplicity. It is conceptually straightforward and divides
the large task of building a software system into a series of
cleanly divided phases, each phase dealing with a separate
logical concern.
1.It is also easy to administer in a contractual setup - as
each phase is completed and its work product produced,
some amount of money is given by the customer to the
developing organization.
49
1. Waterfall Model

Disadvantages
1.The requirements of a system can be frozen before the
design begins.
• Determining the requirements is difficult as the user
does not even know the requirements.
1.Freezing the requirements usually requires choosing the
hardware (a part of the requirements specification).
• If the hardware is selected early, the final software
will use a hardware technology on the limit of
becoming outdated.
50
1. Waterfall Model

Disadvantages
3.It follows the “big bang” approach - the entire software is
delivered in one shot at the end.
• This imposes heavy risks, as the user does not know
until the very end what they are getting.
3.It encourages “requirements bloating”. - all requirements
must be specified at the start and only what is specified will
be delivered.
3.It is a document-driven process that requires formal
documents at the end of each phase.
51
1. Waterfall Model

 The goal of a prototyping-based development process is to
counter the first limitation of the waterfall model.
 In this, instead of freezing the requirements before design
or coding, a throwaway prototype is built to help understand
the requirements.
 This prototype is developed based on the currently known
requirements.
Development of the prototype undergoes design, coding,
and testing phases.
 By using this prototype, the client can better understand the
requirements of the desired system.
 This results in more stable requirements that change less
frequently. 52

 The development of the prototype starts when the
preliminary version of the requirements specification
document has been developed.
 After the prototype has been developed, the end users and
clients are given an opportunity to use the prototype.
 They provide feedback to the developers regarding the
prototype: what is correct, what needs to be modified, what is
missing, what is not needed, etc.
 Based on the feedback, the prototype is modified, and the
users and the clients are again allowed to use the system.
 This cycle repeats.
54

3. Iterative Model
 The iterative development process model tries to combine
the benefits of both prototyping and the waterfall models.
 In this, the software is developed in increments, each
increment adding some functional capability to the system
until the full system is implemented.
 In the first step, a simple initial implementation is done for a
subset of the overall problem.
 This subset contains some of the key aspects of the
problem that are easy to understand and implement.
55

3. Iterative Model
 A project control list is created, that contains all the tasks
that must be performed to obtain the final implementation.
 Each step consists of removing the next task from the list,
designing the implementation for the selected task, coding
and testing the implementation, performing an analysis of
the partial system obtained after this step, and updating the
list as a result of the analysis.
 These three phases are called the design phase,
implementation phase, and analysis phase.
 The process is iterated until the project control list is empty,
at which time the final implementation of the system will be
available.
56

4. Spiral Model
 The activities in this model can be organized like a spiral
that has many cycles.
The radial dimension represents the cumulative cost
incurred in accomplishing the steps done so far.
 The angular dimension represents the progress made in
completing each cycle of the spiral.
 Each cycle in the spiral is split into four sectors:
 Objective setting
 Risk Assessment and reduction
 Development and validation
 Planning
58

4. Spiral Model
Objective setting: Each cycle in the spiral begins with
- the identification of objectives for that cycle,
- the different alternatives that are possible for achieving
the objectives, and
- the constraints that exist.
Risk Assessment and Reduction: The next step is to
evaluate these different alternatives based on the objectives
and constraints.
The focus of evaluation is based on the risk awareness for
the project.
Risks reflect the chances that some of the objectives of the
project may not be met. 60

4. Spiral Model
Development and Validation:
The next step is to develop strategies that resolve the
uncertainties and risks. This step may involve activities such
as benchmarking, simulation, and prototyping.
Planning:
Next, the software is developed, keeping in mind the risks.
Finally, the next stage is planned.
The project is reviewed and a decision made whether to
continue with a further cycle of the spiral.
If it is decided to continue, plans are drawn up for the next
phase of the project 61

5. Agile Process
Agile development approaches evolved as a reaction to
documentation based processes, particularly the waterfall
approach.
Agile approaches are based on some common principles,
 Working software is the key measure of progress in a
project.
 For progress in a project, software should be developed
and delivered rapidly in small increments.
 Even late changes in the requirements should be
entertained. 62

5. Agile Process
 Face-to-face communication is preferred over
documentation.
 Continuous feedback and involvement of customer is
necessary for developing good-quality software.
 Simple design which evolves and improves with time is a
better approach than doing an elaborate design for handling
all possible scenarios.
 The release dates are decided by teams of talented
individuals.
63

SE_Module1new.ppt

Recommended

Recommended

More Related Content

Similar to SE_Module1new.ppt

Similar to SE_Module1new.ppt (20)

More from ADARSHN40

More from ADARSHN40 (10)

Recently uploaded

Recently uploaded (20)

SE_Module1new.ppt