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

UNIT 2: SOFTWARE ENGINEERING PROCESS & PRACTICES

1.0 Software Process Models & Life Cycle (SDLC)

1.1 Fundamentals & Necessity

• Software Crisis: A situation in the late 1960s characterized by projects consistently exceeding budgets, missing deadlines, delivering low-quality software, and failing to meet user needs.

  • Main Reasons: Increasing complexity, poor planning, inadequate requirements analysis, lack of standardized processes, and management challenges.

• Software Process: A structured set of activities, methods, practices, and transformations used to develop and maintain software. Its characteristics include being defined, repeatable, measurable, and controllable.

• Necessities of a Life Cycle Model:

  • Provides a common understanding of the development steps.

  • Enables management control and progress tracking.

  • Imposes discipline and order in a complex project.

  • Facilitates team coordination and role definition.

• Common Issues in Software Life Cycle: Unclear requirements, scope creep, unrealistic schedules/budgets, technical debt, poor communication, and inadequate testing.

1.2 Predictive (Plan-Driven) Models

• Iterative Waterfall Model:

  • A linear, sequential model where each phase must be completed before the next begins. It is "iterative" because it allows for feedback loops (typically from testing to design/requirements) to correct errors.

  • Phases & Activities:

    1. Requirements Analysis: Elicit, analyze, and document needs in an SRS.

    2. System/Software Design: Create architectural and detailed design specs.

    3. Implementation (Coding): Translate design into source code.

    4. Testing: Verify and validate the software against requirements.

    5. Maintenance: Correct faults, improve performance, or adapt to new environments.

  • [!TIP] Exam Focus: Be ready to draw and explain this model with its feedback loops.

• Prototyping Model:

  • A quick, incomplete version (prototype) of the system is built to understand unclear requirements.

  • Process: Identify basic requirements → Build initial prototype → User evaluates prototype → Refine requirements → Re-engineer prototype or build final system.

  • Used when requirements are ambiguous or volatile.

1.3 Agile & Adaptive Models

• Agile Process:

  • An iterative and incremental approach focusing on flexibility, customer collaboration, and rapid delivery of working software.

  • Agile Manifesto Values: Individuals & interactions > processes & tools; Working software > comprehensive documentation; Customer collaboration > contract negotiation; Responding to change > following a plan.

  • Principles: Welcome changing requirements, frequent delivery (weeks), close daily cooperation, sustainable development, technical excellence, simplicity.

• Extreme Programming (XP):

  • An agile methodology emphasizing engineering discipline.

  • Key Practices: Pair programming, Test-Driven Development (TDD), Continuous integration, Small frequent releases, On-site customer, Refactoring, Simple design.

  • Advantages: High-quality code, rapid feedback, adaptability to change, reduced risk.

• Comparison: Function-Oriented vs. Object-Oriented Development

  | Aspect | Function-Oriented (Procedural) | Object-Oriented (OO) | |---------------------|------------------------------------|----------------------------------------| | Primary Unit | Function/Procedure | Object/Class | | Data & Code | Separated (data passed as params) | Bundled together (encapsulation) | | Focus | Sequence of tasks (top-down) | Interactions between objects | | Reuse | Limited (library functions) | High (inheritance, polymorphism) | | Design Model | Data Flow Diagrams (DFDs) | Use Case, Class, Sequence Diagrams |

2.0 Project Planning & Cost Estimation

2.1 Project Planning

• Activities: Define project scope, estimate effort/cost, schedule tasks (Gantt/PERT charts), identify risks, plan resources (people, hardware, software), define quality standards, and establish communication plans.

• Importance: Provides a roadmap, sets realistic expectations, facilitates resource allocation, enables progress tracking, and mitigates risks early.

2.2 Cost Estimation Techniques

• Common Methods:

  • Expert Judgment: Based on experience.

  • Analytical/Model-Based: Use mathematical models (e.g., COCOMO).

  • Bottom-Up (Phase-Based): Estimate cost of each task, sum up.

  • Analogous/Comparative: Use data from similar past projects.

  • Parametric: Use statistical relationships (e.g., LOC, Function Points).

• Constructive Cost Model (COCOMO):

  • A parametric, regression-based model for estimating effort (person-months) and schedule.

  • Basic Formula (Organic Mode Example):

$$ Effort = a \times (Size)^b \times EAF \text{ person-months} $$

    Where:

    *   `Size` = estimated **KLOC** (Kilo Lines of Code).

    *   `a, b` = constants specific to project **mode**.

    *   `EAF` = **Effort Adjustment Factor** (product of 15 cost drivers like reliability, complexity, team experience).

*   **Three Project Modes (Categories):**

    | **Mode**         | **Description**                                      | **a**   | **b**   |

|------------------|------------------------------------------------------|---------|---------| | Organic | Small, familiar team, relaxed environment | 2.4 | 1.05 | | Semi-detached| Medium team, mix of experience, mixed requirements | 3.0 | 1.12 | | Embedded | Tightly coupled with hardware, strict regulations | 3.6 | 1.20 |

*   > [!TIP] **Exam Focus:** Memorize the formula and the three modes with their `a, b` values.

• LOC-Based Estimation:

  • Advantages: Simple, objective metric, good for maintenance cost estimation.

  • Disadvantages: Difficult to estimate early, depends on language, measures size not functionality, can incentivize verbose code.

• Function Point Analysis (FPA): Measures software functionality delivered to the user, independent of technology. Counts inputs, outputs, inquiries, files, interfaces, weighted by complexity.

3.0 Software Requirements Engineering

3.1 Requirements Elicitation & Analysis

• Ways & Means for Collecting Requirements:

  • Interviews: One-on-one or group.

  • Questionnaires/Surveys: For broad input.

  • Workshops/JAD Sessions: Joint application design with stakeholders.

  • Observation/Shadowing: Study user workflow.

  • Document Analysis: Study existing systems, procedures.

  • Prototyping: Build a mock-up to refine needs.

• Feasibility Study:

  • Types: Technical (can we build it?), Economic (cost-benefit analysis), Operational (will it be used?), Legal/Contractual, Schedule.

  • Outcomes: A Feasibility Report recommending "Go/No-Go" with justification, rough estimates, and identified risks.

  • Effect on Requirements: Explicitly shapes the scope. Economic/technical constraints directly filter and prioritize requirements. It sets the boundary for what will be analyzed in detail.

• Prototyping in Elicitation: Used to discover missing requirements and validate user interface ideas. Types: Throwaway/Rapid (discarded) and Evolutionary (built upon).

3.2 Requirements Specification

• Software Requirements Specification (SRS):

  • A formal, comprehensive document describing what the system must do, not how.

  • Typical Structure/Parts:

    1. Introduction (Purpose, Scope, Definitions)

    2. Overall Description (Product perspective, user characteristics, constraints, assumptions)

    3. Specific Requirements (Functional, Non-functional, Interface, Performance, Security, etc.)

    4. Appendices (Use cases, data dictionary, analysis models)

  • Five Desirable Characteristics (IEEE 830):

    1. Correct (accurately reflects user needs)

    2. Unambiguous (single interpretation)

    3. Complete (covers all necessary requirements)

    4. Consistent (no conflicts)

    5. Verifiable (can be tested/checked)

    6. Modifiable (easy to change)

    7. Traceable (source of each requirement known)

    (Any 5 from the common list)

• Organization & Representation:

  • Structured natural language with standard templates.

  • Data Dictionary: Central repository defining all data elements, structures, flows, and stores in the system. Ensures consistency and clarity.

3.3 Requirements Validation

• Verification vs. Validation (V&V):

  • Verification: "Are we building the product right?" → Conformance to specifications. (e.g., Reviews, walkthroughs, static analysis).

  • Validation: "Are we building the right product?" → Conformance to user needs. (e.g., Testing, demonstrations).

• Formal Technical Review (FTR):

  • A peer review process where a team examines a work product (like SRS) for defects.

  • Participants: Author, moderator, recorder, reviewers (3-5 people).

  • Process: Overview → Preparation → Review meeting → Rework → Follow-up.

  • Outcome: List of defects, decisions, and action items. Aims to improve quality and find errors early.

4.0 Software Design

4.1 Design Concepts & Principles

• "Design is not coding and coding is not design":

  • Design is the abstraction at a higher level (architecture, modules, interfaces). It answers "what are the components and how do they interact?"

  • Coding is the implementation in a specific programming language. It is the detailed translation of the design.

  • Good design enables easier coding, testing, and maintenance.

• Architectural Design vs. Procedural Design:

  • Architectural Design (High-level): Defines the system's structure, major components, their relationships, and design principles (e.g., client-server, layered). Focuses on non-functional requirements.

  • Procedural/Detailed Design (Low-level): Specifies the internal logic of each component/module (algorithms, data structures). Focuses on functional requirements.

• Cohesion: The intra-module strength. Measures how closely related and focused the responsibilities of a single module are.

  • Types (High to Low): Functional, Sequential, Communicational, Procedural, Temporal, Logical, Coincidental.

• Coupling: The inter-module strength. Measures the degree of interdependence between modules.

  • Types (Low to High): Data, Stamp, Control, External, Common, Content. Aim for low coupling.

4.2 Design Modeling

• Use Case Diagrams: Capture functional requirements by showing actors (users/external systems) and their interactions (use cases) with the system.

  • Example: ATM System

    DiagramSEARCH: "ATM use case diagram example"

    • Actors: Customer, Bank, Maintenance Technician.

    • Use Cases: Withdraw Cash, Deposit, Check Balance, Maintain ATM (for technician).

• Data Flow Diagrams (DFDs): Show data movement between processes, data stores, and external entities. (Context Level → Level 0 → Level N).

• Entity-Relationship Diagrams (ERDs): Model data and relationships between entities in a database.

5.0 Software Testing

5.1 Testing Fundamentals

• Verification vs. Validation (Reiterated):

  • Verification: Static techniques (reviews, inspections) to find defects early. "Build the product right."

  • Validation: Dynamic execution of software to find defects. "Build the right product."

• Black-Box Testing Techniques: Test based on specifications without knowing internal code.

  • Boundary Value Analysis (BVA): Test at the edges of input domains (min, max, just inside/outside boundaries, nominal values).

    • Example 1: For an input field accepting integers 1-100, test: 0, 1, 2, 99, 100, 101.

    • Example 2: For a date field accepting 01/01/2000 to 31/12/2025, test: 31/12/1999, 01/01/2000, 02/01/2000, 30/12/2025, 31/12/2025, 01/01/2026.

5.2 Levels of Testing

• Unit Testing:

  • Tests individual units/modules (functions, methods) in isolation.

  • Usually done by developers using stubs (for called modules) and drivers (for calling modules).

• Integration Testing:

  • Tests interfaces and interactions between integrated units/modules.

  • Strategies:

    1. Big Bang: All units integrated at once → High risk, hard to debug.

    2. Top-Down: Start from top-level modules, use stubs → Good for early architecture demo.

    3. Bottom-Up: Start from low-level modules, use drivers → Good for early functionality testing.

    4. Sandwich/Hybrid: Combines top-down and bottom-up.

  • Outcomes: Detection of interface mismatches, data flow errors, and module interaction bugs.

• System Testing:

  • Tests the complete, integrated system against its non-functional and functional requirements.

  • Conducted in an environment that mirrors production.

  • Case Study: Operating System (OS) Testing:

    • Functional: Process scheduling, memory management, file system operations, I/O handling.

    • Non-Functional: Performance (boot time, throughput), Security (user isolation), Reliability (mean time between failures), Compatibility (hardware drivers).

• Differentiation: Unit vs. System Testing

  | Aspect | Unit Testing | System Testing | |------------------|-------------------------------------------|-----------------------------------------| | Scope | Single module/function | Entire integrated system | | Performed By | Developers | Independent QA/test team | | Basis | Design specs, internal logic | SRS, user needs | | Focus | Code correctness, logic errors | End-to-end functionality, requirements | | Test Basis | White-box (often) | Black-box |

6.0 Software Maintenance & Re-engineering

6.1 Maintenance Process

• Activities:

  1. Problem Identification & Analysis: Log and categorize the request (corrective, adaptive, perfective, preventive).

  2. Implementation: Modify code, documentation, or data.

  3. Regression Testing: Re-test to ensure changes didn't break existing functionality.

  4. Delivery/Deployment: Release the updated version.

  5. Review/Audit: Post-maintenance review for process improvement.

• Detailed Process: A cyclic process triggered by a change request → Analysis → Design modification → Implementation → Testing → Delivery → Feedback. Requires configuration management to track versions and changes.

6.2 Software Re-engineering

• What is Re-engineering? The examination and alteration of an existing system to reconstitute it in a new form. It is not just maintenance; it's a restructuring effort.

• Process: Often follows the "Re-engineering Cycle":

  Inventory Analysis → Restructuring → Reverse Engineering → Forward Engineering (Reconstruction)

• Reverse Engineering: Analyzing an existing system to identify its components and interrelationships and to create representations at a higher level of abstraction (e.g., extracting design from code, generating DFDs from a running system).

• Forward Engineering: The traditional process of developing new software from scratch using the recovered high-level abstractions (e.g., using the new design to build a modern system).

• Goal: Improve maintainability, extensibility, and performance while preserving functionality. Often done to migrate legacy systems to modern platforms/languages.