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

UNIT 5: SOFTWARE ENGINEERING FUNDAMENTALS

I. Introduction to Software Engineering

• Software Crisis: A period in the 1960s-70s characterized by:

  • Projects exceeding budgets and schedules.

  • Software of poor quality, unreliability, and inadequate performance.

  • Difficulty in maintenance and scalability.

  • Main Causes: Increasing complexity, lack of disciplined engineering approach, unrealistic estimates, poor requirements, and inadequate testing.

• Software Process: A structured set of activities required to develop a software product. It encompasses development, maintenance, and management activities.

  [!TIP] Exam often asks for "manifestations" of software crisis. List them as bullet points with brief explanations.

II. Software Process Models (SDLC)

A. Waterfall Model

• A linear, sequential model 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

• DiagramSEARCH: "waterfall model diagram software engineering"

• Drawback: Inflexible; difficult to go back to a previous phase.

B. Iterative Waterfall Model

• Modifies the classic Waterfall by allowing feedback loops from later phases to earlier ones (e.g., from Testing to Design).

• Addresses the rigidity of the pure Waterfall model by enabling incremental refinement.

C. Agile Process Models

• An iterative and incremental approach focusing on customer collaboration, responding to change, and delivering working software frequently.

• Core values: Individuals & interactions, Working software, Customer collaboration, Responding to change.

• Extreme Programming (XP):

  • Principles: Rapid feedback, Simplicity, Incremental change, Embracing change, Quality work.

  • Advantages: High customer satisfaction, early bug detection, adaptability to changing requirements, improved team morale.

  • Practices: Pair programming, Test-driven development (TDD), Continuous integration, Small releases.

D. Prototyping Models

• Technique: Build a quick, simplified version (prototype) of the system to understand requirements and validate design ideas.

• Model Preparation: Involves identifying known requirements, designing a prototype with limited features, user interaction with prototype, and refinement based on feedback. Used when requirements are unclear or volatile.

E. Necessities of a Life Cycle Model

• Provides a disciplined, systematic framework.

• Ensures completeness and consistency.

• Facilitates planning, scheduling, and budgeting.

• Enables management control and milestone tracking.

• Improves communication among stakeholders.

• Reduces risks and enhances product quality.

F. Issues & Challenges in Software Life Cycle

• Requirements Volatility: Changing customer needs.

• Time & Cost Overruns: Unrealistic initial estimates.

• Quality Assurance: Ensuring reliability, security, performance.

• Scalability & Maintainability: Designing for future growth.

• Team Management & Communication: Coordination in distributed teams.

• Technology Evolution: Keeping software current.

III. Requirements Engineering

A. Requirements Elicitation & Collection Methods

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

• Questionnaires/Surveys: For large user bases.

• Workshops/JAD Sessions: Joint application design with stakeholders.

• Observation: Studying users in their work environment.

• Document Analysis: Studying existing systems/manuals.

• Prototyping: As a discovery tool.

B. Feasibility Studies

• Types:

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

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

  • Operational Feasibility: Will it be used effectively?

  • Legal/Contractual Feasibility: Compliance with laws/policies.

• Outcomes: A Feasibility Report recommending "Go/No-Go" with justification, estimated costs, and risks.

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

C. Software Requirements Specification (SRS)

• Structure (IEEE Std 830):

  1. Introduction (Purpose, Scope, Definitions)

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

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

  4. Appendices (References, Glossary)

• Characteristics of a Good SRS: Correct, Unambiguous, Complete, Consistent, Verifiable, Traceable, Modifiable, Understandable.

  [!TIP] Remember the mnemonic "C-U-C-V-T-M-U" or list them clearly.

D. Use Case Modeling

• Describes system functionality from a user's (actor's) perspective.

• Components: Actors, Use Cases, Relationships (association, include, extend).

• Example: ATM System

  • Actors: Customer, Bank, Maintenance Staff.

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

  • DiagramCANVAS: "A simple use case diagram for an ATM. Place 'Customer' as primary actor on left. Place 'ATM System' as a rectangle in center. Inside rectangle, list ovals for 'Withdraw Cash', 'Check Balance', 'Deposit', 'Authenticate User'. Show associations from Customer to these use cases. Show 'Maintain ATM' use case associated with 'Maintenance Staff' actor. Show '<<include>>' relationship from 'Withdraw Cash' to 'Authenticate User'. Show '<<extend>>' relationship from 'Check Balance' to 'Print Receipt' (optional)."

E. Data Dictionary

• A centralized repository of information about data used in the system (data elements, structures, flows, stores).

• Purpose: Ensures consistency, avoids ambiguity, serves as a single source of truth for data definitions.

• Entries: Name, Alias, Description, Data Type, Length, Range, Format, Source/Owner.

IV. Software Design

A. Design Concepts

• "Design is not Coding and Coding is not Design":

  • Design is about what the system should do (architecture, modules, interfaces, data structures) – the blueprint. It's abstract and technology-agnostic.

  • Coding is about how to implement the design in a specific programming language – the construction. It's concrete and detailed.

  • Good design precedes and guides coding; coding does not replace design.

B. Design Principles & Quality Metrics

• Coupling (Inter-module dependency):

  • Types (from worst to best): Content > Common > Control > Stamp > Data.

  • Significance: Low coupling is desirable. It makes modules independent, easier to understand, test, and modify.

• Cohesion (Intra-module functional strength):

  • Types (from worst to best): Coincidental > Logical > Temporal > Procedural > Communicational > Functional.

  • Significance: High cohesion is desirable. A module should perform a single, well-defined task.

C. Design Approaches

• Function-Oriented Design (FOD): Decomposes the system into a set of functions that transform input to output. Focuses on what the system does. (e.g., Structured Analysis/Design).

• Object-Oriented Design (OOD): Decomposes the system into objects (data + methods). Focuses on data and the entities that manipulate it. Promotes encapsulation, inheritance, polymorphism.

• Architectural Design: Defines the high-level structure, components, and their relationships (e.g., Layered, Client-Server, Microservices).

• Procedural Design: Details the algorithms and procedural logic within each module (often using flowcharts, Nassi-Shneiderman diagrams).

V. Software Cost Estimation

A. Overview of Estimation Methods

• Expert Judgment: Based on experience.

• Analytical/Model-Based: Using mathematical models (COCOMO, SLIM).

• Empirical/Parametric: Using historical data and parameters (LOC, Function Points).

• Bottom-Up: Estimating individual components and summing.

• Top-Down: Estimating based on overall project scope.

B. Constructive Cost Model (COCOMO)

• Effort Equation:

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

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

*   $KLOC$ = Estimated Kilo Lines of Code

*   $a, b$ = Constants based on project type

*   $EAF$ = Effort Adjustment Factor (product of 15 cost drivers)

• Categories of Software Projects:

  1. Organic (Simple): Small teams, familiar environment. (e.g., a, b values: 2.4, 1.05)

  2. Semi-Detached (Intermediate): Mix of experience, mixed environment. (e.g., a, b: 3.0, 1.12)

  3. Embedded (Complex): Tightly coupled with hardware, strict regulations. (e.g., a, b: 3.6, 1.20)

• Process: Estimate KLOC → Determine project category → Calculate nominal effort (E) → Apply EAF → Get final effort estimate.

C. Lines of Code (LOC) Based Estimation

• Method: Estimate number of source lines of code, then use historical productivity (LOC/PM) to compute effort/time.

• Advantages: Simple, intuitive, easy to measure after completion.

• Disadvantages: Highly dependent on programming language & style; difficult to estimate early; does not account for complexity or functionality; can be gamed.

VI. Software Testing

A. Testing Levels & Objectives

• Unit Testing: Test individual units/modules in isolation. Goal: Find logic errors. Done by developers.

• Integration Testing: Test interaction between integrated units/modules.

  • Strategies: Big Bang, Top-Down, Bottom-Up, Sandwich.

  • Outcomes: Identify interface mismatches, data flow issues, API incompatibilities.

• System Testing: Test the complete, integrated system against SRS. Goal: Verify it meets all specified requirements.

  • Case Study: OS Testing: Includes Boot testing, Functional testing (process, memory, file management), Performance testing (throughput, response time), Compatibility testing (hardware, software), Security testing, Usability testing.

B. Testing Techniques

• Boundary Value Analysis (BVA): Test at and around boundaries of equivalence partitions.

  • Principle: Errors often occur at edges.

  • Example 1: For input range 1-100, test: 0, 1, 2, 99, 100, 101.

  • Example 2: For a text field accepting 5-50 characters, test: 4, 5, 6, 49, 50, 51 characters.

C. Verification and Validation (V&V)

• Verification (Are we building the product right?): Evaluates if the software conforms to specifications. (e.g., Reviews, walkthroughs, static analysis).

• Validation (Are we building the right product?): Evaluates if the software meets user needs and requirements. (e.g., Dynamic testing, beta testing).

  [!TIP] V&V is a core concept. Remember: Verification = Conformance to specs; Validation = Fitness for use.

VII. Software Maintenance and Re-engineering

A. Maintenance Process & Activities

• Types: Corrective (fix bugs), Adaptive (environment changes), Perfective (enhancements), Preventive.

• Process: Request → Analysis → Design → Implementation → Testing → Release → Support.

• Activities: Understanding existing code (often hardest), impact analysis, modification, regression testing, documentation update.

B. Software Re-engineering

• Concept: Examination and alteration of an existing system to reconstitute it in a new form. Aims to improve maintainability, performance, or migrate to new tech.

• Process:

  1. Inventory Analysis: Identify candidates.

  2. Restructuring: Reorganize code/data without changing functionality.

  3. Reverse Engineering: Analyze to recover design/requirements.

  4. Re-engineering: Apply restructuring & forward engineering.

  5. Reconstruction: Rebuild using modern tools/methods.

  6. Testing & Deployment.

VIII. Project Management and Quality

A. Project Planning

• Activities:

  1. Define project scope & objectives.

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

  3. Estimate effort, time, cost (using COCOMO, LOC, etc.).

  4. Develop schedule (Gantt chart, PERT).

  5. Identify risks & plan mitigation.

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

  7. Define quality plan & metrics.

• Importance: Provides a roadmap, manages stakeholder expectations, controls budget/schedule, identifies risks early, ensures resource availability.

B. Formal Technical Review (FTR)

• A peer review process where a team (3-7 members) examines a software work product (e.g., SRS, design, code) for defects and improvement opportunities.

• Roles: Moderator (leader), Author, Reviewer(s), Recorder.

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

• Outcome: Defect list, action items, and a decision (Accepted, Accepted with modifications, Rejected).

• Goal: Improve quality, knowledge sharing, and early defect detection at lower cost than testing.