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

UNIT 4: Software Engineering

I. Introduction to Software Engineering

Software Crisis

A situation in the late 1960s characterized by:

• Causes: Increasing complexity, poor project management, unrealistic schedules/budgets, inadequate tools, lack of standardized processes.

• Consequences: Cost overruns, schedule delays, software that doesn't meet user needs, unreliable/unmaintainable software.

Software Process

A structured set of activities required to develop a software product.

• Characteristics: Structured, measurable, repeatable, adaptable, and focused on quality.

Necessities of Software Life Cycle Model

• To manage inherent complexity.

• To provide a framework for consistent, high-quality development.

• To enable planning, tracking, and control.

• To facilitate communication among stakeholders.

• To ensure completeness and maintainability.

Issues of Software Life Cycle

• Changing Requirements: Difficult to freeze requirements early.

• Estimation Difficulties: Accurately predicting time, cost, and resources is challenging.

• Risk Management: Identifying and mitigating technical, managerial, and external risks.

• Quality Assurance: Building quality in vs. testing it in.

• Tool and Method Integration: Using diverse tools and methodologies cohesively.

[!TIP] Exam Focus: Be prepared to explain how a life cycle model addresses these issues.

II. Software Life Cycle Models

Waterfall Model

A linear, sequential approach 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: Feedback loops from later phases to earlier ones (e.g., from Testing back to Design).

Agile Models

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

• Agile Manifesto Principles:

  • 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)

An agile methodology emphasizing technical excellence and frequent releases.

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

• Advantages: High-quality code, rapid feedback, adaptability to changing requirements, improved team communication.

Prototyping Model

Building a preliminary, simplified version of the system to understand requirements and validate design.

• Techniques:

  • Throwaway/Rapid Prototyping: Built for understanding, then discarded.

  • Evolutionary Prototyping: Built incrementally and refined into the final system.

• Prototype Preparation: Identify known requirements, select appropriate tools/fidelity, build core features, gather user feedback, refine.

[!TIP] Common Pitfall: Do not confuse Evolutionary Prototyping with the final system; it's a working model that evolves.

III. Requirements Engineering

Requirements Elicitation Methods

Techniques to gather software requirements from stakeholders:

• Interviews (structured/unstructured)

• Questionnaires/Surveys

• Workshops/JAD sessions

• Observation (shadowing users)

• Document Analysis

• Prototyping

Feasibility Studies

Assessing the practicality and viability of a proposed project.

• Types:

  • Technical Feasibility: Can it be built with current technology?

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

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

  • Schedule Feasibility: Can it be built in time?

• Outcomes: Go/No-Go decision, refined project scope, identified risks and constraints.

• Impact on Requirements: Explicitly defines constraints (budget, tech, time) that shape the Software Requirements Specification (SRS).

Software Requirements Specification (SRS)

A formal document describing the complete software system to be developed.

• Typical Structure/Parts:

  1. Introduction (Purpose, Scope, Definitions)

  2. Overall Description (Product perspective, User characteristics, Constraints)

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

  4. Appendices (Supporting info)

• Desirable Characteristics (SMART):

  • Correct, Unambiguous, Complete, Consistent, Ranked/Ordered, Verifiable, Modifiable, Traceable.

Use Case Modeling

A technique to capture functional requirements by describing interactions between actors and the system.

• Use Case Diagram: Visual representation.

  • ATM Example:

    • Actors: Customer, Bank Employee, Maintenance Engineer.

    • Use Cases: Withdraw Cash, Deposit Funds, Check Balance, Maintain ATM (refill cash, fix jam).

    • Relationships: Association, Include, Extend.

  DiagramSEARCH: "ATM use case diagram example"

Data Dictionary

A centralized repository of information about all data elements in the system.

• Role: Provides consistency, eliminates ambiguity, serves as a single source of truth for data definitions.

• Contents: Name, alias, description, data type, length, format, range, source, ownership, relationships.

IV. Software Design

Design vs. Coding

"Design is what the system does; Coding is how it is implemented."

• Design: High-level abstraction (architecture, modules, interfaces). Focuses on structure, behavior, and non-functional attributes.

• Coding: Translating design into executable code in a specific programming language. Focuses on syntax, algorithms, and data structures.

• Justification: Good design is independent of language. A poor design leads to complex, unmaintainable code regardless of coding skill.

Design Types

• Architectural Design: Defines the high-level structure, major components, and their interactions (system skeleton).

• Procedural Design: Details the internal logic, algorithms, and data structures for each module (low-level specification).

Design Quality Metrics

Development Approaches

V. Software Testing

Unit Testing

Testing individual modules/components in isolation to verify their correctness.

• Performed by developers.

• Uses stubs/drivers to simulate dependent modules.

Integration Testing

Testing combined parts of an application to detect interface defects.

• Strategies:

  • Big-Bang: All modules integrated at once.

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

  • Bottom-Up: Start from low-level modules, use drivers.

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

• Outcomes: Integrated system, detected interface errors, verified module interactions.

System Testing

Testing the complete, integrated system to verify it meets specified requirements.

• Concepts: End-to-end testing, including hardware, software, network, and user environment.

• Case Study: Operating System:

  • Test boot process, process scheduling, memory management, file system operations, device drivers, security features, user interface.

  • Perform under various loads and failure conditions.

Black-Box Testing Techniques

Testing without knowledge of internal code structure.

• Boundary Value Analysis (BVA):

  • Concept: Inputs at the edge of equivalence classes are most likely to cause errors.

  • Rule: For a range [min, max], test 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 chars. Test: 7, 8, 9, 15, 16, 17.

Verification and Validation (V&V)

VI. Software Estimation and Project Planning

Cost Estimation Methods

Constructive Cost Model (COCOMO)

An empirical model for estimating effort, cost, and schedule.

• Effort Equation:

$$ \text{Effort (PM)} = a \times (\text{KLOC})^b \times \text{EAF} $$

\boxed{E = a \times (KLOC)^b \times EAF}

Where:

- `a, b` = Constants based on project type.

- `KLOC` = Estimated size in thousands of lines of code.

- `EAF` = Effort Adjustment Factor (product of 15 cost drivers, 1.0 = nominal).

• Categories of Software Projects:

  | Mode | Description | a | b | | :--- | :--- | :--- | :--- | | Organic | Small team, familiar environment, relaxed schedule. | 2.4 | 1.05 | | Semi-Detached | Mixed team, mix of experience, medium schedule. | 3.0 | 1.12 | | Embedded | Tightly coupled with hardware, strict regulations. | 3.6 | 1.20 |

Project Planning

• Activities:

  1. Define project scope and objectives.

  2. Break down work (WBS - Work Breakdown Structure).

  3. Estimate effort, cost, and duration (using COCOMO, etc.).

  4. Develop schedule (Gantt chart, PERT).

  5. Plan resources (human, hardware, software).

  6. Identify risks and plan mitigation.

  7. Plan communication and quality assurance.

• Importance: Provides a roadmap, facilitates resource allocation, sets realistic expectations, enables progress tracking, and reduces project failure risk.

VII. Software Maintenance and Re-engineering

Maintenance Process

Modification of a software product after delivery.

• Types:

  • Corrective: Fixing defects.

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

  • Perfective: Enhancing performance or maintainability.

  • Preventive: Preventing future problems (e.g., code refactoring).

• Activities: Problem identification & analysis, change request evaluation, design & implementation of change, testing, deployment, documentation update.

Re-engineering

The process of analyzing and altering an existing system to restructure and/or convert it to a new form.

• Process:

  1. Inventory: Identify candidate systems.

  2. Analysis: Understand current system's structure, behavior, and data.

  3. Restructure: Transform code/data to improve quality (without changing functionality).

  4. Re-architect/Rebuild: Significant redesign or complete rewrite.

• Need: Legacy systems are business-critical but built on obsolete tech, hard to maintain, lack documentation, and cannot integrate with new systems.

VIII. Quality Assurance and Reviews

Formal Technical Review (FTR)

A structured, peer-based evaluation of a software artifact (e.g., design, code, SRS) to detect defects.

• Process:

  1. Overview: Leader explains product and process.

  2. Preparation: Reviewers examine material individually.

  3. Meeting: Author presents, reviewers discuss findings.

  4. Rework: Author fixes defects.

  5. Follow-up: Leader verifies fixes.

• Significance:

  • Early defect detection (cheaper to fix).

  • Knowledge sharing and team training.

  • Improves product quality and consistency.

  • Creates an audit trail.

  • Promotes collective code ownership.