COCOMO Model (Constructive Cost Model):

The COCOMO (Constructive Cost Model) is a cost estimation model used to predict the cost, effort, and time required to complete a
software project based on its size and complexity.
• COCOMO Levels:
1. Basic COCOMO: Provides a rough estimate based on software size (LOC - Lines of Code) and a few general factors
(e.g., hardware and personnel experience).
2. Intermediate COCOMO: Incorporates more factors, such as the complexity of the software and project constraints.
3. Advanced COCOMO: Provides the most detailed estimates by considering various cost drivers, such as reliability,
data complexity, and team experience.
• Formula (Basic):
Effort=a×(KLOC)b\text{Effort} = a \times (KLOC)^bEffort=a×(KLOC)b
Where:
o a,ba, ba,b are constants based on project type.
o KLOC is the number of thousands of lines of code.
• Advantages:
o Provides an objective estimate based on historical data.
o Helps in resource planning and budgeting.
• Disadvantages:
o Requires accurate estimation of lines of code.
o May not be as accurate for unconventional or highly innovative projects.
Context Diagram and Data Flow Diagram (DFD)
Context Diagram:
• Definition: A context diagram is a high-level visual representation of the system and its interactions with external entities
(users, other systems, etc.). It shows the system as a single process and how it exchanges information with external actors.
• Purpose: To show the boundary of the system, external entities, and data flows between them and the system.
• Components:
o System: Represented as a single process in the center.
o External Entities: Represented as circles or squares (e.g., users, other systems).
o Data Flows: Arrows representing the data exchange between the system and external entities.
Data Flow Diagram (DFD):
• Definition: A Data Flow Diagram (DFD) is a diagram that represents the flow of data within a system. It shows how input
data is transformed into output through a series of processes.
• Levels of DFD:
o Level 0 (Context Diagram): A high-level overview showing the entire system as a single process and external
entities.
o Level 1 and Beyond: More detailed diagrams that decompose the system into sub-processes to show how data
moves through the system in more detail.
• Components:
o Processes: Represented by circles or rounded rectangles. They transform input data into output.
o Data Flows: Arrows showing data movement.
o Data Stores: Represented by open-ended rectangles where data is stored temporarily.
o External Entities: Sources or destinations of data (users, external systems).
Top-Down Design:
• Definition: Top-down design is an approach where the system is designed starting from the highest-level abstraction (the
overall system) and then progressively broken down into smaller and more detailed sub-systems or components.
• Approach:
1. Start with the broad system architecture and then break it down into smaller modules.
2. Each module is further divided into sub-modules until the system is fully decomposed into small, manageable
pieces.
• Benefits:
o Helps in managing complexity by starting with high-level objectives.
o Promotes systematic decomposition of system functions.
• Challenges:
o Can be difficult to consider low-level details early on.
o Might overlook specific implementation issues at the initial stages.
Bottom-Up Design:
• Definition: Bottom-up design is an approach where the system is built starting from the low-level components or modules
and then gradually integrated into a complete system.
• Approach:
1. Start by designing and implementing the smallest, simplest components.
2. Gradually build up to more complex components by integrating smaller components into larger sub-systems.
• Benefits:
o Early validation of low-level components and their functionality.
o Fosters reusability since components can be designed and used independently.
• Challenges:
o It may lead to fragmented or disjointed designs.
o High-level design issues may not be fully addressed until later.
Decision Tree:
• Definition: A decision tree is a diagram used to represent decision-making logic and outcomes based on various conditions.
It is often used in software design to model and visualize decision processes.
• Components:
o Nodes: Represent conditions or decisions.
o Branches: Represent the possible outcomes or actions based on the decision at each node.
• Benefits:
o Visual representation of complex decision logic.
o Helps in clearly understanding multiple outcomes and conditions.
Decision Table:
• Definition: A decision table is a table used to represent and analyze multiple decision rules. It lists various conditions and
the corresponding actions that should be taken based on combinations of these conditions.
• Components:
o Conditions: Variables or factors that influence the decision (usually listed as columns).
o Actions: Possible outcomes or actions based on conditions (usually represented as rows).
• Benefits:
o Organizes complex decision-making logic.
o Reduces the need for repetitive code or manual checks.

• Feature Decision Tree Decision Table

Graphical (tree structure with nodes Tabular (rows and columns for conditions and
Representation
and branches) actions)
Hierarchical, with nodes
Tabular, with rows representing decision rules and
Structure (decisions/conditions) and branches
columns for conditions/actions
(outcomes)
Sequential or hierarchical decision- Multiple conditions leading to various actions or
Best Use Case
making with clear conditional flow outcomes
Can become complex with many Becomes compact and manageable even with
Complexity
conditions and branches many conditions
Ease of Visual and intuitive for sequential Requires familiarity with tables but compact and
Understanding decisions organized for complex logic
Handling Multiple Less efficient for handling many Efficient for handling multiple conditions and
Conditions conditions, can get cluttered combinations
Focuses on step-by-step, sequential Focuses on evaluating multiple conditions at once
Decision Process
decisions with defined outcomes
Table with conditions like Age > 18, Customer
"Is the customer age > 18? Yes/No -
Example VIP status, and corresponding actions like "Apply
> Discount Yes/No"
Discount" or "No Discount"
Easy to visualize and follow, good Efficient for managing many decision rules in a
Advantages
for clear decision paths compact format
Can become complex with many Can be harder to understand if the table is too large
Disadvantages
conditions (large tree) or the conditions are too complex
Functional vs. Object-Oriented Approach
Functional Approach:
• Definition: The functional approach focuses on functions or procedures as the primary building blocks of the system. The
system is designed around operations or processes that manipulate data.
• Characteristics:
o Focus on data flows and processes.
o Emphasizes how data is transformed through various operations.
o Functions are typically defined to perform specific tasks or computations.
• Example: A payroll system that processes employee data using functions like calculate_salary(), generate_report(), etc.
• Advantages:
o Good for simpler systems with well-defined data flows.
o Easier to implement in procedural languages like C.
• Disadvantages:
o Does not directly model real-world entities.
o Can lead to complex interdependencies as systems grow.
Object-Oriented Approach:
• Definition: The object-oriented approach organizes the system around objects that represent real-world entities. These
objects encapsulate both data and the methods that operate on the data, following principles like encapsulation,
inheritance, and polymorphism.
• Characteristics:
o Focus on objects (instances of classes).
o Objects represent real-world entities and have properties (attributes) and behaviors (methods).
o System behavior is defined by how objects interact.
• Example: In a banking system, objects like Account, Customer, and Transaction interact with each other, and each has
specific attributes (e.g., account number, balance) and methods (e.g., deposit(), withdraw()).
• Advantages:
o Models real-world systems more intuitively.
o Encourages modularity and code reuse.
o Easier maintenance and scalability.
• Disadvantages:
o More complex to design and understand for small systems.
o May require a steeper learning curve for developers unfamiliar with object-oriented principles.
Structured Programming
• Definition: Structured programming is a programming paradigm aimed at improving clarity, quality, and development time
by using a systematic approach to software design.
• Key Features:
o Focuses on sequential control flow, loops, and conditionals.
o Uses functions or procedures to encapsulate tasks, enhancing readability and maintainability.
o Avoids goto statements, promoting logical structure in code.
• Advantages:
o Easier to understand and debug.
o Facilitates modular programming, where each function handles a specific task.
• Example: A simple structured program that uses a loop to process user inputs or a decision-making process with if-else.
2. Object-Oriented Programming (OOP)
• Definition: Object-oriented programming is a programming paradigm that uses objects to represent real-world entities.
Objects encapsulate both data (attributes) and functions (methods) that operate on the data.
• Key Concepts:
o Encapsulation: Bundling data and methods into one unit (class).
o Inheritance: The ability of a new class to inherit properties and methods from an existing class.
o Polymorphism: The ability to use a method in different ways, based on the object type.
o Abstraction: Hiding unnecessary details and exposing only essential features.
• Advantages:
o Promotes code reuse and modularity.
o Easier to maintain and extend due to the separation of concerns (data and behavior).
• Example: A class Car with methods like start() and stop(), and attributes like color and engine type.
Aspect Structured Programming (SP) Object-Oriented Programming (OOP)
A programming paradigm that follows a step-by-step A programming paradigm that organizes software design
Definition
approach using sequences, decisions, and loops. around data (objects) and methods (functions).
Focuses on procedures and functions to operate on Focuses on objects (which combine data and methods)
Focus
data. and their interactions.
Uses functions, sequences, conditionals, and loops for Uses objects, classes, inheritance, encapsulation,
Main Concepts
control flow. polymorphism, and abstraction.
Programs are divided into objects and classes, promoting
Modularity Programs are divided into functions or procedures.
more modular design.
Data and Data and functions are separate, and functions Data and functions are bundled together inside objects,
Functions manipulate data. enhancing encapsulation.
Follows a top-down approach (dividing a task into Follows a bottom-up approach (starting with basic
Approach
smaller sub-tasks). objects and building larger systems).
Limited reusability; code reuse is achieved by creating High reusability through inheritance and polymorphism;
Code Reusability
new functions. existing objects can be extended.
Harder to maintain as the project grows due to lack of Easier to maintain due to clear structure, encapsulation,
Maintainability
clear modularity and abstraction. and data abstraction.
Data is not hidden, meaning it's prone to accidental Data is protected through encapsulation, with controlled
Data Security
modification. access through methods.
Less flexible when changes in data structures or More flexible; changes can be made with minimal impact
Flexibility
operations are required. on the overall system.
1. Levels of Testing
• Unit Testing:
o Definition: Testing individual components or functions in isolation.
o Goal: To verify that each unit of the code behaves as expected.
o Tools: JUnit (Java), pytest (Python), NUnit (.NET).
• Integration Testing:
o Definition: Testing the interaction between different components or modules of the system.
o Goal: To ensure that integrated components work together as expected.
o Example: Testing the interaction between a user authentication module and a database.
• System Testing:
o Definition: Testing the entire system as a whole to verify that all components function together.
o Goal: To verify that the system meets the specified requirements and performs as expected in a real-world
environment.
• Acceptance Testing:
o Definition: Testing conducted to determine if the software meets the business requirements and if it’s ready for
deployment.
o Goal: To ensure the system meets the user’s needs and is ready for release.
2. Integration Testing
• Definition: Integration testing is a type of testing where individual modules or components are combined and tested as a
group.
• Approach:
o Big Bang Integration: All modules are integrated at once and then tested together.
o Incremental Integration: Modules are integrated one at a time, and each new integration is tested before the next
one is added.
• Goal: To ensure that the interactions between modules function correctly and that data flows seamlessly between them.
3. Test Case Specification
• Definition: A test case specification is a document that outlines the inputs, actions, expected outputs, and the conditions
under which a particular feature or functionality is tested.
• Components:
o Test Case ID: Unique identifier.
o Test Description: What is being tested.
o Input Data: Values or conditions required to execute the test.
o Expected Outcome: What the system should do if the test is successful.
o Execution Steps: Steps needed to execute the test.
• Importance: Ensures comprehensive and repeatable testing.