SOFTWARE ENGINEERING
Complete Study Notes with Tricks & Objectives
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📚 TOPICS COVERED
1. Introduction to Software Engineering
2. Software Life-Cycle Models (SDLC)
3. Software Requirements
4. Requirements Specification (SRS)
5. Software Design
6. Coding Issues
7. Software Integration & Testing
8. Quality Assurance & IEEE Standards
9. Software Maintenance & Reuse
10. Software Testing & Audit
11. Objective Questions (MCQs)
UNIT 1: INTRODUCTION TO SOFTWARE ENGINEERING
1.1 What is Software Engineering?
Software Engineering is the systematic application of engineering principles, methods, and tools to the
development and maintenance of high-quality software systems.
🔑 Trick: Remember: SE = 3P formula → Process + People + Product
Key Definitions:
➤ Software: Programs + Documentation + Operating Procedures
➤ Engineering: Application of science to solve real-world problems
➤ Software Engineering: Discipline for producing quality software on time, within budget
Why Software Engineering?
➤ Software Crisis: Cost overruns, late delivery, unreliable software
➤ Need systematic approach for large complex systems
➤ Manage team collaboration and maintenance
💡 Exam Tip: Software Engineering emerged due to the 'Software Crisis' of the 1960s
1.2 Software Characteristics
Software is different from hardware:
Property Software Hardware
Deterioration Does NOT wear out (logical Wears out over time
faults appear)
Manufacturing Developed/engineered, not Manufactured in factories
manufactured
Custom Usually custom-built Mass produced
Failure rate Constant (bugs remain) Bathtub curve
🔑 Trick: Memory trick for Software Characteristics: 'CRUM' → Complexity, Reliability,
Usability, Maintainability
UNIT 2: SOFTWARE LIFE-CYCLE MODELS (SDLC)
2.1 Introduction to SDLC
SDLC (Software Development Life Cycle) is a structured process for planning, creating, testing, and
deploying software.
🔑 Trick: Phases: 'Please Review Design Code Test Deploy' → Planning, Requirements,
Design, Coding, Testing, Deployment
2.2 Waterfall Model
Sequential, phase-by-phase model where each phase must complete before the next begins.
Phases: Requirements → System Design → Implementation → Testing → Deployment → Maintenance
Advantages:
➤ Simple and easy to understand
➤ Well-documented phases
➤ Works well for small, well-defined projects
Disadvantages:
➤ No working software until late in cycle
➤ Poor model for complex & object-oriented projects
➤ Not suitable for changing requirements
🔑 Trick: Waterfall = 'No Going Back' model — once a phase is done, you move forward only
2.3 Prototype Model
A prototype (working model) of the system is built, tested, and refined until client is satisfied.
Types of Prototyping:
➤ Throwaway/Rapid Prototyping — prototype is discarded after requirements are gathered
➤ Evolutionary Prototyping — prototype is refined into final system
➤ Incremental Prototyping — multiple prototypes, then integrated
🔑 Trick: Prototype = 'Show me first' model — build, show client, get feedback, rebuild
2.4 Spiral Model (Boehm, 1988)
Combines iterative development with systematic aspects of waterfall. Focuses on RISK ANALYSIS.
4 Quadrants of Spiral:
➤ Quadrant 1: Determine Objectives, Alternatives, Constraints
➤ Quadrant 2: Identify and Resolve Risks
➤ Quadrant 3: Develop and Verify Next-Level Product
➤ Quadrant 4: Plan Next Phase
🔑 Trick: Spiral = 'Risk-Driven' model — every loop you analyze risk before proceeding
💡 Best for: Large, complex, high-risk projects
2.5 Incremental Model
Software is developed and delivered in increments (pieces). Each increment adds functionality.
➤ First increment: Core product (basic requirements)
➤ Subsequent increments: Add more features
🔑 Trick: Incremental = 'Build piece by piece' — like adding floors to a building
2.6 RAD Model (Rapid Application Development)
High-speed adaptation of waterfall model using component-based construction.
Time frame: 60-90 days
➤ Phase 1: Business Modelling
➤ Phase 2: Data Modelling
➤ Phase 3: Process Modelling
➤ Phase 4: Application Generation
➤ Phase 5: Testing & Turnover
🔑 Trick: RAD = 'Fast and Furious' model — uses reusable components to speed
development
2.7 Agile Model
Iterative approach with continuous collaboration, customer feedback, and small releases.
Agile Manifesto Values:
➤ Individuals and interactions OVER processes and tools
➤ Working software OVER comprehensive documentation
➤ Customer collaboration OVER contract negotiation
➤ Responding to change OVER following a plan
🔑 Trick: AGILE acronym: Adaptive, Collaborative, Iterative, Light-weight, Evolutionary
Model Key Feature Best For Risk
Waterfall Sequential Clear, fixed High (no early
phases requirements feedback)
Prototype Working Unclear requirements Medium
model first
Spiral Risk analysis Large, high-risk projects Managed
Incremental Piece by piece Large systems Low
RAD Fast (60-90 Time-critical projects Medium
days)
Agile Iterative Changing requirements Low
sprints
UNIT 3: SOFTWARE REQUIREMENTS
3.1 What are Software Requirements?
Requirements are descriptions of what a system should do — the services it provides and constraints
on its operation.
Types of Requirements:
Type Description Example
Functional What the system should DO User can log in with
email/password
Non-Functional HOW the system performs System response time < 2 seconds
Domain Requirements from domain of Medical system must follow HIPAA
application
🔑 Trick: FND = Functional, Non-functional, Domain — the 3 types of requirements
3.2 Requirements Engineering Process
Steps in Requirements Engineering:
➤ Feasibility Study — Is the project viable?
➤ Requirements Elicitation — Gather requirements (interviews, surveys, observation)
➤ Requirements Analysis — Analyze for conflicts, completeness
➤ Requirements Specification — Write SRS document
➤ Requirements Validation — Check requirements are correct
➤ Requirements Management — Handle changes to requirements
🔑 Trick: 'FEARSV' → Feasibility, Elicitation, Analysis, Requirements spec, System validation,
Versioning
3.3 Techniques for Requirements Gathering
➤ Interviews (structured/unstructured)
➤ Questionnaires/Surveys
➤ Observation (watching users work)
➤ Prototyping
➤ Use Case Analysis
➤ JAD (Joint Application Development) sessions
💡 Most common exam question: Difference between functional and non-functional
requirements
UNIT 4: SOFTWARE REQUIREMENTS SPECIFICATION (SRS)
4.1 What is SRS?
SRS (Software Requirements Specification) is a document that completely describes all functions,
capabilities, and constraints of a proposed system.
🔑 Trick: SRS = 'Contract between developer and client' — defines WHAT, not HOW
4.2 IEEE 830 SRS Standard Structure
➤ 1. Introduction (Purpose, Scope, Definitions, Overview)
➤ 2. Overall Description (Product Perspective, Functions, User Characteristics)
➤ 3. Specific Requirements (Functional, Non-functional, Interface requirements)
➤ 4. Appendices
➤ 5. Index
4.3 Characteristics of Good SRS
Property Meaning
Correct Every requirement reflects actual system needs
Unambiguous Only one interpretation possible
Complete All requirements included
Consistent No conflicting requirements
Verifiable Can be tested to check satisfaction
Modifiable Easy to change structure
Traceable Origin of requirement is clear
🔑 Trick: 'CUCCVMT' → Correct, Unambiguous, Complete, Consistent, Verifiable, Modifiable,
Traceable
UNIT 5: SOFTWARE DESIGN
5.1 Introduction to Software Design
Software design is the process of defining the architecture, components, interfaces, and other
characteristics of a system.
Levels of Design:
➤ Architectural Design — High-level structure of system
➤ High-Level Design (HLD) — Modular decomposition
➤ Low-Level Design (LLD) — Detailed module logic
🔑 Trick: AHL = Architectural → High-level → Low-level (top-down approach)
5.2 Design Principles
Principle Description Goal
Abstraction Hide implementation details Reduce complexity
Modularity Divide system into modules Easy maintenance
Cohesion Degree of relatedness within module High cohesion = Good
Coupling Degree of interdependence between Low coupling = Good
modules
Encapsulation Bundle data and methods together Data hiding
Hierarchy Organize in parent-child structure Organized design
🔑 Trick: Remember: HIGH Cohesion + LOW Coupling = GOOD Design
💡 Coupling Types (low to high): Data < Stamp < Control < External < Common < Content
5.3 Types of Cohesion (Best to Worst)
➤ 1. Functional (BEST) — all elements contribute to single task
➤ 2. Sequential — output of one element is input of next
➤ 3. Communicational — elements work on same data
➤ 4. Procedural — elements follow specific sequence
➤ 5. Temporal — elements execute at same time
➤ 6. Logical — elements perform similar functions
➤ 7. Coincidental (WORST) — elements have no meaningful relationship
🔑 Trick: 'FSCP TLC' → Functional, Sequential, Communicational, Procedural, Temporal,
Logical, Coincidental
5.4 Software Design Approaches
1. Function-Oriented Design
➤ System viewed as set of functions
➤ Uses Data Flow Diagrams (DFD)
➤ Top-Down approach
2. Object-Oriented Design
➤ System viewed as set of interacting objects
➤ Uses UML diagrams
➤ Concepts: Classes, Objects, Inheritance, Polymorphism, Encapsulation
5.5 User Interface Design Principles
➤ User Familiarity — use terms familiar to users
➤ Consistency — similar operations should have similar interaction
➤ Minimal Surprise — behavior should not surprise users
➤ Recoverability — users can recover from errors
➤ User Guidance — provide meaningful feedback
➤ User Diversity — accommodate different user types
🔑 Trick: 'UCMRUG' = User-familiarity, Consistency, Minimal-surprise, Recoverability, User-
guidance, User-diversity
UNIT 6: CODING ISSUES
6.1 Good Coding Practices
➤ Use meaningful variable and function names
➤ Write self-documenting code
➤ Keep functions small and focused (single responsibility)
➤ Comment complex logic
➤ Follow coding standards consistently
➤ Avoid global variables
➤ Handle errors and exceptions properly
🔑 Trick: 'SMCSCH' → Small functions, Meaningful names, Comments, Standards, Clean
code, Handle errors
6.2 Coding Standards
Coding standards are a set of guidelines for writing code to ensure consistency, readability, and
maintainability.
➤ Naming conventions (camelCase, PascalCase, snake_case)
➤ Indentation and formatting
➤ File and folder structure
➤ Comment requirements
➤ Error handling patterns
6.3 Code Review
Systematic examination of source code to find bugs and improve quality.
Types:
➤ Formal Inspection — structured review by a team
➤ Walkthrough — developer presents code to peers
➤ Code Review — peer review of code changes
➤ Pair Programming — two developers code together (Agile)
🔑 Trick: Review = 'Find bugs BEFORE testing' — cheaper to fix early
6.4 Software Complexity Metrics
Metric Formula/Description Use
LOC (Lines of Code) Count of executable lines Size measurement
Cyclomatic Complexity V(G) = E - N + 2P Complexity of control flow
(CC)
Function Points (FP) Based on inputs, outputs, queries, Productivity measurement
files
Halstead Metrics Based on operators and operands Code volume
measurement
💡 Cyclomatic Complexity: V(G) = E - N + 2 (for single program). CC ≤ 10 is considered
manageable
🔑 Trick: V(G) = Number of independent paths = Number of regions in flow graph + 1
UNIT 7: SOFTWARE INTEGRATION & TESTING
7.1 Introduction to Software Testing
Testing is the process of executing a program with the intent of finding errors.
V&V: Verification vs Validation
Concept Question Type
Verification Are we building the product RIGHT? Static (no execution)
Validation Are we building the RIGHT product? Dynamic (with execution)
🔑 Trick: Validation = customer, Verification = specification
7.2 Levels of Testing
➤ Unit Testing — test individual modules/functions
➤ Integration Testing — test combined modules
➤ System Testing — test complete system
➤ Acceptance Testing — test by client (UAT)
🔑 Trick: 'UISA' → Unit, Integration, System, Acceptance — bottom-up order
7.3 Testing Techniques
Technique Also Called Description
Black Box Testing Functional Testing Test without knowing internal code
White Box Testing Structural/Glass Box Test with knowledge of internal code
Grey Box Testing — Partial knowledge of internals
7.4 Black Box Testing Methods
➤ Equivalence Partitioning — divide inputs into valid/invalid classes
➤ Boundary Value Analysis (BVA) — test at boundaries of input ranges
➤ Decision Table Testing — test all combinations of conditions
➤ State Transition Testing — test state changes
➤ Use Case Testing — test user scenarios
🔑 Trick: BVA Rule: Test at min, min+1, nominal, max-1, max values
7.5 White Box Testing Methods
➤ Statement Coverage — every statement executed at least once
➤ Branch Coverage — every branch (true/false) executed
➤ Path Coverage — every independent path executed
➤ Condition Coverage — every condition tested for true and false
🔑 Trick: Coverage hierarchy: Path > Branch > Statement (path is strongest)
7.6 Integration Testing Approaches
Approach Description Advantage
Big Bang All modules integrated at once Simple, less planning
Top-Down From top modules downward Early working system visible
Bottom-Up From bottom modules upward No stubs needed
Sandwich/Hybrid Combination of top-down and bottom- Balanced approach
up
💡 Stub = dummy module replacing lower module | Driver = dummy module calling lower
module
🔑 Trick: Top-Down needs STUBS | Bottom-Up needs DRIVERS
7.7 Other Types of Testing
➤ Regression Testing — re-test after changes to ensure no new bugs
➤ Performance Testing — test speed, scalability, stability
➤ Load Testing — test behavior under expected load
➤ Stress Testing — test beyond normal operational capacity
➤ Security Testing — test for vulnerabilities
➤ Usability Testing — test ease of use
➤ Alpha Testing — done by developers at developer's site
➤ Beta Testing — done by end-users at customer's site
🔑 Trick: Alpha = Internal testing | Beta = External testing
UNIT 8: QUALITY ASSURANCE & IEEE STANDARDS
8.1 Software Quality
Software quality is the degree to which a software product meets specified requirements and satisfies
customer needs.
McCall's Quality Factors (3 Categories):
➤ Product Operations: Correctness, Reliability, Efficiency, Integrity, Usability
➤ Product Revision: Maintainability, Flexibility, Testability
➤ Product Transition: Portability, Reusability, Interoperability
🔑 Trick: 'CREIUMP FT PRI' → Correctness, Reliability, Efficiency, Integrity, Usability,
Maintainability, Portability, Flexibility, Testability, Portability, Reusability, Interoperability
8.2 Software Quality Assurance (SQA)
SQA is a set of activities that ensures the software development process and product conform to
defined standards and procedures.
➤ Process standards (how work is done)
➤ Product standards (properties the product should have)
➤ Quality reviews and audits
8.3 CMM (Capability Maturity Model)
Level Name Description
Level 1 Initial Unpredictable, poorly controlled, reactive
Level 2 Managed Projects planned, managed, measured
Level 3 Defined Organization-wide standard processes
Level 4 Quantitatively Managed Quantitative objectives for quality
Level 5 Optimizing Continuous improvement through innovation
🔑 Trick: 'IMDQO' → Initial, Managed, Defined, Quantitatively, Optimizing (Level 1 to 5)
💡 Most organizations aim for Level 3 as minimum. Level 5 is best.
8.4 Key IEEE Software Engineering Standards
Standard Purpose
IEEE 830 Software Requirements Specification
IEEE 1012 Software Verification and Validation
IEEE 1028 Software Reviews and Audits
IEEE 1061 Software Quality Metrics Methodology
IEEE 12207 Software Life Cycle Processes
8.5 Software Reviews
➤ Technical Reviews — evaluate software products for correctness
➤ Inspections (Fagan Inspection) — formal, structured review
➤ Walkthroughs — author presents to team for feedback
➤ Audits — independent examination of software product/process
🔑 Trick: Fagan Inspection Steps: Planning → Overview → Preparation → Inspection →
Rework → Follow-up
UNIT 9: SOFTWARE MAINTENANCE & REUSE
9.1 Software Maintenance
Software maintenance is the modification of a software product after delivery to correct faults, improve
performance, or adapt to changed environments.
Type Purpose Example
Corrective Fix bugs/errors found after delivery Fixing login crash bug
Adaptive Adapt to new environment Update for new OS version
Perfective Improve performance/functionality Add new search feature
Preventive Prevent future problems Restructure old code
(reengineering)
🔑 Trick: 'CAPP' → Corrective, Adaptive, Perfective, Preventive — 4 types of maintenance
💡 Corrective = ~20%, Adaptive = ~25%, Perfective = ~50%, Preventive = ~5% of maintenance
effort
9.2 Software Reuse
Software reuse is the process of using existing software components to build new software systems.
Levels of Reuse:
➤ Object/Function level — reuse individual functions
➤ Component level — reuse software components
➤ System level — reuse entire applications
Benefits of Reuse:
➤ Reduced development cost and time
➤ Improved reliability (reused components are tested)
➤ Increased productivity
➤ Better consistency
🔑 Trick: Reuse = 'Don't reinvent the wheel' — use proven components
9.3 Software Re-engineering
Re-engineering is the examination and alteration of a system to reconstitute it in a new form. Includes:
➤ Reverse Engineering — understand existing system
➤ Forward Engineering — create new system from abstract representation
➤ Refactoring — improve internal structure without changing external behavior
UNIT 10: SOFTWARE TESTING & AUDIT
10.1 Software Audit
A software audit is an independent examination of a software product, process, or plan to assess
compliance with specifications, standards, and contracts.
Types of Audits:
➤ Functional Configuration Audit (FCA) — verifies all required functions are implemented
➤ Physical Configuration Audit (PCA) — verifies documentation matches code
➤ In-Process Audit — check during development
➤ Management Audit — evaluate management activities
10.2 Software Configuration Management (SCM)
SCM is the discipline of controlling evolution of software products.
➤ Version Control — managing multiple versions of software
➤ Change Control — managing changes to software artifacts
➤ Build Management — managing software build process
➤ Release Management — managing software releases
🔑 Trick: SCM = VCBR → Version control, Change control, Build management, Release
management
10.3 Risk Management
Risk management involves identifying and controlling risks that may affect project success.
Risk Management Process:
➤ Risk Identification — identify possible risks
➤ Risk Analysis — estimate probability and impact
➤ Risk Planning — develop strategies to manage risks
➤ Risk Monitoring — track risks throughout project
Risk Category Example
Project risks Staff turnover, schedule delays, requirement
changes
Product risks Integration failures, performance issues
Business risks Competitor products, budget cuts
🔑 Trick: Risk Priority Number (RPN) = Probability × Impact
QUICK REFERENCE: ALL TRICKS & SHORTCUTS
Memory Tricks Summary
Topic Memory Trick
Software Characteristics CRUM: Complexity, Reliability, Usability, Maintainability
SDLC Phases Please Review Design Code Test Deploy
Requirements Types FND: Functional, Non-functional, Domain
Good SRS Properties CUCCVMT: Correct, Unambiguous, Complete, Consistent,
Verifiable, Modifiable, Traceable
Design Quality HIGH Cohesion + LOW Coupling = GOOD Design
Cohesion Types (best→worst) FSCP TLC: Functional, Sequential, Communicational,
Procedural, Temporal, Logical, Coincidental
Testing Levels UISA: Unit, Integration, System, Acceptance
Maintenance Types CAPP: Corrective, Adaptive, Perfective, Preventive
CMM Levels IMDQO: Initial, Managed, Defined, Quantitatively,
Optimizing
UI Design Principles UCMRUG: User-familiarity, Consistency, Minimal-surprise,
Recoverability, User-guidance, Diversity
Integration Testing Top-Down needs STUBS, Bottom-Up needs DRIVERS
Verification vs Validation Verification=RIGHT way, Validation=RIGHT thing
OBJECTIVE QUESTIONS (MCQs) — SOFTWARE ENGINEERING
Section A: Introduction & SDLC
Q1. Software Engineering was coined by:
➤ a) Alan Turing
➤ b) Margaret Hamilton ✓
➤ c) Dennis Ritchie
➤ d) Bjarne Stroustrup
Ans: b) Margaret Hamilton coined the term 'software engineering' during the Apollo mission.
Q2. Which SDLC model is best suited for a project with unclear requirements?
➤ a) Waterfall
➤ b) Prototype Model ✓
➤ c) V-Model
➤ d) RAD Model
Ans: b) Prototype model — helps clarify requirements through working models.
Q3. The Spiral Model was proposed by:
➤ a) Winston Royce
➤ b) Barry Boehm ✓
➤ c) Watts Humphrey
➤ d) Michael Jackson
Ans: b) Barry Boehm, 1988
Q4. Which model focuses primarily on RISK MANAGEMENT?
➤ a) Waterfall
➤ b) Incremental
➤ c) Spiral ✓
➤ d) RAD
Ans: c) Spiral Model — each loop includes explicit risk analysis.
Q5. RAD Model typically completes in:
➤ a) 30-45 days
➤ b) 60-90 days ✓
➤ c) 6 months
➤ d) 1 year
Ans: b) 60-90 days
Section B: Requirements & Design
Q6. SRS stands for:
➤ a) Software Resource Specification
➤ b) Software Requirements Specification ✓
➤ c) System Resource Scheduling
➤ d) Software Reliability Standards
Ans: b) Software Requirements Specification
Q7. 'The system shall respond within 3 seconds' is a:
➤ a) Functional Requirement
➤ b) Non-Functional Requirement ✓
➤ c) Domain Requirement
➤ d) Design Requirement
Ans: b) Non-Functional Requirement (performance)
Q8. IEEE standard for SRS is:
➤ a) IEEE 829
➤ b) IEEE 830 ✓
➤ c) IEEE 1028
➤ d) IEEE 1012
Ans: b) IEEE 830
Q9. Which coupling type is BEST (loosest)?
➤ a) Content Coupling
➤ b) Common Coupling
➤ c) Data Coupling ✓
➤ d) Control Coupling
Ans: c) Data Coupling — modules share only simple data parameters.
Q10. Which cohesion type is the BEST?
➤ a) Temporal Cohesion
➤ b) Logical Cohesion
➤ c) Functional Cohesion ✓
➤ d) Sequential Cohesion
Ans: c) Functional Cohesion — all elements contribute to a single, well-defined task.
Section C: Testing
Q11. Testing without knowledge of internal code is called:
➤ a) White Box Testing
➤ b) Black Box Testing ✓
➤ c) Grey Box Testing
➤ d) Unit Testing
Ans: b) Black Box Testing (also called functional testing)
Q12. Cyclomatic Complexity is calculated as:
➤ a) V(G) = E + N - 2P
➤ b) V(G) = E - N + 2P ✓
➤ c) V(G) = E × N
➤ d) V(G) = N - E + P
Ans: b) V(G) = E - N + 2P (E=Edges, N=Nodes, P=Connected components)
Q13. Which testing technique tests at boundary values?
➤ a) Equivalence Partitioning
➤ b) Decision Table Testing
➤ c) Boundary Value Analysis ✓
➤ d) State Transition Testing
Ans: c) BVA — tests at min, min+1, max-1, max values
Q14. Re-running previously completed tests after modification is called:
➤ a) Smoke Testing
➤ b) Regression Testing ✓
➤ c) Sanity Testing
➤ d) Alpha Testing
Ans: b) Regression Testing
Q15. Testing done by users at developer's site is:
➤ a) Beta Testing
➤ b) Alpha Testing ✓
➤ c) Gamma Testing
➤ d) UAT
Ans: b) Alpha Testing (Beta testing = at user's site)
Q16. Stubs are used in which type of integration testing?
➤ a) Bottom-Up
➤ b) Big Bang
➤ c) Top-Down ✓
➤ d) Sandwich
Ans: c) Top-Down (stubs replace lower-level modules that haven't been developed yet)
Section D: Quality & Maintenance
Q17. CMM Level 5 is called:
➤ a) Managed
➤ b) Defined
➤ c) Optimizing ✓
➤ d) Quantitatively Managed
Ans: c) Optimizing — continuous process improvement
Q18. 'Fixing bugs after deployment' is what type of maintenance?
➤ a) Adaptive
➤ b) Perfective
➤ c) Preventive
➤ d) Corrective ✓
Ans: d) Corrective Maintenance
Q19. Verification answers the question:
➤ a) Are we building the RIGHT product?
➤ b) Are we building the product RIGHT? ✓
➤ c) Is the product on schedule?
➤ d) Is the product within budget?
Ans: b) Verification = building it RIGHT (according to specs)
Q20. Which tool is used for Version Control in SCM?
➤ a) JIRA
➤ b) Git ✓
➤ c) Jenkins
➤ d) Selenium
Ans: b) Git (also SVN, CVS are version control tools)
Q21. Function Point metric was proposed by:
➤ a) Barry Boehm
➤ b) Allan Albrecht ✓
➤ c) Tom DeMarco
➤ d) Roger Pressman
Ans: b) Allan Albrecht (1979, IBM)
Q22. McCall's quality model has how many quality factors?
➤ a) 7
➤ b) 9
➤ c) 11 ✓
➤ d) 13
Ans: c) 11 quality factors in McCall's model
Section E: Additional Important MCQs
Q23. The full form of COCOMO is:
➤ a) Constructive Cost Modeling Object
➤ b) Constructive Cost Model ✓
➤ c) Cost Construction Management Object
➤ d) None of the above
Ans: b) COCOMO = COnstructive COst MOdel (by Barry Boehm)
Q24. DFD stands for:
➤ a) Data Flow Diagram ✓
➤ b) Design Flow Diagram
➤ c) Dynamic Function Design
➤ d) Distributed Function Description
Ans: a) Data Flow Diagram
Q25. Which SDLC model is also known as the 'Linear Sequential Model'?
➤ a) Spiral
➤ b) Agile
➤ c) Waterfall ✓
➤ d) Prototype
Ans: c) Waterfall model
FINAL EXAM CHEAT SHEET
Topic Key Point to Remember
SDLC Best Model Depends on need: Waterfall=fixed, Spiral=risky,
Agile=changing reqs
Design Principle #1 High Cohesion + Low Coupling = Good Design
Testing Order Unit → Integration → System → Acceptance
SRS Standard IEEE 830 — defines structure for requirements
document
CMM Best Level Level 5 (Optimizing) — continuous improvement
Cyclomatic Complexity V(G) = E - N + 2 | Should be ≤ 10
Black Box vs White Box Black=external behavior | White=internal code
Maintenance Most Common Perfective (~50% of effort)
Alpha vs Beta Alpha=developer site | Beta=user site
Stubs vs Drivers Stubs=Top-Down | Drivers=Bottom-Up integration
Verification vs Validation Verification=product RIGHT | Validation=RIGHT
product
Risk Formula RPN = Probability × Impact
SRS Properties CUCCVMT (7 properties)
Cohesion Best to Worst Functional > Sequential > Communicational >
Procedural > Temporal > Logical > Coincidental
━━━━ ALL THE BEST FOR YOUR EXAM! ━━━━
Remember: Understand concepts, don't just memorize!