Software Design
Design principles
Problem partitioning
Abstraction
Top down and bottom up-design
Structured approach
Functional versus object oriented approach
Design specifications and verification
Monitoring and control
Cohesiveness
Coupling
Fourth generation techniques
Functional independence
Software Architecture
Transaction and Transform Mapping
The document discusses key aspects of the software design process including that design is iterative and represented at a high level of abstraction, guidelines for quality design include modularity, information hiding, and functional independence, and architectural design defines system context and archetypes that compose the system.
The document discusses various aspects of software design including:
1. The differences between design and programming and the role of a design engineer.
2. The iterative software design process of translating requirements into a blueprint for building software.
3. Key attributes like functionality, efficiency, flexibility, and usability that software design should address.
4. Fundamental software design concepts such as abstraction, architecture, modularity, and information hiding.
This document provides an overview of software engineering concepts related to software design. It discusses the definition and activities of software design, including preliminary and detailed design. It covers software design principles, considerations, and processes. It also describes various software design tools like data flow diagrams, structure charts, and entity-relationship models. Finally, it discusses object-oriented design, user interface design, data design, architectural design, interface design, and component-level design.
The document provides an overview of basic software design concepts including the design process, quality factors, techniques, methodologies, approaches, models, modularization, data design, guidelines, verification, and key issues. It discusses that software design is an iterative process of translating requirements into a system blueprint. The design process involves informal to more formal designs. Quality factors, architectures, technologies, styles, and decomposition are considered. Top-down and bottom-up approaches are described. Modularization, data design, and guidelines are covered. Verification ensures the design is valid before implementation. Key issues are areas most prone to mistakes.
This document discusses various topics related to software design including design principles, concepts, modeling, and architecture. It provides examples of class/data design, architectural design, interface design, and component design. Some key points discussed include:
- Software design creates representations and models that provide details on architecture, data structures, interfaces, and components needed to implement the system.
- Design concepts like abstraction, modularity, encapsulation, and information hiding are important to reduce complexity and improve design.
- Different types of design models include data/class design, architectural design, interface design, and component-level design.
- Good software architecture and design lead to systems that are more understandable, maintainable, and of higher quality.
Software Design
Design principles
Problem partitioning
Abstraction
Top down and bottom up-design
Structured approach
Functional versus object oriented approach
Design specifications and verification
Monitoring and control
Cohesiveness
Coupling
Fourth generation techniques
Functional independence
Software Architecture
Transaction and Transform Mapping
The document discusses key aspects of the software design process including that design is iterative and represented at a high level of abstraction, guidelines for quality design include modularity, information hiding, and functional independence, and architectural design defines system context and archetypes that compose the system.
The document discusses various aspects of software design including:
1. The differences between design and programming and the role of a design engineer.
2. The iterative software design process of translating requirements into a blueprint for building software.
3. Key attributes like functionality, efficiency, flexibility, and usability that software design should address.
4. Fundamental software design concepts such as abstraction, architecture, modularity, and information hiding.
This document provides an overview of software engineering concepts related to software design. It discusses the definition and activities of software design, including preliminary and detailed design. It covers software design principles, considerations, and processes. It also describes various software design tools like data flow diagrams, structure charts, and entity-relationship models. Finally, it discusses object-oriented design, user interface design, data design, architectural design, interface design, and component-level design.
The document provides an overview of basic software design concepts including the design process, quality factors, techniques, methodologies, approaches, models, modularization, data design, guidelines, verification, and key issues. It discusses that software design is an iterative process of translating requirements into a system blueprint. The design process involves informal to more formal designs. Quality factors, architectures, technologies, styles, and decomposition are considered. Top-down and bottom-up approaches are described. Modularization, data design, and guidelines are covered. Verification ensures the design is valid before implementation. Key issues are areas most prone to mistakes.
This document discusses various topics related to software design including design principles, concepts, modeling, and architecture. It provides examples of class/data design, architectural design, interface design, and component design. Some key points discussed include:
- Software design creates representations and models that provide details on architecture, data structures, interfaces, and components needed to implement the system.
- Design concepts like abstraction, modularity, encapsulation, and information hiding are important to reduce complexity and improve design.
- Different types of design models include data/class design, architectural design, interface design, and component-level design.
- Good software architecture and design lead to systems that are more understandable, maintainable, and of higher quality.
for coding and implementation, there is a need of more specific and detailed requirements. The output of this process can directly be used into implementation in programming languages.
This document discusses software design principles and concepts. It covers key aspects of software design such as data design, architectural design, interface design, component design, abstraction, refinement, modularity, architecture, control hierarchy, structural partitioning, data structures, software procedures, and information hiding. The document emphasizes that software design is an iterative process that translates requirements into a blueprint for constructing software. Good design principles include traceability, reuse, and accommodating change. Modular design aims for functional independence, cohesion and low coupling between modules.
This document discusses key concepts in software design engineering including analysis models, design models, the programmer's approach versus best practices, purposes of design, quality guidelines, design principles, fundamental concepts like abstraction and architecture, and specific design concepts like patterns, modularity, and information hiding. It emphasizes that design is important for translating requirements into a quality software solution before implementation begins.
The document discusses key design concepts in software engineering including abstraction, architecture, patterns, separation of concerns, modularity, information hiding, refinement, functional independence, aspects, refactoring, object-oriented design concepts, and design classes. It provides details on each concept, their importance in software design, and how they lead to the development of high-quality software.
This document discusses key concepts and principles of software design. It explains that software design transforms analysis models into a design model through activities like architectural design, interface design, data design, and component-level design. Some key design concepts discussed include abstraction, refinement, modularity, architecture, procedures, and information hiding. The document also covers principles of effective modular design such as high cohesion and low coupling between modules. Different types of cohesion and coupling are defined. Overall, the document provides an overview of the software design process and some fundamental concepts involved.
The document discusses key concepts in software design, including:
- Design involves modeling the system architecture, interfaces, and components before implementation. This allows assessment and improvement of quality.
- Important design concepts span abstraction, architecture, patterns, separation of concerns, modularity, information hiding, and functional independence. Architecture defines overall structure and interactions. Patterns help solve common problems.
- Separation of concerns and related concepts like modularity and information hiding help decompose problems into independently designed and optimized pieces to improve manageability. Functional independence means each module has a single, well-defined purpose with minimal interaction.
The document discusses architectural documentation. It covers views, which divide an architecture into manageable representations. Relevant views depend on usage and include module, component-and-connector, and allocation views. Each view has a template for documentation, including a primary presentation, element catalog, context diagram, variability guide, and rationale. Cross-view documentation explains the organization, what the architecture contains through a system overview and element list, and the rationale for design decisions. Architectural documentation aims to educate users, enable communication, and provide a basis for construction and analysis.
The document discusses software design and implementation. It describes the design phase as involving high-level architectural design to develop the overall structure of a software program, and low-level detailed design to develop specific algorithms and data structures. The implementation phase includes activities like constructing software components, testing, developing prototypes, training, and installing the system. Good design principles include modularity, low coupling between modules, and high cohesion within modules.
The document describes key components of software design including data design, architectural design, interface design, and procedural design. It discusses the goals of the design process which are to implement requirements, create an understandable guide for code generation and testing, and address implementation from data, functional, and behavioral perspectives. The document also covers concepts like abstraction, refinement, modularity, program structure, data structures, software procedures, information hiding, and cohesion and coupling.
The document discusses key concepts in software design including:
- The main activities in software design are data design, architectural design, procedural design, and sometimes interface design. Preliminary design transforms requirements into architecture while detail design refines the architecture.
- Data design develops data structures to represent information from analysis. Architectural design defines program structure and interfaces. Procedural design represents structural components procedurally using notations like flowcharts.
- Other concepts discussed include modularity, abstraction, software architecture, control hierarchy, data structures, and information hiding. Modular design, abstraction and information hiding help manage complexity. Software architecture and control hierarchy define program organization.
The document provides an overview of architectural design in software engineering. It defines software architecture as the structure of components, relationships between them, and properties. The key steps in architectural design are creating data design, representing structure, analyzing styles, and elaborating chosen style. It emphasizes software components and their focus. Examples of architectural styles discussed include data flow, call-and-return, data-centered, and virtual machine.
The document discusses software design and the software design process. It covers stages of design like problem understanding, identifying solutions, and describing solution abstractions. It also discusses phases in the design process like architectural design, abstract specification, interface design, component design, data structure design, and algorithm design. The document outlines principles for good design like linguistic modular units, few interfaces, small interfaces, explicit interfaces, and information hiding. It discusses concepts like coupling, cohesion, and stepwise refinement in software design.
This document discusses object-oriented analysis and design (OOAD). It introduces the Unified Modeling Language (UML) as a standard notation for capturing objects. Analysis investigates the problem domain to identify objects, while design defines how software objects will collaborate to meet requirements. Key concepts discussed include abstraction, encapsulation, information hiding, and the class-responsibility-collaborator modeling technique. Quality management aims to reduce defects through practices applied throughout the software development process.
The document discusses architectural design, including software architecture, architecture genres, styles, and design. It covers topics such as what architecture is, why it's important, architectural descriptions, decisions, genres like artificial intelligence and operating systems, styles like layered and object-oriented, patterns, organization/refinement, representing systems in context, defining archetypes, refining into components, describing instantiations, and assessing alternative designs.
1. The document discusses software design principles for the waterfall software process.
2. It outlines 11 design principles including dividing problems into smaller components, increasing cohesion, reducing coupling, keeping abstraction high, and designing for flexibility, reusability, portability, and defensiveness.
3. It also discusses design techniques like using priorities and objectives to evaluate alternatives and make design decisions.
The document discusses key concepts in software design. It covers 5 levels of design from the system level down to the individual routine level. It also discusses design challenges and provides heuristics to guide design decisions, such as finding real-world objects, hiding secrets through information hiding and encapsulation, forming consistent abstractions, and identifying areas likely to change. The overall goal is to manage complexity through decomposition and isolation of volatile components.
Architecture Design in Software Engineeringcricket2ime
The document discusses various concepts related to software architecture design. It describes that architecture design identifies subsystems and their interactions early in the design process. It involves decomposing a system, determining component responsibilities, and how components communicate and work together. The document outlines different architectural styles like shared repository, client-server, and layered models. It also discusses design decisions, modular decomposition approaches like function-oriented and object-oriented, and control styles like centralized and event-based control.
The document discusses object-oriented design and its role in software development. It describes how design builds upon analysis to provide implementation details. Key aspects of object-oriented design include defining a multilayered architecture, specifying subsystems and components, describing classes and objects, and defining communication mechanisms. The input to design comes from artifacts created in analysis like use cases and class models. The output of design serves as a blueprint to guide construction.
This document discusses software design principles and processes. It describes key stages of design like problem understanding, identifying solutions, and describing solution abstractions. The design process involves phases like architectural design, interface design, and algorithm design. Good design principles include having linguistic modular units, few interfaces with loose coupling between modules, explicit interfaces, and information hiding. Top-down design and stepwise refinement are common design methods. Cohesion and coupling are important attributes of modular design.
for coding and implementation, there is a need of more specific and detailed requirements. The output of this process can directly be used into implementation in programming languages.
This document discusses software design principles and concepts. It covers key aspects of software design such as data design, architectural design, interface design, component design, abstraction, refinement, modularity, architecture, control hierarchy, structural partitioning, data structures, software procedures, and information hiding. The document emphasizes that software design is an iterative process that translates requirements into a blueprint for constructing software. Good design principles include traceability, reuse, and accommodating change. Modular design aims for functional independence, cohesion and low coupling between modules.
This document discusses key concepts in software design engineering including analysis models, design models, the programmer's approach versus best practices, purposes of design, quality guidelines, design principles, fundamental concepts like abstraction and architecture, and specific design concepts like patterns, modularity, and information hiding. It emphasizes that design is important for translating requirements into a quality software solution before implementation begins.
The document discusses key design concepts in software engineering including abstraction, architecture, patterns, separation of concerns, modularity, information hiding, refinement, functional independence, aspects, refactoring, object-oriented design concepts, and design classes. It provides details on each concept, their importance in software design, and how they lead to the development of high-quality software.
This document discusses key concepts and principles of software design. It explains that software design transforms analysis models into a design model through activities like architectural design, interface design, data design, and component-level design. Some key design concepts discussed include abstraction, refinement, modularity, architecture, procedures, and information hiding. The document also covers principles of effective modular design such as high cohesion and low coupling between modules. Different types of cohesion and coupling are defined. Overall, the document provides an overview of the software design process and some fundamental concepts involved.
The document discusses key concepts in software design, including:
- Design involves modeling the system architecture, interfaces, and components before implementation. This allows assessment and improvement of quality.
- Important design concepts span abstraction, architecture, patterns, separation of concerns, modularity, information hiding, and functional independence. Architecture defines overall structure and interactions. Patterns help solve common problems.
- Separation of concerns and related concepts like modularity and information hiding help decompose problems into independently designed and optimized pieces to improve manageability. Functional independence means each module has a single, well-defined purpose with minimal interaction.
The document discusses architectural documentation. It covers views, which divide an architecture into manageable representations. Relevant views depend on usage and include module, component-and-connector, and allocation views. Each view has a template for documentation, including a primary presentation, element catalog, context diagram, variability guide, and rationale. Cross-view documentation explains the organization, what the architecture contains through a system overview and element list, and the rationale for design decisions. Architectural documentation aims to educate users, enable communication, and provide a basis for construction and analysis.
The document discusses software design and implementation. It describes the design phase as involving high-level architectural design to develop the overall structure of a software program, and low-level detailed design to develop specific algorithms and data structures. The implementation phase includes activities like constructing software components, testing, developing prototypes, training, and installing the system. Good design principles include modularity, low coupling between modules, and high cohesion within modules.
The document describes key components of software design including data design, architectural design, interface design, and procedural design. It discusses the goals of the design process which are to implement requirements, create an understandable guide for code generation and testing, and address implementation from data, functional, and behavioral perspectives. The document also covers concepts like abstraction, refinement, modularity, program structure, data structures, software procedures, information hiding, and cohesion and coupling.
The document discusses key concepts in software design including:
- The main activities in software design are data design, architectural design, procedural design, and sometimes interface design. Preliminary design transforms requirements into architecture while detail design refines the architecture.
- Data design develops data structures to represent information from analysis. Architectural design defines program structure and interfaces. Procedural design represents structural components procedurally using notations like flowcharts.
- Other concepts discussed include modularity, abstraction, software architecture, control hierarchy, data structures, and information hiding. Modular design, abstraction and information hiding help manage complexity. Software architecture and control hierarchy define program organization.
The document provides an overview of architectural design in software engineering. It defines software architecture as the structure of components, relationships between them, and properties. The key steps in architectural design are creating data design, representing structure, analyzing styles, and elaborating chosen style. It emphasizes software components and their focus. Examples of architectural styles discussed include data flow, call-and-return, data-centered, and virtual machine.
The document discusses software design and the software design process. It covers stages of design like problem understanding, identifying solutions, and describing solution abstractions. It also discusses phases in the design process like architectural design, abstract specification, interface design, component design, data structure design, and algorithm design. The document outlines principles for good design like linguistic modular units, few interfaces, small interfaces, explicit interfaces, and information hiding. It discusses concepts like coupling, cohesion, and stepwise refinement in software design.
This document discusses object-oriented analysis and design (OOAD). It introduces the Unified Modeling Language (UML) as a standard notation for capturing objects. Analysis investigates the problem domain to identify objects, while design defines how software objects will collaborate to meet requirements. Key concepts discussed include abstraction, encapsulation, information hiding, and the class-responsibility-collaborator modeling technique. Quality management aims to reduce defects through practices applied throughout the software development process.
The document discusses architectural design, including software architecture, architecture genres, styles, and design. It covers topics such as what architecture is, why it's important, architectural descriptions, decisions, genres like artificial intelligence and operating systems, styles like layered and object-oriented, patterns, organization/refinement, representing systems in context, defining archetypes, refining into components, describing instantiations, and assessing alternative designs.
1. The document discusses software design principles for the waterfall software process.
2. It outlines 11 design principles including dividing problems into smaller components, increasing cohesion, reducing coupling, keeping abstraction high, and designing for flexibility, reusability, portability, and defensiveness.
3. It also discusses design techniques like using priorities and objectives to evaluate alternatives and make design decisions.
The document discusses key concepts in software design. It covers 5 levels of design from the system level down to the individual routine level. It also discusses design challenges and provides heuristics to guide design decisions, such as finding real-world objects, hiding secrets through information hiding and encapsulation, forming consistent abstractions, and identifying areas likely to change. The overall goal is to manage complexity through decomposition and isolation of volatile components.
Architecture Design in Software Engineeringcricket2ime
The document discusses various concepts related to software architecture design. It describes that architecture design identifies subsystems and their interactions early in the design process. It involves decomposing a system, determining component responsibilities, and how components communicate and work together. The document outlines different architectural styles like shared repository, client-server, and layered models. It also discusses design decisions, modular decomposition approaches like function-oriented and object-oriented, and control styles like centralized and event-based control.
The document discusses object-oriented design and its role in software development. It describes how design builds upon analysis to provide implementation details. Key aspects of object-oriented design include defining a multilayered architecture, specifying subsystems and components, describing classes and objects, and defining communication mechanisms. The input to design comes from artifacts created in analysis like use cases and class models. The output of design serves as a blueprint to guide construction.
This document discusses software design principles and processes. It describes key stages of design like problem understanding, identifying solutions, and describing solution abstractions. The design process involves phases like architectural design, interface design, and algorithm design. Good design principles include having linguistic modular units, few interfaces with loose coupling between modules, explicit interfaces, and information hiding. Top-down design and stepwise refinement are common design methods. Cohesion and coupling are important attributes of modular design.
Similar to Software Eng S3 ( Software Design ).pptx (20)
An In-Depth Exploration of Natural Language Processing: Evolution, Applicatio...DharmaBanothu
Natural language processing (NLP) has
recently garnered significant interest for the
computational representation and analysis of human
language. Its applications span multiple domains such
as machine translation, email spam detection,
information extraction, summarization, healthcare,
and question answering. This paper first delineates
four phases by examining various levels of NLP and
components of Natural Language Generation,
followed by a review of the history and progression of
NLP. Subsequently, we delve into the current state of
the art by presenting diverse NLP applications,
contemporary trends, and challenges. Finally, we
discuss some available datasets, models, and
evaluation metrics in NLP.
Online train ticket booking system project.pdfKamal Acharya
Rail transport is one of the important modes of transport in India. Now a days we
see that there are railways that are present for the long as well as short distance
travelling which makes the life of the people easier. When compared to other
means of transport, a railway is the cheapest means of transport. The maintenance
of the railway database also plays a major role in the smooth running of this
system. The Online Train Ticket Management System will help in reserving the
tickets of the railways to travel from a particular source to the destination.
Cricket management system ptoject report.pdfKamal Acharya
The aim of this project is to provide the complete information of the National and
International statistics. The information is available country wise and player wise. By
entering the data of eachmatch, we can get all type of reports instantly, which will be
useful to call back history of each player. Also the team performance in each match can
be obtained. We can get a report on number of matches, wins and lost.
Update 40 models( Solar Cell ) in SPICE PARK(JUL2024)
Software Eng S3 ( Software Design ).pptx
1. Unit-3(Software Design)
• Basic Concept of Software Design,
• Architectural Design,
• Low Level Design: Modularization, Design Structure Charts, Pseudo Codes, Flow Charts,
• Coupling and Cohesion Measures,
• Design Strategies
• Function Oriented Design,
• Object Oriented Design,
• Top-Down and Bottom-Up Design.
• Software Measurement and Metrics:
• Various Size Oriented Measures: Halestead's Software Science,
• Function Point (FP) Based Measures,
• Cyclomatic Complexity Measures: Control Flow Graphs.
2. Design
• In software design phase input is SRS document and output is SDD.
• Software designing is most creative process, where we actually decide how a
problem will be solved.
Design
SRS SDD
3. Characteristics of a Good SDD
• The SDD must contain all the requirement which were given in SRS.
• The design document must be readable, easy to understand and maintainable.
• It must describe a complete picture of data, functional and behavioural domain.
4. Steps of design
• Software designing is a 3-step process
Interface Design Architectural Design Details Design
5. Interface design
• In this, we treat system as a whole and understand the relationship between the
system & environment.
• Here we treat system as a black box and do not concentrate how a function will be
implemented but we decide what is input & what should be the output according to
user requirement or SRS
System
I/P O/P
6. Architectural design
• In this we understand what are the major modules that must be
implemented in the system and what are their responsibility and how
they will communicate with each other.
• We do not give stress on individual modules but concentrate coupling
and cohesion between the modules. Here we treat modules as black
box.
7. Detailed design/Low level design
• In this, specification of internal elements of all modules their functions, their
processing methods, data structure, algorithms, everything is defined properly.
8. Modularity
• In modular architecture, we understand that a system is composed of well
defined conceptually simple and independent units interacting through a well-
defined interface.
9. • Advantage of having modular architecture
• Easy to understand and explain
• It is easy to design and document
• It is easy to code and test.
• It is easy to maintain.
10. Design Structure Charts
• Structure Chart represent hierarchical structure of modules. It breaks down the entire
system into lowest functional modules, describe functions and sub-functions of each
module of a system to a greater detail.
• Structure Chart partitions the system into black boxes (functionality of the system is
known to the users but inner details are unknown). Inputs are given to the black boxes
and appropriate outputs are generated.
11. Symbols used in construction of structured chart
• Module: It represents the process or task of the system. It is of three types.
• Control Module: A control module branches to more than one sub module.
• Sub Module: Sub Module is a module which is the part (Child) of another
module.
• Library Module: Library Module are reusable and invokable from any
module.
12. • Conditional Call: It represents that control module can select any of the sub
module on the basis of some condition.
13. • Loop (Repetitive call of module): It represents the repetitive execution of
module by the sub module. A curved arrow represents loop in the module. All
the sub modules cover by the loop repeat execution of module.
14. • Data Flow: It represents the flow of data between the modules. It is
represented by directed arrow with empty circle at the end.
15. • Control Flow: It represents the flow of control between the modules.
It is represented by directed arrow with filled circle at the end.
16. • Physical Storage: Physical Storage is that where all the
information are to be stored.
18. Benefits of Design Structure Charts in Software Engineering
• Improved understanding of system architecture
• Simplified communication between team members
• Easier identification of potential issues and dependencies
• Support for modular and maintainable software design
19. Pseudocode
• Pseudocode is a simplified, informal representation of an algorithm or a program that
uses a mix of natural language and programming constructs.
• It is used to illustrate the high-level structure and logic of an algorithm without the
syntactic details of a specific programming language.
• Pseudocode helps developers plan and discuss algorithms, making it easier to
understand and translate into actual code later in the software development process.
20. Coupling and cohesion
• Coupling and cohesion are two parameters on which we can understand the
quality of modularity in the design of a software
• Coupling
• The measure of interdependence of one module over another module
21. • Types of coupling
• Data Coupling: Here two modules communicate with each other
only by-passing data. it is most desired type of coupling. e.g.
addition by using call by value is an example of data coupling.
22. • Stamp Coupling: When two modules communicate with each other by
passing of data structure is called stamp coupling. e.g. addition of two
value but by call by reference.
23. • Control Coupling: The module is set to be controlled coupled if they
communicate using control information with each other. e.g.
dependence of two modules on each other because of flag.
24. • External Coupling: in case of external coupling two modules on each
other external to the logic of software (mostly because of hardware
issue). e.g. data bus, CPU, main memory etc.
25. • Common Coupling: Two modules are set to be common coupled if
they share some global data. e.g. synchronization issue between the
processes.
26. • Content Coupling: when one module is a part or context of another
module then it is called content coupling it is worst type of coupling.
28. • Types of cohesion
• Coincidental Cohesion: as the name suggest is the worst kind of
cohesion where the only relationship between the functions which
are present in a module is random or coincidental.
29. • Logical Cohesion: All the elements of a module perform similar or
slightly similar operations, for e.g. if mouse, printer, scanner functions
are written in the same module.
30. • Temporal Cohesion: In case of temporal cohesion functions are related by a fact
that all the task must be executed in the same time span. so, there is a flow
control between the functions. for e.g. two functions first which catch the
exception and second which flash an error message.
31. • Procedural Cohesion: Here functions of a module are related to each
other through a flow control i.e. they are part of an algorithm or
procedure. for e.g. two functional first which check the file access
permission and second which opens the file.
32. • Communicational Cohesion: in case of communicational cohesion
different functions are operating on the same data structure. for e.g.
push and pop.
33. • Sequential Cohesion: here sequence is very important and the
functions are the part of sequence along with data dependency for
e.g. function1 which provides the data and function2 which process
the data.
34. • Functional Cohesion: in functional cohesion, different functions of a
module cooperate with each other. perform a single function. for e.g. a
module which control mouse must have different functions like accessing
the location of the track ball, then decoding it on the screen and give an
appropriate cursor movement
35. Design Approach
• There are two popular approach using which design is done
Top down approach Bottom Up approach
36. • In top down approach, the problem is divided into small no of
programs according to user requirements and we repeat the process
until the problem become so easy till we can solve it directly.
37. • Advantage
• More Systematic.
• Easy to understand and provide a modular architecture.
• In correspondence with user requirement cost and time prediction is
possible.
• Should be used with small and medium size products.
• Used mostly.
• Disadvantage
• When a problem is very complex and very large then we can not understand
the entire problem as a whole.
38. • Bottom Up: This approach is important as the s/w grows in complexity in a
systematic fashion. if the problem is very difficult to understand instead of
understanding the entire problem, we must solve some sub-problem and then
should keep repeating the process until the entire problem is solved.
39. • Advantage
• Should be used on large size projects.
• Easy to use by designers as we work in incremental fashion.
• Disadvantage
• it has complex architecture very difficult to understand and manage.
40. Estimation model
• Here we try to estimate about two things time and cost of
development
• Majorly estimation can be divided into four types
• Post estimation
• Base estimation
• Decomposition
• Empirical model
41. Post / Delayed estimation
• In case of a friendly partly and known technology, we do not estimate
either the time or the cost, because we know that cost will support as
in every situation.
42. Base estimation
• In base estimation we predict the cost and time of the entire project
based on the experience which we have gained from the previous
projects.
43. Decomposition based estimation
• It is used for large projects where decomposition of the problem into smaller
problems is done, usually it is done on two bases.
• Direct Estimation(White Box): Size oriented metrices (KLOC)
• Indirect Estimation(Black Box): Function oriented metrices (FP)
44. • Effort = Size / Productivity
• Productivity = Size / Effort
• Size = Effort X Productivity
• Cost = Effort X Pay
• Duration = Effort / Team Size
• Team Size = Effort / Duration
• Effort = Duration X Team Size
45. Q Consider a banking application which required 4 modules as follows:
User Interface = 5400 LOC
Database = 8500 LOC
Server = 7300 LOC
Client = 5500 LOC
Find the total expenditure of company if productivity of the person is 870 Loc per month.
Consider the salary of each developer is 1500 US dollar per month.
46. Q Consider a application which contain 3 modules M1, M2, M3 having following size
M1 – 14.4 KLOC
M2 – 21.5 KLOC
M3 – 8.4 KLOC
if the cost of writing 1KLOC is 50 dollars. Find the cost of the application. if the
productivity of the developer is 4 KLOC per month. Find the effort, if the project is
required to be completed in month then predict the team size.
47. Q Consider a application which if required to be developed by drdo contain 3 modules M1, M2,
M3 having following size
M1 – 4600 LOC optimistic developer
M2 – 6900 LOC most likely developer
M3 – 8600 LOC pessimistic developer
What is the expected size of application
In general if the software development effort is 10 person-month, find the productivity.
if the development is required to be done in 2 months then find the team size?
Size = (Soptimistic + 4 X Slikely + Spessimistic)/6
48. Indirect Estimation
• Here we use functional points to predict the cost of development, it is a better technique in
general compare to kloc because it considers the logical complexity of the product, as in
general it is not necessary that the larger the project the more complex it will be code.
• (size oriented, function oriented, extended functions point matrices) here we say that the
size of the software is directly dependent on the number and type of different functions it
performs.
FP
2D 3D
49. • 2D- in 2D FP we consider only information domain where we consider mainly five factors, as
follows:
• No of inputs: Each user data input is counted
• No of outputs: Output refers to reports, screen and error messages
• No of inquiries: The no of distinct interactive queries made by user which requires specific
actions by the system
• No of files: Each logical file. So either can be data structure or physical files
• No of external interfaces: Data files on tapes, disk etc. and other interfaces that are used
to transmit information to other systems are counted
FP
2D
Unadjustable Adjustable
3D
51. In Unadjustable case
o FP= total_count
o In Adjustable case
o FP= total_count * EAF(error adjustable factor/Cost adjustment Factor)
𝑖=1
o EAF = 0.65 + 0.01*∑𝑖=14 𝑓i
o In FP analysis 14 factors are indirectly involved to estimate the size of the software.
52. • 3D- In 3D FP we consider only information domain where we consider
mainly five factors, and along with Function domain and behaviour
domain.
FP
2D
Unadjustable Adjustable
3D
53. Empirical models
• Empirical models are estimation models which uses empirically
derived formulas for predicting based on LOC or FP.
• Different authors provides different mathematically derived formula
based on either LOC or FP.
• Out of all COCOMO models in most versatile and universally accepted
54. COCOMO(1981)
• COCOMO model (construction cost model) is the most widely used
estimating technique. It is a regression-based model developed by
barry boehm, he postulated that there are essentially three important
classes of the software.
• Organic(application)
• Semidetached(utility)
• Embedded(system)
55. • In order to classify a product into any of the three proposed classes, we take
into consideration the characteristics of the product as well as those of the
development team.
• Data processing and scientific program are considered to be application
programs. Complier, linkers etc are utility programs. Operating system and real
time system programs are system programs.
• According to the brooks the relative level of the product complexity for the
three categories of product are in the ratio 1:3:9 for application, utility and
system programs relatively
56. • Organic: Relatively small group work in a familiar environment to
develop well understood application program, here little innovation is
required, constraints and deadlines are few and the development
environment is stable.
57. • Semidetached: Project teams consist of a mixture of experienced and
inexperienced staff. It is of medium size, some innovation is required,
constraints and deadlines are moderate and the development
environment is somewhat fluid.
58. • Embedded: the s/w is strongly coupled to complex h/w, such as air traffic
control, ATM’s or weapon systems. The project team is large, a great deal of
innovation is required, constraints and deadlines are tight and the development
environment consist of many complex interfaces, including those with h/w and
with customer.
59. Basic COCOMO
• A simple and static cost estimation model that calculates project effort and duration based
on the size of the software, measured in thousands of lines of code (KLOC)
• Provides a rough order-of-magnitude estimate of project effort and duration
• Uses three modes: Organic, Semi-Detached, and Embedded
60. Basic COCOMO
• DE = ab (KLOC) bb
• DD = cb (KLOC) db
• Team Size = DE / DD
61. • DE = ab (KLOC) bb
• DD = cb (KLOC) db
20KLOC Organic Semidetached Embedded
Effort 55.75 PM 85.95 PM 131 PM
Duration 11.52 M 11.8 M 11.89 M
Team Size 5 7 11
• Team Size = DE/DD
62. Intermediate COCOMO
• Definition: An extension of the Basic COCOMO model that refines effort and duration
estimates by considering additional project factors, such as product attributes, hardware
constraints, and personnel/team attributes.
• Introduces 15 cost drivers to adjust the estimation, these drivers plays a major role in
computation of effort estimation.
• Effort Adjustment Factor (EAF) accounts for the influence of cost drivers.
63. • DE = a (KLOC)b X EAF(Error Adjustment Factor)
20 KLOC /
EAF=1.25
Organic Semidetached Embedded
Effort 92.9 PM 107.4 PM 127.4 PM
64. • DE = a (KLOC)b X EAF(Error Adjustment Factor)
20 KLOC /
EAF=1.25
Organic Semidetached Embedded
Effort 92.2 PM 107.4PM 127.4 PM
65. • DE = a (KLOC)b X EAF(Error Adjustment Factor)
20 KLOC /
EAF=1..675
Organic Semidetached Embedded
Effort 124PM 116.7 PM 170.76 PM
66. Detailed COCOMO
• Definition: The most comprehensive and accurate COCOMO model that divides
a software project into multiple components or modules, and accounts for
interactions between cost drivers and project phases.
• Estimates effort and duration for each component using the Intermediate
COCOMO model, then sums them up.
• Considers software reuse, hardware constraints, and personnel/team attributes
in estimation.
67. Other Empirical models
• E = 5.2 X (KLOC)0.91 Waltson & Felix Model
• E = 5.2 + 0.73X(KLOC)1.16 Bailey-Basili Model
• E = 3.2 X (KLOC)1.05 Simple Bohem Model
• E = 5.288 X (KLOC)1.047 Doty Model
68. Cyclomatic Complexity
• Cyclomatic complexity is a software metric that measures the
complexity of a program's control flow by counting the number of
linearly independent paths through the source code.
69. Need:
• Assess code maintainability and readability
• Identify potential errors and areas of high risk
• Determine testing effort required
• Aid in refactoring efforts to simplify code
70. Objective:
• Quantify the complexity of a program or function
• Facilitate better decision-making in software development
• Improve overall code quality and understandability
71. Process:
• Identify the program's decision points (such as if, while, and for
statements)
• Calculate the number of linearly independent paths by counting the
decision points and adding one
• Interpret the resulting value:
• Low value: lower complexity, easier to maintain and test
• High value: higher complexity, harder to maintain and test, may
require refactoring
72.
73. • Given a control flow graph G of a program, the cyclomatic complexity V(G) can
be computed as:
• V(G) = E – N + 2, where E is the number of edges and N is the total number of
nodes
• V(G) = V(G) = Total number of bounded areas + 1
• Any region enclosed by nodes and edges can be called as a bounded area.
• The cyclomatic complexity of a program can also be easily computed by
computing the number of decision statements of the program.