About this previous year paper
SOFTWARE ENGINEERING (ECS602)
Section-wise Solved Answers & Notes
SECTION – A (10 × 2 = 20 Marks)
Very short & precise answers
(a) Software crisis
The software crisis refers to difficulty in developing reliable, large, and maintainable software on time and within budget, observed mainly in the 1960s–70s.
(b) Major software characteristics
• Intangible • Developed, not manufactured
• Does not wear out • Highly complex
• Easy to modify (maintenance intensive)
(c) Methods of requirements elicitation
• Interviews • Questionnaires
• Observation • Workshops/JAD
• Prototyping • Document analysis
(d) Software vs Software Engineering
| Software | Software Engineering |
|---|---|
| Program or product | Systematic development process |
| Code-focused | Process-focused |
| No standard method | Uses models & standards |
(e) Verification vs Validation
| Verification | Validation |
|---|---|
| “Are we building the product right?” | “Are we building the right product?” |
| Process-oriented | Product-oriented |
| Reviews & inspections | Testing |
(f) Classification of software design
• Architectural design • Interface design
• Component-level design • Data design
(g) Major software design tools
• Data Flow Diagram (DFD) • Structure Charts
• Pseudocode • Flowcharts
• UML diagrams
(h) Names of design principles • Abstraction
• Modularity • Information hiding
• Low coupling • High cohesion
(i) Top-down vs Bottom-up approach
| Top-down | Bottom-up |
|---|---|
| Start from main system | Start from components |
| Stepwise refinement | Component integration |
| Easier control | Better reuse |
(j) Software quality
Software quality is the degree to which software meets stated and implied requirements, such as reliability, efficiency, usability, and maintainability.
SECTION – B (Attempt Any Five) (5 × 10 = 50 Marks)
(a) Formal Technical Review (FTR)
FTR is a systematic peer review of software artifacts (requirements, design, code).
Should it assess style & correctness?
Yes, because:
Programming style improves readability and maintainability
Correctness ensures functional accuracy
Both are essential for long-term quality.
(b) ISO vs SEI-CMM
| ISO 9001 | SEI-CMM |
|---|---|
| Quality standard | Process maturity model |
| Certification-based | Improvement-based |
| Product + process | Process focused |
(c) Risk management & types of risks
Risk management: Identifying, analyzing, and mitigating risks.
Project risks: Schedule, cost, resources
Technical risks: Technology, performance, integration
(d) Data Flow Diagram (DFD) DFD shows flow of data through a system.
Rules for good DFD:
• No data store to data store flow • Every process must have input & output
• Balance between levels
Example: Student registration system (Context → Level-1 DFD)
(e) Software Quality Assurance (SQA) with life cycle
SQA ensures quality at every SDLC phase.
Activities: • Standards definition
• Reviews & audits • Testing
• Documentation control
(f) Software Development Life Cycle (SDLC)
SDLC phases: Requirement analysis
Design Coding
Testing Deployment
Maintenance Each phase ensures controlled development.
(g) Characteristics of good SRS & specification types
Good SRS characteristics:
• Correct • Complete
• Unambiguous • Verifiable
• Consistent
Formal vs Informal specification:
• Formal: Precise, mathematical, less ambiguity • Informal: Easy to understand, flexible
(h) Characteristics of software process • Predictable
• Repeatable • Measurable
• Adaptable • Well-defined
SECTION – C (Attempt Any Two) (2 × 15 = 30 Marks)
Q3. Coupling and Cohesion
Coupling Degree of interdependence between modules.
Best coupling:
• Low coupling (data coupling)
Worst coupling:
• Content coupling
Cohesion Degree to which elements within a module belong together.
Best cohesion:
• Functional cohesion
Worst cohesion:
• Coincidental cohesion
Role in design:
Low coupling + High cohesion = better maintainability & reusability
Q4. Structure Charts
Structure charts show module hierarchy and interaction.
Rules for good structure charts: • Single entry & exit
• Clear module naming • Use data/control couples
• Avoid excessive fan-out
Example: Payroll processing system