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

UNIT 5: Software Engineering for Wireless Sensor Networks

1.0 Foundations of Software Engineering

1.1 Software Crisis: Definition and Primary Causes

Software Crisis refers to the set of problems encountered during software development in the late 1960s–70s, characterized by projects consistently exceeding budgets, missing deadlines, delivering low-quality software, and failing to meet user needs.

Primary Causes:

• Increasing Complexity: Software systems grew larger and more intricate.

• Lack of disciplined engineering practices: Treated as an art, not a science.

• Poor project management: Inadequate planning, estimation, and control.

• Unrealistic expectations: From users and management.

• Insufficient testing and documentation.

• Rapid hardware advancement: Software couldn't keep pace with evolving platforms.

1.2 Software Process and Life Cycle Concepts

A Software Process is a structured set of activities required to develop a software product. The Software Life Cycle (SLC) is the sequence of phases a software product goes through from conception to retirement.

Key Phases (Typical Waterfall):

1. Requirement Analysis

2. System Design

3. Implementation (Coding)

4. Testing

5. Deployment

6. Maintenance

[!TIP] Exam Focus: Be prepared to draw and explain the classic Waterfall model diagram. Understand that real-world processes are often iterative or incremental.

1.3 Necessities and Common Issues of Software Life Cycle Models

Necessities:

• Provide a roadmap for development teams.

• Enable project management (scheduling, costing, tracking).

• Ensure quality control through defined checkpoints.

• Facilitate communication among stakeholders.

• Allow for predictability and risk management.

Common Issues:

• Rigidity: Difficulty accommodating changing requirements.

• Late testing: Defects found late are costly to fix.

• Documentation overhead: Excessive paperwork can slow progress.

• Customer feedback delay: User sees product only at the end.

• Assumes stable requirements: Often unrealistic in dynamic environments.

2.0 Software Process Models

2.1 Traditional Sequential Models

2.1.1 Waterfall Model (including Iterative Waterfall)

Waterfall Model: A linear-sequential approach where each phase must be completed before the next begins. Progress flows downward like a waterfall.

Phases (with activities):

1. Requirement Analysis: Gather and document requirements → SRS.

2. System Design: Architecture, high-level and detailed design → SDD.

3. Implementation: Code based on design.

4. Testing: Verify against requirements.

5. Deployment: Deliver to user.

6. Maintenance: Fix bugs, enhance features.

[!TIP] Diagram Reference: Visualize as a series of descending blocks with arrows pointing only forward. Each phase has a "verification & validation" checkpoint before moving on.

Iterative Waterfall: Adds feedback loops from later phases to earlier ones (e.g., from Testing back to Design). Allows for limited revisions but still largely sequential.

2.1.2 Phases and Activities in Waterfall Model

See 2.1.1 above. Key deliverables per phase:

• Requirements: SRS document.

• Design: Design Document (DD).

• Code: Source code, unit test reports.

• Testing: Test plans, bug reports, validated software.

• Deployment: User manuals, installed system.

• Maintenance: Maintenance reports, updated versions.

2.2 Agile Development Methodologies

2.2.1 Agile Manifesto and Principles

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.

Key Principles (selected):

• Our highest priority is satisfying the customer through early and continuous delivery.

• Welcome changing requirements, even late in development.

• Deliver working software frequently (weeks rather than months).

• Face-to-face conversation is the best form of communication.

• Sustainable development—maintain a constant pace.

2.2.2 Agile Process Models

• Scrum: Iterative with fixed-length sprints (2-4 weeks), daily stand-ups, product backlog.

• Kanban: Visual workflow management (Kanban board), limit work-in-progress.

• Extreme Programming (XP): See 2.3.

• Adaptive Software Development (ASD): Speculate, Collaborate, Learn cycles.

2.3 Extreme Programming (XP)

2.3.1 Key Practices

• Test-Driven Development (TDD): Write test before code.

• Pair Programming: Two developers at one workstation.

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

• Refactoring: Continuously improve code design.

• Small Releases: Frequent, incremental releases.

• On-site Customer: Customer is part of the team.

• Simple Design: Only what is needed today.

• Metaphor: Shared story of how the system works.

• Collective Code Ownership: Anyone can change any code.

• Coding Standards: Uniform style for all code.

2.3.2 Advantages of XP

• High quality: Due to TDD and pair programming.

• Rapid feedback: Continuous integration and customer involvement.

• Adaptability: Welcomes changing requirements.

• Reduced risk: Early detection of issues.

• Improved team morale: Collaboration and shared ownership.

• Better design: Refactoring leads to clean code.

[!TIP] Exam Focus: XP is often contrasted with traditional models. Emphasize its practices and how they address software crisis issues (e.g., quality, changing requirements).

2.4 Prototyping Model

2.4.1 Prototyping Techniques

• Throwaway/Rapid Prototyping: Build a quick, incomplete model to understand requirements, then discard and build the final system.

• Evolutionary Prototyping: Build a robust prototype and incrementally add functionality until it becomes the final system.

• Incremental Prototyping: Develop prototypes for different subsystems and integrate them.

2.4.2 Preparation and Use of Prototype Models

Preparation:

1. Identify known requirements and uncertain areas.

2. Choose prototyping type (throwaway vs. evolutionary).

3. Develop prototype focusing on user interface and key functions.

4. Present to user/stakeholders for feedback.

Use:

• Clarify ambiguous requirements.

• Explore design alternatives.

• Validate feasibility (technical, usability).

• Train users on the eventual system.

• Reduce risk of building the wrong system.

[!TIP] Common Pitfall: Prototyping can lead to "prototype syndrome" where users mistake the prototype for the final system, or developers get stuck refining the prototype instead of building the real product.

3.0 Requirements Engineering

3.1 Requirements Elicitation and Collection Techniques

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

• Questionnaires/Surveys: For large user groups.

• Observation: Watch users in their environment.

• Document Analysis: Study existing systems, manuals.

• Workshops/JAD Sessions: Joint Application Design with stakeholders.

• Use Case Modeling: Identify actors and scenarios.

• Brainstorming: Generate ideas freely.

• Prototyping: See 2.4.

3.2 Feasibility Studies

3.2.1 Types and Outcomes

Types:

• Technical Feasibility: Can the technology be built/used?

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

• Operational Feasibility: Will it fit into existing workflows? User acceptance?

• Schedule Feasibility: Can it be built in time?

• Legal/Contractual Feasibility: Compliance with laws, contracts.

Outcomes: A Feasibility Report recommending:

• Go/No-Go Decision.

• Identified risks and constraints.

• Revised project scope or approach.

3.2.2 Impact on Software Requirements Collection

• Explicit Impact: Feasibility directly shapes functional requirements (e.g., technical constraints limit features) and non-functional requirements (e.g., budget affects performance, schedule affects scope).

• Implicit Impact: Feasibility influences prioritization of requirements, selection of technology stack, and architectural decisions that later affect detailed requirements.

3.3 Software Requirements Specification (SRS)

3.3.1 Structure and Standard Parts of SRS Document

Standard Structure (IEEE 830 style):

1. Introduction: Purpose, Scope, Definitions, Acronyms, References, Overview.

2. Overall Description: Product perspective, User characteristics, Constraints, Assumptions and dependencies.

3. Specific Requirements:

   • Functional Requirements (with use cases or user stories).

   • Non-Functional Requirements (performance, security, usability, reliability, etc.).

   • Interface Requirements (user, hardware, software, communication).

   • Other Requirements (legal, regulatory, operational).

3.3.2 Desirable Characteristics of a Good SRS

• Unambiguous: Each requirement has one interpretation.

• Complete: All necessary requirements are included.

• Consistent: No conflicting requirements.

• Verifiable: Can be tested/inspected.

• Modifiable: Easy to change without affecting others.

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

• Correct: Actually reflects user needs.

• Ranked/Prioritized: By importance/stability.

[!TIP] Exam Focus: Often asked: "List five desirable characteristics." Memorize the list above (Unambiguous, Complete, Consistent, Verifiable, Modifiable, Traceable, Correct, Ranked).

3.4 Requirements Representation and Modeling

3.4.1 Use Case Diagrams (e.g., ATM Machine Example)

Use Case Diagram Components:

• Actor: Role outside the system (e.g., Customer, Bank).

• Use Case: Functionality provided to actor (e.g., Withdraw Cash, Check Balance).

• System Boundary: Box containing all use cases.

• Relationships: Association (actor-use case), Include, Extend, Generalization.

ATM Example:

• Actors: Customer, Bank (as maintenance/refill), ATM Technician.

• Use Cases (for Customer): Insert Card, Enter PIN, Select Transaction, Withdraw Cash, Check Balance, Print Receipt, Eject Card.

• Include Relationship: "Withdraw Cash" includes "Validate PIN" and "Check Account Balance".

• Extend Relationship: "Print Receipt" may extend "Withdraw Cash" optionally.

[!DIAGRAM: SEARCH: ATM use case diagram] (Search for "ATM use case diagram UML" online for standard representation)

3.4.2 Data Dictionary

A Data Dictionary (or metadata repository) is a centralized repository of definitions and metadata for all data elements in a system, used during requirements and design phases.

Contains:

• Data element names and aliases.

• Data type (integer, string, etc.).

• Data structure (composition, e.g., Address = Street + City + PIN).

• Data range/validity (e.g., Age: 0-120).

• Default values.

• Source/owner of the data.

• Security classification.

Purpose:

• Eliminate ambiguity in requirements.

• Ensure consistent naming and definition.

• Support design (database schema, program variables).

• Aid in testing (expected data formats).

4.0 Software Project Planning and Cost Estimation

4.1 Project Planning

4.1.1 Key Activities in Project Planning

1. Define Scope: What is in/out of project.

2. Breakdown Work: Work Breakdown Structure (WBS).

3. Estimate Effort & Duration: For each task (using estimation techniques).

4. Develop Schedule: Gantt chart, PERT/CPM.

5. Resource Allocation: People, hardware, software, budget.

6. Risk Planning: Identify risks, mitigation strategies.

7. Quality Plan: Standards, reviews, testing approach.

8. Communication Plan: Stakeholder updates, meetings.

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

4.1.2 Importance of Project Planning

• Provides clear direction and milestones.

• Enables realistic estimation of cost and time.

• Facilitates resource optimization.

• Helps in risk identification and mitigation.

• Improves communication among team and stakeholders.

• Forms baseline for monitoring and control.

• Increases likelihood of project success.

4.2 Cost Estimation Methods Overview

• Expert Judgment: Rely on experienced individuals.

• Analogy/Historical: Use data from similar past projects.

• Parametric Models: Use mathematical models based on project parameters (LOC, function points, use cases).

  • COCOMO (Constructive Cost Model).

  • Function Point Analysis.

• Bottom-Up Estimation: Estimate individual components, sum up.

• Three-Point Estimation: (Optimistic + 4*Most Likely + Pessimistic)/6 (PERT).

• Planning Poker/Agile Estimation: Story points, relative sizing.

4.3 Constructive Cost Model (COCOMO)

4.3.1 Categories of Software Projects in COCOMO

COCOMO classifies projects into three modes based on development environment:

1. Organic Mode: Relatively small, familiar software, with relaxed constraints (e.g., business systems). Team familiar with application area.

2. Semi-Detached Mode: Mixture of experienced and inexperienced staff, mixed constraints (e.g., transaction processing, OS). Medium size.

3. Embedded Mode: Tightly coupled with hardware, complex constraints (e.g., real-time systems, avionics). Strict performance/size requirements.

4.3.2 Detailed Explanation of COCOMO

Basic Equation:

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

Where:

• $E$ = Effort in person-months (PM).

• $KLOC$ = Estimated thousands of lines of code.

• $a, b$ = Constants depending on project mode.

• $EAF$ = Effort Adjustment Factor (product of 15 cost drivers, each rated 0.9–1.4).

Cost Drivers (EAF): Examples: Required software reliability (RELY), database size (DATA), product complexity (CPLX), programmer capability (PCAP), etc.

Schedule Calculation:

$$ T_{dev} = c \times (E)^d $$

Where $$\displaystyle T_{dev} $$ is development time in months, $c, d$ are mode-dependent constants.

Mode Constants (COCOMO'81):

[!TIP] Exam Focus: Memorize the three modes and their characteristics. Know the formula and that EAF is a product of cost drivers. Modern variants: COCOMO II (uses size in KDSI, different calibrations).

4.4 Lines of Code (LOC) Based Estimation

4.4.1 Advantages

• Simple and intuitive: Easy to understand and communicate.

• Historical data available: Many past projects have LOC counts.

• Directly related to coding effort: More code generally means more work.

• Useful for comparison: Between similar projects.

• Parametric models (like COCOMO) use LOC.

4.4.2 Disadvantages

• Language-dependent: Same functionality requires different LOC in different languages (e.g., Java vs. C vs. Python).

• Hard to estimate early: Requirements not detailed enough to count LOC.

• Doesn't capture complexity: 100 LOC of simple code vs. 100 LOC of complex algorithm differ greatly.

• Encourages bad practices: Developers may write verbose code to inflate LOC.

• Ignores non-coding activities: Design, testing, documentation effort not directly proportional to LOC.

• Poor for GUI-intensive or scripting projects.

[!TIP] Exam Focus: Contrast LOC with Function Points (FP) which are language-independent but harder to count. Mention that FP counts functionality delivered to user, independent of technology.

5.0 Software Design

5.1 Design Fundamentals

5.1.1 "Design is not Coding and Coding is not Design": Justification

• Design is the abstraction of how the system will work (architecture, modules, interfaces, data structures). It answers "what" and "how" at a high level.

• Coding is the concrete implementation of the design in a specific programming language. It answers "exactly how" with syntax and semantics.

• Design precedes coding: You cannot code without a design (even if informal).

• Different skills: Design requires creativity, system thinking, trade-off analysis. Coding requires language mastery, debugging, attention to detail.

• Design is more stable: Changes in design affect many modules; code changes are localized (if design is good).

• Design focuses on structure and behavior; coding focuses on correct syntax and algorithms.

5.2 Design Principles and Quality Metrics

5.2.1 Coupling: Definition and Types

Coupling measures the strength of interconnection between modules. Low coupling is desirable.

Types (from strongest to weakest):

1. Content Coupling: One module directly accesses/modifies another's internal data. Worst.

2. Common Coupling: Multiple modules share same global data.

3. Control Coupling: One module passes control flags to another (e.g., "mode" variable).

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

5. Data Coupling: Modules share simple data (e.g., integers, strings) via parameters. Best/Barely acceptable.

5.2.2 Cohesion: Definition and Types

Cohesion measures the functional relatedness within a module. High cohesion is desirable.

Types (from strongest to weakest):

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

2. Sequential Cohesion: Output of one part is input to another (e.g., read file, process data).

3. Communicational Cohesion: Parts operate on same data (e.g., functions that read/write a record).

4. Procedural Cohesion: Parts follow a specific sequence of execution (e.g., if then else).

5. Temporal Cohesion: Parts executed at same time (e.g., initializeAll()).

6. Logical Cohesion: Parts are logically related but executed based on control flag (e.g., performOperation(opCode)).

7. Coincidental Cohesion: No meaningful relationship (e.g., "miscellaneous" functions). Worst.

[!TIP] Exam Focus: Often asked: "Differentiate between coupling and cohesion." Coupling = between modules; Cohesion = within a module. Aim for low coupling, high cohesion.

5.3 Design Approaches and Styles

5.3.1 Architectural Design

Defines the high-level structure of the system: major components, their responsibilities, interactions, and technologies used.

• Styles: Layered, Client-Server, Microservices, Pipe-and-Filter, Event-Driven.

• Output: Architecture diagram, component specifications, technology choices.

• Focus: Non-functional requirements (performance, scalability, security).

5.3.2 Procedural Design

Focuses on procedures/functions and their invocation sequence. Uses structured programming concepts (sequence, selection, iteration).

• Tools: Structure charts, flowcharts, Nassi-Shneiderman diagrams.

• Emphasis: Control flow, modular decomposition.

5.3.3 Function-Oriented vs. Object-Oriented Design

[!TIP] Exam Focus: For WSN software, OOD is often preferred due to encapsulation (sensor nodes as objects), inheritance (common node behaviors), and easier maintenance. However, FOD may be used for resource-constrained, simple data-processing tasks.

6.0 Software Testing

6.1 Testing Fundamentals

6.1.1 Verification vs. Validation (V&V)

• Verification: "Are we building the product right?"

  Process of evaluating software to determine whether it satisfies specified requirements. Conforms to specifications.

  Activities: Reviews, inspections, static analysis, unit/integration testing.

• Validation: "Are we building the right product?"

  Process of evaluating software during or at end of development to determine whether it satisfies stakeholder needs. Fulfills intended use.

  Activities: System testing, acceptance testing, beta testing.

[!TIP] Mnemonic: Verification = Specifications (internal), Validation = Stakeholder needs (external).

6.1.2 Formal Technical Review (FTR)

A formal, structured peer review of a software artifact (requirements, design, code) by a team of qualified personnel to detect defects, ensure standards, and share knowledge.

Key Roles:

• Moderator/Leader: Runs the meeting.

• Author: Presents the material.

• Reviewers: Examine artifact beforehand, note issues.

• Recorder: Documents defects and decisions.

Process:

1. Planning: Select product, team, distribute materials.

2. Overview: Author presents high-level view.

3. Preparation: Reviewers examine individually.

4. Review Meeting: Discuss defects, classify severity.

5. Rework: Author fixes defects.

6. Follow-up: Moderator verifies fixes.

Outcome: Defect report, action items, decision (accept/reject).

6.2 Levels of Testing

6.2.1 Unit Testing

• Scope: Individual smallest testable units (functions, methods, classes).

• Performed by: Developers.

• Techniques: White-box (path coverage, condition coverage).

• Tools: JUnit (Java), pytest (Python), NUnit (.NET).

• Goal: Verify correctness of code logic, handle edge cases.

6.2.2 Integration Testing: Strategies and Outcomes

Goal: Test interfaces and interactions between integrated units/modules.

Strategies:

1. Big Bang: All modules integrated at once and tested. High risk, hard to debug.

2. Top-Down: Start from top-level modules, use stubs for lower modules not ready.

3. Bottom-Up: Start from lowest-level modules, use drivers to simulate calls from above.

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

5. Continuous Integration: Frequent integration and testing (part of Agile/XP).

Outcomes:

• Interface defects (parameter mismatches, protocol errors).

• Data flow errors.

• Inadequate error handling between modules.

• Performance issues in integrated system.

• Integration test plan and integration test report.

6.2.3 System Testing: Case Study (Operating System Example)

Goal: Test the complete, integrated system against functional and non-functional requirements.

Case Study: Operating System (OS) System Testing

• Functional Testing:

  • Boot process (cold/warm boot).

  • Process creation, scheduling, termination.

  • Memory management (allocation, paging, swapping).

  • File system operations (create, read, write, delete, permissions).

  • Device driver functionality (disk, keyboard, display).

  • Inter-process communication (pipes, sockets, shared memory).

  • System calls API correctness.

• Non-Functional Testing:

  • Performance: Boot time, context switch time, I/O throughput.

  • Stress/Load: Many processes, heavy I/O, memory exhaustion.

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

  • Reliability: Mean Time Between Failures (MTBF), crash recovery.

  • Compatibility: With different hardware configurations, software applications.

  • Usability: Command-line interface, system configuration tools.

• Tools: Stress generators (e.g., stress-ng), performance profilers, security scanners.

Outcome: System Test Report with pass/fail, defects, performance metrics. Sign-off for Acceptance Testing.

6.3 Test Design Techniques

6.3.1 Black-Box Testing: Boundary Value Analysis (BVA) with Examples

Black-Box Testing: Test based on specifications without knowledge of internal code. Focus on inputs and outputs.

Boundary Value Analysis (BVA): Test at boundaries of input domains because errors often occur at edges.

For a single input variable x with range [a, b]:

Test values: a-1, a, a+1, b-1, b, b+1 (if valid/invalid specified).

Example 1: Age field (valid: 18–60)

• Valid boundaries: 18, 19, 59, 60.

• Invalid boundaries: 17, 61.

• Also test: A typical valid value (e.g., 30).

Example 2: Password length (min 8, max 16 characters)

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

[!TIP] Robustness Testing: Also test values just outside boundaries (like 17, 61 above) to check error handling. For multiple variables, use Boundary Value Analysis + Equivalence Partitioning.

7.0 Software Maintenance and Evolution

7.1 Maintenance Process

A structured process for managing changes after software delivery.

Steps:

1. Request Identification: User submits change request/bug report.

2. Analysis & Evaluation: Assess impact, feasibility, cost. Prioritize.

3. Planning: Define tasks, resources, schedule for change.

4. Implementation: Design, code, unit test the change.

5. Testing: Integration, regression, system testing of change.

6. Deployment: Deliver updated software to user (patch, new version).

7. Verification/Closure: User accepts change; close request.

7.2 Maintenance Activities

Four types:

1. Corrective Maintenance: Fix defects (bugs) found in operation.

2. Adaptive Maintenance: Adapt software to changed environment (OS, hardware, regulations).

3. Perfective Maintenance: Enhance performance, usability, maintainability (non-defect).

4. Preventive Maintenance: Proactively improve future maintainability (refactoring, updating docs).

[!TIP] Statistic: Typically, 60-80% of total software cost is maintenance. Perfective and adaptive often dominate over corrective.

7.3 Software Re-engineering

The process of analyzing, redesigning, and modifying an existing system to restructure and/or convert it to a new form, while preserving its functionality.

Process Steps:

1. Inventory Analysis: Identify candidate systems for re-engineering.

2. Reverse Engineering: Analyze existing system to understand its structure, function, and data. Output: higher-level representations (models, diagrams).

3. Restructuring: Transform the system without changing functionality (e.g., code refactoring, data normalization, architecture improvement).

4. Forward Engineering (Re-engineering): Use new understanding to rebuild or modify the system, often with modern technologies.

5. Validation & Delivery: Test new system, deploy.

Goals: Improve maintainability, extend life, migrate to new platform, reduce technical debt.

8.0 Supporting Concepts and Processes

8.1 Software Process (General Overview)

A Software Process is the set of activities, methods, practices, and transformations used to develop and maintain software. It includes:

• Process Framework: Common activities (communication, planning, modeling, construction, deployment).

• Process Patterns: Reusable techniques for specific situations.

• Process Models: Waterfall, Agile, Spiral, etc. (see Unit 2).

• Process Assessment: CMMI, ISO 9001 to measure maturity.

• Process Improvement: Tailoring, adopting best practices.

8.2 Data Dictionary in Context of Requirements/Design

A centralized repository of information about all data elements in a system, used throughout development.

In Requirements Phase:

• Defines data terms used in SRS (e.g., "Customer" attributes: ID, Name, Address).

• Clarifies data types, formats, ranges for requirements.

• Supports use case descriptions (input/output data).

In Design Phase:

• Drives database schema design (tables, columns, types).

• Defines interface parameters between modules.

• Specifies global data structures.

• Aids in code generation and consistency checking.

Content per Entry:

• Name: Unique identifier.

• Alias: Other names.

• Description: Meaning/purpose.

• Data Type: Integer, string, date, etc.

• Data Structure: Composite (e.g., Address = Street(50) + City(30) + PIN(6)).

• Range/Valid Values: e.g., Age: 0..120.

• Default Value.

• Source/Owner: Where data originates/which module owns it.

• Security Level.

[!TIP] Link to SRS: The Data Dictionary is often an appendix to the SRS to ensure all terms are precisely defined and consistent.