Software Configuration Management (SCM) is the general process of managing a changing software system throughout its development and maintenance lifecycle.: "Configuration management is the name given to the general process of managing a...

A software process model is an abstract representation of a software process. It describes a process from a particular perspective and presents a simplified description of a software development process, organized as a framework of activ...

In evolutionary prototyping, the prototype developed initially is incrementally refined on the basis of customer feedback until it finally gets accepted. The same prototype is continuously improved through multiple iterations rather than...

Differences Between Functional and Non-Functional Requirements

Definitions

Functional Requirements define what a system or its component should do. They specify the functions, features, and behaviours that the software system must possess.

Non-Functional Requirements define the quality attributes of a software system. They specify how the software system should fulfill the functional requirements (e.g., performance, reliability, usability).

Differences Table

Which is More Critical and Why?

Functional requirements are more critical than non-functional requirements. The reasons are:

1. Mandatory Nature: Functional requirements are mandatory, meaning the system cannot be accepted or delivered without fulfilling them. Non-functional requirements, while important, are not strictly mandatory.

2. Core Purpose: Functional requirements define the very purpose of the system. If a system does not perform its intended functions (e.g., a banking system that cannot process transactions), it is completely useless regardless of how fast or secure it is.

3. Basis for Non-Functional Requirements: Non-functional requirements only make sense in the context of functional requirements. A system must first do something before we can measure how well it does it.

4. User Specification: Functional requirements are specified directly by the user, reflecting the actual needs the system must meet. Satisfying the user's core needs is the primary goal of software development.

Note: However, in safety-critical systems (e.g., nuclear power plants, aviation), non-functional requirements such as reliability and safety can become equally or even more critical, since failure can cost lives.

Software Pricing, COCOMO Cost Modeling, and Its Disadvantages

1. Importance of Software Pricing

Software pricing is a critical activity in software project management. It must take into account broader organizational, economic, political, and business considerations. Simply calculating the cost of development is not enough; pricing decisions are influenced by many strategic factors.

The major factors that affect software pricing are:

Why Software Pricing Matters:

• It determines the profitability and sustainability of a software organization.
• It affects the bidding and tendering process for software contracts.
• It helps in resource planning -- knowing how much to invest in development, testing, and maintenance.
• Roughly 60% of costs are development costs and 40% are testing costs, so accurate pricing ensures these are covered.
• For customer software, evolution costs often exceed development costs, making long-term pricing strategy essential.

2. COCOMO Cost Modeling Technique

Definition

The Constructive Cost Model (COCOMO) is an algorithmic software cost estimation model. It predicts or estimates:

• The effort required for the project (in person-months)
• The total project cost
• The scheduled time for the project

This model depends on the number of lines of code (LOC) for software product development.

Estimation Approaches

COCOMO fits within the broader software estimation process, which includes estimating:

• Size of the software product
• Effort required
• Overall cost of the project

Estimation can be done using either:

• Top-down approach (also called Macro Model): Overall cost is derived from global properties of the project.
• Bottom-up approach: The cost of each software component is estimated individually and then combined to arrive at the overall project cost. COCOMO's detailed model is the leading method using this bottom-up approach.

Types / Levels of COCOMO

COCOMO is applied at three levels depending on the accuracy needed:

a) Basic COCOMO

• Estimates effort and duration based purely on lines of code (LOC).
• Uses the formula:

Effort (E)    = a * (KLOC)^b   [person-months]
Duration (D)  = c * (E)^d      [months]

Where a, b, c, d are constants that depend on the project type.

b) Intermediate COCOMO

• Extends Basic COCOMO by introducing cost driver attributes such as:
  • Product attributes (reliability, complexity)
  • Hardware attributes (memory constraints)
  • Personnel attributes (analyst capability)
  • Project attributes (use of software tools)
• These attributes adjust the effort estimate more accurately.

c) Detailed COCOMO (Advanced)

• Uses the bottom-up approach.
• The cost of each individual software component is estimated and then combined.
• It aims at constructing the estimate of a system from the knowledge gained about small software components and their interactions.
• Provides the most accurate estimate among the three levels.

Project Categories in COCOMO

3. Disadvantages of COCOMO

Despite being widely used, COCOMO has several notable disadvantages:

1. Dependence on Lines of Code (LOC)

   • The model relies heavily on LOC as the primary input. LOC is difficult to estimate accurately at the early stages of a project, making early estimates unreliable.

2. Does Not Handle Modern Development Well

   • COCOMO was designed for traditional software development. It does not adequately address object-oriented development, component-based development, or agile methodologies.

3. Difficulty in Accurate Cost Driver Assessment

   • In Intermediate and Detailed COCOMO, the cost drivers (effort multipliers) are subjective and require expert judgment, which can introduce human bias into the estimation.

4. Not Suitable for All Project Types

   • COCOMO is less effective for real-time systems, embedded systems, or projects with rapidly changing requirements, as these do not fit neatly into its three project categories.

5. Ignores Reuse and COTS Components

   • The model does not properly account for reused code, commercial off-the-shelf (COTS) components, or third-party libraries, which are common in modern software development.

6. Historical Data Dependency

   • The constants (a, b, c, d) used in the formulas are derived from historical project data. If an organization's projects differ significantly from the data used to calibrate the model, the estimates will be inaccurate.

7. Does Not Consider Team Dynamics

   • COCOMO does not fully account for team communication overhead, organizational culture, or management quality, all of which significantly affect project cost and schedule.

Summary Table

A software process model is an abstract representation of a software process. It describes a process from a particular perspective and presents a simplified description of a software development process, organized as a framework of activ...

Software Configuration Management (SCM) is the general process of managing a changing software system throughout its development and maintenance lifecycle.: "Configuration management is the name given to the general process of managing a...

Software Pricing, COCOMO Cost Modeling, and Its Disadvantages

1. Importance of Software Pricing

Software pricing is a critical activity in software project management. It must take into account broader organizational, economic, political, and business considerations. Simply calculating the cost of development is not enough; pricing decisions are influenced by many strategic factors.

The major factors that affect software pricing are:

Why Software Pricing Matters:

• It determines the profitability and sustainability of a software organization.
• It affects the bidding and tendering process for software contracts.
• It helps in resource planning -- knowing how much to invest in development, testing, and maintenance.
• Roughly 60% of costs are development costs and 40% are testing costs, so accurate pricing ensures these are covered.
• For customer software, evolution costs often exceed development costs, making long-term pricing strategy essential.

2. COCOMO Cost Modeling Technique

Definition

The Constructive Cost Model (COCOMO) is an algorithmic software cost estimation model. It predicts or estimates:

• The effort required for the project (in person-months)
• The total project cost
• The scheduled time for the project

This model depends on the number of lines of code (LOC) for software product development.

Estimation Approaches

COCOMO fits within the broader software estimation process, which includes estimating:

• Size of the software product
• Effort required
• Overall cost of the project

Estimation can be done using either:

• Top-down approach (also called Macro Model): Overall cost is derived from global properties of the project.
• Bottom-up approach: The cost of each software component is estimated individually and then combined to arrive at the overall project cost. COCOMO's detailed model is the leading method using this bottom-up approach.

Types / Levels of COCOMO

COCOMO is applied at three levels depending on the accuracy needed:

a) Basic COCOMO

• Estimates effort and duration based purely on lines of code (LOC).
• Uses the formula:

Effort (E)    = a * (KLOC)^b   [person-months]
Duration (D)  = c * (E)^d      [months]

Where a, b, c, d are constants that depend on the project type.

b) Intermediate COCOMO

• Extends Basic COCOMO by introducing cost driver attributes such as:
  • Product attributes (reliability, complexity)
  • Hardware attributes (memory constraints)
  • Personnel attributes (analyst capability)
  • Project attributes (use of software tools)
• These attributes adjust the effort estimate more accurately.

c) Detailed COCOMO (Advanced)

• Uses the bottom-up approach.
• The cost of each individual software component is estimated and then combined.
• It aims at constructing the estimate of a system from the knowledge gained about small software components and their interactions.
• Provides the most accurate estimate among the three levels.

Project Categories in COCOMO

3. Disadvantages of COCOMO

Despite being widely used, COCOMO has several notable disadvantages:

1. Dependence on Lines of Code (LOC)

   • The model relies heavily on LOC as the primary input. LOC is difficult to estimate accurately at the early stages of a project, making early estimates unreliable.

2. Does Not Handle Modern Development Well

   • COCOMO was designed for traditional software development. It does not adequately address object-oriented development, component-based development, or agile methodologies.

3. Difficulty in Accurate Cost Driver Assessment

   • In Intermediate and Detailed COCOMO, the cost drivers (effort multipliers) are subjective and require expert judgment, which can introduce human bias into the estimation.

4. Not Suitable for All Project Types

   • COCOMO is less effective for real-time systems, embedded systems, or projects with rapidly changing requirements, as these do not fit neatly into its three project categories.

5. Ignores Reuse and COTS Components

   • The model does not properly account for reused code, commercial off-the-shelf (COTS) components, or third-party libraries, which are common in modern software development.

6. Historical Data Dependency

   • The constants (a, b, c, d) used in the formulas are derived from historical project data. If an organization's projects differ significantly from the data used to calibrate the model, the estimates will be inaccurate.

7. Does Not Consider Team Dynamics

   • COCOMO does not fully account for team communication overhead, organizational culture, or management quality, all of which significantly affect project cost and schedule.

Summary Table

--- Aspect Verification Validation --------- Definition Checking whether the system is built correctly (process-oriented) Checking whether the right system is built (product-oriented) Focus Confirms the system conforms to its specificati...

In evolutionary prototyping, the prototype developed initially is incrementally refined on the basis of customer feedback until it finally gets accepted. The same prototype is continuously improved through multiple iterations rather than...

Differences Between Functional and Non-Functional Requirements

Definitions

Functional Requirements define what a system or its component should do. They specify the functions, features, and behaviours that the software system must possess.

Non-Functional Requirements define the quality attributes of a software system. They specify how the software system should fulfill the functional requirements (e.g., performance, reliability, usability).

Differences Table

Which is More Critical and Why?

Functional requirements are more critical than non-functional requirements. The reasons are:

1. Mandatory Nature: Functional requirements are mandatory, meaning the system cannot be accepted or delivered without fulfilling them. Non-functional requirements, while important, are not strictly mandatory.

2. Core Purpose: Functional requirements define the very purpose of the system. If a system does not perform its intended functions (e.g., a banking system that cannot process transactions), it is completely useless regardless of how fast or secure it is.

3. Basis for Non-Functional Requirements: Non-functional requirements only make sense in the context of functional requirements. A system must first do something before we can measure how well it does it.

4. User Specification: Functional requirements are specified directly by the user, reflecting the actual needs the system must meet. Satisfying the user's core needs is the primary goal of software development.

Note: However, in safety-critical systems (e.g., nuclear power plants, aviation), non-functional requirements such as reliability and safety can become equally or even more critical, since failure can cost lives.

Requirements engineering (RE) is a process that involves all of the activities required to create and maintain a system requirements document. Its purpose is to make the problem being stated clear and complete, and to ensure that the sol...

Software maintenance refers to the time-to-time modification and evolution of a software system to meet the changing needs of customers and to correct errors discovered after deployment. It is one of the four fundamental software enginee...

Agile development is a software development method based on iterative and incremental development in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It is also known as rapid...

Behavioral Model

Definition

A behavioral model is a type of system model that describes the dynamic behavior of a system as it executes. It shows what happens or what should happen when a system responds to a stimulus from its environment. In other words, it represents how a system changes its state in response to events or data inputs over time.

Behavioral model is one of the four main types of system models (along with Contextual, Interaction, and Structural models) used to represent a system from different perspectives during system modeling.

Purpose

• To show the dynamic aspects of a system
• To describe how a system responds to events or inputs
• To help analysts and designers understand the flow of control and data within a system
• To validate system requirements during requirement engineering

Types of Stimuli in Behavioral Models

Behavioral models can be driven by two types of stimuli:

Common Notations Used

1. State Diagram (State Machine Diagram) - shows states and transitions
2. Activity Diagram - shows flow of activities/actions

Example: ATM Behavioral Model (State Diagram)

Consider a simple ATM machine system. Its behavior can be modeled using states and transitions:

[Idle]
   |
   | Card Inserted
   v
[Card Verification]
   |
   | PIN Entered Correctly
   v
[Menu Display]
   |
   | User selects "Withdraw"
   v
[Processing Withdrawal]
   |
   | Amount Dispensed
   v
[Transaction Complete]
   |
   | Card Ejected
   v
[Idle]

Explanation of States:

• Idle: ATM is waiting for a customer
• Card Verification: ATM reads and verifies the inserted card
• Menu Display: Customer is shown available options after successful PIN entry
• Processing Withdrawal: ATM processes the withdrawal request
• Transaction Complete: Cash is dispensed and receipt is printed
• Idle: ATM returns to waiting state after card is ejected

Key Points

• Behavioral models are primarily used in requirement engineering to validate and communicate system functionality
• They help identify what the system does in response to various inputs or events
• They are especially useful for real-time and event-driven systems such as ATMs, traffic control systems, and embedded systems

Summary: A behavioral model captures the dynamic nature of a system by showing how it transitions between states or performs activities in response to stimuli. It is an essential tool for understanding, validating, and communicating system behavior during software development.

--- A use case model is a graphical representation of the interactions among the elements of a system and its external entities called actors. It focuses on the functional requirements and provides an outside view of the system. - User/C...

An SRS (Software Requirements Specification) document is a formal document that precisely describes all the requirements of the software system to be developed. It serves as a contract between the client and the development team. --- A s...

The architectural design process includes the following three major activities: - The system is decomposed into major sub-systems. - Communication mechanisms between these sub-systems are identified. - Each sub-system is relatively indep...

Risk management is the process of identifying risks that might affect the project schedule or quality of the software being developed, and taking action to avoid or minimize these risks. It involves assessing major project risks to estab...

Short Notes

a. System Engineering (2.5 marks)

System engineering is a broad, interdisciplinary approach concerned with the design, implementation, management, and maintenance of complex systems in which software is one component among many (including hardware, people, processes, and organizations).

Key points:

• Scope: System engineering considers the system as a whole, not just the software. It includes hardware engineering, process design, and human factors alongside software development.
• Relationship to Software Engineering: Software engineering is a subset of system engineering. While software engineering focuses on building and maintaining software, system engineering addresses how all components work together to meet overall system goals.
• Activities involved:
  • System specification: Defining what the overall system must do.
  • System design: Deciding how responsibilities are distributed across hardware, software, and people.
  • System integration: Combining all components and verifying they work together.
  • System validation: Confirming the complete system meets user and business requirements.
• Importance: As software is trusted with all aspects of our lives (trust challenge) and failures in safety-critical areas such as aviation and nuclear power can be catastrophic (risk challenge), system engineering ensures that all parts of a complex system are properly coordinated and verified.

b. Release Testing (2.5 marks)

Release testing refers to the coding practices and test strategies that give teams confidence that a software release candidate is ready for users.

Key points:

• Definition: Release testing aims to find and eliminate errors and bugs from a software release so that it can be safely delivered to users (as per course notes).
• Primary Goal: The primary goal of the release testing process is to convince the customer that the system is good enough for use.
• Nature: It is typically a black-box testing process, meaning testers focus on the behavior of the system from the user's perspective rather than internal code structure.
• Difference from System Testing:
  • System testing is carried out by the development team.
  • Release testing is usually performed by a separate testing team that was not involved in development, ensuring an unbiased evaluation.
• Scope: Release testing covers functional requirements, performance, reliability, and usability to ensure the product meets its specification before deployment.
• Relation to User Testing: Even after thorough release testing, user testing is still essential because influences from the user's real working environment (performance, usability, robustness) cannot be fully replicated in a testing environment.

Summary Table