Wireless Sensor Networks (IT-604 (C)) - Unit 2 Short Notes

UNIT 2: SOFTWARE ENGINEERING LIFECYCLE & PRACTICES

I. SOFTWARE PROCESS MODELS & LIFE CYCLE

A. Fundamental Concepts

• Software Crisis: A term used in the late 1960s to describe the escalating problems in software development, characterized by projects that were consistently over budget, behind schedule, and of poor quality. Main reasons included:

  • Increasing complexity of software.

  • Lack of disciplined engineering practices.

  • Poor project management and estimation.

  • Inadequate requirements analysis.

• Software Process: A structured set of activities required to develop, deliver, and maintain a software product. It provides a framework for managing the complexity of software development.

• Necessities of a Life Cycle Model:

  • Provides a common understanding of the development process.

  • Enables planning, scheduling, and budgeting.

  • Establishes checkpoints for management review.

  • Facilitates resource allocation and team coordination.

  • Helps in risk identification and mitigation.

• Issues of Software Life Cycle:

  • Choosing the right model for the project context.

  • Handling changing requirements.

  • Accurate estimation of cost, time, and resources.

  • Ensuring quality throughout the process.

  • Managing risks and uncertainties.

B. Predictive (Plan-Driven) Models

• Iterative Waterfall Model:

  • A linear, sequential model where each phase must be completed before the next begins. Phases flow downwards like a waterfall.

  • Phases & Activities:

    1. Requirement Analysis: Gather and analyze requirements; produce SRS.

    2. System Design: Define system architecture, hardware/software specs; produce SDD.

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

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

    5. Deployment & Maintenance: Install, train users, and fix issues.

  • [!TIP] Common Pitfall: Assumes requirements are stable and fully understood upfront, which is rarely true. Changes are costly to implement late in the cycle.

• Prototyping Model:

  • A rapid, throwaway prototype is built to understand unclear or incomplete requirements.

  • Technique:

    1. Identify basic, known requirements.

    2. Quickly build an initial prototype (focus on UI/UX, not robustness).

    3. User interacts with prototype, provides feedback.

    4. Refine requirements based on feedback.

    5. Discard prototype and develop the final system using the refined requirements.

  • Useful for user interface-heavy systems and when requirements are ambiguous.

C. Agile & Evolutionary Models

• Agile Process:

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

  • Core Principles (Agile Manifesto):

    • Individuals and interactions over processes and tools.

    • Working software over comprehensive documentation.

    • Customer collaboration over contract negotiation.

    • Responding to change over following a plan.

  • Emphasizes small, cross-functional teams, frequent releases (sprints), and continuous feedback.

• Extreme Programming (XP):

  • A specific agile methodology that takes best practices to "extreme" levels.

  • Key Practices:

    • Pair Programming: Two developers work together at one workstation.

    • Test-Driven Development (TDD): Write tests before writing functional code.

    • Continuous Integration: Integrate and test code multiple times a day.

    • Small Releases: Release useful functionality in very short iterations (1-2 weeks).

    • On-site Customer: A real user is part of the team full-time.

  • Advantages: High code quality, rapid feedback, adaptability to changing requirements, strong customer involvement.

D. Model Differentiation

• Function-Oriented vs. Object-Oriented Development:

II. REQUIREMENTS ENGINEERING

A. Requirements Elicitation & Analysis

• Feasibility Studies:

  • Conducted before full-scale requirements gathering to assess project viability.

  • Types:

    • Technical: Can it be built with current/available tech?

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

    • Operational: Will it be used effectively in the organization?

    • Schedule: Can it be built in time?

    • Legal/Contractual: Compliance with laws/contracts.

  • Outcomes: A Feasibility Report recommending "Go/No-Go" and outlining major constraints/risks.

  • Effect on Requirements: Direct and explicit. Feasibility findings filter and shape the scope of requirements. Economic constraints limit features; technical constraints define platform choices.

• Ways & Means for Collecting Requirements:

  • Interviews: One-on-one or group discussions.

  • Questionnaires/Surveys: For large user bases.

  • Workshops/JAD Sessions: Structured group meetings with stakeholders.

  • Observation/Shadowing: Watching users in their work environment.

  • Document Analysis: Studying existing manuals, forms, systems.

  • Prototyping: As discussed above.

  • Use Case Modeling: Capturing functional requirements via scenarios.

• Organization & Representation:

  • Requirements are organized into a hierarchical structure (e.g., Feature -> Sub-feature -> Requirement).

  • Represented in natural language, structured templates, or models (like use case diagrams, data flow diagrams).

  • Stored in a Requirements Management Tool or a Requirements Specification Document (SRS).

B. Requirements Specification

• Software Requirements Specification (SRS):

  • A formal, comprehensive document that describes the complete software system to be developed.

  • Typical Structure (IEEE 830 Standard):

    1. Introduction (Purpose, Scope, Definitions)

    2. Overall Description (Product Perspective, User Characteristics, Constraints)

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

    4. Other Requirements (e.g., Legal, Regulatory)

  • Desirable Characteristics of a Good SRS:

    • Correct & Complete: All requirements are stated accurately and nothing is missing.

    • Unambiguous: Single, clear interpretation.

    • Consistent: No conflicting requirements.

    • Verifiable: Can be tested/inspected to confirm implementation.

    • Modifiable: Easy to change without affecting other parts.

    • Traceable: Each requirement can be traced to its source and to design/code/test artifacts.

C. Supporting Techniques

• Use Case Modeling:

  • A technique for capturing functional requirements by describing system interactions with actors (users or external systems).

  • Use Case Diagram Components:

    • Actor: Role played by a user or external system.

    • Use Case: A discrete piece of functionality the system provides (oval).

    • System Boundary: Box enclosing all use cases.

    • Associations: Lines connecting actors to use cases.

  • ATM Example:

    • Actors: Customer, Bank, Maintenance Staff.

    • Use Cases: Withdraw Cash, Check Balance, Deposit, Maintain ATM.

    • Withdraw Cash may include relationships like <<include>> (e.g., Validate Card) or <<extend>> (e.g., Print Receipt).

III. SOFTWARE DESIGN

A. Design Fundamentals

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

  • Design is the plan or blueprint of the software. It defines the architecture, components, interfaces, and data structures at a high level of abstraction. It answers "what are the parts and how do they relate?"

  • Coding is the implementation of that design in a specific programming language. It is a detailed, low-level activity focused on syntax and algorithms.

  • Justification: Good design leads to maintainable, scalable, and testable code. Starting to code without a design leads to spaghetti code, poor structure, and high maintenance cost. Design decisions (e.g., module decomposition) are independent of coding language specifics.

• Architectural Design vs. Procedural Design:

  • Architectural Design (High-Level): Defines the system's overall structure, major components, their responsibilities, and how they communicate (e.g., client-server, layered, microservices). Focuses on non-functional requirements (performance, security).

  • Procedural Design (Low-Level/Detailed): Defines the internal logic of each component/module. Specifies algorithms, data structures, and exact control flow. Focuses on functional implementation.

B. Design Quality Metrics

• Cohesion: The degree of relatedness of the responsibilities within a single module.

  • Types (High to Low):

    1. Functional: Module performs a single, well-defined task (e.g., calculateTax()).

    2. Sequential: Output of one part is input to another.

    3. Communicational: Parts operate on the same data.

    4. Procedural: Elements are ordered in a specific sequence.

    5. Temporal: Elements are related by timing (e.g., initializeAll()).

    6. Logical: Elements are logically related but perform different functions (e.g., getInput() that reads keyboard, mouse, file).

    7. Coincidental: No meaningful relationship (worst).

  • Goal: Maximize functional cohesion.

• Coupling: The degree of interdependence between modules.

  • Types (Low to High):

    1. Data Coupling: Modules share simple data (e.g., integers, strings).

    2. Stamp Coupling: Modules share composite data (e.g., a record) but use only parts of it.

    3. Control Coupling: One module passes control flags to another.

    4. Common Coupling: Modules share global data.

    5. Content Coupling: One module modifies the internal code/data of another (worst).

  • Goal: Minimize coupling, aiming for data coupling.

C. Design Documentation

• Data Dictionary:

  • A centralized repository of metadata (data about data) for all data elements used in the system.

  • Purpose & Use:

    • Consistency: Ensures uniform naming, definition, and format of data across all design documents (DFDs, ER diagrams, structure charts).

    • Reference: Single source of truth for data element attributes (name, type, size, range, source, owner).

    • Analysis: Helps identify data flow, redundancy, and relationships.

    • Communication: Common vocabulary for designers, developers, and DBAs.

IV. SOFTWARE COST ESTIMATION

A. Estimation Methods Overview

• Expert Judgment: Based on experience of experts (subjective, prone to bias).

• Analytical (Bottom-Up): Break project into small tasks, estimate each, sum up (accurate but time-consuming).

• Analogous (Top-Down): Use historical data from similar past projects (quick, less accurate if projects differ).

• Parametric: Use mathematical models with cost drivers (e.g., LOC, FP, team experience).

• COCOMO & FP-based: Specific parametric models.

B. Model-Based Estimation

• Constructive Cost Model (COCOMO):

  • A parametric, regression-based model that estimates effort (person-months) and schedule based on software size (KLOC) and project attributes.

  • Basic Formula:

$$Effort = a \times (Size)^b \quad [person-months]$$

$$Tdev = c \times (Effort)^d \quad [months]$$

    Where `a, b, c, d` are constants depending on project **mode**.

*   **Categories of Software (Modes):**

    1.  **Organic (Simple):** Small teams, familiar environment, relaxed requirements. (`a=2.4, b=1.05, c=2.5, d=0.38`)

    2.  **Semi-detached (Medium):** Mix of experienced/inexperienced, mixed requirements. (`a=3.0, b=1.12, c=2.5, d=0.35`)

    3.  **Embedded (Complex):** Tight hardware/software integration, stringent regulations. (`a=3.6, b=1.20, c=2.5, d=0.32`)

*   **Effort Adjustment (EAF):** The basic estimate is multiplied by an **Effort Adjustment Factor** based on 15 **cost drivers** (e.g., RELY - required reliability, TIME - execution time constraint, ACAP - analyst capability, etc.). Each driver has a scale (Very Low to Extra High) with a multiplier.

$$Effort_{adjusted} = Effort_{basic} \times EAF$$

C. Size-Based Estimation

• Lines of Code (LOC) Based Estimation:

  • Method: Count or estimate the number of source lines in the final delivered code. Use this Size in models like COCOMO.

  • Advantages:

    • Simple, intuitive concept.

    • Directly measurable after completion (for calibration).

    • Well-established historical databases exist.

  • Disadvantages:

    • Highly language-dependent (100 LOC in C ≠ 100 LOC in Python).

    • Difficult to estimate early in the lifecycle.

    • Encourages "code bloat" (more LOC = higher estimate, may incentivize verbose code).

    • Does not capture complexity or functionality well.

    • Varies greatly with programmer skill and coding style.

V. SOFTWARE TESTING

A. Testing Fundamentals

• Verification vs. Validation (V&V):

  • Verification ("Are we building the product right?"): Process of evaluating software to determine whether it satisfies specified requirements. Focus on processes and documentation. (e.g., Reviews, Inspections, Static Analysis).

  • Validation ("Are we building the right product?"): Process of evaluating software during or at the end of development to determine whether it satisfies stakeholder needs and requirements. Focus on the actual product. (e.g., Functional Testing, System Testing).

  • Key Difference: Verification checks conformance to specs; Validation checks fitness for use.

B. Testing Levels

• Unit Testing:

  • Definition: Testing of individual units/components (smallest testable parts) in isolation.

  • Scope: Typically performed by developers on their own code. Uses stubs (for called modules) and drivers (for calling modules). Focuses on code logic, paths, and conditions.

• Integration Testing:

  • Definition: Testing of combined units/components to verify their interactions and interfaces.

  • Strategies:

    • Big Bang: All units integrated at once and tested (high risk, hard to debug).

    • Top-Down: Start from top-level modules, use stubs, integrate downwards.

    • Bottom-Up: Start from bottom-level modules, use drivers, integrate upwards.

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

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

• System Testing:

  • Definition: Testing of the complete, integrated system to verify it meets the specified functional and non-functional requirements.

  • Scope: Performed by independent test team in an environment mirroring production. Includes functional, performance, security, usability, recovery testing.

  • Case Study (Operating System):

    • Functional: Test file operations (create, delete, copy), process scheduling, memory management APIs.

    • Performance: Boot time, application launch time, I/O throughput.

    • Security: User authentication, access control, privilege escalation.

    • Compatibility: Run applications from different vendors, support various hardware.

    • Recovery: System crash recovery, power failure handling.

• Differentiation: Unit vs. System Testing:

  | Aspect | Unit Testing | System Testing | | :--- | :--- | :--- | | Focus | Individual code units | Complete integrated system | | Performed By | Developers | Independent Test Team | | Test Basis | Detailed design, code | SRS, System Requirements | | Test Environment | Developer's workstation | Staging/Production-like | | Test Type | White-box (mostly) | Black-box (mostly) | | Defects Found | Logic errors, syntax | Requirement gaps, interface, non-functional |

C. Testing Techniques

• Boundary Value Analysis (BVA):

  • A black-box test design technique based on the principle that errors often occur at boundaries of input domains.

  • For a range [min, max], test values are: min-1, min, min+1, max-1, max, max+1.

  • Example 1: Input field accepts age 18-60.

    • Test values: 17, 18, 19, 59, 60, 61.

  • Example 2: Password length 8-16 characters.

    • Test values: 7, 8, 9, 15, 16, 17.

D. Quality Assurance Review

• Formal Technical Review (FTR):

  • A structured, peer review process to evaluate a software product (e.g., SRS, design, code) for quality and correctness.

  • Participants: Author, Moderator (leads), Recorder (notes), Reviewers (2-5 experts).

  • Process:

    1. Planning: Define scope, distribute materials.

    2. Overview: Author presents product.

    3. Preparation: Reviewers examine product individually.

    4. Review Meeting: Discuss findings, identify defects.

    5. Rework & Follow-up: Author fixes defects; moderator verifies.

  • Goal: Find defects early, ensure conformance to standards, improve product quality and team knowledge. More formal than a "walkthrough".

VI. SOFTWARE PROJECT MANAGEMENT

A. Project Planning

• Different Activities in Project Planning:

  1. Scope Planning: Define and document project scope, deliverables, and boundaries (SOW).

  2. Schedule Planning: Develop project schedule using techniques like Gantt charts, PERT/CPM. Define milestones.

  3. Cost Estimation & Budgeting: Use techniques (COCOMO, LOC) to estimate cost and allocate budget.

  4. Resource Planning: Identify and schedule human resources, hardware, software.

  5. Risk Planning: Identify risks, assess probability/impact, plan mitigation strategies.

  6. Quality Planning: Define quality standards and procedures (e.g., FTR, testing strategy).

  7. Communication Planning: Define information flow, reporting structure, meeting schedules.

  8. Procurement Planning: Decide what to buy/build, vendor selection.

• Importance of Project Planning:

  • Provides a roadmap for the project team.

  • Enables realistic commitment to schedule and budget.

  • Facilitates coordination among team members and stakeholders.

  • Establishes baselines for monitoring and control.

  • Proactive risk management.

  • Increases likelihood of project success.

B. Maintenance

• Maintenance Process:

  • A post-deployment activity to modify the software after delivery.

  • Process Steps:

    1. Problem Identification & Analysis: User reports issue; analyze if it's a bug, enhancement, or new requirement.

    2. Change Request (CR) Logging: Formal record of the requested change.

    3. Impact Analysis: Assess effect of change on design, code, documentation, schedule, cost.

    4. Change Implementation: Design, code, test the modification (often using same lifecycle as original development).

    5. Release & Deployment: Deliver the updated version to users with release notes.

    6. Verification/Validation: Ensure change works and didn't break existing functionality (regression testing).

    7. Closure: Update documentation, close CR.

• Software Maintenance Activities:

  • Corrective: Fixing defects (bugs).

  • Adaptive: Modifying software to cope with environmental changes (new OS, hardware, regulations).

  • Perfective: Enhancing performance, maintainability, or adding minor features requested by users.

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

VII. SOFTWARE RE-ENGINEERING & EVOLUTION

• Re-engineering:

  • The examination, understanding, and modification of an existing system to restructure and/or convert it into a new form, typically to improve maintainability, performance, or to migrate to a new platform.

  • Process (Often called "Reverse Engineering -> Modify -> Forward Engineering"):

    1. Inventory Analysis: Assess existing system's condition, quality, and business value.

    2. Reverse Engineering: Analyze the legacy system to recover its design, specifications, and data structures (often from old code without documentation). Creates higher-level abstractions.

    3. Restructuring: Transform the recovered design/code into a new, improved structure without changing external behavior (e.g., modularization, removing dead code).

    4. Reconstruction (Forward Engineering): Use the new structure as a basis for new development, possibly adding new functionality using modern practices.

    5. Testing & Deployment: Rigorous testing (especially regression) to ensure equivalence and deploy the re-engineered system.

  • Goal: Not just "fixing bugs" but fundamentally improving the system's architecture and quality to extend its useful life and reduce future maintenance costs. Distinct from maintenance (which preserves functionality) and new development (which creates new functionality).