Intellectual Property Rights (IT-604 (A)) - Unit 3 Short Notes

UNIT 3: SOFTWARE ENGINEERING PROCESS & LIFE CYCLE MODELS

I. Introduction & Software Crisis

Software Engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.

Software Crisis refers to the difficulties and problems encountered in the late 1960s while developing large software systems.
Causes:

• Increasing complexity of software.

• Lack of systematic development approaches.

• Unrealistic schedules and budgets.

• Poor quality and maintainability.

• Inadequate requirements analysis.

• Rapid hardware advancement outpacing software methods.

Necessities of a Life Cycle Model:

• Provides a structured framework for development.

• Ensures completeness and consistency.

• Facilitates planning, scheduling, and resource allocation.

• Improves communication among stakeholders.

• Enables better management of changes and risks.

Key Issues in Software Life Cycle:

• Quality: Meeting user needs reliably.

• Cost: Budget overruns due to poor estimation.

• Time: Delays from unrealistic planning.

• Maintenance: High cost (60-80% of total) due to poor design.

[!TIP]

Exam Focus: Be ready to list at least 4 causes of software crisis and 4 issues in life cycle. Link crisis to the need for engineering principles.

II. Software Process Models (SDLC Models)

Waterfall Model

A linear sequential model where each phase must be completed before the next begins.
Phases:

1. Requirements Analysis

2. System Design

3. Implementation (Coding)

4. Testing

5. Deployment

6. Maintenance

Iterative Waterfall: Adds feedback loops from later phases to earlier ones (e.g., testing → design). Allows refinement but still document-driven.

Prototyping Model

Build a quick, simplified version (prototype) to understand requirements.
Types:

• Throwaway Prototyping: Built for understanding, then discarded.

• Evolutionary Prototyping: Continuously refined into final system.

Prototype Preparation:

1. Identify basic requirements.

2. Build prototype (using tools like scripting, mock-ups).

3. User evaluates and provides feedback.

4. Refine or rebuild based on feedback.

Agile Process Models

Based on 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.

Extreme Programming (XP):

• Practices: Pair programming, test-driven development (TDD), continuous integration, small releases, refactoring, collective ownership.

• Advantages: High adaptability, rapid feedback, improved quality, customer satisfaction.

• Disadvantages: Less documentation, requires high customer involvement, scalability challenges.

[!TIP]

Common Pitfall: Do not confuse iterative waterfall with agile. Waterfall iterations are phase-based; agile iterations deliver working software frequently.

Other Models (Brief)

• Spiral Model: Risk-driven, combines waterfall and prototyping. Each spiral = planning → risk analysis → engineering → evaluation.

• Incremental Model: Delivers system in increments (functional slices). Each increment goes through full SDLC.

• RAD (Rapid Application Development): Emphasizes rapid prototyping and iterative development with minimal planning.

III. Requirements Engineering

Requirements Elicitation/Collection Methods:

• Interviews: Structured/unstructured with stakeholders.

• Surveys/Questionnaires: For large user groups.

• Observation: Study users in their environment.

• Workshops/JAD Sessions: Group meetings for consensus.

• Document Analysis: Review existing systems, policies.

Organizing & Representing Requirements:

• Use Cases: Describe interactions between actor and system.

• Use Case Diagrams: Visual representation (actors, use cases, system boundary).

  Example: ATM system – actors: Customer, Bank, Maintenance; use cases: Withdraw, Deposit, Balance Inquiry.

  DiagramCANVAS: Simple ATM use case diagram with Customer actor linked to Withdraw, Deposit, Balance Inquiry use cases inside system boundary.

Feasibility Study:

• Types:

  • Technical: Can it be built with current tech?

  • Economic: Cost-benefit analysis (ROI, NPV).

  • Operational: Will it be used? Organizational fit.

  • Legal: Compliance with laws/regulations.

• Outcomes: Go/No-Go decision, refined requirements, risk identification.

• Effect on Requirements: Explicitly shapes scope; implicit assumptions are validated. High cost may lead to requirement prioritization.

Software Requirements Specification (SRS):

• Purpose: Single source of truth for requirements; contract between client and developer.

• Characteristics (ISO/IEC 9126): Correct, unambiguous, complete, consistent, ranked for importance/priority, verifiable, modifiable, traceable.

• Typical Structure (IEEE 830):

  1. Introduction (purpose, scope, definitions)

  2. Overall Description (product perspective, user characteristics, constraints)

  3. Specific Requirements (functional, non-functional, interface)

  4. Appendices (supporting info)

Data Dictionary:

Central repository of metadata about data elements (names, aliases, descriptions, formats, allowed values). Used in requirements analysis to ensure consistency and resolve conflicts.

[!TIP]

Exam Focus: Always list at least 5 characteristics of a good SRS. For feasibility, distinguish between technical (can we build?) and operational (will they use?).

IV. Software Design

"Design is not coding and coding is not design" – Justification:

• Design is high-level abstraction (what the system does, components, interfaces). Focuses on architecture, modules, data structures.

• Coding is implementation detail (how components are written in a language).

• Good design enables efficient coding; poor design leads to tangled, unmaintainable code.

Design Principles:

• Abstraction: Hide complexity; show only essential features.

• Modularity: Divide system into manageable, independent modules.

• Information Hiding: Modules hide internal details; expose only necessary interfaces.

Design Quality Metrics:

Design Types:

• Architectural Design (High-level): System structure, major components, relationships, technology choices.

• Procedural/Detailed Design (Low-level): Internal logic of each module, algorithms, data structures.

Function-Oriented vs. Object-Oriented Design:

V. Software Cost Estimation

Need & Challenges:

• Need: Budgeting, resource planning, bid proposals.

• Challenges: Uncertainty, human factors, technology volatility, incomplete requirements.

LOC (Lines of Code) Based Estimation:

• Method: Count source lines; use historical productivity (LOC/person-month).

• Advantages: Simple, language-dependent metrics available.

• Disadvantages: Language-dependent (C vs. Python), hard to estimate early, ignores functionality, quality issues.

COCOMO (Constructive Cost Model):

• Purpose: Estimate effort (person-months) and schedule (months) based on size (KLOC) and project type.

• Effort Equation:

$$E = a \cdot (KLOC)^b \cdot EAF$$

where:

• $E$ = Effort in person-months

• $a, b$ = Constants from table (below)

• $KLOC$ = Estimated size in thousands of lines of code

• $EAF$ = Effort Adjustment Factor (product of 15 cost drivers, 1.0 average)

• Schedule Equation:

$$T = c \cdot (E)^d$$

where $T$ = Development time in months, $c, d$ = Constants.

• Project Categories (Organic, Semi-detached, Embedded):

Other Estimation Methods:

• Use Case Points: Based on number and complexity of use cases, actor complexity, technical/environmental factors.

• Expert Judgment: Delphi technique, group consensus.

• Analytical/Parametric: Based on mathematical models (COCOMO is parametric).

[!TIP]

Exam Focus: Memorize the three COCOMO modes and their a, b values. Remember EAF adjusts for product, platform, personnel, project attributes (e.g., required reliability, complexity).

VI. Software Testing

Fundamentals:

• Verification: "Are we building the product right?" (Conformance to specs).

• Validation: "Are we building the right product?" (Fulfills user needs).

Levels of Testing:

1. Unit Testing: Test individual modules/components in isolation. Focus: internal logic, paths, data flow.

2. Integration Testing: Test interactions between integrated modules.

   • Strategies:

     • Big Bang: All modules integrated at once → high risk.

     • Top-Down: Start from top (main control); use stubs for lower modules.

     • Bottom-Up: Start from bottom (utility modules); use drivers.

     • Sandwich/Hybrid: Combination of top-down and bottom-up.

   • Outcomes: Interface errors, data flow issues.

3. System Testing: Test complete, integrated system against requirements.

   • Case Study (OS): Test boot process, process scheduling, memory management, file system, device drivers, security, recovery. Performed in target hardware environment.

Testing Techniques:

• Black-Box Testing: Based on specifications without code knowledge.

  • Boundary Value Analysis (BVA): Test at boundaries of input domains (just below, on, just above).

    Example 1: Input range 1–100 → test: 0, 1, 2, 99, 100, 101.

    Example 2: Password length 8–16 chars → test: 7, 8, 9, 15, 16, 17.

• White-Box Testing: Based on code structure (statement coverage, branch coverage, basis path testing).

Functional Testing (FTR):

• Explanation: Black-box testing where test cases are derived from functional requirements/specs.

• Process:

  1. Identify functions from SRS.

  2. For each function, determine input conditions.

  3. Design test cases to exercise each condition.

  4. Execute and compare actual vs. expected output.

  5. Log defects.

[!TIP]

Common Pitfall: In BVA, always test just outside boundaries (e.g., 0, 101 for 1–100). Do not test only valid boundaries (1, 100).

VII. Software Maintenance & Re-engineering

Maintenance Process & Types:

1. Corrective: Fix defects found after release.

2. Adaptive: Modify for environment changes (OS, hardware, regulations).

3. Perfective: Enhance performance, usability, maintainability.

4. Preventive: Proactive changes to prevent future problems (e.g., code refactoring).

Re-engineering:

• Definition: Restructuring or rewriting existing system to improve quality, often using new technology.

• Need: Legacy systems obsolete, high maintenance cost, new platform requirements.

• Process:

  1. Reverse Engineering: Analyze existing system to understand its structure and function (create higher-level abstractions).

  2. Restructuring: Transform representation (e.g., code restructuring, data reorganization) without changing functionality.

  3. Forward Engineering: Rebuild system using new specifications/architecture.

Software Reverse Engineering:

• Process of analyzing software to identify components, relationships, and recover design/requirements. Tools: disassemblers, decompilers, static analyzers.

VIII. Software Project Planning & Management

Project Planning Activities:

1. Scope Definition: Boundaries, deliverables, exclusions.

2. Effort & Cost Estimation: Using models (COCOMO, FP).

3. Scheduling: Milestones, Gantt charts, critical path.

4. Risk Planning: Identify, assess, mitigate risks.

5. Quality Plan: Standards, reviews, testing strategy.

6. Configuration Management Plan: Version control, change control.

7. Staffing & Resource Plan: Team structure, training, tools.

Importance of Project Planning:

• Sets realistic expectations.

• Allocates resources efficiently.

• Identifies risks early.

• Provides baseline for monitoring and control.

• Reduces uncertainty and chaos.

Metrics in Software Project Management:

• Size: KLOC, Function Points (FP).

• Effort: Person-months.

• Schedule: Months, milestone dates.

• Quality: Defect density (defects/KLOC), test coverage.

• Productivity: LOC/person-month, FP/person-month.

• Cost: Cost per FP, total cost.

[!TIP]

Exam Focus: Distinguish planning (what to do) from scheduling (when to do). For metrics, know definitions: Function Points measure functionality independent of language; defect density = total defects / size.