SoftwareEngineering.pptx

SOFTWARE ENGINEERING
Dr. R PRIYAANAND
Professor & Head
Department of Computer Applications – PG
Vels Institute of Science Technology and Advanced Studies
Chennai
1

SOFTWARE ENGINEERING
• It is the systematic, disciplined, cost effective technique for software
development.
• Software is a program or set of programs containing instructions that
provide desired functionality.
• Software, when made for a specific requirement is called software
product.
• And Engineering is the process of designing and building something
that serves a particular purpose and finds a cost-effective solution to
problems.
• 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. 2

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.
 To manage Large software - It is easier to build a wall than to a house or building,
likewise, as the size of software become large engineering has to step to give it a
scientific process.
 For more 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 Management- 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.
 To manage the Dynamic Nature- The always growing and adapting nature of
software hugely depends upon the environment in which user works. 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.
 For better Quality Management- Better process of software development provides
better and quality software product.
3

Product:
In the context of software engineering, Product includes any software
manufactured based on the customer’s request. This can be a problem
solving software or computer based system. It can also be said that this
is the result of a project.
Process:
Process is a set of sequence steps that have to be followed to create a
project. The main purpose of a process is to improve the quality of the
project. The process serves as a template that can be used through the
creation of its examples and is used to direct the project.
4

Difference between Product & process
 The main difference between a process and a product is that the
process is a set of steps that guide the project to achieve a convenient
product.
 while on the other hand, the product is the result of a project that is
manufactured by a wide variety of people.
5

Software Evolution
• The process of developing a software product using software engineering
principles and methods is referred to as software evolution.
• This includes the initial development of software and its maintenance and
updates, till desired software product is developed, which satisfies the
expected requirements.
6

7
 Evolution starts from the requirement gathering process. After
which developers create a prototype of the intended software and
show it to the users to get their feedback at the early stage of
software product development.
 The users suggest changes, on which several consecutive updates
and maintenance keep on changing too. This process changes to
the original software, till the desired software is accomplished.
 Even after the user has desired software in hand, updation of the
existing software keep going

8
 SDLC
 Software Development Life Cycle, SDLC for short, is a well-
defined, structured sequence of stages in software engineering to
develop the intended software product.
 It is a pictorial and diagrammatic representation of the software
life cycle.
 A life cycle model represents all the methods required to make a
software product through its life cycle stages.
 It also captures the structure in which these methods are to be
undertaken.

9
Need of SDLC
 Without using an exact life cycle model, the development of a
software product would not be in a systematic and disciplined
manner.
 When a team is developing a software product, there must be a
clear understanding among team representative about when
and what to do. Otherwise, it would point to chaos and project
failure.

10
Example- Suppose a software development issue is divided into
various parts and the parts are assigned to the team members.
From then on, suppose the team representative is allowed the
freedom to develop the roles assigned to them in whatever way
they like. It is possible that one representative might start writing
the code for his part, another might choose to prepare the test
documents first, and some other engineer might begin with the
design phase of the roles assigned to him. This would be one of
the perfect methods for project failure.

11
SDLC Cycle
SDLC Cycle represents the process of developing
software. SDLC framework includes the following
steps:

12
Communication
This is the first step where the user initiates the request for a desired software
product. He contacts the service provider and tries to negotiate the terms. He
submits his request to the service providing organization in writing.
Requirement Gathering
This step onwards the software development team works to carry on the
project. The team holds discussions with various stakeholders from problem
domain and tries to bring out as much information as possible on their
requirements.
Feasibility Study
After requirement gathering, the team comes up with a rough plan of software
process. At this step the team analyzes if a software can be made to fulfill all
requirements of the user and if there is any possibility of software being no
more useful. It is found out, if the project is financially, practically and
technologically feasible for the organization to take up.

13
System Analysis
System analysis includes Understanding of software product limitations,
learning system related problems or changes to be done in existing
systems beforehand, identifying and addressing the impact of project
on organization and personnel etc.
Software Design
The inputs from users and information gathered in requirement
gathering phase are the inputs of this step. The output of this step
comes in the form of two designs; logical design and physical design.
Engineers produce meta-data and data dictionaries, logical diagrams,
data-flow diagrams and in some cases pseudo codes.
Coding
This step is also known as programming phase. The implementation of
software design starts in terms of writing program code in the suitable

14
Coding
This step is also known as programming phase. The implementation of software
design starts in terms of writing program code in the suitable programming language
and developing error-free executable programs efficiently.
Testing
An estimate says that 50% of whole software development process should be tested.
Errors may ruin the software from critical level to its own removal. Software testing is
done while coding by the developers and thorough testing is conducted by testing
experts at various levels of code such as module testing, program testing, product
testing, in-house testing and testing the product at user’s end. Early discovery of errors
and their remedy is the key to reliable software.
Integration
Software may need to be integrated with the libraries, databases and other program(s).
This stage of SDLC is involved in the integration of software with outer world
entities.

15
Implementation
This means installing the software on user machines. At times, software needs
post-installation configurations at user end. Software is tested for portability and
adaptability and integration related issues are solved during implementation.
Operation and Maintenance
This phase confirms the software operation in terms of more efficiency and less
errors. If required, the users are trained on, or aided with the documentation on
how to operate the software and how to keep the software operational. The
software is maintained timely by updating the code according to the changes
taking place in user end environment or technology. This phase may face
challenges from hidden bugs and real-world unidentified problems

16
Difference between Process and product?

17
SOFTWARE DEVELOPMENT LIFE CYCLE
Software Development Life Cycle (SDLC) is a process used by the software industry
to design, develop and test high quality software. The SDLC aims to produce a high-
quality software that meets or exceeds customer expectations, reaches completion
within times and cost estimates. (Systematic approach --- Customer- service provider)

18
THE STAGES OF SDLC
Stage1: Planning and requirement analysis
Business analyst and Project organizer set up a meeting with the client to
gather all the data like what the customer wants to build, who will be the
end user, what is the objective of the product. Before creating a product, a
core understanding or knowledge of the product is very necessary.
(Startup company- in planning phase- what needed- cost-time how much I am
having- -requirement-informal communication, formal communication, -all verbal
communication done here )

19
THE STAGES OF SDLC
Stage2: Defining Requirements Once the requirement analysis is done,
the next stage is to certainly represent and document the software
requirements and get them accepted from the customer.
This is accomplished through "SRS"- Software Requirement Specification
document which contains all the product requirements to be constructed and
developed during the project life cycle.
(Idea of requirement of customer they got from planning phase- requirement of
customer, estimations of cost, staff, charges of service provide, charge customer can
give then negotiation. Then prepare a SRS (software requirement specification)-
proper documentation in written. Customer can change later but 70% around
requirement done by customer.)

20
Stage3: Designing the Software
The Design phase models the way a software application will work. Some
aspects of the design include:
Architecture – Specifies programming language, industry practices,
overall design, and use of any templates or boilerplate
User Interface – Defines the ways customers interact with the software,
and how the software responds to input
Platforms – Defines the platforms on which the software will run, such as
Apple, Android, Windows version, Linux, or even gaming consoles
Programming – Not just the programming language, but including
methods of solving problems and performing tasks in the application
Prototyping can be a part of the Design phase. A prototype is like one of
the early versions of software in the Iterative software development
model. It demonstrates a basic idea of how the application looks and
works.
(No major role of customer-DFD-Front end back end-It helps in coding- layout of -House
architecture - ERmodel in dbms-Technology-language)

21
Stage4: Developing the project
In this phase of SDLC, the actual development begins, and the
programming is built. The implementation of design begins
concerning writing code. Developers have to follow the coding
guidelines described by their management and programming tools
like compilers, interpreters, debuggers, etc. are used to develop and
implement the code.
Stage5: Testing
After the code is generated, it is tested against the requirements to
make sure that the products are solving the needs addressed and
gathered during the requirements stage.
During this stage, unit testing, integration testing, system testing,
acceptance testing are done.

22
Stage6: Deployment
In the deployment phase, the application is made available to users.
Stage7: Maintenance
Once when the client starts using the developed systems, then the real
issues come up and requirements to be solved from time to time.
This procedure where the care is taken for the developed product is
known as maintenance.

Winston Royce introduced the Waterfall Model in 1970.This model has five
phases: Requirements analysis and specification, design, implementation, and
all kind of testing like unit testing, integration and system testing, and
deployment and maintenance.
23
WATERFALL MODEL

24
When to use SDLC Waterfall Model?
Some Circumstances where the use of the Waterfall
model is most suited are:
•When the requirements are constant and not
changed regularly.
•A project is short
•Where the tools and technology used is consistent
and is not changing
•When resources are well prepared and are available
to use.

25
Advantages of Waterfall model
•This model is simple to implement also the number of
resources that are required for it is minimal.
•The requirements are simple and explicitly declared; they
remain unchanged during the entire project development.
•The start and end points for each phase is fixed, which
makes it easy to cover progress.
•The release date for the complete product, as well as its
final cost, can be determined before development.
•It gives easy to control and clarity for the customer due to
a strict reporting system.

26
Disadvantages of Waterfall model
•In this model, the risk factor is higher, so this model is not
suitable for more significant and complex projects.
•This model cannot accept the changes in requirements during
development.
•It becomes tough to go back to the phase. For example, if the
application has now shifted to the coding phase, and there is a
change in requirement, It becomes tough to go back and
change it.
•Since the testing done at a later stage, it does not allow
identifying the challenges and risks in the earlier phase, so the
risk reduction strategy is difficult to prepare.
No Feedback- No experiment-no change -Parallelism-no -1st one team then next-
ideal resource
No flexibility-rigidity High risk- House example- bedroom , kitchen all problem
come to know

27
Incremental Model
 Incremental Model is a process of software development
where requirements divided into multiple standalone modules
of the software development cycle.
 In this model, each module goes through the requirements,
design, implementation and testing phases.
 Every subsequent release of the module adds function to the
previous release. The process continues until the complete
system achieved.
1st module- then add something in 1st module which is 2nd module-
Development is not done in once -module by module development
Lock requirement phase-make SRS document then starts module1 development
Maximum customer interaction so chances of error is less- 1st module developed and delivered
to customer for use-then customer can add changes for next module
Full cost, full manpower, full machinery not involve at once
Early release product demand
When updation come new features included

28
When we use the Incremental Model?
o When the requirements are huge
o A project has a lengthy development schedule.
o When Software team are not very well skilled or trained.
o When the customer demands a quick release of the product.
o You can develop prioritized requirements first.

29
Advantage of Incremental Model
•Errors are easy to be recognized.
•Easier to test and debug
•More flexible.
•Simple to manage risk because it handled during its
iteration.
•The Client gets important functionality early.
Disadvantage of Incremental Model
•Need for good planning
•Total Cost is high.

30
ITERATIVE MODEL
 In this Model, you can start with some of the software specifications
and develop the first version of the software.
 After the first version if there is a need to change the software, then a
new version of the software is created with a new iteration.

31
The various phases of Iterative model are as follows:
1. Requirement gathering & analysis: In this phase, requirements are gathered
from customers and check by an analyst whether requirements will fulfil or not.
Analyst checks that need will achieve within budget or not. After all of this, the
software team skips to the next phase.
2. Design: In the design phase, team design the software by the different diagrams
like Data Flow diagram, activity diagram, class diagram, state transition diagram,
etc.
3. Implementation: In the implementation, requirements are written in the coding
language and transformed into computer programmes which are called Software.
4. Testing: After completing the coding phase, software testing starts using different
test methods. There are many test methods, but the most common are white box,
black box, and grey box test methods.
5. Deployment: After completing all the phases, software is deployed to its work
environment.
6. Review: In this phase, after the product deployment, review phase is performed to
check the behavior and validity of the developed product. And if there are any error
found then the process starts again from the requirement gathering.
7. Maintenance: In the maintenance phase, after deployment of the software in the
working environment there may be some bugs, some errors or new updates are
required. Maintenance involves debugging and new addition options.

32
When to use the Iterative Model?
1.When requirements are defined clearly and easy to understand.
2.When the software application is large.
3.When there is a requirement of changes in future.
Advantage(Pros) of Iterative Model:
1.Testing and debugging during smaller iteration is easy.
2.A Parallel development can plan.(parallel project can be developed)
3.It is easily acceptable to ever-changing needs of the project.(different
versions can be implemented)
4.Risks are identified and resolved during iteration.
5.Limited time spent on documentation and extra time on designing.
Disadvantage(Cons) of Iterative Model:
1.It is not suitable for smaller projects.
2.More Resources may be required.
3.Design can be changed again and again because of imperfect
requirements.
4.Requirement changes can cause over budget.
5.Project completion date not confirmed because of changing
requirements.( no of iteration not confirmed so completion date not
confirmed)

33
Evolutionary model
 Evolutionary is a combination of Iterative and Incremental
model of software development life cycle.
 Evolutionary model suggests breaking down of work into
smaller chunks, prioritizing them and then delivering those
chunks to the customer one by one.
 The number of chunks is huge and is the number of deliveries
made to the customer. The main advantage is that the
customer’s confidence increases as he constantly services from
the beginning of the project to verify and validate his
requirements. The model allows for changing requirements as
well as all work in broken down into maintainable work

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

36
Spiral Model-
1st loop cover 4 phases
Then if needed modification then 2nd loop
continues till PM satisfy that a perfect
product.
Used for large project like ISRO,NASA
1. Risk Handling-Where analysis of risk is
very important this model is used i.e. more
focus on risk
2. Radius- more means cost more
3.Angular dimension- shows progress
4. Meta model

37
Spiral Model
The spiral model, initially proposed by Boehm.
The spiral model has four phases. A software project repeatedly passes through
these phases in iterations called Spirals. Using the spiral model, the software is
developed in a series of incremental releases.
Objective setting: Each cycle in the spiral starts with the identification of purpose
for that cycle, the various alternatives that are possible for achieving the targets, and
the constraints that exists.
Risk Assessment and reduction: The next phase in the cycle is to calculate these
various alternatives based on the goals and constraints. The focus of evaluation in
this stage is located on the risk perception for the project.
Development and validation: The next phase is to develop strategies that resolve
uncertainties and risks. This process may include activities such as benchmarking,
simulation, and prototyping.
Planning: Finally, the next step is planned. The project is reviewed, and a choice
made whether to continue with a further period of the spiral. If it is determined to
keep, plans are drawn up for the next step of the project.

38
When to use Spiral Model?
•When the project is large
•When requirements are unclear and complex
•When changes may require at any time
•Large and high budget projects
Advantages
•High amount of risk analysis
•Useful for large and mission-critical projects.
Disadvantages
•Can be a costly model to use.
•Doesn't work well for smaller projects.
•Time

39
PROTOTYPE MODE
 A prototype is a toy implementation of the system.
 In many instances, the client only has a general view of what is expected
from the software product.
 In such a scenario where there is an absence of detailed information
regarding the input to the system, the processing needs, and the output
requirement, the prototyping model may be employed.

40
Steps of Prototype Model
1.Requirement Gathering and Analyst
2.Quick Decision
3.Build a Prototype
4.Assessment or User Evaluation
5.Prototype Refinement
6.Engineer Product
Advantage of Prototype Model
1.Reduce the risk of incorrect user requirement
2.Good where requirement are changing/uncommitted
3.Support early product marketing
4.Errors can be detected much earlier as the system is made side
by side.

41
Disadvantage of Prototype Model
1.An unstable/badly implemented prototype often
becomes the final product.
2.Difficult to know how long the project will last.
3.Easy to fall back into the code and fix without
proper requirement analysis, design, customer
evaluation, and feedback.
4.Prototyping tools are expensive.
5.Special tools & techniques are required to build a
prototype.
6.It is a time-consuming process.

42
Agile Model
Means move quickly –if completely develop takes more time to finish
Project divided into small projects but work parallelly
All work in same label to share knowledge freely(startups)
Parallel development
Not work more in requirement gathering, documentation, design
More focus on development and release fast
Every week customer meeting
Version are coming very fast how( laptop example)
Large project –breaks into chunks-called-iteration
Develop-test-release-feedback(major)eg.online purchase we check feedback
Iteration developed in parallel.
Large project-chunks-Release-feedback-enhance-re-release

43
 Agile methods break tasks into smaller iterations, or parts do not
directly involve long term planning. The project scope and
requirements are laid down at the beginning of the development
process.
 Plans regarding the number of iterations, the duration and the scope
of each iteration are clearly defined in advance.
 The division of the entire project into smaller parts helps to minimize
the project risk and to reduce the overall project delivery time
requirements.
 Each iteration involves a team working through a full software
development life cycle including planning, requirements analysis,
design, coding, and testing before a working product is
demonstrated to the client.

44
1.Requirements gathering: In this phase, you must define the requirements. You
should explain business opportunities and plan the time and effort needed to build
the project. Based on this information, you can evaluate technical and economic
feasibility.
2. Design the requirements: When you have identified the project, work with
stakeholders to define requirements. You can use the user flow diagram or the
high-level UML diagram to show the work of new features and show how it will
apply to your existing system.
3. Construction/ iteration: When the team defines the requirements, the work
begins. Designers and developers start working on their project, which aims to
deploy a working product. The product will undergo various stages of
improvement, so it includes simple, minimal functionality.

45
4.Testing: In this phase, the Quality Assurance team examines the product's
performance and looks for the bug.
5. Deployment: In this phase, the team issues a product for the user's work
environment.
6. Feedback: After releasing the product, the last step is feedback. In this, the team
receives feedback about the product and works through the feedback.

46
Waterfall
model
Iterative
model
Prototype
model
Incremental
model
Evolutionar
y model
Spiral model Agile
model
 Basic,
Rigid,
Inflexible,
(Start and
end user
interaction
)
 Proble
m well
unders
tood
 After
each
stage
feedba
ck can
be
given
 User
require
ment
not
cleared.
 No early
lock on
require
ment.
 High
user
involve
ment
 Reusabil
ity
 Module by
module
delivery
 But
requireme
nts locked
 Easy to
test and
debug
 Large
Project
Same as
incremental
 Differenc
e is here
require
ment
not
locked
 Risk
handling
is more,
 Not for
small
project
 No early
lock on
requirem
ent
 Flexi
ble
Advanc
ed
Parallel.
 Proj
ect
divid
ed
into
smal
l
proj
ects
 All
work
in
sam
e
label
, to

SRS(Software requirement
specification)
SRS is a description of a software system to be developed.
It lays out functional and non functional requirements of the
software to be developed.
SRS mention functional and non functional requirement so
finally we can check system match those requirement or not?
47

Functional Requirement and Non functional
requirement
 Requirements, which are related to functional/working aspect
of software fall into functional requirement category.
 Non-functional requirements are expected characteristics of
target software.(security-security check should be there),
storage-in back end how database is stored and accessed,
configuration-latest server, performance(response time), cost,
flexibility, Disaster recovery)
48

49
Properties of a good SRS document
The essential properties of a good SRS document are the
following:
Concise: The SRS report should be concise and at the same time,
unambiguous, consistent, and complete. Verbose and irrelevant
descriptions decrease readability and also increase error possibilities.
Structured: It should be well-structured. A well-structured document
is simple to understand and modify. In practice, the SRS document
undergoes several revisions to cope up with the user requirements.
Often, user requirements evolve over a period of time. Therefore, to
make the modifications to the SRS document easy, it is vital to make
the report well-structured.

50
Conceptual integrity: It should show conceptual integrity so that
the reader can merely understand it. Response to undesired events:
It should characterize acceptable responses to unwanted events.
These are called system response to exceptional conditions.
Verifiable: All requirements of the system, as documented in the
SRS document, should be correct. This means that it should be
possible to decide whether or not requirements have been met in an
implementation.

51
Requirement Engineering
The process to gather the software requirements from client,
analyze and document them is known as requirement engineering.
The goal of requirement engineering is to develop and maintain
sophisticated and descriptive ‘System Requirements Specification’
document.
Requirement Engineering Process
It is a four step process, which includes –
 Feasibility Study
 Requirement Gathering & Requirement Elicitation and
Analysis
 Software Requirement Specification
 Software Requirement Validation

52
Feasibility study
When the client approaches the organization for getting the
desired product developed, it comes up with rough idea about
what all functions the software must perform and which all
features are expected from the software.(Technically, ethically,
economically)
Referencing to this information, the analysts does a detailed study
about whether the desired system and its functionality are feasible
to develop.
The output of this phase should be a feasibility study report that
should contain adequate comments and recommendations for
management about whether or not the project should be undertaken.

53
Requirement Gathering
 If the feasibility report is positive towards undertaking the project,
next phase starts with gathering requirements from the user.
 Analysts and engineers communicate with the client and end-users
to know their ideas on what the software should provide and
which features they want the software to include.

Software Requirement Specification
• SRS is a document created by system analyst after the
requirements are collected from various stakeholders.
SRS should come up with following features:
 User Requirements are expressed in natural language.
 Technical requirements are expressed in structured language,
which is used inside the organization.
 Design description should be written.
 Format of Forms and GUI screen prints.
 Conditional and mathematical notations for DFDs etc.
54

55
Software Requirement Validation
 After requirement specifications are developed, the
requirements mentioned in this document are validated.
 User might ask for illegal, impractical solution or experts may
interpret the requirements incorrectly.
 This results in huge increase in cost if not solved in the
beginning.

56
Software Requirement Management:
Requirement management is the process of managing changing
requirements during the requirements engineering process and
system development. New requirements emerge during the process
as business needs a change, and a better understanding of the
system is developed.
The priority of requirements from different viewpoints changes
during development process.

57
ANALYSIS AND DESIGN
Analysis Modeling or Requirement modeling is a technical
representation of the system.
It acts as a link between system description and design model.
In Analysis Modelling, information, behavior, and functions of
the system are defined and translated into the architecture,
component, and interface level design in the design modeling.

58
Analysis modeling can be
1. Scenario based modeling
2. Class based modeling
3. Flow oriented modeling

59
Scenario based Modeling
The Requirement modeling with UML begins with the
creation of scenarios with the join of activity and use cases
diagram.
Scenarios- specific purpose
• If the software engineer understand how end users want to
interact with a system, the software team will be able to
properly characterize requirements and build meaningful
analysis and design models.

60
Analysis modeling with UML begins with the creation of
scenarios in the form of uses-cases, activity diagram
Use-case Diagram for a SafeHome software
In general, use cases are written first in an informal narrative
fashion
• Use case: Access camera surveillance via the Internet—
display camera views
•Actor: homeowner
• The homeowner logs onto the SafeHome Products website.
• The homeowner enters his or her user ID.
• The homeowner enters two passwords (each at least eight
characters in length).

61
• The system displays all major function buttons.
• The homeowner selects the “surveillance” from the major
function buttons.
• The homeowner selects “pick a camera.”
• The system displays the floor plan of the house.
• The homeowner selects a camera icon from the floor plan.
• The homeowner selects the “view” button.
• The system displays a viewing window that is identified by
the camera ID.
• The system displays video output within the viewing
window at one frame per second.

62
Alternative Actions • Can the actor take some other action at this
point? • Is it possible that the actor will encounter some error
condition at this point? • Is it possible that the actor will encounter
behavior invoked by some event outside the actor’s control?

63
Activity diagram
• The UML activity diagram supplements the use-case by
providing a graphical representation of the flow of interaction
within a specific scenario
• Similar to flowchart an activity diagram uses rounded
rectangles to imply a specify system functions, arrows to
represent flow through the system, decision diamonds to depict
a branching decision and solid horizontal lines to indicate that
parallel activities are occurring

65
UML Modeling
A UML diagram is a diagram based on the UML (Unified
ModelingLanguage) with the purpose of visually representing a
system along with its main actors, roles, actions, artifacts or
classes, in order to better understand, alter, maintain, or document
information about the system.
There are three important types of UML modeling.
o Structural modelling
o Behavioural modelling
o Architectural modelling

66
Structural Modeling
Structural modeling captures the static features of a system.
Structural model represents the framework for the system and this
framework is the place where all other components exist. Hence,
the class diagram, component diagram and deployment diagrams
are part of structural modeling. They all represent the elements and
the mechanism to assemble them.
The structural model never describes the dynamic behavior of the
system. Class diagram is the most widely used structural diagram.

67
.
Classes diagrams:
Class diagrams are the main building block of any object-oriented
solution. It shows the classes in a system, attributes, and operations
of each class and the relationship between each classes.
A class has three parts :
 Name at the top
 Attributes in the middle
 Operations or methods at the bottom.

68
 Objects diagrams:
Objects diagram, sometimes referred to as
Instance diagrams are very similar to class diagram .
Like class diagrams, they also show the relationship
between objects but they use real-world examples.
 Deployment diagrams:
A deployment diagram shows the hardware of your
system and the software in that hardware. Deployment
diagrams are useful when your software solution is
deployed across multiple machines with each having a
unique configuration. Below is an example deployment
diagram.

69
Behavioural Modeling: Behavioural model describes the
interaction in the system. It represents the interaction among the
structural diagrams. Behavioural modeling shows the dynamic
nature of the system. They consist of the following −
 Activity diagrams
 Interaction diagrams
 Use case diagrams
All the above show the dynamic sequence of flow in a
system.

70
 Activity diagrams:
 Activity diagrams represent workflows in a graphical way.
 They can be used to describe the business workflow or
the operational workflow of any component in a system.
Sometimes activity diagrams are used as an alternative to
State machine diagrams.
 Interaction diagrams:
 Interaction diagrams are very similar to activity diagrams.
While activity diagrams show a sequence of processes,
Interaction overview diagrams show a sequence of
interaction diagrams.

71
 Use case diagrams
 Use case diagrams give a graphic overview of the actors involved in a
system, different functions needed by those actors and how these different
functions interact.
 Architectural Modeling:
Architectural model represents the overall framework of the system. It
contains both structural and behavioral elements of the system.
Architectural model can be defined as the blueprint of the entire system.
Package diagram comes under architectural modeling.

72
Data modelling
Data modeling in software engineering is the process of creating a data model by
applying formal data model descriptions using data modeling techniques. Data
modeling is a technique for defining business requirements for a database
Data modelling is the process used to structure how data is stored, as well as
modelling relationships within the data.
The goal is to create a visual data map that accurately describes the data
structure, how data will flow through the system whilst highlighting important
data relationships.

73
Data Objects:
A data object is a representation of Composite information that must be
understood by software.
A data object can be external entity (eg.,anything that produces or consumed
information), a thing (eg., a report or a display), an occurance (eg., a telephone
call) or event(eg., an alarm), a role(eg., salesperson), an organizational unit (eg.,
accounting department), a place (eg., warehouse), or a structure (eg., a file).
A data object encapsulates data only, there is no reference within a data
objects.
For example, a person or a car can be viewed as a data object in the sense
that either can be defined in terms of a set of attributes. The description of the
data object incorporates the data object and all of its attributes.

74
Structural Modeling:
Structural modeling captures the static features of a system. Structural model represents
the framework for the system and this framework is the place where all other components
exist. Hence, the class diagram, component diagram and deployment diagrams are part of
structural modeling. They all represent the elements and the mechanism to assemble
them.
The structural model never describes the dynamic behavior of the system. Class diagram
is the most widely used structural diagram.
 Classes diagrams:
Class diagrams are the main building block of any object-oriented solution. It shows the
classes in a system, attributes, and operations of each class and the relationship between
each classes.
A class has three parts :
 Name at the top
 Attributes in the middle
 Operations or methods at the bottom.

75
Data Attributes :
Data attributes define the properties of a data object and take one of three
different characteristics. They can be used to
 Name an instance of the data objects.
 Describe the instance.
 Make reference to another instance in another table.
In addition, one or more of the attributes must be defined as an identifier, where
the identifier attributes becomes a key attributes when we want to find an instance of
the data objects.

76
The values of the identifier must be unique, although this is not a requirement. The
set of attributes that is appropriate for a given data object is determined through an
understanding of the problem context.
The attributes for car might serve well for an application that would be used by a
department of motor vehicles, but these attributes would be useless for an automatic
company that needs manufacturing control software.
To reduce the redundancy and to provide consistency in table these data objects
tables are formalized by applying a set of normalization rules that will result in a
relational model for the data. These normalization rules are:

77
 A given instance of adata objects has one and only one value for each objects.
 Attributes represent elementary data items they should contain no internal
structure.
 When more than one attributes is used to identify a data objects be sure that
descriptive and referential attributes represent a characteristics of the entire
objects and not a characteristic of some things that would be identified by only
part of the identifier.
 All non identifierattributes must represent some characteristic of the instance
named by the identifier of the data objects and describe some other attributes
that is not an identifier.

78
Relationships :
Data objects are connected to one another in different ways. Consider the two data objects,
person and car. These objects can be represented using the simple notation.

79
A connection is established between person
and car because the two objects are related.
For example,
 A person owns a car.
 A person is insured to drive a car.
The relationships own and insured to drive
define the relevant connections between
person and car. It provide important
information about the directionality of the
relationship and often reduce ambiguity
and misinterpretations.

80
What is data modeling in software engineering and Explain its types.
Data modelling is the process used to structure how data is stored, as well as
modelling relationships within the data. The goal is to create a visual data map that
accurately describes the data structure, how data will flow through the system whilst
highlighting important data relationships.
Types of Data Models:
There are mainly three different types of data models:
1. Conceptual Data models
2. Logical Data models,
3. Physical Data models.

82
1. Conceptual Data models: This Data Model defines WHAT the system contains.
This model is typically created by Business stakeholders and Data Architects. The
purpose is to organize, scope and define business concepts and rules.
2. Logical Data Model: Defines HOW the system should be implemented regardless of
the DBMS. This model is typically created by Data Architects and Business Analysts.
The purpose is to developed technical map of rules and data structures.
3. Physical Data Model: This Data Model describes HOW the system will be
implemented using a specific DBMS system. This model is typically created by DBA
and developers. The purpose is actual implementation of the database.

83
Explain about dataflow diagrams with suitable example.
Data-flow diagrams:
 Data-flow diagrams (DFDs) model a perspective of the system that is most readily
understood by users – the flow of information through the system and the activities that
process this information.
 Data-flow diagrams provide a graphical representation of the system that aims to be
accessible to computer specialist and non-specialist users alike.
 The models enable software engineers, customers and users to work together effectively
during the analysis and specification of requirements.
 Although this means that our customers are required to understand the modeling
techniques and constructs, in data-flow modeling only a limited set of constructs are used,
and the rules applied are designed to be simple and easy to follow.
 These same rules and constructs apply to all data-flow diagrams (i.e., for each of the
different software process activities in which DFDs can be used).

84
information. Processes are notated as
rectangles with three parts, such as “Order
Supplies” and “Make Payments” in the
above example.
 Data-flows — the data inputs to and
outputs from to these activities. Data-flows
are notated as named arrows, such as
“Delivery” and “Supply Order” in the
example above.
 External entities — the sources from
which information flows into the system
and the recipients of information leaving
the system. External entities are notated as
ovals, such as “Supplier” in the example
above.
 Data stores — where information is stored

85
The diagrams are supplemented by
supporting documentation including a data
dictionary, describing the contents of data-
flows and data stores; and process
definitions, which provide detailed
descriptions of the processes identified in
the data-flow diagram.

86
Data Modeling: Data modeling is the process of creating a
simplified diagram of a software system and the data
elements it contains, using text and symbols to represent the
data and how it flows.
Modeling concepts:
Data Objects :A data object can be an external entity , a thing
,an occurrence or event ,a role, an organizational unit, a place,
or a structure.
Data Attributes :Data attributes define the properties of a data
object.
They can be used to (1) name an instance of the data object,
(2) describe the instance, or (3) make reference to another
instance in another table.
In addition, one or more of the attributes must be defined as
an identifier—that is, the identifier attribute becomes a "key"
when we want to find an instance of the data object.

88
Data objects are connected to one another in different ways.
Consider the two objects person and car ,a connection is
established between them because they are related. For
example
 A person owns a car
 A person is insured to drive a car.
Cardinality and Modality
We must understand how many occurrences of object X are
related to how many occurrences of objectY.
This leads to a data modeling concept called cardinality.

90
Flow-Oriented Modeling
A Data Flow Diagram (DFD) is a traditional visual
representation of the information flows within a system. A neat
and clear DFD can depict the right amount of the system
requirement graphically.
The objective of a DFD is to show the scope and boundaries of a
system as a whole.
It may be used as a communication tool between a system analyst
and any person who plays a part in the order that acts as a starting
point for designing a system.

92
Circle: A circle (bubble) shows a process that transforms data
inputs into data outputs.
Data Flow: A curved line shows the flow of data into or out of a
process or data store.
Data Store: A set of parallel lines shows a place for the
collection of data items. A data store indicates that the data is
stored which can be used at a later stage or by the other
processes in a different order. The data store can have an
element or group of elements.
Source or Sink: Source or Sink is an external entity and acts as
a source of system inputs or sink of system outputs.

93
0-level DFD:
It is also known as a context diagram. It’s designed to be an abstraction
view, showing the system as a single process with its relationship to
external entities. It represents the entire system as a single bubble with input
and output data indicated by incoming/outgoing arrows.

94
Levels in Data Flow Diagrams (DFD)
In Software engineering DFD(data flow diagram) can be
drawn to represent the system of different levels of
abstraction.
Higher-level DFDs are partitioned into low levels-hacking
more information and functional elements.
Levels in DFD are numbered 0, 1, 2 or beyond. Here, we will
see mainly 3 levels in the data flow diagram, which are: 0-
level DFD, 1-level DFD, and 2-level DFD.

95
1-level DFD:
In 1-level DFD, the context diagram is decomposed into multiple
bubbles/processes. In this level, we highlight the main functions
of the system and breakdown the high-level process of 0-level
DFD into subprocesses.

96
2-level DFD:
2-level DFD goes one step deeper into parts of 1-level DFD. It can
be used to plan or record the specific/necessary detail about the
system’s functioning.

97
Purpose of Class Diagrams
1.Shows static structure of classifiers in a system
2.Diagram provides a basic notation for other structure
diagrams prescribed by UML
3.Helpful for developers and other team members too
4.Business Analysts can use class diagrams to model systems
from a business perspective
A UML class diagram is made up of:
•A set of classes and
•A set of relationships between classes

98
What is a Class
A description of a group of objects all with similar roles in the system, which consists of:
•Structural features (attributes) define what objects of the class "know"
• Represent the state of an object of the class
• Are descriptions of the structural or static features of a class
•Behavioral features (operations) define what objects of the class "can do"
• Define the way in which objects may interact
• Operations are descriptions of behavioral or dynamic features of a class
Class Notation
A class notation consists of three parts:
1.Class Name
1. The name of the class appears in the first partition.
2.Class Attributes
1. Attributes are shown in the second partition.
2. The attribute type is shown after the colon.
3. Attributes map onto member variables (data members) in code.
3.Class Operations (Methods)
1. Operations are shown in the third partition. They are services the class provides.
2. The return type of a method is shown after the colon at the end of the method signature.
3. The return type of method parameters is shown after the colon following the parameter
name.
4. Operations map onto class methods in code

99
Software testing
Software Testing is a method to check whether the actual
software product matches expected requirements and to ensure
that software product is Defect free. It involves execution of
software/system components using manual or automated tools to
evaluate one or more properties of interest. The purpose of
software testing is to identify errors, gaps or missing
requirements in contrast to actual requirements.

100
Principles of testing
• Testing shows the presence of defects.
• Exhaustive testing is not possible.
• Early testing.
• Defect clustering.
• Pesticide paradox.
• Testing is context-dependent.
• Absence of errors fallacy.

101
Verification and Validation
Verification:
 Verification is the process of checking that a software achieves its goal without any
bugs. It is the process to ensure whether the product that is developed is right or not. It
verifies whether the developed product fulfills the requirements that we have.
Verification is static testing.
Validation:
 Validation is the process of checking whether the software product is up to the mark
or in other words product has high level requirements. It is the process of checking the
validation of product i.e. it checks what we are developing is the right product. it is
validation of actual and expected product. Validation is the dynamic testing.

102
Testing strategies.
 Software Testing is a type of investigation to find out if there is any default or error
present in the software so that the errors can be reduced or removed to increase the
quality of the software and to check whether it fulfills the specifies requirements or
not.
 According to Glen Myers, software testing has the following objectives:
(I) The process of investigating and checking a program to find whether there is an error
or not and does it fulfill the requirements or not is called testing.
(II) When the number of errors found during the testing is high, it indicates that
the testing was good and is a sign of good test case.
(III) Finding an unknown error that’s wasn’t discovered yet is a sign of a
successful and a good test case.

103
Basis Path Testing: -
The basis path testing is same, but it is based on a White Box Testing method, that defines
test cases based on the flows or logical path that can be taken through the program. Basis
path testing involves execution of all possible blocks in a program and achieves maximum
path coverage with least number of test cases. It is a hybrid of branch testing and path
testing methods.
The objective behind basis path testing is that it defines the number of independent paths,
thus the number of test cases needed can be defined explicitly (maximizes the coverage of
each test case).

104
Here we will take a simple example, to get better idea what is basis path testing
include.
In the above example, we can see there are few conditional statements that is
executed depending on what condition it suffice.
Here there are 3 path or condition that need to be tested to get the output,
• Path 1: 1,2,3,5,6, 7
• Path 2: 1,2,4,5,6, 7
• Path 3: 1, 6, 7

105
Levels of Testing:
Testing any application or software, the test engineer needs to follow multiple
testing techniques.
In order to detect an error, we will implement software testing; therefore, all the
errors can be removed to find a product with more excellent quality.
Different Levels of Testing:
In software testing, we have four different levels of testing, which are as
discussed below:
 Unit Testing
 Integration Testing
 System Testing
 Acceptance Testing

107
Level 1: Unit Testing
Unit testing is the first level of software testing, which is used to test if software
modules are satisfying the given requirement or not.
Unit testing will help the test engineer and developers in order to understand the
base of code that makes them able to change defect causing code quickly. The
developers implement the unit.
Level 2: Integration Testing
The second level of software testing is the integration testing. The integration
testing process comes after unit testing.
It is mainly used to test the data flow from one module or component to other
modules.
In simple words, we can say that integration testing aims to evaluate the accuracy
of communication among all the modules.

108
Level 3: System Testing
The third level of software testing is system testing, which is used to test the
software's functional and non-functional requirements.
It is end-to-end testing where the testing environment is parallel to the production
environment. In the third level of software testing, we will test the application as a
whole system.
Level 4: Acceptance Testing
The last and fourth level of software testing is acceptance testing, which is used to
evaluate whether a specification or the requirements are met as per its delivery.
The software has passed through three testing levels (Unit Testing, Integration
Testing, System Testing). Some minor errors can still be identified when the end-
user uses the system in the actual scenario.
The acceptance testing is also known as User acceptance testing (UAT) and is done
by the customer before accepting the final product.

112
Debugging:
Debugging works stepwise, starting from identifying the errors, analyzing
followed by removing the errors. Whenever a software fails to deliver the
result, we need the software tester to test the application and solve it.
Here is a list of some of the widely used debuggers:
o Radare2
o WinDbg
o Valgrind

113
Benefits of Debugging:
o Debugging can immediately report an error condition whenever it occurs. It
prevents hampering the result by detecting the bugs in the earlier stage, making
software development stress-free and smooth.
o It offers relevant information related to the data structures that further helps in
easier interpretation.
o Debugging assist the developer in reducing impractical and disrupting
information.
o With debugging, the developer can easily avoid complex one-use testing code to
save time and energy in software development.

114
Steps involved in Debugging:
Following are the different steps that are involved in debugging:
1. Identify the Error: Identifying an error in a wrong may result in the wastage of time.
Thus, it is mandatory to identify the actual error.
2. Find the Error Location: Once the error is correctly discovered, you will be required
to thoroughly review the code repeatedly to locate the position of the error.
3. Analyze the Error: The third step comprises error analysis, a bottom-up approach
that starts from the location of the error followed by analyzing the code. This step
makes it easier to comprehend the errors.

115
1. Prove the Analysis: After analyzing the primary bugs, it is necessary to look
for some extra errors that may show up on the application. By incorporating
the test framework, the fourth step is used to write automated tests for such
areas.
2. Cover Lateral Damage: The fifth phase is about accumulating all of the unit
tests for the code that requires modification. As when you run these unit tests,
they must pass.
3. Fix & Validate: The last stage is the fix and validation that emphasizes fixing
the bugs followed by running all the test scripts to check whether they pass.

117
Software Configuration Management
In Software Engineering, Software Configuration Management(SCM) is a
process to systematically manage, organize, and control the changes in the
documents, codes, and other entities during the Software Development
Life Cycle. The primary goal is to increase productivity with minimal
mistakes. SCM is part of cross-disciplinary field of configuration
management and it can accurately determine who made which revision.

118
Need of Configuration management
The primary reasons for Implementing Technical Software Configuration Management
System are
 There are multiple people working on software which is continually updating
 It may be a case where multiple version, branches, authors are involved in a software
config project, and the team is geographically distributed and works concurrently
 Changes in user requirement, policy, budget, schedule need to be accommodated.
 Software should able to run on various machines and Operating Systems
 Helps to develop coordination among stakeholders
 SCM process is also beneficial to control the costs involved in making changes to a
system

119
project management concepts.
A project is a group of tasks that need to complete to reach a clear result. A project
also defines as a set of inputs and outputs which are required to achieve a goal.
Projects can vary from simple to difficult and can be operated by one person or a
hundred.
Projects usually described and approved by a project manager or team executive.
They go
beyond their expectations and objects, and it's up to the team to handle logistics and
complete the project on time. For good project development, some teams split the
project into specific tasks so they can manage responsibility and utilize team
strengths

120
Software project management is an art and discipline of planning and supervising
software
projects. It is a sub-discipline of software project management in which software
projects
planned, implemented, monitored and controlled.
It is a procedure of managing, allocating and timing resources to develop computer
software that fulfills requirements.
In software Project Management, the client and the developers need to know the length,
period and cost of the project.

121
Prerequisite of software project management
There are three needs for software project management. These are:
1. Time
2. Cost
3. Quality
It is an essential part of the software organization to deliver a quality product,
keeping the cost within the client?s budget and deliver the project as per
schedule. There are various factors, both external and internal, which may
impact this triple factor. Any of three-factor can severely affect the other two.

122
Process and project metrics:
Software Metrics
 A software metric is a measure of software characteristics which are
measurable or countable. Software metrics are valuable for many reasons,
including measuring software performance, planning work items, measuring
productivity, and many other uses.
 Within the software development process, many metrics are that are all
connected. Software metrics are similar to the four functions of management:
Planning, Organization, Control, or Improvement.

123
Classification of Software Metrics
Software metrics can be classified into two types as follows:
1. Product Metrics: These are the measures of various characteristics of the
software product. The two important software characteristics are:
1. Size and complexity of software.
2. Quality and reliability of software.
These metrics can be computed for different stages of SDLC.
2. Process Metrics: These are the measures of various characteristics of the
software development process. For example, the efficiency of fault detection.
They are used to measure the characteristics of methods, techniques, and tools that
are used for developing software.

124
Types of Metrics
Internal metrics: Internal metrics are the metrics used for measuring properties
that are viewed to be of greater importance to a software developer. For example,
Lines of Code (LOC) measure.
External metrics: External metrics are the metrics used for measuring properties
that are viewed to be of greater importance to the user, e.g., portability, reliability,
functionality, usability, etc.
Hybrid metrics: Hybrid metrics are the metrics that combine product, process, and
resource metrics. For example, cost per FP where FP stands for Function Point
Metric.
Project metrics: Project metrics are the metrics used by the project manager to
check the project's progress. Data from the past projects are used to collect various
metrics, like time and cost; these estimates are used as a base of new software.
Note that as the project proceeds, the project manager will check its progress from
time-to-time and will compare the effort, cost, and time with the original effort,
cost and time. Also understand that these metrics are used to decrease the
development costs, time efforts and risks.

125
before development is initiated, but how is this done? Several estimation procedures
have been developed and are having the following attributes in common.
1.Project scope must be established in advanced.
2.Software metrics are used as a support from which evaluation is made.
3.The project is broken into small PCs which are estimated individually.
To achieve true cost & schedule estimate, several option arise.
4.Delay estimation
5.Used symbol decomposition techniques to generate project cost and schedule
estimates.
6.Acquire one or more automated estimation tools.

126
Uses of Cost Estimation
1.During the planning stage, one needs to choose how many engineers are
required for the project and to develop a schedule.
2.In monitoring the project's progress, one needs to access whether the project is
progressing according to the procedure and takes corrective action, if necessary.
Cost Estimation Models
A model may be static or dynamic. In a static model, a single variable is taken as
a key element for calculating cost and time. In a dynamic model, all variable are
interdependent, and there is no basic variable.

127
Role of QA in Software Development?
A QA team, working on piece of software, will work with a Solution Architect to
analyse the requirements, define the parameters that determine if the product meets
their needs, and create a set of
The Importance of QA in Software Development
Saves Time and Money
The advantage of having systems and processes in place during development is that
they anticipate and prevent most bugs and flaws from developing in the first place. As
a result, the errors that do surface are relatively minor, and can be fixed easily.
On the other hand, without QA, most bugs would potentially be bigger and may only
be caught in the testing phase, or after the program was released. Fixing these bugs
after the fact would require more time, which in turn could cost more.

128
Maintains Product Quality
QA processes are designed to ensure that the software product works reliably and
is stable. In addition, there are Quality Control (QC) tests designed to test the
functionality, performance, security, usability, and more.
Furthermore, these tests also consider the fact that the user might not use the
program as it was intended. Part of this testing is to ‘idiot-proof’ the product so
that improper use does cause failure.
As a result, the final product has minimal defects and is guaranteed to work as
intended.

129
Ensures Security
Whilst a software program might perform all functions as intended, it may not
necessarily be completely secure. If there are any weakness in its defences, the
product and users’ data could be compromised.
One of the reasons QA is so important in software development is to ensure that
your product is built with security in mind, and has been tested properly to ensure
that the safeguards in place work.
Protects Your Reputation
The quality of your software can reflect on your company and brand. By releasing
a high-quality product that offers excellent features with comprehensive security,
you can build a positive reputation for your business.
This is where the importance of QA in software development is most evident. It
ensures that your product serves as a fitting brand ambassador for your business.

130
Customer Satisfaction
In order to ensure satisfied customers, your product needs to fulfil their
needs. It should have all the features required and work properly. The role
of QA is exactly that – to make sure that the software gives your customers
exactly what they expect.
The QA team would define the features of the deliverables and then work
through each step of the development process to ensure that they are being
delivered. They then check to see if the software works smoothly and
without any problems. As a result, customers get a quality product that they
are happy to use.

131
Various types of reengineering activities
Software Re-engineering is a process of software development which is done to improve
the maintainability of a software system. Re-engineering is the examination and alteration
of a system to reconstitute it in a new form. This process encompasses a combination of
sub-processes like reverse engineering, forward engineering, reconstructing etc.
Software Re-Engineering Activities:
1. Inventory Analysis:
Every software organisation should have an inventory of all the applications.
 Inventory can be nothing more than a spreadsheet model containing information that
provides a detailed description of every active application.
 By sorting this information according to business criticality, longevity, current
maintainability and other local important criteria, candidates for re-engineering appear.
 The resource can then be allocated to a candidate application for re-engineering work.

132
2. Document reconstructing:
Documentation of a system either explains how it operates or how to use it.
Documentation must be updated.
 It may not be necessary to fully document an application.
 The system is business-critical and must be fully re-documented.
3. Reverse Engineering:
Reverse engineering is a process of design recovery. Reverse engineering tools extract data,
architectural and procedural design information from an existing program.
4. Code Reconstructing:
 To accomplish code reconstructing, the source code is analysed using a reconstructing
tool. Violations of structured programming construct are noted and code is then
reconstructed.
 The resultant restructured code is reviewed and tested to ensure that no anomalies have
been introduced.

133
5. Data Restructuring:
 Data restructuring begins with a reverse engineering activity.
 Current data architecture is dissected, and the necessary data models are defined.
 Data objects and attributes are identified, and existing data structure are reviewed for
quality.
6. Forward Engineering:
Forward Engineering also called as renovation or reclamation not only for recovers
design information from existing software but uses this information to alter or
reconstitute the existing system in an effort to improve its overall quality.

SoftwareEngineering.pptx

Recommended

Recommended

More Related Content

Similar to SoftwareEngineering.pptx

Similar to SoftwareEngineering.pptx (20)

Recently uploaded

Recently uploaded (20)

SoftwareEngineering.pptx