KCS601 - SOFTWARE ENGINEERING (2023-24) - NOTES IN SIMPLE LANGUAGE
SECTION A – SHORT QUESTIONS (2 Marks Each)
a. What is Software Engineering?
Software Engineering is the use of engineering methods to design, develop, and maintain
software efficiently.
b. What are the characteristics of software?
1. Correctness – Works as expected.
2. Reliability – Performs well over time.
3. Efficiency – Uses fewer resources.
4. Maintainability – Easy to update.
5. Portability – Runs on different systems.
c. Why is SRS needed?
SRS clearly lists what the software must do. It helps developers and clients understand the
software goals.
d. What are stubs and drivers?
• Stub: Dummy code used to test higher modules.
• Driver: Dummy code used to test lower modules.
e. What is LOC? Mention two pros and cons.
LOC is a measure of how many lines of code are in a program.
• Pros: Easy to count, useful for effort estimation.
• Cons: Doesn’t show quality, encourages more code.
f. What is pseudo code? How is it different from an algorithm?
Pseudo code looks like code but isn’t real. Algorithms are step-by-step solutions.
g. Why is white box testing important?
It checks the actual code logic, making sure all paths and loops work as expected.
h. What is error, fault, and failure?
• Error: Developer’s mistake.
• Fault: Bug in the program.
• Failure: Software doesn’t work correctly.
i. Reasons for increase in software cost?
1. Projects are getting complex.
2. User needs keep changing.
j. Why is risk management needed?
To find and reduce risks early in software projects, saving time and cost.
SECTION B – SHORT NOTES (10 Marks Each)
2a. Software Engineering is Layered Technology
Software engineering is built on four layers:
1. Quality Focus – At the center, ensures good output.
2. Process Layer – Manages how development is done.
3. Methods – Technical work like coding, testing.
4. Tools – Software that helps in development.
All layers support each other to create high-quality software.
2b. Feasibility Study and its Types
A feasibility study checks if a project is possible.
Types:
1. Technical – Do we have the skills?
2. Economic – Is it affordable?
3. Legal – Is it legally okay?
4. Operational – Will it work in real use?
5. Schedule – Can we finish on time?
2c. Code Inspection, FTR, and Walkthrough
• Code Inspection: Team reviews code for errors.
• FTR (Formal Technical Review): Review of design/code by a team to follow standards.
• Walkthrough: Developer explains their code to the team.
All these help catch mistakes early.
2d. Mutation, Alpha, Beta, and Regression Testing
• Mutation Testing: Make small changes to test code strength.
• Alpha Testing: Done inside company.
• Beta Testing: Done by users before final release.
• Regression Testing: Check that new code doesn’t break old features.
2e. What is Software Re-engineering and why is it needed?
Re-engineering means improving old software.
Needed when:
• Tech is outdated.
• Software runs slow.
• Requirements have changed.
• Code is hard to manage.
SECTION C – LONG QUESTIONS (More Detailed Answers)
3a. Software Quality Attributes
These are the features that define how good software is:
1. Functionality – Does the right job.
2. Reliability – Works without crashing.
3. Usability – Easy to learn and use.
4. Efficiency – Uses less memory and CPU.
5. Maintainability – Easy to fix and update.
6. Portability – Can be used on different devices.
Each quality helps the software perform better for users and developers.
3b. SDLC and Its Activities
Software Development Life Cycle (SDLC) is the step-by-step way to build software.
1. Requirement Gathering – Understand what is needed.
2. Design – Plan the software structure.
3. Implementation – Code the software.
4. Testing – Check for bugs.
5. Deployment – Deliver to users.
6. Maintenance – Fix bugs, add features.
Following SDLC ensures better and timely delivery of software.
4a. Requirement Elicitation Techniques
Used to collect software requirements:
1. Interview – Ask users directly.
2. Questionnaire – Get written feedback.
3. Observation – Watch how users work.
4. Workshop – Group discussion.
5. Prototyping – Create a sample version.
6. Document Study – Read existing materials.
These help understand what users really want.
4b. SEI CMM vs ISO 9000 + CMM Levels
Feature SEI CMM ISO 9000
Focus Software process quality Product quality
Use For software companies For all types of companies
Levels 5 maturity levels No levels
CMM Levels:
1. Initial – No process, chaotic.
2. Repeatable – Some planning.
3. Defined – Standard process used.
4. Managed – Measure and control.
5. Optimizing – Continuous improvement.
5a. Cohesion and Coupling
• Cohesion – How well tasks in one module are related.
o Functional (best): One clear task.
o Sequential: Output of one is input to next.
o Communicational: Same data used.
o Procedural: Steps in order.
o Temporal: Done at same time.
o Logical: Similar functions selected by user.
o Coincidental (worst): Random group.
• Coupling – Connection between modules.
o Data (best): Only data shared.
o Stamp: Share part of a data structure.
o Control: Share control info.
o Common: Share global data.
o Content (worst): One uses internals of another.
Good design = High Cohesion + Low Coupling
5b. Software Size Metrics
Used to estimate effort and cost.
1. LOC – Count code lines.
2. Function Points – Based on user inputs, outputs, and files.
3. Cyclomatic Complexity – Counts number of code paths.
4. Halstead Metrics – Uses operators and operands.
Helpful in planning and comparing software.
6a. Test Cases for Prime Number Program
Input range: [1, 100]
1. Boundary Value Testing
o Values: 1, 2, 99, 100
2. Robust Testing
o Include invalid values: 0, 101, -1
3. Worst-Case Testing
o Combine all edge and middle values
Example:
• Input 2 → Prime
• Input 4 → Not Prime
• Input 101 → Invalid
6b. Integration Testing Approaches
Check if modules work together.
1. Top-Down
o Start from main module using stubs.
2. Bottom-Up
o Start from lower modules using drivers.
3. Sandwich
o Mix of both.
4. Big Bang
o All at once. Hard to debug.
7a. Software Maintenance
Changes made after software is delivered.
1. Corrective – Fix errors.
2. Adaptive – Support new systems.
3. Perfective – Improve performance.
4. Preventive – Avoid future issues.
Needed for fixing bugs, adding features, or updating tech.
7b. COCOMO Model and Person Month
COCOMO estimates software effort based on size.
• Basic: Uses only LOC.
• Intermediate: Includes other factors.
• Detailed: Phase-wise estimation.
Formula:
Effort = a × (KLOC)^b
Person Month (PM):
• 1 person working for a month.
• Used to measure project effort.
Example:
If project size is 10 KLOC and a = 2.4, b = 1.05:
Effort ≈ 2.4 × (10)^1.05 = 25 PM
