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

UNIT 1: FOUNDATIONS OF SOFTWARE ENGINEERING

1.0 Introduction & Software Crisis

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

• Need: To manage complexity, ensure quality, meet deadlines/budgets, and produce maintainable software.

• Software Crisis: A term used in the 1960s-70s describing the common problems of:

  • Projects exceeding budgets and schedules.

  • Software being unreliable or inefficient.

  • Difficulty in maintenance.

  • Failure to meet user needs.

• Causes: Increasing complexity, lack of standardized processes, poor management, unrealistic expectations, and hardware advancements outpacing software methodologies.

• Necessities of a Life Cycle Model: Provides a structured framework, defines phases & deliverables, facilitates planning & control, improves communication, and enables process improvement.

• Goals of SDLC: To produce high-quality software that meets requirements, is maintainable, and is delivered on time and within budget.

[!TIP] Exam Focus: "Software Crisis" and "Necessities of Life Cycle Model" are direct 7m questions. Link crisis causes to the need for engineering principles.

2.0 Software Process Models (SDLC Models)

2.1 Traditional/Linear Models

Waterfall Model:

• Phases (Sequential): Requirements → Design → Implementation → Testing → Deployment → Maintenance.

• Iterative Waterfall: Each phase is revisited (feedback loop) to correct errors, but the overall flow remains downward.

• Advantages: Simple, easy to understand, good for well-understood projects, milestones are clear.

• Disadvantages: Inflexible, no working software until late, difficult to change requirements, high risk for large/complex projects.

• When to use: Projects with stable, clear requirements (e.g., government systems).

Prototyping Model:

• Types:

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

  • Evolutionary Prototyping: Build a robust core prototype and incrementally add features to evolve it into the final system.

• How Prototypes are Built: Use tools (e.g., scripting languages, low-code platforms) to quickly simulate UI, basic functionality, or workflows. Focus on user experience and requirements clarification, not performance.

• When Used: When requirements are unclear, complex, or need user validation early.

2.2 Agile Models

Agile Manifesto & Principles:

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

• Principles: Early & continuous delivery, welcome changing requirements, frequent delivery (weeks), close daily cooperation, trust & motivate, face-to-face conversation, working software as primary measure, sustainable development, technical excellence, simplicity, self-organizing teams.

Extreme Programming (XP):

• Key Practices: Short iterations (1-3 weeks), Pair Programming, Test-Driven Development (TDD), Continuous Integration, Refactoring, Small releases, On-site customer, Planning game.

• Advantages: High quality (due to TDD & pair programming), rapid feedback, adaptability to change, high customer satisfaction, reduced risk.

General Agile Process: Requirements are captured in a Product Backlog. The team selects a subset for a short Sprint (iteration). They plan, design, code, and test within the sprint. At the end, a potentially shippable product increment is demonstrated. The backlog is re-prioritized for the next sprint.

[!TIP] Exam Focus: Be ready to contrast Waterfall vs. Prototyping vs. Agile. For XP, list 4-5 key practices and their benefits. Agile is about values and responding to change.

3.0 Software Requirements Engineering

3.1 Feasibility Study

• Types:

  • Technical: Can it be built with current tech?

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

  • Operational: Will it be used? Does it fit organizational culture?

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

  • Schedule: Can it be built in time?

• Outcomes: A Feasibility Report recommending "Go/No-Go", preliminary cost/time estimates, identified risks, and high-level requirements.

• Effect on Requirements: Explicitly shapes the scope and constraints (budget, tech stack) of the subsequent requirements phase. Implicitly influences prioritization.

3.2 Requirements Elicitation & Collection

• Techniques:

  • Interviews: Structured/unstructured with stakeholders.

  • Questionnaires/Surveys: For large user groups.

  • Observation: Watch users in their environment.

  • Document Analysis: Study existing systems, procedures.

  • Workshops/JAD Sessions: Collaborative group meetings.

  • Prototyping: As discussed, to elicit feedback.

3.3 Requirements Organization & Representation

• Use Case Diagrams (UML): Visual representation of system functionality from a user's (actor's) perspective.

  • Components: Actors (users/external systems), Use Cases (functional units), System Boundary, Associations (lines).

  • ATM Case Study Example:

    • Actors: Customer, Bank, Maintenance Staff.

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

    • Relationships: Withdraw Cash and Check Balance are associated with the Customer actor.

  • DiagramSEARCH: "ATM use case diagram UML"

3.4 Software Requirements Specification (SRS)

• Structure/Parts (IEEE 830 Standard):

  1. Introduction (Purpose, Scope, Definitions, References, Overview).

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

  3. Specific Requirements (Functional, Non-functional - performance, security, usability, interface, etc.).

  4. Appendices (supporting info).

• Desirable Characteristics of a Good SRS:

  • Correct, Unambiguous, Complete, Consistent, Verifiable, Modifiable, Traceable.

  • Ranked for importance/priority.

  • Understandable by non-technical stakeholders.

  • Specifies what, not how.

3.5 Prototyping in Requirements

• Role: To resolve ambiguity, discover missing requirements, validate UI/UX design, and build user confidence before final development.

• Technique: Build a throwaway prototype focusing on critical, high-risk, or user-facing aspects. Demonstrate to users/stakeholders, gather feedback, refine requirements, then discard.

4.0 Software Design Concepts & Principles

4.1 Distinction: "Design is not coding and coding is not design."

• Design: What the system will do and how it will be structured (architecture, modules, interfaces, data). Abstract, focuses on components and their relationships. Output: Design documents, diagrams.

• Coding (Implementation): How the design is translated into executable code in a specific programming language. Concrete, syntax-focused.

• Key Point: Good design makes coding easier and more maintainable. Coding decisions should not drive architectural design.

4.2 Design Principles

• Coupling (Inter-module dependency): Degree of interdependence between modules.

  • Types (Low to High): Data Coupling < Stamp Coupling < Control Coupling < External Coupling < Common Coupling < Content Coupling (worst).

  • Goal: Minimize coupling (aim for Data Coupling).

• Cohesion (Intra-module strength): Degree to which elements inside a module belong together.

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

  • Goal: Maximize cohesion (aim for Functional Cohesion).

4.3 Design Types

• Architectural/High-Level Design (HLD): Defines the system's overall structure, major components, their responsibilities, and interconnections (e.g., client-server, layered, microservices). Output: Architecture diagrams, component specs.

• Procedural/Detailed Design (LLD): Specifies the internal logic of each component/module. Defines algorithms, data structures, and precise interfaces. Output: Flowcharts, pseudocode, class diagrams.

4.4 Function-Oriented vs. Object-Oriented Development

4.5 Re-engineering

• Concept: The process of examining and altering an existing system to reconstitute it in a new form. It is forward-looking (unlike maintenance which fixes the old).

• Detailed Explanation (The 6 R's):

  1. Reverse Engineering: Analyzing the existing system to identify its components and interrelationships (create higher-level abstractions like models).

  2. Restructuring: Reorganizing the existing code (without changing behavior) to improve structure (e.g., eliminate goto's, improve modularity).

  3. Re-documentation: Updating/creating documentation to reflect the new understanding.

  4. Re-targeting: Porting the system to a new hardware/software platform.

  5. Re-architecture: Changing the system's architectural style (e.g., monolithic to service-oriented).

  6. Re-coding: Re-implementing parts or all of the system in a new language/technology.

• Goal: Improve maintainability, extensibility, performance, or to leverage new technologies.

5.0 Software Testing

5.1 Verification vs. Validation (V&V)

• Verification: "Are we building the product right?" → Conformance to specifications. Static techniques (reviews, inspections). Answers: "Does the software meet its specifications?"

• Validation: "Are we building the right product?" → Fitness for intended use. Dynamic testing (executing software). Answers: "Does the software do what the user needs?"

5.2 Levels of Testing

• Unit Testing: Testing individual components/modules in isolation (usually by developers). Uses stubs/drivers. Focus: internal logic, paths.

• Integration Testing: Testing interactions between integrated units/modules.

  • Strategies:

    • Top-Down: Start from top (main control module), use stubs for lower modules. Good for early structure demo.

    • Bottom-Up: Start from lowest-level modules, use drivers. Good for early functionality testing.

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

  • Outcomes: Identify interface mismatches, data flow errors, incorrect module interactions.

• System Testing: Testing the complete, integrated system as a whole against its specified requirements (SRS).

  • Case Study (OS): Testing an OS involves:

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

    • Performance: Boot time, throughput, response time.

    • Compatibility: With different hardware, software, drivers.

    • Stress/Load: Under high CPU/memory demand.

    • Security: Access control, user isolation.

    • Usability: CLI/GUI consistency.

5.3 Testing Techniques

• Black-Box Testing (Behavioral): Tests based on specifications without knowledge of internal code.

  • Boundary Value Analysis (BVA): Test at and around boundaries of input domains (min, min+, nom, max-, max, max+).

    • Example 1: Input field accepts 1-100. Test: 0, 1, 2, 99, 100, 101.

    • Example 2: Date field: day 1-31. Test: 0, 1, 15, 31, 32.

  • Equivalence Partitioning: Divide input data into valid/invalid partitions, test one from each.

• Use Case-Based Testing: Derive test cases from use cases and scenarios. Tests the system from an end-user workflow perspective (happy path, alternate flows, error flows).

[!TIP] Exam Focus: BVA is a favorite. Always state the boundaries and test values clearly. Differentiate Integration (interfaces) vs. System (complete SRS) testing.

6.0 Software Maintenance & Project Management

6.1 Maintenance Process

• Types:

  • Corrective: Fixing defects (bugs).

  • Adaptive: Modifying system for environment changes (OS, hardware, laws).

  • Perfective: Enhancing performance, maintainability, or adding features.

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

• Activities: Request identification → Analysis → Design → Implementation → Testing → Release → Support.

6.2 Project Planning

• Activities:

  1. Define project scope & objectives.

  2. Identify tasks & milestones (WBS - Work Breakdown Structure).

  3. Estimate effort, time, cost (for each task).

  4. Allocate resources (people, tools).

  5. Develop schedule (Gantt chart, PERT).

  6. Plan for risk, quality, communication.

• Importance: Provides a roadmap, manages stakeholder expectations, enables progress tracking, facilitates resource allocation, and is key to risk mitigation.

6.3 Cost Estimation

• Need: For budgeting, bidding, project feasibility, resource planning, and control.

• Methods:

  • Expert Judgment: Based on experience.

  • Analogous Estimating: Using data from similar past projects.

  • Parametric Models: Use mathematical models with project parameters (e.g., LOC, FP).

  • Bottom-Up: Estimate individual tasks, then sum.

• Lines of Code (LOC) Based Estimation:

  • Advantages: Simple, intuitive, good measure of size, many historical databases exist.

  • Disadvantages: Difficult to estimate early, language-dependent, doesn't capture complexity/functionality well, can incentivize verbose code.

• Constructive Cost Model (COCOMO):

  • Basic Formula:

$$ \boxed{PM = A \times (KDSI)^B \times EAF} $$

    *   `PM` = Person-Months (effort).

    *   `A, B` = Constants based on project mode.

    *   `KDSI` = Thousands of Delivered Source Instructions (LOC/1000).

    *   `EAF` = Effort Adjustment Factor (product of 15 cost drivers, e.g., RELY, DATA, CPLX, TIME, STOR, VIRT, TURN, ACAP, AEXP, PCAP, VEXP, LEXP, MODP, TOOL, SCED).

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

    1.  **Organic (Mode 1):** Relatively small, familiar environment, relaxed schedule. `A=2.4, B=1.05`

    2.  **Semi-Detached (Mode 2):** Mix of experience levels, mixed requirements. `A=3.0, B=1.12`

    3.  **Embedded (Mode 3):** Tightly coupled with hardware, complex, strict regulations. `A=3.6, B=1.20`

*   **Output:** Effort (PM), Development Time (TDEV = C × (PM)^D), People (PM/TDEV).

[!TIP] Exam Focus: COCOMO is crucial. Memorize the formula, the 3 modes with their A/B values, and what EAF represents. Be ready to calculate effort for a given KDSI and mode.

7.0 Supporting Processes & Quality

• Software Quality Assurance (SQA): A set of activities ensuring processes and procedures are followed to produce quality software.

  • Formal Technical Reviews (FTR): A formal, structured peer review process (e.g., Inspection, Walkthrough). A team (moderator, author, reviewers) examines a work product (e.g., design doc, code) for defects. Goal: Find defects early, improve quality, share knowledge.

• Data Dictionary: A centralized repository of metadata (data about data).

  • Purpose: Defines all data elements, structures, flows, and stores in the system. Ensures consistency, serves as a single source of truth, aids in design, and supports impact analysis.

  • Contains: Name, alias, description, data type, format, range, default value, source, relationships.

• Software Process: The set of activities, methods, practices, and transformations used to develop and maintain software.

  • Importance: Provides a framework for repeatability, predictability, control, and continuous improvement (CMMI, ISO). A defined process is key to managing complexity and quality.

[!TIP] Exam Focus: FTR is more formal than a walkthrough (has specific roles, defect logging). Data Dictionary is not the database itself, but its definition. Define "Software Process" clearly for 5m.