Software Engineering (IT-604 (B)) - Unit 1 Short Notes

I. INTRODUCTION TO SOFTWARE ENGINEERING

Software Crisis

• Definition: Period (1960s-70s) marked by frequent project failures, budget/schedule overruns, and low-quality software.

• Causes:

  • Increasing system complexity.

  • Inadequate project management and planning.

  • Unrealistic cost/time estimates.

  • Evolving requirements mid-project.

  • Shortage of skilled professionals.

• Characteristics:

  • Cost exceeds budget.

  • Delays in delivery.

  • Poor reliability and performance.

  • User dissatisfaction.

  • Maintenance difficulties.

[!TIP]

Exam Focus: Common question: "What is software crisis? Explain with examples."

Example: Therac-25 radiation machine failures due to software bugs.

Software Product vs. Software Process

Software Life Cycle (SDLC)

• Phases:

  1. Requirement Analysis: Gather and analyze user needs.

  2. System Design: Architecture and detailed design.

  3. Implementation: Coding.

  4. Testing: Verify and validate.

  5. Deployment: Release to users.

  6. Maintenance: Fixes, enhancements, adaptation.

• Overview: Sequential or iterative flow; models organize these phases differently.

II. SOFTWARE PROCESS MODELS

Traditional/Linear Models

Waterfall Model

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

• Advantages:

  • Simple, easy to understand.

  • Well-documented milestones.

  • Suitable for well-defined, stable requirements.

• Disadvantages:

  • Inflexible; difficult to revisit earlier phases.

  • Late testing; defects found late are costly.

  • Not suitable for dynamic requirements.

[!TIP]

Also called Linear Sequential Model. Past papers frequently ask for advantages/disadvantages.

Prototyping Model

• Types:

  • Throwaway Prototyping: Build prototype to understand requirements, then discard.

  • Evolutionary Prototyping: Build prototype and evolve into final system.

• Applications: Unclear requirements, user interface design, proof-of-concept.

• Advantages:

  • Early user feedback.

  • Reduces risk of misunderstanding requirements.

  • Users see tangible output early.

• Disadvantages:

  • May lead to incomplete system if prototype is mistaken for final.

  • Excessive changes can increase cost.

  • Poorly managed prototypes may become final system with low quality.

Evolutionary Models

Spiral Model

• Diagram:

  DiagramCANVAS: A spiral diagram with cycles. Each cycle divided into four quadrants: (1) Objective Setting, (2) Risk Assessment, (3) Development and Validation, (4) Planning for next iteration. Radius indicates cost, angle indicates progress.

• Activities per Cycle:

  1. Objective Setting: Define goals, alternatives, constraints.

  2. Risk Assessment: Identify and resolve risks (e.g., feasibility, safety).

  3. Development and Validation: Build next version (prototype or increment).

  4. Planning: Review results, plan next iteration.

• Advantages:

  • Risk-driven; explicit risk management.

  • Flexible; supports changes.

  • Suitable for large, critical systems.

• Disadvantages:

  • Complex and costly.

  • Requires expertise in risk analysis.

  • May lead to indefinite iterations.

Incremental Model

• Phases: Each increment goes through design, code, test; increments integrate to form final product.

• Applications: Large systems, early user feedback, resource-constrained projects.

• Advantages:

  • Early delivery of部分功能.

  • Easier to manage and test.

  • User feedback incorporated incrementally.

• Disadvantages:

  • Requires careful planning of increments.

  • Integration challenges if architecture not robust.

Iterative Waterfall Model

• Waterfall with feedback loops between phases (e.g., testing → design). Allows refinement but retains sequential core.

Agile and Adaptive Models

Agile Process Model

• Features:

  • Iterative and incremental.

  • Customer collaboration over contract negotiation.

  • Responding to change over following a plan.

  • Self-organizing teams.

• Principles (Agile Manifesto):

  1. Individuals and interactions over processes and tools.

  2. Working software over comprehensive documentation.

  3. Customer collaboration over contract negotiation.

  4. Responding to change over following a plan.

• Differences from Traditional Models:

  • Traditional: Plan-driven, sequential, fixed scope, heavy documentation.

  • Agile: Value-driven, iterative, flexible scope, minimal documentation, continuous feedback.

[!TIP]

Exam Question: "Illustrate the Agile Process Model and explain how it differs from traditional process models."

Key Point: Emphasize flexibility, customer involvement, and iterative delivery.

Extreme Programming (XP)

• Practices:

  • Pair Programming: Two developers work together.

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

  • Continuous Integration: Frequent code integration.

  • Refactoring: Continuous code improvement.

  • Small Releases: Frequent, short iterations.

• Advantages:

  • High code quality.

  • Rapid feedback.

  • Adaptable to changing requirements.

• Disadvantages:

  • Requires high discipline and customer availability.

  • Not suitable for large distributed teams without adaptation.

Rational Unified Process (RUP)

• Phases:

  1. Inception: Define scope, business case.

  2. Elaboration: Plan project, specify architecture.

  3. Construction: Build product.

  4. Transition: Deploy to users.

• Disciplines: Business modeling, requirements, analysis & design, implementation, test, deployment, configuration & change management, project management, environment.

• Iterative: Each phase has multiple iterations.

Specialized Models

Rapid Application Development (RAD)

• Phases:

  1. Requirements Planning: Identify scope, constraints.

  2. User Design: Prototyping with user involvement.

  3. Construction: Reuse components, automated tools.

  4. Cutover: Implementation, training, conversion.

• Applications: Time-critical projects, user-intensive systems (e.g., business apps).

• Advantages:

  • Fast development (60-90 days).

  • High user satisfaction.

  • Reduced risk through prototyping.

• Disadvantages:

  • Requires skilled, cohesive team.

  • Scalability issues for large systems.

  • Management commitment essential.

Component-Based Development Model

• Definition: Build system from reusable components (e.g., libraries, services).

• Process: Identify components → adapt/compose → integrate.

• Advantages:

  • Reusability reduces development time.

  • Improved maintainability.

  • Higher quality through tested components.

• Disadvantages:

  • Component availability and compatibility.

  • Integration complexity.

Process Improvement Frameworks

Capability Maturity Model (CMM)

• Levels:

  1. Initial: Chaotic, ad hoc.

  2. Repeatable: Project management processes established.

  3. Defined: Processes standardized across organization.

  4. Managed: Measured and controlled.

  5. Optimizing: Continuous process improvement.

• Significance:

  • Provides roadmap for process improvement.

  • Higher maturity correlates with better quality, predictability, and cost control.

  • Used for vendor assessment and process benchmarking.

[!TIP]

Past Question: "Describe CMM and its significance in process improvement."

Remember: Levels 1-5 and key characteristics of each.

CMMI (Capability Maturity Model Integration)

• Integrates multiple CMMs (e.g., software, systems engineering).

• Representations:

  • Staged: Maturity levels (similar to CMM).

  • Continuous: Capability levels per process area.

• Focus on process improvement across disciplines.

Process Customization and Improvement

• Methods:

  • Tailor standard processes to project context (size, criticality, team).

  • Use metrics to identify bottlenecks.

  • Adopt best practices (e.g., code reviews, automated testing).

  • Continuous feedback and adaptation.

• Impact on Software Quality:

  • Better fit to project needs → higher efficiency.

  • Reduced defects through improved practices.

  • Enhanced predictability and control.

III. REQUIREMENTS ENGINEERING

Types of Requirements

Functional Requirements

• Definition: What the system should do (functions, features).

• Examples:

  • "The system shall allow users to reset passwords."

  • "The system shall generate monthly sales reports."

Non-Functional Requirements

• Definition: Constraints on system operation or qualities.

• Types:

  • Performance: Response time, throughput (e.g., "Search results within 2 seconds").

  • Security: Authentication, authorization, encryption.

  • Usability: Ease of learning, efficiency (e.g., "New users shall perform tasks within 10 minutes").

  • Reliability: Mean time between failures (MTBF).

  • Maintainability: Ease of modification (e.g., "Code cyclomatic complexity < 10").

  • Portability: Ability to run on different platforms.

• Examples:

  • "The system shall support 1000 concurrent users."

  • "All passwords shall be stored encrypted."

[!TIP]

Past Question: "Differentiate between functional and non-functional requirements with examples."

Key: Functional = behavior; Non-functional = constraints/qualities.

Requirements Elicitation

Techniques:

• Interviews: One-on-one, deep dive into user needs.

• Surveys/Questionnaires: Broad, quantitative data collection.

• Workshops/Group Sessions: Collaborative brainstorming (e.g., JAD sessions).

• Prototyping: Build mock-ups to clarify requirements.

• Observation: Watch users in their environment to understand context.

• Role: Identify explicit and implicit needs, constraints, and workflows.

Requirements Analysis and Specification

System Requirements Specification (SRS) Document

• Structure (IEEE 830 standard):

  1. Introduction: Purpose, scope, definitions, references.

  2. Overall Description: Product perspective, user characteristics, constraints, assumptions.

  3. Specific Requirements:

     • Functional requirements.

     • Non-functional requirements.

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

     • Data requirements.

• Characteristics of Good SRS:

  • Correct.

  • Unambiguous.

  • Complete.

  • Consistent.

  • Verifiable.

  • Traceable.

  • Modifiable.

  (Blueprint mentions "INSPIRE Qualities" – likely a typo; standard is CUCVTM or similar.)

Use Case Modeling

• Components:

  • Actors: Users or external systems interacting with the system.

  • Use Cases: Functional units from actor's perspective (e.g., "Withdraw Cash").

  • Relationships:

    • Association: actor-use case link.

    • Include: mandatory sub-use case (e.g., "Authenticate" included in "Withdraw").

    • Extend: optional extension (e.g., "Print Receipt" extends "Withdraw").

• Creation Process:

  1. Identify actors (primary, secondary).

  2. Identify use cases (scenarios, goals).

  3. Describe use cases (preconditions, postconditions, main flow, alternate flows).

  4. Model relationships (include, extend).

• Application in Requirement Analysis: Captures functional requirements in user-oriented way; basis for test case design.

Data Dictionary

• Role: Central repository defining all data elements, their types, formats, relationships, and constraints. Ensures consistency across requirements, design, and code.

Requirements Validation and Verification

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

  • Techniques: Reviews (inspections), Prototyping, Model checking (formal methods).

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

  • Techniques: Testing, code inspections, walkthroughs.

• Difference: Validation checks requirements against user needs; verification checks implementation against requirements.

Requirement Traceability

• Challenges:

  • Complexity of large systems with many requirements.

  • Changing requirements over time.

  • Lack of tool support or expertise.

  • Maintaining links across artifacts (requirements → design → code → tests).

• Mitigation Strategies:

  • Traceability Matrix: Table linking requirements to design elements, code modules, and test cases.

  • Tools: Requirements management tools (e.g., IBM DOORS, JIRA with add-ons).

  • Standards: Follow IEEE 830 for SRS, establish traceability policies.

  • Unique IDs: Assign identifiers to requirements for tracking.

IV. SOFTWARE DESIGN

Design Fundamentals

Design Principles

• Abstraction: Hide complexity, show essential features (e.g., interfaces).

• Modularity: Divide system into manageable, independent modules.

• Information Hiding: Encapsulate implementation details within modules.

• Least Privilege: Minimize access rights for modules/users.

• SOLID:

  • Single Responsibility: One reason to change.

  • Open/Closed: Open for extension, closed for modification.

  • Liskov Substitution: Subtypes must be substitutable for base types.

  • Interface Segregation: Many client-specific interfaces better than one general.

  • Dependency Inversion: Depend on abstractions, not concretions.

• DRY: Don't Repeat Yourself – avoid code duplication.

Golden Rules of User Interface Design

1. Aesthetic: Visually appealing, professional.

2. Efficient: Minimize user effort, shortcuts.

3. Consistent: Uniform layout, terminology, behavior.

4. Forgiving: Prevent errors, provide easy recovery (undo).

5. User-centered: Design for user tasks and mental models.

Design Metrics

• Coupling: Interdependence between modules.

  • Types: Content, Common, Control, Stamp, Data (least desirable to most).

  • Low coupling desirable for maintainability.

• Cohesion: Relatedness within a module.

  • Types: Functional (best), Sequential, Communicational, Procedural, Temporal, Logical, Coincidental (worst).

  • High cohesion desirable.

• Importance: Predict maintainability, testability, reusability; guide refactoring.

Design Approaches

Function-Oriented Design (Structured Design)

• Steps:

  1. Transform DFDs into structured charts.

  2. Identify modules and their hierarchy.

  3. Define module interfaces and data structures.

• Data Flow Diagrams (DFDs):

  • Show data movement between processes, data stores, external entities.

  • Levels: Context (level 0), Level 1, etc.

• Structured Charts: Hierarchical representation of module calls and data passing.

Object-Oriented Design

• Concepts:

  • Objects: Instances with state (attributes) and behavior (methods).

  • Classes: Blueprints for objects.

  • Inheritance: Mechanism for hierarchy (subclass inherits from superclass).

  • Polymorphism: Same interface, different implementations (e.g., method overriding).

• Comparison with Function-Oriented:

Component-Based Design

• Definition: Design using pre-built, reusable components (e.g., libraries, services, microservices).

• Advantages:

  • Reusability reduces development time.

  • Improved maintainability (isolated components).

  • Faster development with off-the-shelf components.

  • Better quality through tested components.

Pattern-Based Design

• Use of Design Patterns: Reusable solutions to common design problems.

  • Examples: Singleton (single instance), Observer (publish-subscribe), Factory (object creation), MVC (separation of concerns).

Modeling with UML

UML Diagrams:

• Use Case Diagram: Actors, use cases, relationships.

• Class Diagram: Static structure (classes, attributes, operations, associations).

• Sequence Diagram: Interactions over time (objects, messages, activation).

• Collaboration Diagram: Interactions with links (similar to sequence, different notation).

• State Diagram: State transitions of an object (states, events, actions).

• Activity Diagram: Workflow or business process (actions, decisions, parallelism).

• Deployment Diagram: Physical nodes (servers, devices) and artifacts (executables, files).

Application in Representing Software Architecture:

• Multiple Views:

  • Logical View: Class diagrams, object model (static structure).

  • Process View: Sequence/activity diagrams (concurrency, behavior).

  • Physical View: Deployment diagrams (hardware, networking).

  • Scenarios: Use case diagrams (requirements, functionality).

Example: UML for Library Management System

• Use Case Diagram:

  • Actors: Member, Librarian, System.

  • Use Cases: Borrow Book, Return Book, Search Catalog, Manage Inventory, Generate Reports.

  • Relationships:

    • "Borrow Book" includes "Authenticate User".

    • "Return Book" extends "Calculate Fine" if overdue.

• Class Diagram:

  • Classes: Book, Member, Loan, Librarian, Catalog.

  • Attributes: Book: ISBN, title, author; Member: ID, name, email.

  • Operations: Book: checkAvailability(), Member: borrowBook().

  • Associations: Member borrows Book via Loan (many-to-many).

[!TIP]

Past Question: "Create a UML diagram for a Library Management System and explain its components."

Answer: Draw use case and class diagrams; explain actors, use cases, classes, relationships.

Architectural Design

Architectural Styles:

• Layered: Separate concerns into layers (e.g., presentation, business logic, data). Each layer uses services of layer below.

• Client-Server: Client requests services from server (e.g., web app).

• Pipe-and-Filter: Data flows through filters (e.g., compilers: lexical analysis → parsing → code generation).

• Microservices: Independent, loosely coupled services communicating via APIs (e.g., REST).

Architectural Views:

• Logical View: Class diagrams, object model.

• Process View: Sequence/activity diagrams for runtime behavior.

• Physical View: Deployment diagrams for hardware/software mapping.

• Development View: Package/module organization (for developers).

V. SOFTWARE TESTING

Testing Fundamentals

Software Testing:

• Objectives:

  • Find defects.

  • Ensure quality and reliability.

  • Build confidence in software.

  • Prevent failures in production.

• Importance in QA: Integral part of quality assurance; verifies correctness and completeness.

Test Levels:

1. Unit Testing: Test individual units (functions, methods) in isolation. Usually by developers.

2. Integration Testing: Test interfaces and interactions between units/modules.

3. System Testing: Test complete integrated system against requirements.

4. Acceptance Testing: Validate with user/customer (User Acceptance Testing - UAT).

Test Plan:

• Importance: Roadmap for testing; ensures coverage, resource allocation, and communication.

• Components:

  • Test plan identifier.

  • Scope (in/out of scope).

  • Approach (techniques, tools, pass/fail criteria).

  • Resources (people, hardware, software).

  • Schedule (milestones, deliverables).

  • Risks and contingencies.

Static vs Dynamic Analysis:

• Static Analysis: Examine code/document without execution.

  • Examples: Code reviews, walkthroughs, static analysis tools (e.g., SonarQube, lint).

• Dynamic Analysis: Execute program with test inputs.

  • Examples: Unit testing, system testing, performance testing.

Test Design Techniques

Black-Box Testing

• Based on requirements, no knowledge of internal code.

• Equivalence Partitioning:

  • Divide input domain into equivalence classes (valid and invalid).

  • Rule: For each valid class, one test; for each invalid class, one test.

  • Example: Input age (1-120). Classes: valid [1,120]; invalid: <1, >120. Test cases: age=30 (valid), age=0 (invalid), age=121 (invalid).

• Boundary Value Analysis (BVA):

  • Test edges of partitions (boundaries).

  • Rules: For range [a,b], test a-1, a, a+1, b-1, b, b+1.

  • Example: Age 1-120 → test 0,1,2,119,120,121.

  • Often finds off-by-one errors.

[!TIP]

Past Question: "What is Boundary Value Analysis? Explain with example."

Key: Always test just below, at, and just above boundaries.

White-Box Testing

• Based on code structure (control flow, data flow).

• Statement Coverage: Execute every statement at least once.

• Branch Coverage: Execute each branch (true/false) at least once.

• Path Coverage: Execute all possible paths (often infeasible for large programs).

• Example:

  
  if x > 0:
  
      print("Positive")
  
  else:
  
      print("Non-positive")
  
  

  • Branch coverage requires tests for x>0 (true) and x<=0 (false).

Test Oracles

• Definition: Mechanism to determine if test output is correct.

• Types:

  • Specified: Derived from requirements/specifications.

  • Derived: From similar systems or models.

  • Heuristic: Based on experience or rules of thumb (e.g., "no crashes").

Test Case Design

• Criteria: Input, expected output, preconditions, postconditions.

• Example for Login Module:

  | Test ID | Input | Expected Output | Test Condition | |-------------|-------------------------|-----------------------------|--------------------------| | TC01 | valid user, valid pass | Login successful, redirect | Normal flow | | TC02 | valid user, invalid pass| Error message "Invalid pass"| Invalid password | | TC03 | empty user, valid pass | Error "User required" | Empty field validation |

Integration and System Testing

Integration Testing Strategies:

• Top-Down: Start from top modules, use stubs for lower modules. Advantage: early demonstration of major functions. Disadvantage: stubs may be complex.

• Bottom-Up: Start from bottom modules, use drivers for upper modules. Advantage: early testing of low-level functions. Disadvantage: drivers needed.

• Sandwich: Combination of top-down and bottom-up (test middle layer first).

• Big-Bang: Integrate all modules at once. High risk, hard to debug; rarely used.

System Testing Types:

• Functional: Verify features against requirements.

• Performance: Load, stress, scalability testing (e.g., JMeter).

• Security: Vulnerability scanning, penetration testing.

• Recovery: Failover, backup/restore testing.

• Usability: User-friendliness, accessibility.

• Compatibility: With different OS, browsers, devices.

Acceptance Testing:

1. Alpha: In-house testing by developers or internal users.

2. Beta: At user site by real users (field testing).

3. Contract: Per contract specifications (legal).

4. Regulation: Compliance with laws/standards (e.g., FDA, GDPR).

Test Metrics and Tools

Test Metrics:

• Purpose: Measure testing progress, effectiveness, product quality.

• Types:

  • Size: Lines of Code (LOC), Function Points.

  • Effort: Person-hours, cost.

  • Coverage: Requirements coverage, code coverage (statement, branch).

  • Defect Density: Defects per KLOC (thousand lines of code).

• Product vs Process Metrics:

  • Product Metrics: Measure the software (defect density, complexity, reliability).

  • Process Metrics: Measure the development process (effort, cost, schedule, defect removal efficiency).

Testing Tools:

• Categories:

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

  • Integration/Functional: Selenium (web), Cucumber (BDD), Postman (API).

  • Performance: JMeter, LoadRunner.

  • Management: TestRail, Zephyr (test management).

VI. SOFTWARE PROJECT MANAGEMENT

Project Planning

• Activities:

  • Scope Definition: Create Work Breakdown Structure (WBS).

  • Estimation: Cost, effort, schedule.

  • Scheduling: Assign tasks, dependencies, durations.

  • Risk Planning: Identify, assess, mitigate risks.

  • Quality Planning: Define quality standards, metrics.

• Project Metrics: Track progress (e.g., earned value, defect density, schedule variance).

Estimation Techniques

Cost Estimation Methods:

• Expert Judgment: Consult experienced individuals.

• Analogous: Use historical data from similar projects.

• Parametric: Use mathematical models (COCOMO, function points).

COCOMO Model

• Categories:

  • Organic: Simple, familiar environment, small team (e.g., business app).

  • Semi-detached: Mixed environment, medium project (e.g., utility software).

  • Embedded: Tightly coupled with hardware, complex (e.g., real-time systems).

• Effort Calculation:

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

Where:

• $E$: Effort in person-months.

• $a, b$: Constants (Organic: a=2.4, b=1.05; Semi-detached: a=3.0, b=1.12; Embedded: a=3.6, b=1.20).

• $KLOC$: Thousands of lines of code.

• $EAF$: Effort Adjustment Factor (product of 15 cost drivers, e.g., reliability, complexity).

LOC-Based Estimation:

• Advantages: Simple, based on historical data.

• Disadvantages: Early estimation difficult; language-dependent; inaccurate for new paradigms (e.g., OO, component-based).

Effort and Schedule Estimation:

• Putnam Model: $$\displaystyle \text{Effort} = \frac{(\text{Size})^{3/4}}{t^{3/4}} \times \text{constants} $$, where $t$ is time.

• Function Points: Measure functionality independent of language. Calculate based on:

  • Inputs, Outputs, Inquiries, Files, Interfaces.

  • Weighted by complexity (simple, average, complex).

  • Adjusted by Influence Factors (14 factors like data communications, distributed processing).

Scheduling and Tracking

Steps:

1. Task Decomposition: Break project into tasks (WBS).

2. Dependency Identification: Determine task order (PERT/CPM).

3. Duration Estimation: Estimate time per task.

4. Critical Path: Longest path determines project duration; tasks on critical path have zero slack.

5. Resource Allocation: Assign people, tools.

Tools:

• Gantt Charts: Bar chart showing tasks over time.

• PERT: Probabilistic, uses optimistic (O), most likely (M), pessimistic (P) estimates: $$\displaystyle \text{Expected Time} = \frac{O + 4M + P}{6} $$.

• Project Management Software: MS Project, Jira, Asana.

Tracking Mechanisms:

• Milestones: Key events (e.g., "Design Complete").

• Earned Value Management (EVM):

  • PV (Planned Value): Budgeted cost for scheduled work.

  • EV (Earned Value): Budgeted cost for completed work.

  • AC (Actual Cost): Actual cost incurred.

  • CV (Cost Variance) = EV - AC.

  • SV (Schedule Variance) = EV - PV.

  • CPI (Cost Performance Index) = EV / AC.

  • SPI (Schedule Performance Index) = EV / PV.

Risk Management

Risk Identification:

• Techniques: Checklists, brainstorming, Delphi (anonymous expert consensus), SWOT analysis.

Risk Assessment:

• Probability: Likelihood (0-1 or low/medium/high).

• Impact: Severity (cost, schedule, quality impact).

• Prioritization: Risk Matrix (plot probability vs impact); prioritize high-probability, high-impact risks.

Risk Mitigation Strategies:

• Avoid: Change plan to eliminate risk (e.g., use proven technology).

• Transfer: Shift to third party (e.g., insurance, outsourcing).

• Mitigate: Reduce probability or impact (e.g., prototyping, training).

• Accept: Acknowledge risk, have contingency plan (e.g., budget reserve).

Risk Information Sheet (format):

• Risk ID, Description, Probability, Impact, Priority, Mitigation Strategy, Owner, Status.

Feasibility Analysis

Types:

• Technical: Can we build it with available technology?

• Economic: Cost-benefit analysis, ROI, payback period.

• Operational: Will users adopt it? Fit with existing processes?

• Legal: Compliance with laws, regulations (e.g., data privacy).

• Schedule: Can we meet deadline with available resources?

Outcomes: Feasibility report, recommendation (go/no-go decision).

Software Configuration Management (SCM)

Functions:

• Version Control: Track changes to artifacts (code, docs). Tools: Git, SVN.

• Change Control: Process for requesting, reviewing, approving, implementing changes.

• Configuration Auditing: Verify compliance with specifications and standards.

• Status Reporting: Report on configurations, changes, baselines.

Version Control Example with Git:

• Repository: Central storage (e.g., GitHub, GitLab).

• Branching: Create branch for feature/fix (git branch feature-x).

• Merging: Combine branches (git merge feature-x).

• Common Commands:

  • git clone <repo>: Copy repository.

  • git add <file>: Stage changes.

  • git commit -m "msg": Commit changes.

  • git push: Upload to remote.

  • git pull: Fetch and merge remote changes.

VII. SOFTWARE QUALITY ASSURANCE (SQA)

Quality Concepts

• Definition: Conformance to requirements and fitness for use.

• McCall's Quality Factors:

  • Correctness, Reliability, Efficiency, Integrity, Usability, Maintainability, Flexibility, Testability, Portability, Reusability, Interoperability.

SQA Activities

• Reviews: Formal Technical Review (FTR) – structured inspection of artifacts.

• Audits: Independent evaluation of compliance with standards.

• Testing: As described in Unit V.

• Process Compliance: Ensure adherence to defined processes and standards.

Quality Metrics

• Product Metrics: Measure the software product.

  • Defect density (defects/KLOC).

  • Complexity (cyclomatic complexity).

  • Reliability (MTBF – Mean Time Between Failures).

• Process Metrics: Measure the development process.

  • Effort (person-months).

  • Cost.

  • Defect removal efficiency (DRE) = (Defects found before release) / (Total defects found).

Software Quality Standards

• ISO 9001: Quality management systems – requirements for organizations.

• IEEE Standards:

  • IEEE 730: SQA plans.

  • IEEE 829: Test documentation.

  • IEEE 830: SRS.

VIII. SOFTWARE MAINTENANCE AND EVOLUTION

Types of Maintenance

1. Corrective: Fix defects found after release.

2. Adaptive: Adapt to environment changes (OS, hardware, regulations).

3. Perfective: Enhancements, performance improvements, usability.

4. Preventive: Prevent future problems (e.g., refactoring, code cleanup).

Maintenance Process

1. Request Analysis: Receive and evaluate change requests.

2. Implementation: Design, code, unit test changes.

3. Testing: Regression testing to ensure no side effects.

4. Distribution: Deploy updated software.

5. Documentation: Update user manuals, release notes.

Re-engineering vs Reverse Engineering

• Reverse Engineering: Analyze existing system to understand its structure and function. Output: models, documentation.

• Re-engineering: Redesign and reimplement to improve quality (may include reverse engineering as first step).

• Difference: Reverse is understanding; re-engineering is rebuilding.

Program Comprehension Techniques

• Documentation: Read existing design docs, comments.

• Debugging: Run and observe behavior.

• Clustering: Group related code modules (e.g., by functionality).

• Static Analysis Tools: Use tools to visualize structure (e.g., call graphs).

Software Evolution

• Concepts: Software must evolve to remain useful in changing environment.

• Strategies:

  • Spiral: Iterative evolution with risk analysis.

  • Incremental: Stepwise enhancements.

IX. SPECIAL TOPICS (From Past Papers)

Structured Methods

• Overview: Use Structured Analysis (SA) and Structured Design (SD).

  • SA: DFDs, data dictionaries, structured English.

  • SD: Structured charts, module design.

• Application: Traditional systems, data-flow oriented (e.g., business information systems).

Test Oracles

• Definition: Source of expected results for test comparison.

• Types:

  • Specified: From requirements/specs.

  • Derived: From similar systems or models.

  • Heuristic: Based on experience (e.g., "no crashes").

• Example: For login test, specified oracle: "Valid credentials → success message."

Feasibility Analysis

• As in Section VI.

Test Case Design

• Techniques: Equivalence partitioning, boundary value analysis, decision tables, state transition testing.

• Best Practices:

  • Clear, concise, repeatable.

  • Traceable to requirements.

  • Independent (minimal dependencies).

  • Cover both positive and negative scenarios.

Object Models

• In OOAD, three models:

  1. Object Model: Static structure (classes, objects, relationships).

  2. Dynamic Model: State changes (state diagrams, sequence diagrams).

  3. Functional Model: Data transformations (data flow diagrams).

Component Model

• Detailed: Component interfaces, contracts (pre/post conditions), reuse mechanisms.

• Examples:

  • COM (Component Object Model): Microsoft binary standard.

  • EJB (Enterprise JavaBeans): Java component model.

  • .NET Assemblies: .NET component units.

• Advantages: Reusability, maintainability, independent deployment.

Design Principles

• Comprehensive List:

  • SOLID (as above).

  • DRY: Don't Repeat Yourself.

  • KISS: Keep It Simple, Stupid.

  • YAGNI: You Ain't Gonna Need It (avoid over-engineering).

  • Law of Demeter: Principle of least knowledge (talk only to immediate friends).

Traceability

• In Requirements and Design: Link requirements to design elements and test cases.

• Challenges: Changing requirements, complexity, tool support.

• Mitigation: Traceability matrix, tools (e.g., IBM DOORS), unique IDs, standards (IEEE 830).