SECTION A (Short Answers)

a. Define Software Engineering

 Application of engineering principles to software development

 Systematic, disciplined approach to building software

 Includes design, development, testing and maintenance

b. Software Characteristics

 Functionality: Does what users need

 Reliability: Works correctly under all conditions

 Usability: Easy to learn and use

 Efficiency: Uses resources properly

 Maintainability: Easy to modify

 Portability: Works on different systems

c. Need of SRS (Software Requirements Specification)

 Clearly defines what software should do

 Serves as contract between client and developers

 Guides design and development

 Helps in testing and validation

 Reduces misunderstandings

d. Stubs and Drivers

 Stubs: Temporary code that simulates called functions (used in top-down testing)

 Drivers: Temporary code that calls functions being tested (used in bottom-up testing)

 Both help test components before whole system is ready

e. LOC (Lines of Code)

 Measure of program size by counting code lines

 Advantages: Simple to count, direct measure of size

 Disadvantages: Doesn't measure complexity, varies by language

f. Pseudo Code vs Algorithm

 Pseudo Code: Informal code-like description of steps (no strict rules)

 Algorithm: Precise step-by-step procedure to solve problem

 Pseudo code is for human understanding, algorithms are more formal

g. Importance of White Box Testing

 Tests internal structure/code

  Checks all logical paths

 Finds hidden errors

 Ensures all statements executed

 Measures code coverage

h. Error, Fault, Failure

 Error: Human mistake in coding

 Fault (Bug): Incorrect code from error

 Failure: Fault causes wrong output

i. Reasons for Software Cost Increase

 Changing requirements

 Poor planning/estimation

 Complex technology

 Lack of skilled developers

j. Need for Risk Management

 Identifies potential problems early

 Helps prepare solutions in advance

 Reduces project failures

 Controls costs and schedules

 Improves decision making

SECTION B (Detailed Answers - Choose any 3)

B.a. Software Engineering as Layered Technology

Software engineering is built like a layered cake with four important levels:

1. Quality Focus (Top Layer)

o Most important layer - ensures good quality software

o Includes customer satisfaction, reliability, efficiency

o Follows standards like ISO 9000

2. Process Layer

o Framework for development activities

o Includes requirements, design, coding, testing

o Models like waterfall, agile, spiral

o Defines who does what and when

3. Methods Layer
 o How to do the technical work

o Includes:

 Requirements gathering methods

 Design techniques (flowcharts, UML)

 Programming practices

 Testing approaches

4. Tools Layer (Bottom Layer)

o Software that helps in development

o Examples:

 IDEs (Visual Studio, Eclipse)

 Version control (Git)

 Testing tools (Selenium)

 Project management (Jira)

All layers work together - tools support methods, methods follow processes, and everything aims for
quality.

B.b. Feasibility Study

Importance:

 Checks if project is worth doing before spending money

 Identifies potential problems early

 Helps decide go/no-go decision

 Provides information for planning

 Reduces risk of failure

Types of Feasibility:

1. Technical Feasibility

o Can we build it with current technology?

o Do we have required skills?

o Is hardware/software available?

o Example: Building AI system needs experts

2. Economic Feasibility (Cost-Benefit)

o Is project financially worth it?

o Compares costs vs benefits

o Calculates ROI (Return on Investment)

o Example: Will software save more money than it costs?

 3. Legal Feasibility

o Does it follow laws and regulations?

o Privacy, data protection issues

o Licensing requirements

o Example: Healthcare software needs HIPAA compliance

4. Operational Feasibility

o Will users accept and use it?

o Fits with current operations?

o Training requirements

o Example: New system shouldn't disrupt work

5. Schedule Feasibility

o Can we complete it on time?

o Realistic deadlines?

o Resource availability

o Example: Can't build complex system in 1 month

B.c. Code Review Techniques

1. Code Inspection

o Most formal review method

o Team examines code line by line

o Steps:
a) Planning - decide what to review
b) Overview - author explains code
c) Preparation - reviewers study code
d) Meeting - discuss defects
e) Rework - fix found issues
f) Follow-up - verify fixes

o Focuses on finding defects early

o Uses checklist of common errors

2. Formal Technical Reviews (Peer Reviews)

o Less formal than inspection

o Colleagues review each other's work

o Goals:

 Find errors

 Ensure standards followed

 Share knowledge
 o Participants:

 Moderator (leads meeting)

 Author (explains work)

 Reviewers (find issues)

 Scribe (records findings)

o Output: List of defects to fix

3. Walkthrough

o Least formal method

o Author presents code to team

o Purpose:

 Educate team about code

 Get feedback

 Find improvements

o Less focused on finding defects

o More discussion-oriented

o May use test cases to demonstrate

Comparison:

 Formality: Inspection > FTR > Walkthrough

 Preparation: Inspection needs most preparation

 Time: Inspection takes most time

 Best for critical code: Inspection

 Best for knowledge sharing: Walkthrough

B.d. Testing Types Notes

Mutation Testing

 Creates small changes (mutations) in code

 Runs tests to see if mutations are caught

 If test fails: Good (killed mutation)

 If test passes: Bad (mutation survived)

 Measures test quality - good tests kill many mutations

 Example: Change '>' to '<' in condition

Alpha & Beta Testing

 Alpha Testing:
 o Done by test team at developer site

o Simulates real environment

o Finds major bugs before release

 Beta Testing:

o Done by real users at their location

o Tests in real environment

o Gets user feedback

o Finds usability issues

Regression Testing

 Re-running old tests after changes

 Ensures new code doesn't break old functionality

 Important during maintenance

 Can be automated for efficiency

 Test suites grow over time

 Example: After bug fix, check other features still work

B.e. Software Re-engineering

What is Re-engineering?

 Process of improving old software

 Modernizing without changing functionality

 Like renovating an old house

Why Needed?

1. Old systems hard to maintain

2. Outdated technology

3. Poor documentation

4. Performance issues

5. Need to work with new systems

Re-engineering Process:

1. Inventory Analysis: Decide which systems need work

2. Documentation: Recreate missing docs

3. Reverse Engineering: Extract design from code

4. Restructuring: Improve code structure

5. Forward Engineering: Rebuild with modern tools

 6. Testing: Verify same functionality

Benefits:

 Cheaper than new development

 Keeps business knowledge

 Improves maintainability

 Better performance

 Works with new systems

SECTION C (Detailed Answers - Choose any 1 from each)

3.a. Software Quality Attributes

1. Correctness

 Does what it's supposed to do

 Meets requirements

 No bugs in implementation

2. Reliability

 Works without failing

 Handles errors gracefully

 Measured as MTBF (Mean Time Between Failures)

3. Efficiency

 Uses resources well

 Fast performance

 Low memory/CPU usage

4. Integrity

 Security features

 Protects from unauthorized access

 Data remains correct

5. Usability

 Easy to learn

 Easy to use

 Good user interface

 Helpful documentation

6. Maintainability

 Easy to fix bugs

  Easy to add features

 Well-structured code

 Good documentation

7. Testability

 Easy to test

 Features can be verified

 Supports automated testing

8. Flexibility

 Easy to modify

 Adapts to changes

 Modular design

9. Portability

 Works on different platforms

 Easy to move to new hardware

 Minimal changes needed

10. Reusability

 Components can be reused

 Saves development time

 Requires good design

4.a. Requirement Elicitation Techniques

1. Interviews

 One-on-one meetings

 Structured (prepared questions) or unstructured

 Pros: Detailed information

 Cons: Time consuming

2. Questionnaires

 Written questions to many people

 Good for large groups

 Pros: Quick, covers many

 Cons: Limited depth

3. Workshops

 Group meetings (like JAD sessions)

  All stakeholders together

 Pros: Gets different views

 Cons: Can be dominated by loud people

4. Observation

 Watch users do their work

 See real problems

 Pros: Real-world information

 Cons: May change user behavior

5. Prototyping

 Build quick demo version

 Get early feedback

 Pros: Users understand better

 Cons: May focus only on UI

6. Document Analysis

 Study existing documents

 Manuals, forms, reports

 Pros: Understand current system

 Cons: May be outdated

7. Brainstorming

 Creative group session

 Generate many ideas

 Pros: Innovative solutions

 Cons: Needs good facilitator

8. Use Cases

 Describe system-user interactions

 "User does X, system does Y"

 Pros: Clear scenarios

 Cons: May miss edge cases

5.a. Cohesion and Coupling

Cohesion (How well module's parts belong together)

Types (Good to Bad):

1. Functional: All parts work for single purpose (best)

 2. Sequential: Output of one part is input to next

3. Communicational: Parts work on same data

4. Procedural: Parts execute in order

5. Temporal: Parts run at same time (like startup)

6. Logical: Parts related logically but not functionally

7. Coincidental: Parts unrelated (worst)

Coupling (How much modules depend on each other)

Types (Good to Bad):

1. Data: Share only simple data (best)

2. Stamp: Share composite data (like structures)

3. Control: One controls other's logic

4. External: Share external formats/devices

5. Common: Share global data

6. Content: One modifies other's internals (worst)

Good design has high cohesion and low coupling.

6.a. Test Case Design

What is COCOMO?

 COnstructive COst MOdel

 Estimates effort, cost and schedule

 Based on project size (in KLOC)

Types:

1. Basic: Quick rough estimate

o Effort = a×(KLOC)^b

o a,b depend on project type

2. Intermediate: Adds cost drivers

o 15 factors like experience, complexity

o Adjusts basic estimate

3. Detailed: Phase-level estimates

o Different for each development phase

o Most accurate
1. Software Engineering Basics

 Software Engineering: Designing, developing, testing, maintaining software systematically.

 Software Components: Program (code), Documentation, Operating Procedures (User

Manual).

 Software Characteristics:

o Doesn’t wear out

o Not manufactured (digital, not physical)

o Reusability of components

o Flexible (easy to update)

 Software Crisis: Problems in development (delays, high costs, poor quality, changing
requirements).
  Layered Technology:

o Quality Focus (top layer)

o Process Layer (SDLC, Agile)

o Methods Layer (design, coding, testing)

o Tools Layer (IDEs, version control)

2. Software Quality Attributes

 Functionality: Works as required.

 Reliability: No crashes/failures.

 Usability: Easy to use.

 Performance: Fast and efficient.

 Security: Protects data.

 Maintainability: Easy to update.

 Portability: Works on different systems.

 Scalability: Handles growth.

Three Dimensions of Quality:

1. Quality of Design (planning)

2. Quality of Conformance (follows design)

3. Quality of Performance (real-world use)

3. SDLC (Software Development Life Cycle)

 Phases:

1. Requirement Analysis (SRS document)

2. Planning (budget, team, tech stack)

3. Design (UI/UX, database, architecture)

4. Development (coding)

5. Testing (unit, integration, system testing)

6. Deployment (launch)

7. Maintenance (updates, bug fixes)

4. SDLC Models

1. Waterfall Model:

o Linear, step-by-step (no going back).

o Pros: Simple, clear structure.

o Cons: Inflexible, late testing.

 2. Prototype Model:

o Build sample → get feedback → improve → final product.

o Pros: Early user input, reduces risk.

o Cons: Time-consuming if many changes.

3. Spiral Model:

o Combines Waterfall + Iterative + Risk Analysis.

o Pros: Manages risks, flexible.

o Cons: Expensive, complex.

4. Iterative Model:

o Develop in cycles (add features gradually).

o Pros: Adaptable, early partial versions.

o Cons: Requires good planning.

5. RAD (Rapid Application Development):

o Parallel development + quick prototypes.

o Pros: Fast, user feedback.

o Cons: Needs strong teamwork.

5. Key Comparisons

 Conventional vs. Software Engineering:

o Physical vs. digital.

o Materials (steel, concrete) vs. code.

o Fixed vs. flexible (updates).

o Wears out vs. doesn’t wear out.

 Iterative vs. Spiral Model:

o Iterative: Step-by-step improvements.

o Spiral: Focuses on risk management.

6. Testing & Maintenance

 Testing Types:

o Unit Testing (individual components).

o Integration Testing (combined modules).

o Regression Testing (check old features after updates).

o Alpha/Beta Testing (internal vs. user testing).

 Maintenance:

o Corrective (fix bugs).

 o Adaptive (update for new environments).

o Perfective (add features).

o Preventive (avoid future issues).

7. Risk Management

 Identifying risks early (cost, schedule, tech).

 Mitigation strategies (plan B, prototypes).

8. Documentation

 SRS (Software Requirements Specification): What the software should do.

 Technical Docs: For developers.

 User Manuals: For end-users.

1. Requirement Engineering (RE)

 Definition: Process of collecting, analyzing, documenting, and managing software

requirements.

 Steps:

1. Feasibility Study (Technical, Economic, Legal, Operational, Schedule).

2. Elicitation (Interviews, Surveys, Workshops, Observation).

3. Analysis (Clarity, Completeness, Feasibility).

4. Documentation (SRS Document).

5. Validation (Test Cases, Prototyping, Consistency Checks).

6. Management (Handling changes).

 Importance: Avoids misunderstandings, saves cost/time, ensures quality.

2. Feasibility Study

 Types:

o Technical: Can it be built with current technology?

o Economic: Cost vs. benefits (ROI).

 o Legal: Compliance with laws (e.g., GDPR).

o Operational: Will users accept it?

o Schedule: Can it be completed on time?

3. Requirement Elicitation Techniques

 Interviews: Direct stakeholder questions.

 Surveys/Questionnaires: Large-scale feedback.

 Workshops: Group discussions.

 Observation: Watching users.

 Prototyping: Early demo for feedback.

 Problems: Unclear/changing requirements, communication gaps, conflicts.

4. Software Requirement Specification (SRS)

 Purpose: Blueprint for development (agreement between client/developer).

 Parts:

o Functional Requirements (What the system does, e.g., "User can login").

o Non-Functional Requirements (How it performs, e.g., "Loads in 3 seconds").

o Goals of Implementation (Tech stack, e.g., Java, MySQL).

 Characteristics:

o Complete, Consistent, Feasible, Modifiable, Testable, Unambiguous.

 IEEE 830 Standard:

o Introduction (Purpose, Scope).

o Overall Description (User needs, constraints).

o Specific Requirements (Detailed features, interfaces, security).

5. Information Modeling & Diagrams

 Data Flow Diagram (DFD):

o Elements: External Entity, Process, Data Flow, Data Store.

o Levels:

 Level 0 (Context Diagram: System as one process).

 Level 1 (Sub-processes, e.g., "Login," "Payment").

 Level 2 (Detailed tasks).

 Decision Table/Tree:

o Rules for conditions/actions (e.g., Loan Approval: "If employed AND credit score >700
→ Approve").

 Entity-Relationship (ER) Model: Database design (Entities, Attributes, Relationships).

6. Software Quality Assurance (SQA)

 Objectives: Ensure reliability, usability, security, maintainability.

 Activities:

o Verification (Process checks: "Are we building it right?").

o Validation (Product testing: "Did we build the right thing?").

o SQA Plan (Testing strategies, audits, documentation).

 Quality Frameworks:

o ISO 9000: Standards for QMS (Quality Management System).

o SEI-CMM: 5 maturity levels (Initial → Optimizing).

7. Verification vs. Validation

Aspect Verification Validation

Focus Process (Design, Docs) Product (Final Software)

Testing (Unit, Integration,

Methods Reviews, Walkthroughs
UAT)

Timing Early in SDLC Before deployment

Checking SRS for

Example Testing login functionality.
completeness.

8. ISO 9000 vs. SEI-CMM

Feature ISO 9000 SEI-CMM

International Standards Software Engineering

Developer
Organization. Institute (SEI).
 Feature ISO 9000 SEI-CMM

Scope Generic (All industries). Software-specific.

No levels (Pass/Fail 5 maturity levels (Initial to

Levels
certification). Optimizing).

Quality Management
Focus Process improvement.
System (QMS).

9. Key Diagrams & Tools

 DFD vs. Flowchart:

o DFD: Data movement (External Entities, Processes).

o Flowchart: Step-by-step logic (Decisions, Loops).

 Decision Table: Tabular rules (Conditions → Actions).

 ER Diagram: Database relationships (Entities, Attributes).

10. SQA in SDLC Phases

1. Requirements: Validate clarity/completeness.

2. Design: Review architecture/security.

3. Development: Code reviews, unit testing.

4. Testing: Functional, performance, security tests.

5. Deployment: Monitor post-release issues.

Key One-Liners

 Black Box SRS: Describes "what" (not "how").

 Prototyping: Early demo to refine requirements.

 SQA Plan: Guidelines for quality checks (testing, audits).

 CMM Level 5: Continuous improvement (AI, automation).