1.

Verification and Validation

Verification and Validation are two crucial processes in software engineering to ensure that the
software meets requirements and works as intended.

• Verification:

o Focuses on whether the product is being built correctly.

o Ensures that the software development process and intermediate products conform
to specifications.

o It is process-oriented and involves reviews, inspections, and walkthroughs.

o Example: Checking if the design document meets the requirements.

o Techniques: Code reviews, static analysis, and unit testing.

• Validation:

o Focuses on whether the right product is being built.

o Ensures the final product meets the user’s needs and intended use.

o It is product-oriented and involves dynamic testing.

o Example: Testing if the software works as expected in real-world scenarios.

o Techniques: System testing, acceptance testing, and usability testing.

Key Difference:

• Verification checks “Are we building the product right?”

• Validation checks “Are we building the right product?”

2. Requirement Engineering Process

Requirement Engineering (RE) is the process of defining, documenting, and maintaining software
requirements. It ensures that the system meets stakeholder needs.

Stages of Requirement Engineering:

1. Elicitation:

o Collecting requirements from stakeholders, users, and other sources.

o Techniques: Interviews, surveys, brainstorming, observation, and workshops.

2. Analysis and Negotiation:

o Analyzing collected requirements for conflicts, feasibility, and completeness.

o Resolving conflicts through negotiation with stakeholders.

3. Specification:

o Documenting requirements formally (Software Requirements Specification - SRS).

 o Requirements are written clearly, concisely, and unambiguously.

4. Validation:

o Ensuring the requirements are correct, complete, and feasible.

o Techniques: Reviews, prototyping, and model validation.

5. Management:

o Handling changes to requirements throughout the project lifecycle.

o Ensuring requirements traceability and version control.

3. Phases of Software Development Life Cycle (SDLC)

The SDLC is a structured process used to design, develop, and test high-quality software. It outlines
the stages of software creation.

Phases of SDLC:

1. Planning:

o Define project goals, scope, resources, and timeline.

o Conduct feasibility studies and risk analysis.

2. Requirement Analysis:

o Gather and analyze functional and non-functional requirements.

o Create the Software Requirements Specification (SRS).

3. Design:

o Design the architecture and system models (high-level and low-level designs).

o Focus on UI design, database design, and system interfaces.

4. Implementation (Coding):

o Developers write the actual code based on design documents.

o Follow coding standards and best practices.

5. Testing:

o Test the software for bugs and defects.

o Types: Unit testing, integration testing, system testing, and acceptance testing.

6. Deployment:

o Release the software to users.

o Conduct deployment in phases or fully, depending on project needs.

7. Maintenance:
 o Handle bug fixes, updates, and enhancements post-deployment.

o Ensure the software adapts to changing requirements.

4. Software Testing Life Cycle (STLC)

STLC is a sequence of activities performed during the testing process to ensure software quality. It is
integrated into SDLC but focuses purely on testing.

Phases of STLC:

1. Requirement Analysis:

o Analyze testing requirements and identify testable aspects.

o Understand functional and non-functional requirements.

2. Test Planning:

o Develop the test plan document, define scope, objectives, and timelines.

o Allocate resources, estimate effort, and identify risks.

3. Test Case Development:

o Write detailed test cases and scripts.

o Prepare test data and define expected results.

4. Test Environment Setup:

o Prepare the software and hardware environment to execute tests.

o Ensure servers, networks, and configurations are ready.

5. Test Execution:

o Execute test cases, log defects, and compare actual results with expected ones.

o Use defect tracking tools.

6. Test Closure:

o Evaluate test completion criteria, document test summary reports, and ensure all
defects are addressed.

o Conduct retrospective meetings and lessons learned.

Q5.

The COCOMO (Constructive Cost Model) is a method used to estimate how much time, effort, and
money is needed to develop software. It was created by Barry Boehm in 1981 and is still used
because it helps predict project costs based on the size of the software (measured in lines of code).

Why Use COCOMO?

COCOMO helps project managers:

 • Estimate effort – How many people and months are needed to complete the project.

• Estimate time – How long the project will take.

• Estimate cost – How much money will be needed for the project.

This makes planning and budgeting easier, reducing the risk of surprises during development.

1. Basic COCOMO

• A simple model that estimates effort based only on the size of the software (KLOC – Kilo
Lines of Code).

• Less accurate but quick to use.

Formula:

Effort=a×(KLOC)bEffort = a \times (KLOC)^bEffort=a×(KLOC)b

• Effort – How much work is needed (in person-months).

• KLOC – How many thousand lines of code will be written.

• a and b – Constants that change depending on project type.

Types of Projects in Basic COCOMO:

1. Organic – Small and simple projects (e.g., school management software).

2. Semi-Detached – Medium projects with some complexity (e.g., database systems).

3. Embedded – Large, complex systems that require strict rules (e.g., software for aircraft).

2. Intermediate COCOMO

• Adds more accuracy by considering factors like team experience, software complexity, and
development tools.

• Uses cost drivers (like how reliable the software needs to be) to adjust the estimate.

Formula:

Effort=a×(KLOC)b×EAFEffort = a \times (KLOC)^b \times EAFEffort=a×(KLOC)b×EAF

• EAF (Effort Adjustment Factor) – A number based on different project characteristics.

3. Detailed COCOMO

• The most advanced version that breaks the project into smaller parts and estimates each
part separately.

• Provides very accurate estimates by looking at every phase of development (design, coding,
testing).

Example of COCOMO in Action

Let’s say you are developing software that will take 50,000 lines of code (50 KLOC) and the project is
semi-detached.
 1. Effort Calculation:

Effort=3.0×(50)1.12=228 person-monthsEffort = 3.0 \times (50)^{1.12} = 228 \text{ person-

months}Effort=3.0×(50)1.12=228 person-months

2. Time to Develop:

Time=2.5×(228)0.35=14 monthsTime = 2.5 \times (228)^{0.35} = 14 \text{

months}Time=2.5×(228)0.35=14 months

3. Cost:
If the cost per person-month is $10,000:

228×10,000=2.28 million dollars228 \times 10,000 = 2.28 \text{ million

dollars}228×10,000=2.28 million dollars

Advantages of COCOMO

• Easy to use – Simple calculations for project estimation.

• Flexible – Can be used for small and large projects.

• Customizable – More accurate for complex projects if you use Intermediate or Detailed
models.

6. Importance of Software Engineering Paradigm in System Development

A software engineering paradigm is a model or pattern followed during software development. It

outlines the structure, methods, tools, and techniques needed to build reliable software.

Why is it Important?

1. Organized Approach – Ensures systematic software development by breaking down complex

processes into smaller, manageable stages.

2. Consistency – Developers follow the same approach, resulting in predictable and uniform
output.

3. Error Reduction – By following a structured paradigm, the chances of errors and defects are
minimized.

4. Scalability – A proper paradigm makes it easier to scale software as project requirements

grow.

5. Risk Management – Helps in identifying and addressing risks early in the development
process.

6. Better Resource Management – Helps in estimating time, cost, and manpower efficiently.

Example Paradigms:

• Waterfall Model – Sequential, phase-by-phase approach.

• Agile Model – Iterative and flexible development.

• Spiral Model – Focuses on risk analysis and iterative refinement.

 • V-Model – Emphasizes verification and validation at each stage.

7. Difference Between BRS and SRS Documents

BRS and SRS are requirement documents that guide software development, but they address
different needs and audiences.

BRS (Business Requirements SRS (Software Requirements

Aspect
Specification) Specification)
Describes business goals and Describes technical and functional
Purpose
objectives. requirements of the software.
Detailed technical solution to meet
Focus High-level business needs.
business needs.
Business stakeholders (clients,
Audience Developers, testers, and project teams.
managers).
Why the project is needed and what How the system will function and meet
Content
the business expects. business goals.
Technical, with precise functionality and
Scope Broad, non-technical.
constraints.
"System should improve customer "System should respond to user queries
Example
satisfaction." within 3 seconds."

1. Black Box Testing

1. Focus on functionality without knowledge of internal code.

2. Requirement-driven testing based on specifications.

3. Tests inputs and outputs without internal system access.

4. Performed by testers or QA teams with no programming knowledge.

5. Applicable at higher levels – system, acceptance, and UI testing.

2. White Box Testing

1. Tests internal logic, paths, and code structure.

2. Requires programming skills and knowledge of source code.

3. Focuses on code coverage – paths, loops, and conditions.

4. Conducted by developers or technical testers.

5. Applied during unit testing, integration, and security testing.

3. Gray Box Testing

1. Partial knowledge of internal code and system architecture.

2. Combines black and white box techniques.

3. Focuses on data flow, APIs, and integration.

4. Tests both functional and internal logic to some extent.

5. Used for integration, penetration, and regression testing.