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

UNIT 1: SOFTWARE ENGINEERING FUNDAMENTALS & LIFECYCLE

1. INTRODUCTION TO SOFTWARE ENGINEERING

Software Crisis

Definition: A period in the 1960s-70s where software projects frequently failed—exceeded budgets, missed deadlines, produced low-quality or unreliable systems, and were difficult to maintain.

Primary Causes:

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

• Lack of Disciplined Processes: Ad-hoc, "code-and-fix" development.

• Inadequate Requirements: Unclear, incomplete, or changing user needs.

• Poor Project Management: Underestimated time/cost, inadequate staffing.

• Quality Issues: Insufficient testing, leading to buggy software.

• Maintenance Challenges: Code was difficult to understand and modify.

Software Process

Definition: A structured set of activities, methods, practices, and transformations used to develop and maintain software.

Key Characteristics:

• Understandable & Communicable: Must be clear to all stakeholders.

• Predictable: Should allow estimation of cost and schedule.

• Visible: Progress should be measurable.

• Supportable: Enables training and process improvement.

• Adaptable: Can be tailored to project needs.

Importance: Provides a framework for consistent, high-quality, and manageable software development, reducing chaos and improving predictability.

Software Engineering Paradigms (Development Approaches)

• Plan-Driven / Traditional: (e.g., Waterfall, Spiral) Emphasize extensive upfront planning, fixed requirements, sequential phases.

• Agile / Adaptive: (e.g., XP, Scrum) Emphasize iterative development, customer collaboration, responding to change, working software over documentation.

• Prototyping: Focuses on building quick, disposable or evolutionary models to clarify requirements.

• Component-Based: Assembles systems from pre-existing, reusable components.

• Formal Methods: Uses mathematical notation for specification and verification.

2. SOFTWARE PROCESS MODELS

Waterfall Model

Definition: A linear-sequential, phase-gate model where each phase must be completed before the next begins.

Phases (with diagram):

1. Requirements Analysis → 2. System Design → 3. Implementation → 4. Testing → 5. Deployment → 6. Maintenance

DiagramCANVAS: A downward flowing arrow with 6 distinct, non-overlapping boxes labeled as above. Arrows only point forward, no feedback loops.

Iterative Waterfall Model: Adds feedback loops from later phases (e.g., testing) back to earlier phases (e.g., design/requirements) to accommodate corrections. Still largely sequential but allows limited iteration.

Agile Process

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.

Characteristics: Iterative & incremental development, self-organizing teams, continuous feedback, adaptive planning, early and continuous delivery of valuable software.

Extreme Programming (XP)

Key Practices:

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

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

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

• Small Releases: Frequent, short releases (1-3 weeks).

• Refactoring: Regularly restructure code to improve design.

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

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

Prototyping Model

Types:

• Throwaway/Rapid Prototyping: Build a quick, simplified model to understand requirements, then discard it. Build the final system from scratch.

• Evolutionary Prototyping: Build a robust, functional prototype that is continuously refined and becomes the final system.

Prototype Development Process:

1. Identify Basic Requirements: Gather core user needs.

2. Develop Initial Prototype: Build a partial, working model.

3. User Evaluation & Feedback: Users interact with prototype; feedback is collected.

4. Refine Prototype: Revise based on feedback (repeat steps 3-4 until satisfied).

5. Final System Construction: Use the validated prototype as the basis for the full system (for evolutionary) or as a specification (for throwaway).

Other Models (Brief)

• Spiral Model: Combines waterfall with iterative prototyping. Each "loop" (spiral) represents a phase with risk analysis at each iteration. High-risk projects.

• Incremental Model: Software is designed, implemented, and tested incrementally (as a series of builds), with each build adding functionality.

• V-Model: Extension of waterfall showing validation & verification activities corresponding to each development phase.

3. REQUIREMENTS ENGINEERING

Feasibility Study

Types:

• Technical Feasibility: Can the technology be built/used? (Tools, skills, infrastructure)

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

• Operational Feasibility: Will the system be used? (User acceptance, organizational fit)

• Schedule Feasibility: Can it be built in the required timeframe?

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

Outcomes: A Feasibility Report recommending "Go/No-Go" for the project, outlining scope, constraints, risks, and preliminary cost/time estimates.

Impact on Requirements: Explicitly defines high-level business needs and constraints that directly shape the Software Requirements Specification (SRS). It sets the boundary for what is in scope and out of scope.

Requirements Elicitation

Techniques for Collecting Requirements:

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

• Questionnaires/Surveys: For large user groups.

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

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

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

• Prototyping: Using prototypes to uncover implicit needs.

Organization & Representation:

• Use Case Modeling: Captures functional requirements via actors, use cases, and scenarios.

• User Stories: Short, simple descriptions from user perspective (Agile).

• Functional Requirements Document: Detailed list of system functions.

• Non-functional Requirements: Specified separately (performance, security, usability).

Software Requirements Specification (SRS)

Structure & Parts (IEEE 830 Standard):

1. Introduction (Purpose, Scope, Definitions, Acronyms)

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

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

4. Appendices (References, Glossary)

Desirable Characteristics (SMART + Others):

• Correct & Unambiguous

• Complete

• Consistent (no contradictions)

• Verifiable (testable)

• Modifiable (well-structured, traceable)

• Traceable (each requirement has unique ID, linked to source and design/test elements)

Use Case Modeling

Use Case Diagram: Shows system's functional requirements from an actor's perspective.

Components:

• Actor: Role played by a user or external system (stick figure).

• Use Case: A discrete unit of work providing value to an actor (oval).

• System Boundary: Box containing all use cases.

• Relationships: Association (line), <<include>> (mandatory sub-function), <<extend>> (optional/conditional behavior).

ATM Example:

DiagramCANVAS: A box labeled "ATM System". Inside: ovals for "Withdraw Cash", "Check Balance", "Deposit Cash", "Authenticate User". Outside: stick figures labeled "Customer", "Bank". Customer has lines connecting to all use cases. "Authenticate User" is included by "Withdraw", "Check Balance", "Deposit".

Use Case Narrative: Detailed text for each use case: Name, Actors, Preconditions, Basic Flow (main success scenario), Alternate Flows, Postconditions.

4. SOFTWARE DESIGN

Design Fundamentals

"Design is not coding and coding is not design" – Justification:

• Design is the plan or blueprint for the software structure, components, interfaces, and data. It's an abstract, high-level activity focused on what the system does and how its parts collaborate. It precedes coding.

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

• Key Distinction: Design addresses architecture, modularity, and scalability. Poor design leads to complex, unmaintainable code regardless of coding skill. Good design makes coding straightforward and the resulting system robust.

Design Concepts

• Architectural Design: Defines the highest-level structure of the system (e.g., client-server, layered, microservices). Identifies major components and their interactions.

• Procedural/Detailed Design: Defines the internal logic of each component/module. Specifies algorithms, data structures, and exact processing steps (often using flowcharts, pseudocode).

Design Quality Metrics

Coupling (Inter-module Dependency):

| Type | Definition | Quality |

| :--- | :--- | :--- |

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

| Common Coupling | Multiple modules share same global data. | Very Poor |

| External Coupling | Modules depend on external data formats/communication protocols. | Poor |

| Control Coupling | One module passes control flags to another. | Moderate |

| Stamp Coupling | Modules share composite data structures but use only parts. | Acceptable |

| Data Coupling | Modules share simple data values (e.g., integers). | Best |

Cohesion (Intra-module Functional Relatedness):

| Type | Definition | Quality |

| :--- | :--- | :--- |

| Coincidental | Elements are unrelated; module does many unrelated things. | Worst |

| Logical | Elements are logically related but perform different functions (e.g., all I/O routines). | Very Poor |

| Temporal | Elements are processed at the same time (e.g., initialization). | Poor |

| Procedural | Elements follow a specific sequence of execution. | Moderate |

| Communicational | Elements operate on the same data/information. | Good |

| Sequential | Output of one element is input to another. | Very Good |

| Functional | All elements contribute to a single, well-defined task. | Best |

Goal: Minimize Coupling, Maximize Cohesion.

Supporting Documents

Data Dictionary:

• Purpose: A centralized repository of metadata (data about data) for all data elements, structures, flows, and stores in the system.

• Role in Design: Ensures consistency and clarity in data definitions across all design documents (DFDs, ER diagrams, module specs). It is the single source of truth for data names, types, formats, ranges, and relationships, preventing ambiguity and facilitating communication between analysts and designers.

Development Approaches

| Aspect | Function-Oriented | Object-Oriented |

| :--- | :--- | :--- |

| Primary View | System as a set of functions that transform input to output. | System as a set of objects (data + methods) that interact. |

| Decomposition | Top-down, breaking functions into sub-functions. | Bottom-up, identifying objects and their relationships. |

| Data & Code | Data and functions are separate. | Data and methods are encapsulated together. |

| Primary Mechanism | Data Flow between functions. | Message Passing between objects. |

| Example | Structured Analysis/Design (DFDs, HIPO). | UML (Use Case, Class, Sequence Diagrams). |

5. SOFTWARE TESTING

Testing Fundamentals

• Verification vs. Validation (V&V):

• Verification: "Are we building the product right?" (Conformance to specs). Process-oriented. (e.g., reviews, walkthroughs).

• Validation: "Are we building the right product?" (Fulfills user needs). Product-oriented. (e.g., testing with users).

• Formal Technical Review (FTR):

• Definition: A formal, documented meeting where software work products (e.g., design, code) are examined by peers for defects, standards compliance, and improvement.

• Participants: Author, Moderator, Reviewer(s), Recorder.

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

• Goal: Find defects early, improve quality, share knowledge. Less formal than an inspection.

Testing Levels

| Level | What is Tested? | Primary Goal | Performed By |

| :--- | :--- | :--- | :--- |

| Unit Testing | Individual modules/components in isolation. | Verify correctness of a single unit's logic. | Developers |

| Integration Testing | Groups of integrated units/modules. | Expose interface defects & interaction problems. | Developers/Testers |

| System Testing | The complete, integrated system. | Verify the system meets all specified requirements (functional & non-functional). | Independent Test Team |

| Acceptance Testing | The system in its operational environment. | Validate the system for user/customer acceptance (UAT). | Users/Customers |

Integration Testing Approaches & Outcomes:

• Big-Bang: All modules integrated at once. Outcome: Difficult to isolate interface defects; chaotic.

• Top-Down: Start from top-level modules, use stubs for lower modules. Outcome: Early demo of high-level functions; stubs may hide lower-level issues.

• Bottom-Up: Start from lowest-level modules, use drivers. Outcome: Early testing of core functionality; drivers needed.

• Sandwich/Hybrid: Combines top-down and bottom-up. Outcome: Balances early demo and thorough testing.

System Testing Case Study: Operating System

• Functional Testing: Test file operations (create/delete/copy), process management, memory allocation.

• Performance Testing: Boot time, multitasking efficiency, I/O throughput.

• Security Testing: User authentication, access control, protection against unauthorized access.

• Compatibility Testing: With different hardware configurations, drivers, and application software.

• Stress/Load Testing: Under heavy CPU, memory, and I/O load.

• Recovery Testing: Simulate power failures, disk errors; check system recovery.

Testing Techniques

Boundary Value Analysis (BVA)

• Definition: A black-box test design technique that focuses on test cases at the boundaries of input domains (minimum, maximum, just inside/outside boundaries) and output domains.

• Rationale: Errors often occur at edges of valid/invalid ranges.

• Example 1: For an input field accepting integers 1 to 100:

• Valid Boundary Values: 1, 100, 2, 99

• Invalid Boundary Values: 0, 101

• Example 2: For a password field requiring 8-16 alphanumeric characters:

• Valid: 8 chars, 16 chars, 9 chars, 15 chars

• Invalid: 7 chars, 17 chars

6. SOFTWARE COST ESTIMATION

Constructive Cost Model (COCOMO)

Categories of Software (by project size & team familiarity):

1. Organic (Simple): Small teams, familiar environment, relaxed product requirements. (e.g., simple business app).

2. Semi-Detached (Medium): Mixed team experience, mix of rigid and relaxed requirements. (e.g., transaction processing system).

3. Embedded (Complex): Tightly coupled with hardware, stringent requirements, innovative team. (e.g., real-time flight control).

COCOMO Formula (Basic):

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

Where:

• $E$ = Effort in Person-Months (PM)

• $KLOC$ = Estimated size in Kilo Lines of Code

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

Mode-Specific Formulas (Intermediate COCOMO):

Uses 15 Cost Drivers (e.g., RELY - required reliability, TIME - execution time constraint, ACAP - analyst capability) to adjust the effort.

$$E = a \times (KLOC)^b \times \prod_{i=1}^{15} EM_i$$

Where $$\displaystyle EM_i $$ is the effort multiplier for each cost driver.

Time & Cost Estimation:

• Development Time (TDEV) in months: $$\displaystyle TDEV = c \times (E)^d $$

• Average Staff Size (S): $$\displaystyle S = E / TDEV $$

\boxed{E = a \times (KLOC)^b \times \prod EM_i} \quad \text{(Intermediate COCOMO Effort Equation)}

Lines of Code (LOC) Based Estimation

Advantages:

• Simple, intuitive metric.

• Historical data often available for calibration.

• Directly correlates with implementation effort.

Disadvantages:

• Language-dependent: Same functionality yields different LOC in different languages.

• Requires early design: Size must be estimated before design is complete (chicken-egg problem).

• Doesn't capture complexity: 100 LOC of complex algorithm vs. 100 LOC of simple I/O.

• Encourages "code bloat": Developers may write more lines to inflate estimates.

• Poor for early phases: Not usable during requirements/design.

Other Estimation Methods (Brief)

• Function Point Analysis (FPA): Measures functionality delivered to the user based on external inputs, outputs, inquiries, files, interfaces. Language-independent. Requires historical data for calibration.

• Use Case Points (UCP): Estimates based on number and complexity of use cases and actor roles, adjusted by technical and environmental factors.

• Expert Judgment: Based on experience of seasoned professionals (subjective).

• Analogy-Based: Comparing with similar past projects.

• Parametric Models: Use mathematical models with multiple parameters (COCOMO, FPA are examples).

7. PROJECT PLANNING

Activities in Project Planning

1. Define Project Scope: Clearly state objectives, deliverables, boundaries, and constraints.

2. Identify Tasks & Activities: Work Breakdown Structure (WBS) – hierarchical decomposition of total work.

3. Estimate Resources & Effort: For each task (people, time, tools, cost).

4. Sequence Tasks & Identify Dependencies: Create network diagram (PERT/CPM).

5. Develop Schedule: Assign start/end dates, critical path analysis.

6. Plan Staffing: Assign roles, responsibilities, and team structure.

7. Plan Risk Management: Identify risks, assess probability/impact, plan mitigation.

8. Plan Quality & Processes: Define standards, methods, and tools to be used.

9. Plan Communication: Stakeholder communication matrix.

10. Prepare Budget: Cost estimation and financial planning.

11. Document Plan: Create comprehensive Project Management Plan (PMP).

Importance of Project Planning

• Provides Direction & Focus: Clear roadmap for the team.

• Reduces Uncertainty: Identifies risks and prepares contingencies.

• Enables Resource Optimization: Efficient allocation of people, time, and money.

• Facilitates Monitoring & Control: Baseline against which progress is measured.

• Improves Communication: Sets expectations for all stakeholders.

• Increases Probability of Success: Proactive management vs. reactive firefighting.

Role: The single most critical activity for project success. "Failing to plan is planning to fail."

8. SOFTWARE MAINTENANCE

Maintenance Process

Types of Maintenance:

• Corrective: Fixing defects discovered after delivery.

• Adaptive: Modifying software to cope with changes in environment (OS, hardware, laws).

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

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

Activities Involved:

1. Request Identification & Analysis: Log and classify change requests.

2. Impact Analysis: Assess effect of change on other components, cost, schedule.

3. Planning & Scheduling: Prioritize and allocate resources.

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

5. Testing: Integration, system, and regression testing of the modified system.

6. Deployment & Delivery: Release the updated version to users.

7. Documentation Update: Update all related documents (SRS, design, user manuals).

Software Re-engineering

Definition: The systematic transformation of an existing legacy system into a new form to realize improved quality, maintainability, and functionality. It is a comprehensive overhaul, not just patching.

Detailed Explanation (Process):

1. Inventory & Assessment: Catalog all legacy systems; assess quality, business value, and technical condition.

2. Restructuring: Reorganize code without changing behavior (e.g., convert to modern language, improve modularity, eliminate dead code). Preserves functionality.

3. Re-documentation: Create or update documentation (SRS, design, code comments) for the restructured system.

4. Re-coding / Rewriting: Re-implement parts or all of the system using modern languages/architectures, often based on recovered design.

5. Re-building: Re-architect the system (e.g., from monolithic to service-oriented), possibly adding new functionality.

6. Re-documentation (Again): Final documentation for the new system.

Goal: Extend the useful life of valuable legacy systems, reduce maintenance costs, and integrate them with modern systems. It is more cost-effective than complete replacement ("rip-and-replace") for large, business-critical systems.

9. FREQUENTLY ASKED SHORT NOTE TOPICS

Software Process

A set of activities, methods, practices, and transformations used to develop and maintain software. Provides a framework for consistent, predictable, and high-quality development. Examples: Waterfall (sequential), Agile (iterative), Prototyping (model-based). Choice depends on project context (size, risk, requirements stability).

Integration Testing

Testing of integrated groups of modules to expose interface defects and interaction problems. Approaches:

• Big-Bang: All at once (chaotic).

• Top-Down: From top, using stubs (early demo).

• Bottom-Up: From bottom, using drivers (early core test).

• Sandwich: Hybrid (balanced).

Outcomes: Detection of mismatched data formats, incorrect API calls, unexpected module interactions, and improper control flow between integrated units.

Cohesion

Measure of functional relatedness within a single module. Goal: High Cohesion.

• Functional Cohesion (Best): All parts contribute to one function (e.g., calculate_tax()).

• Sequential Cohesion: Output of one part is input to another.

• Communicational Cohesion: All parts operate on same data.

• Procedural Cohesion: Parts follow a specific execution sequence.

• Temporal Cohesion: Parts executed at same time (e.g., initialize_all()).

• Logical Cohesion: Parts are logically related but perform different functions (e.g., all print_* functions).

• Coincidental Cohesion (Worst): Unrelated parts lumped together.

Data Dictionary

A centralized repository of metadata (data about data) for all elements in a system. Contains names, aliases, descriptions, data types, formats, ranges, default values, and relationships. Purpose: Ensures consistency and clarity in data definitions across all design documents (DFDs, ER models, program specifications). Acts as the single source of truth for data, preventing ambiguity and facilitating communication between analysts, designers, and developers.

Verification and Validation (V&V)

• Verification: "Are we building the product right?" → Conformance to specifications. Process-oriented. Activities: Reviews, walkthroughs, inspections, static analysis.

• Validation: "Are we building the right product?" → Fulfills user needs and intended use. Product-oriented. Activities: Dynamic testing, prototyping, user acceptance testing (UAT).

Analogy: Verification checks if the blueprint is correct; Validation checks if the built house matches what the client wanted.

Coupling

Measure of inter-dependency between modules. Goal: Low Coupling.

• Data Coupling (Best): Modules share simple data values.

• Stamp Coupling: Modules share composite data but use only parts.

• Control Coupling: One module passes control flags.

• External Coupling: Dependence on external data formats/protocols.

• Common Coupling: Multiple modules share global data.

• Content Coupling (Worst): One module directly accesses another's internal data/code.

Formal Technical Review (FTR)

A formal, documented meeting for evaluating software work products (design, code) by peers. Participants: Author, Moderator (leads), Reviewers (2-4 experts), Recorder (logs defects). Process: Overview → Individual Preparation → Review Meeting (defect-focused, not solution-focused) → Rework by Author → Follow-up to verify fixes. Goal: Find defects early, improve quality, share knowledge, ensure standards compliance. Less rigorous than an inspection.

Boundary Value Analysis (BVA)

A black-box test design technique focusing on test cases at the boundaries of input/output domains (min, max, just inside/outside). Rationale: Errors frequently occur at edges of valid/invalid ranges. Example: For input range 1-100, test values: 0, 1, 2, 99, 100, 101. Often combined with Equivalence Partitioning (testing one valid and one invalid value from each partition).