SlideShare ist ein Scribd-Unternehmen logo
1 von 32
Application Of
Fuzzy Logic in
Software-Engineering
M.Siddardha
P.Dinesh
Saurabh Sharma
WHAT IS SOFTWARE ENGINEERING?
 Software engineering is an engineering that is concerned with
all aspects of software production.
 Software, is any set of machine instructions to perform
specific operations.
 Software Engineering is the application of a
systematic, disciplined, quantifiable approach to
 Design
 Development
 Testing and
 Maintenance and Evolution of a SOFTWARE.
Component-Based Software
Engineering
• Most of today’s applications are large and
complex.
• An application must have some additional
characteristics like usability, flexibility, simple
installation, reusability, portability,
interoperable, etc. to fight with the
advancement in the technology and rapidly
changing requirements
Component Based Development
(CBD)
• CBD can be best described by the following
two guiding principles:
– Reuse but do not reinvent;
– Assemble pre-built components rather than
coding line by line.
• Component Based Software Development
(CBSD) is getting popular in software industry
as a new effective development paradigm.
• It emphasizes the design and construction of
software system using reusable components.
• CBSD is capable of reducing development cost
and increasing the reliability of entire
software system using components.
Component
• A component is a Reusable and self -contained
piece of software with well-specified interface
that is independent of any application.
• It is an independent executable entity that can
be made up of one or more executable objects
• Size of a component may vary from simple
functions to an entire application systems
• New components can be developed, or even
acquired from third party.
• An extra effort must be paid for the additional
functionality of the component beyond the current
application’s need, to make the component more
useful
Reusability
• It is the degree to which a component can be
re-used and reduces the software
development cost by enabling less coding and
more integration
Implementation of Fuzzy System
for Estimation of Re-Usability
• Fuzzy based model for estimation of re-
usability considers five factors as inputs and
provides a crisp value of reusability
• All inputs can be classified into fuzzy sets
• The output reusability is classified as Very
High, High, Medium, Low and Very Low.
Estimating The Reusability
• To estimate reusability of Component Based
System, following factors have been identified:
– Customizability
– Interface Complexity
– Understandability
– Portability
• Customizability is defined as the ability to
modify a component as per the application
requirement
– Better reusability can be achieved if
customizability is high
– Customizability of a component may vary from 0
to 1.
• Interface Complexity:
– As components are black box in nature, we are
unable to get the source code of these
components.
– Interface acts as a main source for
understanding, use and implementation and
finally maintenance for the component.
– Therefore for better reusability, interface
complexity should be as low as possible .
• Understandability:
– Documentation provides the ease with which a user
can learn to operate, prepare inputs for, and interpret
outputs of a system or component.
– Better reusability can be achieved if
Understandability is better
• Portability
– It is the ability of a component to be transferred from
one environment to another. It is typically concerned
with reuse of component on new platforms.
• There are many rules fed to FIM such as:
– if Customizability of components is Low, Interaction
Complexity among component is High,
Understandability is Low, Commonality is Low and
Portability is Low then it is very difficult to maintain
the system i.e. Reusability will be Very Low.
– If Customizability of components is Low, Interaction
Complexity among component is High,
Understandability is Low, Commonality is Medium and
Portability is Medium then Reusability will be Low.
– Etc..,
Requirements Engineering
• Many of the Software development phases
are highly communication-intensive activity
that involves analysts, architects, developers,
testers, business stakeholders, and end users.
• Among all the phases of software engineering,
requirements are key ingredient
• So, the focus of every development
methodology is on requirement engineering
phase.
• Software development involves roughly 50
percent computing and 50 percent
communication.
• Whenever human communication
involve, various linguistic variables come into
picture.
example
• For example, in object-oriented methods a candidate class
is generally identified by applying the rule:
• If an entity in a requirement specification is relevant and
exist autonomously then select it as a candidate class.
• This rule says "an entity is either a candidate class or not a
candidate class but not both".
• The software engineer may sometimes conclude that the
entity partially fulfils the relevance criterion, and may
prefer to define the relevance of an entity, for instance, as
substantially relevant. This definition would imply the
classification of the entity as a partial class, which is
considered as an inconsistent class definition by the current
object-oriented methods.
example
• The rule should have been:
• If an entity in a requirement specification is relevance-value
relevant and can exist autonomy value autonomous in the
application domain, then select it as a relevance-value relevant
candidate class. Here,
– relevance and autonomy are the properties (inputs)
– relevance-value and autonomy-value indicate the domains of these
properties.
– Based on these domains and rules for the relevance of candidate class,
we can get the crisp output of candidate class
• For example, relevance-value may represent the set of values
{Weakly, Slightly, Fairly, Substantially, Strongly}, and autonomy-
value may represent the set of values {Dependently, Partially
Dependently, Fully Autonomously}.
Autonomy Dependent Partially
dependent
Fully
Relevance
Weakly Weakly Weakly Weakly
Slightly Weakly Slightly Slightly
Fairly Weakly Slightly Fairly
Substantially Weakly Fairly Substantially
Strongly Slightly Fairly Strongly
Fuzzy Logic in
Size estimation.
Size estimation
• To estimate the size of an object (to
be created) using the sizes of
predefined list of objects.
Advantages of size estimation
• Size estimation can be done in
advance to make better plans
• To assist in tracking progress
• to learn and build estimating skills.
Uncertainty in estimation
• Estimation is an uncertain process
• Earlier you try to estimate, the less is the
accuracy of estimation
Steps in size estimation
1. Gather size data on previously developed
programs.
2. Divide the historical product size data into
size ranges.
3. Compare the planned product with these
prior products.
4. Based on this comparison, select the size that
seems most appropriate for the new product.
Application of size estimation.
• A file utility of 1,844 LOC.
• A file management program of 5,834 LOC.
• A personnel record keeping program of 6,845
LOC.
• A report generating package of 18,386 LOC.
• An inventory management program of 25,943
LOC.
Steps in size estimation
• log(1844) = 3.266
• log(5834) = 3.766
• log(6845)= 3.835
• log(18386)= 4.2645
• log(25943)= 4.414
We will establish 5 size ranges, as follows:
3.122 – 3.409 (1,325 to 2,566) very small
3.409 – 3.696 ( 2,566 to 4,970) small
3.696 – 3.983 (4,970 to 9,626) medium
3.983 – 4.270 (9,626 to 18,641) large
4.270 – 4.557 (18,641 to 36,104) very large.
3.266 3.553 3.840 4.127 4.4143.122 3.409 3.696 3.983 4.270 4.557
• file utility  very small
• file management program medium
• personnel record keeping programmedium
• A report generating package large
• An inventory management programvery
large
Analysis
• Suppose we want to estimate the size of a
program “Analyze marketing”
• It is a substantially more complex application
than either the file management or personnel
programs. It is not as complex as the inventory
management program and appears to have
significantly more function than the report
package. You conclude that the new program is in
the lower end of “very large,” or from 18 to 25
KLOC.
Drawbacks of size estimation
• It requires a lot of data.
• It only provides a crude sizing.
• It is not useful for programs much larger or
smaller than the historical data.
THANK YOU

Weitere ähnliche Inhalte

Was ist angesagt?

Software cost estimation
Software cost estimationSoftware cost estimation
Software cost estimationHaitham Ahmed
 
Se 381 - lec 25 - 32 - 12 may29 - program size and cost estimation models
Se 381 - lec 25 - 32 - 12 may29 - program size and cost estimation modelsSe 381 - lec 25 - 32 - 12 may29 - program size and cost estimation models
Se 381 - lec 25 - 32 - 12 may29 - program size and cost estimation modelsbabak danyal
 
Software Estimation Part I
Software Estimation Part ISoftware Estimation Part I
Software Estimation Part Isslovepk
 
Metrics for project size estimation
Metrics for project size estimationMetrics for project size estimation
Metrics for project size estimationNur Islam
 
Issues in software cost estimation
Issues in software cost estimationIssues in software cost estimation
Issues in software cost estimationKashif Aleem
 
Software cost estimation project
Software  cost estimation projectSoftware  cost estimation project
Software cost estimation projectShashank Puppala
 
Software Cost Estimation
Software Cost EstimationSoftware Cost Estimation
Software Cost EstimationMirza Obaid
 
Software Cost Estimation Techniques
Software Cost Estimation TechniquesSoftware Cost Estimation Techniques
Software Cost Estimation TechniquesSanthi thi
 
Software Estimation Technique
Software Estimation TechniqueSoftware Estimation Technique
Software Estimation TechniqueGeorge Ukkuru
 
Software Size Estimation
Software Size EstimationSoftware Size Estimation
Software Size EstimationMuhammad Asim
 
Software cost estimation
Software cost estimationSoftware cost estimation
Software cost estimationdjview
 
Software Estimation
Software EstimationSoftware Estimation
Software EstimationDinesh Singh
 
Estimation
EstimationEstimation
Estimationweebill
 
Software Project Cost Estimation
Software Project Cost EstimationSoftware Project Cost Estimation
Software Project Cost EstimationDrew Tkac
 

Was ist angesagt? (19)

Software cost estimation
Software cost estimationSoftware cost estimation
Software cost estimation
 
Se 381 - lec 25 - 32 - 12 may29 - program size and cost estimation models
Se 381 - lec 25 - 32 - 12 may29 - program size and cost estimation modelsSe 381 - lec 25 - 32 - 12 may29 - program size and cost estimation models
Se 381 - lec 25 - 32 - 12 may29 - program size and cost estimation models
 
Software Estimation Part I
Software Estimation Part ISoftware Estimation Part I
Software Estimation Part I
 
Unit 5
Unit   5Unit   5
Unit 5
 
Metrics for project size estimation
Metrics for project size estimationMetrics for project size estimation
Metrics for project size estimation
 
Issues in software cost estimation
Issues in software cost estimationIssues in software cost estimation
Issues in software cost estimation
 
Software Metrics
Software MetricsSoftware Metrics
Software Metrics
 
Ch26
Ch26Ch26
Ch26
 
Software cost estimation project
Software  cost estimation projectSoftware  cost estimation project
Software cost estimation project
 
Software Cost Estimation
Software Cost EstimationSoftware Cost Estimation
Software Cost Estimation
 
Software Cost Estimation Techniques
Software Cost Estimation TechniquesSoftware Cost Estimation Techniques
Software Cost Estimation Techniques
 
Software Estimation Technique
Software Estimation TechniqueSoftware Estimation Technique
Software Estimation Technique
 
Software cost estimation
Software cost estimationSoftware cost estimation
Software cost estimation
 
Software Size Estimation
Software Size EstimationSoftware Size Estimation
Software Size Estimation
 
Software cost estimation
Software cost estimationSoftware cost estimation
Software cost estimation
 
Software Metrics
Software MetricsSoftware Metrics
Software Metrics
 
Software Estimation
Software EstimationSoftware Estimation
Software Estimation
 
Estimation
EstimationEstimation
Estimation
 
Software Project Cost Estimation
Software Project Cost EstimationSoftware Project Cost Estimation
Software Project Cost Estimation
 

Ähnlich wie Software engineering

Welingkar First Year Project- ProjectWeLike
Welingkar First Year Project- ProjectWeLikeWelingkar First Year Project- ProjectWeLike
Welingkar First Year Project- ProjectWeLikePrinceTrivedi4
 
Component based development | what, why and how
Component based development | what, why and howComponent based development | what, why and how
Component based development | what, why and howRakesh Kumar Jha
 
Ncerc rlmca202 adm m4 ssm
Ncerc rlmca202 adm m4 ssmNcerc rlmca202 adm m4 ssm
Ncerc rlmca202 adm m4 ssmssmarar
 
Introduction to Software Engineering
Introduction to Software EngineeringIntroduction to Software Engineering
Introduction to Software EngineeringSaqib Raza
 
Software Architecture
Software ArchitectureSoftware Architecture
Software ArchitectureAhmed Misbah
 
Lect5 improving software economics
Lect5 improving software economicsLect5 improving software economics
Lect5 improving software economicsmeena466141
 
UNIT-4design-concepts-se-pressman-ppt.PPT
UNIT-4design-concepts-se-pressman-ppt.PPTUNIT-4design-concepts-se-pressman-ppt.PPT
UNIT-4design-concepts-se-pressman-ppt.PPTmalathijanapati1
 
Software design for scientific applications
Software design for scientific applicationsSoftware design for scientific applications
Software design for scientific applicationsPriyanka Lal
 
Design principles & quality factors
Design principles & quality factorsDesign principles & quality factors
Design principles & quality factorsAalia Barbe
 
Designing and documenting software architecture unit 5
Designing and documenting software architecture unit 5Designing and documenting software architecture unit 5
Designing and documenting software architecture unit 5Sudarshan Dhondaley
 
Unit 8 software quality and matrices
Unit 8 software quality and matricesUnit 8 software quality and matrices
Unit 8 software quality and matricesPreeti Mishra
 
Software process models
Software process modelsSoftware process models
Software process modelsMalik WaQas
 
Agile Software Development Life Cycle
Agile Software Development Life CycleAgile Software Development Life Cycle
Agile Software Development Life CycleUTKARSHSRIVASTAVA235
 
Principles: Usability, Architecture, Design
Principles:  Usability, Architecture, DesignPrinciples:  Usability, Architecture, Design
Principles: Usability, Architecture, DesignJohn Liebenau
 
#ATAGTR2020 Presentation - Microservices – Explored
#ATAGTR2020 Presentation - Microservices – Explored#ATAGTR2020 Presentation - Microservices – Explored
#ATAGTR2020 Presentation - Microservices – ExploredAgile Testing Alliance
 
Software architecture
Software architectureSoftware architecture
Software architectureUri Meirav
 
Software maintenance real world maintenance cost
Software maintenance real world maintenance costSoftware maintenance real world maintenance cost
Software maintenance real world maintenance costmalathieswaran29
 
Software Quality Factors-Non Functional Rq.pptx
Software Quality Factors-Non Functional Rq.pptxSoftware Quality Factors-Non Functional Rq.pptx
Software Quality Factors-Non Functional Rq.pptxsingbling
 

Ähnlich wie Software engineering (20)

Welingkar First Year Project- ProjectWeLike
Welingkar First Year Project- ProjectWeLikeWelingkar First Year Project- ProjectWeLike
Welingkar First Year Project- ProjectWeLike
 
Component based development | what, why and how
Component based development | what, why and howComponent based development | what, why and how
Component based development | what, why and how
 
Ncerc rlmca202 adm m4 ssm
Ncerc rlmca202 adm m4 ssmNcerc rlmca202 adm m4 ssm
Ncerc rlmca202 adm m4 ssm
 
Introduction to Software Engineering
Introduction to Software EngineeringIntroduction to Software Engineering
Introduction to Software Engineering
 
Software Architecture
Software ArchitectureSoftware Architecture
Software Architecture
 
Lect5 improving software economics
Lect5 improving software economicsLect5 improving software economics
Lect5 improving software economics
 
UNIT-4design-concepts-se-pressman-ppt.PPT
UNIT-4design-concepts-se-pressman-ppt.PPTUNIT-4design-concepts-se-pressman-ppt.PPT
UNIT-4design-concepts-se-pressman-ppt.PPT
 
Software design for scientific applications
Software design for scientific applicationsSoftware design for scientific applications
Software design for scientific applications
 
sdlc.pptx
sdlc.pptxsdlc.pptx
sdlc.pptx
 
Design principles & quality factors
Design principles & quality factorsDesign principles & quality factors
Design principles & quality factors
 
Designing and documenting software architecture unit 5
Designing and documenting software architecture unit 5Designing and documenting software architecture unit 5
Designing and documenting software architecture unit 5
 
Unit 8 software quality and matrices
Unit 8 software quality and matricesUnit 8 software quality and matrices
Unit 8 software quality and matrices
 
Software process models
Software process modelsSoftware process models
Software process models
 
Requirement engineering
Requirement engineeringRequirement engineering
Requirement engineering
 
Agile Software Development Life Cycle
Agile Software Development Life CycleAgile Software Development Life Cycle
Agile Software Development Life Cycle
 
Principles: Usability, Architecture, Design
Principles:  Usability, Architecture, DesignPrinciples:  Usability, Architecture, Design
Principles: Usability, Architecture, Design
 
#ATAGTR2020 Presentation - Microservices – Explored
#ATAGTR2020 Presentation - Microservices – Explored#ATAGTR2020 Presentation - Microservices – Explored
#ATAGTR2020 Presentation - Microservices – Explored
 
Software architecture
Software architectureSoftware architecture
Software architecture
 
Software maintenance real world maintenance cost
Software maintenance real world maintenance costSoftware maintenance real world maintenance cost
Software maintenance real world maintenance cost
 
Software Quality Factors-Non Functional Rq.pptx
Software Quality Factors-Non Functional Rq.pptxSoftware Quality Factors-Non Functional Rq.pptx
Software Quality Factors-Non Functional Rq.pptx
 

Software engineering

  • 1. Application Of Fuzzy Logic in Software-Engineering M.Siddardha P.Dinesh Saurabh Sharma
  • 2. WHAT IS SOFTWARE ENGINEERING?  Software engineering is an engineering that is concerned with all aspects of software production.  Software, is any set of machine instructions to perform specific operations.  Software Engineering is the application of a systematic, disciplined, quantifiable approach to  Design  Development  Testing and  Maintenance and Evolution of a SOFTWARE.
  • 3. Component-Based Software Engineering • Most of today’s applications are large and complex. • An application must have some additional characteristics like usability, flexibility, simple installation, reusability, portability, interoperable, etc. to fight with the advancement in the technology and rapidly changing requirements
  • 4. Component Based Development (CBD) • CBD can be best described by the following two guiding principles: – Reuse but do not reinvent; – Assemble pre-built components rather than coding line by line.
  • 5. • Component Based Software Development (CBSD) is getting popular in software industry as a new effective development paradigm. • It emphasizes the design and construction of software system using reusable components. • CBSD is capable of reducing development cost and increasing the reliability of entire software system using components.
  • 6. Component • A component is a Reusable and self -contained piece of software with well-specified interface that is independent of any application. • It is an independent executable entity that can be made up of one or more executable objects • Size of a component may vary from simple functions to an entire application systems
  • 7. • New components can be developed, or even acquired from third party. • An extra effort must be paid for the additional functionality of the component beyond the current application’s need, to make the component more useful
  • 8. Reusability • It is the degree to which a component can be re-used and reduces the software development cost by enabling less coding and more integration
  • 9. Implementation of Fuzzy System for Estimation of Re-Usability • Fuzzy based model for estimation of re- usability considers five factors as inputs and provides a crisp value of reusability • All inputs can be classified into fuzzy sets • The output reusability is classified as Very High, High, Medium, Low and Very Low.
  • 10. Estimating The Reusability • To estimate reusability of Component Based System, following factors have been identified: – Customizability – Interface Complexity – Understandability – Portability
  • 11. • Customizability is defined as the ability to modify a component as per the application requirement – Better reusability can be achieved if customizability is high – Customizability of a component may vary from 0 to 1.
  • 12. • Interface Complexity: – As components are black box in nature, we are unable to get the source code of these components. – Interface acts as a main source for understanding, use and implementation and finally maintenance for the component. – Therefore for better reusability, interface complexity should be as low as possible .
  • 13. • Understandability: – Documentation provides the ease with which a user can learn to operate, prepare inputs for, and interpret outputs of a system or component. – Better reusability can be achieved if Understandability is better • Portability – It is the ability of a component to be transferred from one environment to another. It is typically concerned with reuse of component on new platforms.
  • 14. • There are many rules fed to FIM such as: – if Customizability of components is Low, Interaction Complexity among component is High, Understandability is Low, Commonality is Low and Portability is Low then it is very difficult to maintain the system i.e. Reusability will be Very Low. – If Customizability of components is Low, Interaction Complexity among component is High, Understandability is Low, Commonality is Medium and Portability is Medium then Reusability will be Low. – Etc..,
  • 15.
  • 16. Requirements Engineering • Many of the Software development phases are highly communication-intensive activity that involves analysts, architects, developers, testers, business stakeholders, and end users. • Among all the phases of software engineering, requirements are key ingredient • So, the focus of every development methodology is on requirement engineering phase.
  • 17. • Software development involves roughly 50 percent computing and 50 percent communication. • Whenever human communication involve, various linguistic variables come into picture.
  • 18. example • For example, in object-oriented methods a candidate class is generally identified by applying the rule: • If an entity in a requirement specification is relevant and exist autonomously then select it as a candidate class. • This rule says "an entity is either a candidate class or not a candidate class but not both". • The software engineer may sometimes conclude that the entity partially fulfils the relevance criterion, and may prefer to define the relevance of an entity, for instance, as substantially relevant. This definition would imply the classification of the entity as a partial class, which is considered as an inconsistent class definition by the current object-oriented methods.
  • 19. example • The rule should have been: • If an entity in a requirement specification is relevance-value relevant and can exist autonomy value autonomous in the application domain, then select it as a relevance-value relevant candidate class. Here, – relevance and autonomy are the properties (inputs) – relevance-value and autonomy-value indicate the domains of these properties. – Based on these domains and rules for the relevance of candidate class, we can get the crisp output of candidate class • For example, relevance-value may represent the set of values {Weakly, Slightly, Fairly, Substantially, Strongly}, and autonomy- value may represent the set of values {Dependently, Partially Dependently, Fully Autonomously}.
  • 20. Autonomy Dependent Partially dependent Fully Relevance Weakly Weakly Weakly Weakly Slightly Weakly Slightly Slightly Fairly Weakly Slightly Fairly Substantially Weakly Fairly Substantially Strongly Slightly Fairly Strongly
  • 21. Fuzzy Logic in Size estimation.
  • 22. Size estimation • To estimate the size of an object (to be created) using the sizes of predefined list of objects.
  • 23. Advantages of size estimation • Size estimation can be done in advance to make better plans • To assist in tracking progress • to learn and build estimating skills.
  • 24. Uncertainty in estimation • Estimation is an uncertain process • Earlier you try to estimate, the less is the accuracy of estimation
  • 25. Steps in size estimation 1. Gather size data on previously developed programs. 2. Divide the historical product size data into size ranges. 3. Compare the planned product with these prior products. 4. Based on this comparison, select the size that seems most appropriate for the new product.
  • 26. Application of size estimation. • A file utility of 1,844 LOC. • A file management program of 5,834 LOC. • A personnel record keeping program of 6,845 LOC. • A report generating package of 18,386 LOC. • An inventory management program of 25,943 LOC.
  • 27. Steps in size estimation • log(1844) = 3.266 • log(5834) = 3.766 • log(6845)= 3.835 • log(18386)= 4.2645 • log(25943)= 4.414
  • 28. We will establish 5 size ranges, as follows: 3.122 – 3.409 (1,325 to 2,566) very small 3.409 – 3.696 ( 2,566 to 4,970) small 3.696 – 3.983 (4,970 to 9,626) medium 3.983 – 4.270 (9,626 to 18,641) large 4.270 – 4.557 (18,641 to 36,104) very large. 3.266 3.553 3.840 4.127 4.4143.122 3.409 3.696 3.983 4.270 4.557
  • 29. • file utility  very small • file management program medium • personnel record keeping programmedium • A report generating package large • An inventory management programvery large
  • 30. Analysis • Suppose we want to estimate the size of a program “Analyze marketing” • It is a substantially more complex application than either the file management or personnel programs. It is not as complex as the inventory management program and appears to have significantly more function than the report package. You conclude that the new program is in the lower end of “very large,” or from 18 to 25 KLOC.
  • 31. Drawbacks of size estimation • It requires a lot of data. • It only provides a crude sizing. • It is not useful for programs much larger or smaller than the historical data.

Hinweis der Redaktion

  1. Speak of lookup tables for single values