THEORY EXAMINATION (SEM–VI) 2016-17 SOFTWARE ENGINEERING

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

(e) Verification vs Validation

(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

(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

(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

Q5. Software Process Models

(i) Waterfall Model                                              • Linear sequential model
• Each phase completed before next                  • Simple & easy to manage
• Rigid, less flexible

(ii) Spiral Model                                                   • Risk-driven iterative model
• Combines waterfall & prototyping                   • Suitable for large, complex systems
• Costly and complex