Subject Syllabus Hub145+ MCQs6 Topics

Software Engineering

Software development lifecycles (SDLC, Agile), requirement analysis, architectural design, software testing strategies, maintenance, and quality assurance.

Topic Syllabus & Revision Notes

High-yield concept summaries, formulas, and common exam pitfalls for each topic.

Topic 112 Key Rules

Software Engineering

# Software Engineering - Complete Theory & Master Revision Guide A comprehensive, exam-oriented reference guide covering all 5 core units of Software Engineering for undergraduate computer science and competitive exams. --- ## Unit 1: Introduction, SDLC Models, SRS, Formal Specification, V&V ### 1.1 Software Development Life Cycle (SDLC) Models - **Waterfall Model**: Sequential phase-driven model (Requirements -> Design -> Implementation -> Testing -> Maintenance). Best for stable, well-understood requirements. High risk for dynamic projects. - **Prototyping Model**: Builds a working mock-up early to elicit customer requirements. Useful when user requirements are ambiguous. - **Rapid Application Development (RAD)**: High-speed adaptation of Waterfall using component-based construction and prototyping. Project must be modularized into 60-90 day cycles. - **Spiral Model (Boehm)**: Risk-driven iterative model combining Waterfall rigidity with Prototyping iteration. 4 quadrants: (1) Objective setting, (2) Risk assessment & reduction, (3) Development & validation, (4) Planning. - **Agile Methodology & Scrum**: Iterative/incremental approach prioritizing working software and customer collaboration. Uses short Sprints (2-4 weeks), Daily Standups, Product Backlog, and Scrum Master. ### 1.2 Software Requirements Specification (SRS) - Standardized by **IEEE 830 standard**. - **Characteristics of Good SRS**: Correct, Unambiguous, Complete, Consistent, Ranked for importance/stability, Verifiable, Modifiable, Traceable. - SRS documents **functional requirements** (what system should do) and **non-functional requirements** (performance, security, usability, reliability). ### 1.3 Formal Requirements Specification & Verification/Validation - **Formal Specifications**: Uses mathematical notation (set theory, predicate calculus, logic) to define state and behavior without ambiguity (e.g., Z, VDM, Larch). - **Verification vs Validation**: - *Verification*: "Are we building the product right?" (Reviews, walkthroughs, inspections - Static testing). - *Validation*: "Are we building the right product?" (Testing against actual user requirements - Dynamic testing). --- ## Unit 2: Software Project Management & Estimation ### 2.1 Project Estimation Techniques (LOC & Function Points) - **Lines of Code (LOC)**: Direct size metric. Dependent on programming language syntax. - **Function Point (FP) Analysis (Albrecht)**: Language-independent size estimation based on 5 Information Domain Characteristics: 1. External Inputs (EI) 2. External Outputs (EO) 3. External Inquiries (EQ) 4. Internal Logical Files (ILF) 5. External Interface Files (EIF) - **FP Formula**: $FP = UFP \times [0.65 + 0.01 \times \sum EDI]$ where $UFP$ is Unadjusted Function Points and $EDI$ (or $CAF$) is Value Adjustment Factor based on 14 General System Characteristics (complexity range 0 to 5). ### 2.2 COCOMO Estimation Model (Boehm) - **Basic COCOMO**: Effort $E = a \times (KLOC)^b$ person-months; Duration $D = c \times (E)^d$ months. - *Organic*: $a = 2.4, b = 1.05, c = 2.5, d = 0.38$ (Small team, stable environment) - *Semi-detached*: $a = 3.0, b = 1.12, c = 2.5, d = 0.35$ (Medium team, mixed experience) - *Embedded*: $a = 3.6, b = 1.20, c = 2.5, d = 0.32$ (Strict hardware/software constraints) - **Intermediate COCOMO**: Incorporates 15 Cost Drivers (Effort Multipliers $EAF$). $E = a \times (KLOC)^b \times EAF$. - **Detailed COCOMO**: Applies phase-sensitive effort multipliers across subsystem components. ### 2.3 Risk Management & Project Scheduling - **RMMM Plan**: Risk Mitigation, Monitoring, and Management. - **Scheduling Tools**: - **Gantt Chart**: Visual timeline of task schedules, dependencies, and progress. - **PERT / CPM**: Network-based scheduling identifying **Critical Path** (longest path through network with 0 float/slack time). - **PERT Expected Duration**: $T_e = \frac{a + 4m + b}{6}$ where $a$ = optimistic time, $m$ = most likely time, $b$ = pessimistic time. --- ## Unit 3: Requirement Analysis & Structured Analysis ### 3.1 Requirement Analysis & Specification - **Analysis Tasks**: Problem recognition, Evaluation & synthesis, Modeling, Specification, Review. - **Data Dictionary**: Centralized repository containing definitions of all data elements, data structures, data flows, and data stores used in analysis models. ### 3.2 Structured Analysis & Flow Diagrams - **Data Flow Diagram (DFD)**: Graph showing data flow through a system. - *Symbols*: Process (Circle/Bubble), Data Flow (Arrow), Data Store (Open rectangle/Parallel lines), External Entity (Square/Rectangle). - *Levels*: Level 0 (Context Diagram - single process block representing entire system), Level 1 (Major subsystems), Level 2 (Detailed process breakdown). - **Control Flow Diagram (CFD)** & **Process Specification (PSEC)**: Describes control signals and algorithmic step-by-step detail using Structured English, Decision Tables, or Decision Trees. - **Behavioral Modeling & Finite State Machine (FSM)**: State Transition Diagrams (STD) showing system states, events, and transitions. --- ## Unit 4: Software Design & Modularity ### 4.1 Fundamentals of Software Design - **Abstractions**, **Refinement**, **Modularity**, **Software Architecture**, **Information Hiding** (Parnas Principle). ### 4.2 Modular Design Metrics: Cohesion & Coupling - **Cohesion** (Internal strength within a single module - Higher is Better): 1. *Functional* (Best/Highest): Module performs exactly one single targeted function. 2. *Sequential*: Output of one element is input to next. 3. *Communicational*: Elements operate on same input/output data. 4. *Procedural*: Elements execute in a specific sequence. 5. *Temporal*: Elements executed at same time (e.g., initialization). 6. *Logical*: Elements logically related but perform different actions. 7. *Coincidental* (Worst/Lowest): Elements combined randomly without meaningful relationship. - **Coupling** (Interdependence between modules - Lower is Better): 1. *Data Coupling* (Best/Lowest): Modules communicate via simple scalar data parameters. 2. *Stamp (Data-Structure) Coupling*: Modules pass entire data structures (composite data). 3. *Control Coupling*: One module passes control flags/signals to influence execution flow of another. 4. *External Coupling*: Modules share external protocol/hardware interface. 5. *Common Coupling*: Modules share global variables/data structures. 6. *Content Coupling* (Worst/Highest): One module directly accesses/modifies internal data/code of another. ### 4.3 Cyclomatic Complexity (McCabe) - Metric measuring logical complexity of a control flow graph $G$. - Formulas: 1. $V(G) = E - N + 2P$ (where $E$ = edges, $N$ = nodes, $P$ = connected components, usually $P=1$). 2. $V(G) = P_{pred} + 1$ (where $P_{pred}$ = number of predicate/decision nodes). 3. $V(G) = \text{Number of enclosed bounded regions} + 1$. --- ## Unit 5: Object-Oriented Analysis & Design (OOAD) & UML ### 5.1 OOAD Concepts & Principles - **Class & Object Modeling**: Mapping real-world domain entities to classes and objects. - **Relationships**: - *Association*: General semantic link between two classes. - *Aggregation*: Weak "has-a" relationship (independent lifecycle). - *Composition*: Strong "part-of" relationship (bound lifecycle). - *Generalization/Inheritance*: "is-a" taxonomy hierarchy. ### 5.2 Introduction to Unified Modeling Language (UML) - **Structural Diagrams**: - **Class Diagram**: Static structure showing classes, attributes, operations, and relationships. - **Object Diagram**: Snapshot of instances at runtime. - **Behavioral Diagrams**: - **Use Case Diagram**: System boundaries, Actors, Use Cases, `<<include>>` (mandatory dependency), `<<extend>>` (optional/conditional dependency). - **Sequence Diagram**: Interaction diagram emphasizing time ordering of messages exchanged between lifelines. - **Activity Diagram**: Dynamic flow of control/activities (similar to flowchart with parallel forks and joins). - **State Machine / Statechart Diagram**: States, state transitions, and events for a single object state machine.

View Cheat Sheet & MCQs
Topic 210 Key Rules

Software Engineering Unit 1: SDLC Models, SRS, Formal Specification & V&V

# UNIT 1: Introduction, Software Life-Cycle Models, Software Requirements Specification (SRS), Formal Requirements Specification, Verification & Validation ## 1.1 Introduction to Software Engineering & Crisis Software Engineering is defined by IEEE as "the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software." ### The Software Crisis During the 1960s and 1970s, computer hardware evolved rapidly while software development remained an unstructured, informal craft. This led to severe issues collectively termed the **Software Crisis**: - Projects running significantly over budget and past deadlines. - Software being unreliable, unmaintainable, and exhibiting low quality. - Unmet user expectations due to poor requirement elicitation. - High software maintenance costs (often exceeding 70-80% of total lifecycle cost). ### Software Engineering Principles To overcome the software crisis, fundamental principles were established: 1. **Modularity**: Dividing a large complex system into smaller, independent, manageable units. 2. **Abstraction**: Hiding internal implementation details while exposing essential interface capabilities. 3. **Information Hiding (Parnas Principle)**: Restricting access to internal data structures and module logic. 4. **Localization**: Grouping related code and data elements together in single modules. 5. **Uniformity**: Standardized coding styles, documentation, and design notations. 6. **Completeness & Confirmability**: Ensuring all requirements are met and verifiable through formal testing. --- ## 1.2 Software Development Life Cycle (SDLC) Models ### 1. Classical Waterfall Model Introduced by Winston Royce (1970), the Waterfall Model is a linear-sequential software process model divided into distinct non-overlapping phases: 1. **Feasibility Study**: Technical, economic, and operational viability analysis. 2. **Requirement Analysis & Specification**: Gathering user requirements and producing the SRS. 3. **Design**: System Architecture, High-Level Design (HLD), and Low-Level Design (LLD). 4. **Coding & Unit Testing**: Translating design into executable source code modules. 5. **Integration & System Testing**: Combining modules and verifying system functionality. 6. **Maintenance**: Corrective, adaptive, perfective, and preventive maintenance. #### Advantages & Disadvantages - *Advantages*: Simple, easy to manage, clear milestones, well-documented phases. - *Disadvantages*: High risk and uncertainty; rigid phase boundaries; no working software until late in the lifecycle; unsuitable for long or complex projects with evolving requirements. --- ### 2. Prototyping Model When user requirements are vague or ill-defined, the Prototyping Model builds a working mock-up (prototype) early in the development lifecycle. #### Workflow 1. Quick Requirement Gathering. 2. Quick Design & Prototype Construction. 3. Customer Prototype Evaluation & Feedback. 4. Prototype Refinement (Iterative loop until requirements stabilize). 5. Final Product Engineering (Building full system based on approved prototype). #### Types of Prototypes - **Throwaway Prototyping**: The prototype is discarded after requirements are finalized, and system code is rebuilt cleanly. - **Evolutionary Prototyping**: The prototype is continuously refined and expanded into the final production system. --- ### 3. Rapid Application Development (RAD) Model The RAD model is a high-speed adaptation of the linear-sequential model, prioritizing component-based construction. - Requires system modularization into independent sub-components. - Multiple parallel development teams build sub-modules within tight 60–90 day timeframes. - Heavy reliance on reusable software components, automated GUI builders, and CASE tools. --- ### 4. Spiral Model (Boehm) Proposed by Barry Boehm in 1988, the Spiral Model is an iterative, risk-driven process model. It combines the structured rigidity of the Waterfall Model with the iterative nature of Prototyping. #### The 4 Spiral Quadrants 1. **Objective Setting & Identification**: Define phase objectives, alternative solutions, and constraints. 2. **Risk Assessment & Reduction**: Evaluate technical and operational risks; build prototypes to mitigate risks. 3. **Development & Validation**: Develop code, perform unit/integration/system testing, and build the product release. 4. **Planning**: Review phase progress and plan the next spiral iteration. #### Key Strength The Spiral Model is unique because it explicitly incorporates **Risk Analysis** as a primary phase activity. It is the model of choice for large, expensive, high-risk systems (e.g., defense aerospace systems). --- ### 5. Agile Methodology & Scrum Framework Agile software development values individuals and interactions over processes, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan (Agile Manifesto). #### Scrum Framework Key Elements - **Sprints**: Fixed-duration iterative development cycles lasting 2 to 4 weeks. - **Product Backlog**: Prioritized master list of user stories and functional requirements. - **Sprint Backlog**: Subset of product backlog items selected for execution in the current sprint. - **Scrum Roles**: - *Product Owner*: Defines user stories and prioritizes backlog. - *Scrum Master*: Facilitates team process and eliminates operational blockers. - *Development Team*: Cross-functional self-organizing engineering group. - **Ceremonies**: Daily Standup (15-min sync), Sprint Planning, Sprint Review (demo), Sprint Retrospective. --- ## 1.3 Software Requirements Specification (SRS) ### Definition & Purpose An SRS is a formal document that describes the intended behavior, constraints, interfaces, and quality attributes of a software system. It forms the binding legal contract between software customers and developers. ### IEEE 830 Standard Structure 1. **Introduction**: Purpose, Scope, Definitions, References, Overview. 2. **Overall Description**: Product perspective, Product functions, User characteristics, Constraints, Assumptions. 3. **Specific Requirements**: - **Functional Requirements**: Statements detailing input processing, output generation, and business rules. - **Non-Functional Requirements**: Performance, Reliability, Security, Usability, Maintainability, Availability. - **External Interface Requirements**: User interfaces, Hardware interfaces, Software interfaces, Communications interfaces. ### Characteristics of a Good SRS (IEEE 830) - **Correct**: Every requirement accurately states a feature to be delivered. - **Unambiguous**: Every requirement has exactly ONE interpretation. - **Complete**: Includes all significant functional and non-functional requirements. - **Consistent**: No requirements conflict with one another. - **Ranked for Importance & Stability**: Requirements labeled as essential, conditional, or optional. - **Verifiable**: There exists a cost-effective finite process to verify that the software meets the requirement. - **Modifiable**: Structure permits easy structural changes without breaking consistency. - **Traceable**: Origin of each requirement is clear, and forward/backward tracing to design/code is possible. - **Implementation Independent**: Specifies WHAT system does, not HOW it is coded. --- ## 1.4 Formal Requirements Specification Formal methods use mathematical notations—derived from set theory, predicate logic, algebraic structures, and state machines—to specify software behavior without natural language ambiguity. ### Key Specification Languages - **Z Notation**: Model-based specification language based on Zermelo-Fraenkel set theory and first-order predicate logic. Uses *Schemas* to define state spaces and state transitions. - **VDM (Vienna Development Method)**: Model-oriented language featuring explicit pre-conditions and post-conditions for data operations. - **Larch**: Two-tiered specification approach separating interface specification from underlying logic. ### Benefits & Drawbacks - *Benefits*: Eliminates ambiguity, enables mathematical proof of correctness, catches design flaws early. - *Drawbacks*: Requires specialized mathematical background; steep learning curve; high initial cost; difficult for non-technical stakeholders to review. --- ## 1.5 Software Verification & Validation (V&V) ### Verification vs Validation Core Distinction - **Verification**: *"Are we building the product right?"* - Static evaluation process. - Checks if software artifacts conform to specifications defined in preceding phases. - Involves Reviews, Inspections, Walkthroughs, static code analysis without executing software. - **Validation**: *"Are we building the right product?"* - Dynamic evaluation process. - Checks if the built software satisfies actual customer operational needs. - Involves running functional tests, performance tests, and acceptance tests on executable code. ### Levels of Software Testing 1. **Unit Testing**: Testing individual functions, classes, or modules in isolation (White-Box testing). 2. **Integration Testing**: Testing module interfaces and combined sub-assemblies (Top-down, Bottom-up, Big-Bang, Sandwich). 3. **System Testing**: Testing complete integrated system against functional and non-functional SRS specs (Black-Box testing). 4. **Acceptance Testing**: Final testing by end-users before production deployment. - **Alpha Testing**: Conducted at developer's site by internal users in a controlled environment. - **Beta Testing**: Conducted at customer's site by end-users in a real operational environment. --- ---

View Cheat Sheet & MCQs
Topic 310 Key Rules

Software Engineering Unit 2: Software Project Management, Estimation & COCOMO

# UNIT 2: Software Project Management: Objectives, Resource Estimation, LOC & FP Estimation, Effort Estimation, COCOMO Model, Risk Analysis, Software Project Scheduling ## 2.1 Software Project Management (SPM) Fundamentals SPM encompasses planning, monitoring, and controlling software projects to ensure software is delivered on time, within budget, and meeting quality standards. ### The Management Spectrum (4 Ps) 1. **People**: Project managers, software engineers, clients, end-users. Human resource selection and team structure. 2. **Product**: Defining software scope, functional objectives, and technical constraints. 3. **Process**: Selecting the appropriate SDLC framework model. 4. **Project**: Planning, tracking, risk management, and quality control. --- ## 2.2 Software Size & Resource Estimation ### 1. Lines of Code (LOC) Direct, direct-count size metric measuring source code volume (e.g., SLOC, KLOC). - *Formula*: Productivity = $KLOC / \\text{Person-Months}$ - *Limitations*: Highly dependent on programming language syntax (1 LOC in Python != 1 LOC in Assembly); rewards verbose code; difficult to estimate early during requirement phase. --- ### 2. Albrecht Function Point (FP) Analysis Function Point analysis measures software size based on functional units delivered to the user, completely independent of programming language syntax. #### The 5 Information Domain Characteristics 1. **External Inputs (EI)**: Elementary user inputs that update internal system logical files (e.g., registration form submission). 2. **External Outputs (EO)**: Data processing outputs generated for users (e.g., report generation, confirmation receipt). 3. **External Inquiries (EQ)**: Interactive input queries resulting in immediate data retrieval without updating data files. 4. **Internal Logical Files (ILF)**: User-identifiable logical data groups maintained inside system boundary (e.g., database tables). 5. **External Interface Files (EIF)**: Data files maintained by external systems referenced for reading/lookup only. #### Step-by-Step Function Point Calculation 1. Calculate **Unadjusted Function Points (UFP)**: $$UFP = \\sum (\\text{Count}_i \\times \\text{Weight}_i)$$ where weight depends on complexity (Low, Average, High) of each of the 5 domain characteristics. 2. Determine **Value Adjustment Factor (VAF)** based on 14 General System Characteristics (GSCs) scored from 0 (no influence) to 5 (strong influence): - Data communications, Distributed processing, Performance, Heavily used configuration, Transaction rate, On-line data entry, End-user efficiency, On-line update, Complex processing, Reusability, Installation ease, Operational ease, Multiple sites, Facilitate change. 3. Calculate Total Degree of Influence ($EDI = \\sum F_i$, range 0 to 70). 4. Calculate final adjusted **Function Points (FP)**: $$FP = UFP \\times [ 0.65 + 0.01 \\times \\sum F_i ]$$ *(Note: The Adjustment Factor ranges from 0.65 when $EDI=0$ to 1.35 when $EDI=70$)*. --- ## 2.3 COCOMO Estimation Model (Boehm) Constructive Cost Model (COCOMO) is an empirical cost estimation model based on historical project data. ### Software Project Modes - **Organic Mode**: Small teams, familiar software environment, flexible requirements, minimal innovation needed. - **Semi-Detached Mode**: Medium teams, mixed experience levels, combination of rigid and flexible requirements. - **Embedded Mode**: Tight hardware/software/operational constraints, complex interfaces, high technical regulation. --- ### 1. Basic COCOMO Calculates effort and duration strictly as a function of estimated size in Thousands of Delivered Source Instructions (KLOC). #### Effort & Duration Formulas - Effort: $E = a \\cdot (KLOC)^b$ [Person-Months] - Development Duration: $D = c \\cdot (E)^d$ [Months] - Recommended Staff Size: $SS = E / D$ [Persons] #### Coefficient Constants Matrix | Mode | $a$ | $b$ | $c$ | $d$ | | :--- | :--- | :--- | :--- | :--- | | **Organic** | 2.4 | 1.05 | 2.5 | 0.38 | | **Semi-Detached** | 3.0 | 1.12 | 2.5 | 0.35 | | **Embedded** | 3.6 | 1.20 | 2.5 | 0.32 | --- ### 2. Intermediate COCOMO Extends Basic COCOMO by multiplying basic effort with an **Effort Adjustment Factor (EAF)** derived from 15 Cost Drivers across 4 categories: 1. *Product Attributes*: Required software reliability, Database size, Product complexity. 2. *Hardware Attributes*: Execution time constraint, Main memory constraint, Virtual machine volatility, Environment turn-around time. 3. *Personnel Attributes*: Analyst capability, Applications experience, Programmer capability, Virtual machine experience, Programming language experience. 4. *Project Attributes*: Use of modern software tools, Application of software engineering methods, Required development schedule. #### Formula $$E = a \\cdot (KLOC)^b \\times EAF$$ where $EAF = \\prod_{i=1}^{15} \\text{Cost Driver Rating}_i$. --- ### 3. Detailed (Complete) COCOMO Applies phase-sensitive cost driver ratings to individual subsystem modules, recognizing that cost factors vary across Requirements, High-Level Design, Detailed Design, Coding, Unit Testing, and Integration phases. --- ## 2.4 Risk Analysis & Management ### Risk Categories - **Project Risks**: Threaten project budget, schedule, staffing, and resources. - **Technical Risks**: Threaten quality and timeliness due to technical complexity or hardware limits. - **Business Risks**: Threaten economic viability (e.g., market risk, sales risk, management change risk). ### Risk Management Steps 1. **Risk Identification**: Brainstorming risk checklists (Product size, Business impact, Staff experience, Process maturity). 2. **Risk Projection (Estimation)**: Rate Risk Likelihood ($L_i$) and Risk Impact ($I_i$). Calculate Risk Exposure: $$RE = P(\\text{Risk}) \\times \\text{Cost of Risk}$$ 3. **Risk Refinement**: Breaking down macro risks into detailed micro risk components. 4. **Risk Mitigation, Monitoring, and Management (RMMM Plan)**: - *Mitigation*: Proactive steps to reduce risk likelihood or impact before it occurs. - *Monitoring*: Tracking risk indicators during development. - *Management*: Contingency plan execution if risk materializes. --- ## 2.5 Software Project Scheduling & Network Analysis ### Work Breakdown Structure (WBS) Decomposes total project scope into hierarchical, smaller work packages and tasks. ### 1. Gantt Chart Horizontal bar chart displaying task start dates, finish dates, durations, and task overlap dependencies. --- ### 2. PERT / CPM Network Analysis Program Evaluation and Review Technique (PERT) and Critical Path Method (CPM) represent project schedules as activity-on-edge or activity-on-node directed graphs. #### Key Terminology - **Earliest Start (ES)** / **Earliest Finish (EF)**: Earliest time a task can begin/end. - **Latest Start (LS)** / **Latest Finish (LF)**: Latest time a task can begin/end without delaying total project completion. - **Float / Slack Time**: Total time an activity can be delayed without delaying project completion date. $$\\text{Slack} = LS - ES = LF - EF$$ - **Critical Path**: Longest continuous path through activity network diagram. All activities on critical path have **Zero Float (Slack = 0)**. #### PERT Weighted Average Duration Calculation Since activity durations are uncertain, PERT uses 3-point estimates following a Beta distribution: 1. Optimistic Time ($a$): Shortest completion time under ideal conditions. 2. Most Likely Time ($m$): Normal completion time. 3. Pessimistic Time ($b$): Maximum completion time under worst conditions. #### Formulas - Expected Task Duration: $T_e = \\frac{a + 4m + b}{6}$ - Standard Deviation: $\\sigma = \\frac{b - a}{6}$ - Variance: $\\sigma^2 = \\left( \\frac{b - a}{6} \\right)^2$ --- ---

View Cheat Sheet & MCQs
Topic 47 Key Rules

Software Engineering Unit 3: Requirement Analysis & Structured Analysis (DFD & CFD)

# UNIT 3: Requirement Analysis: Tasks, Principles, Prototyping & Specification, Data Dictionary, Finite State Machine (FSM) Models, Structured Analysis (DFD & CFD) ## 3.1 Requirement Analysis Tasks & Principles ### Requirement Analysis Tasks 1. **Problem Recognition**: Understanding system domain, organizational environment, and stakeholder pain points. 2. **Evaluation & Synthesis**: Analyzing data flows, functional boundaries, operational constraints, and technical feasibility. 3. **Modeling**: Abstracting system functional requirements into graphical structural models. 4. **Specification**: Formally documenting requirements into an SRS. 5. **Review & Validation**: Conducting customer requirement walkthroughs to resolve conflicts and ambiguities. ### Core Analysis Principles - Operational domain must be represented and understood. - Models must depict information flow, control flow, and data structures. - System functions must be partitioned hierarchically to show architectural detail. - Essential requirements must be separated from implementation choices. --- ## 3.2 Data Dictionary (DD) A Data Dictionary is a centralized repository that stores precise structural definitions of every data flow, data store, process name, and composite data element referenced across analysis models. ### Data Dictionary Notation Rules - `=` : is composed of / equals - `+` : AND (sequence) - `[ | ]` : OR (selection of one alternative) - `{ }` : Iteration / repetition (0 or more times) - `( )` : Optional data item - `*...*` : Comment string #### Example Entry ```text Customer_Record = Customer_ID + Customer_Name + Address + (Phone_Number) + 1{Order_History}5 ``` --- ## 3.3 Behavioral Modeling & Finite State Machine (FSM) Behavioral modeling represents how a software system reacts to external events and changes internal states. ### State Transition Diagram (STD) Notation - **State** (Rectangle with rounded corners): Represents a specific system mode of operation (e.g., *Idle*, *Authenticating*, *Processing*). - **Transition Arrow**: Directed line indicating movement from source state to target state. - **Event / Action Label**: Format `Event [Guard Condition] / Action`. - *Event*: External occurrence triggering transition. - *Guard Condition*: Boolean predicate that must be TRUE for transition to occur. - *Action*: Output operation executed during transition. --- ## 3.4 Structured Analysis & Data Flow Diagrams (DFDs) Structured Analysis is a traditional process-centric technique introduced by DeMarco, Yourdon, and Gane & Sarson to transform requirements into Data Flow Diagrams. ### The 4 Standard DFD Symbols 1. **Process (Circle / Bubble)**: Transforms incoming data flows into outgoing data flows. 2. **External Entity / Source or Sink (Rectangle)**: Real-world entities outside system boundary that send data into or receive data from system. 3. **Data Store (Parallel Lines / Open Rectangle)**: Repository of resting data (database table, file, cache). 4. **Data Flow (Arrow)**: Named pipeline conveying moving data between processes, data stores, and entities. --- ### DFD Hierarchy & Leveling Rules #### Level 0 DFD (Context Diagram) Abstract high-level view showing the entire system as **one single process bubble** interacting with external entities. Contains 0 data stores. #### Level 1 DFD Explodes Level 0 bubble into major functional subsystems (typically 3 to 7 process bubbles), revealing primary data stores and inter-process data flows. #### Level 2+ DFD (Sub-process Explosion) Further decomposes complex Level 1 processes into sub-processes for detailed algorithmic clarity. #### Conservation of Data (Balancing Rule) All input and output data flows entering/leaving a process at Level $N$ MUST match the input and output data flows of its exploded sub-diagram at Level $N+1$. --- ## 3.5 Control Flow Diagrams (CFDs) & Process Specifications (PSEC) ### Control Flow Diagram (CFD) Extension of DFD for real-time systems. Replaces data flows with **Control Flows** (dashed arrows conveying discrete signals/events) and processes with **Control Specification (CSPEC)** modules. ### Process Specification (PSEC) Describes the internal algorithmic logic executed inside primitive DFD processes. Expressed using: - **Structured English**: Restricted natural language using `IF-THEN-ELSE`, `DO-WHILE` control logic. - **Decision Tables**: Tabular matrix mapping combinations of conditions to actions. - **Decision Trees**: Tree graph illustrating conditional decision paths. --- ---

View Cheat Sheet & MCQs
Topic 58 Key Rules

Software Engineering Unit 4: Software Design, Modularity, Cohesion & Coupling

# UNIT 4: Software Design: Design Fundamentals, Effective Modular Design, Data Architectural & Procedural Design, Design Documentation ## 4.1 Fundamentals of Software Design Software design transforms SRS specifications into detailed operational blueprints ready for implementation. ### Key Design Principles 1. **Abstraction**: Procedural abstraction (named sequence of operations) and Data abstraction (named collection of data attributes). 2. **Refinement (Stepwise Refinement)**: Top-down process of decomposing high-level statements into detailed lower-level procedural steps. 3. **Modularity**: Dividing system logic into independently named and addressable software components. 4. **Software Architecture**: Macro-structure organizing modules, relationships, and global control flow. 5. **Information Hiding**: Designing modules such that internal algorithms and data structures are inaccessible to other modules. --- ## 4.2 Effective Modular Design: Cohesion & Coupling ### The Core Architectural Rule Achieve **HIGH Cohesion** within individual modules and **LOW Coupling** between modules. --- ### Module Cohesion (Internal Module Strength) Cohesion measures the functional closeness of processing elements within a single module. (Ranked from Lowest/Worst to Highest/Best): 1. **Coincidental Cohesion (Worst)**: Elements are combined randomly without meaningful functional relationship. 2. **Logical Cohesion**: Elements are logically categorized together (e.g., a module containing all I/O routines) but execute different tasks based on input parameters. 3. **Temporal Cohesion**: Elements are grouped because they execute at the same point in time (e.g., system initialization routine `InitSystem()`). 4. **Procedural Cohesion**: Elements execute in a specific order to accomplish a multi-step procedure. 5. **Communicational Cohesion**: Elements operate on the same input data or produce the same output dataset. 6. **Sequential Cohesion**: Output of one processing element serves as direct input to the next element in a pipeline sequence. 7. **Functional Cohesion (Best)**: Module performs exactly **ONE targeted, well-defined single function** (e.g., `CalculateTax()`). --- ### Module Coupling (Inter-Module Interdependence) Coupling measures the degree of interdependence between separate software modules. (Ranked from Best/Lowest to Worst/Highest): 1. **Data Coupling (Best)**: Modules communicate strictly by passing simple scalar data parameters through function calls. 2. **Stamp (Data Structure) Coupling**: Modules communicate by passing composite data structures (e.g., passing a full `StudentRecord` struct when only `Age` is needed). 3. **Control Coupling**: One module passes control flags/signals to another module to dictate its internal execution logic. 4. **External Coupling**: Modules share an external interface schema or hardware device communication protocol. 5. **Common Coupling**: Modules share access to global data spaces or global shared memory. 6. **Content Coupling (Worst)**: One module directly modifies or accesses internal data, state, or code inside another module, violating encapsulation completely. --- ## 4.3 Cyclomatic Complexity (McCabe) Developed by Thomas McCabe in 1976, Cyclomatic Complexity is a quantitative software metric measuring the number of linearly independent paths through a program's control flow graph $G=(V,E)$. ### Calculating Cyclomatic Complexity $V(G)$ #### Method 1: Edge-Node Formula $$V(G) = E - N + 2P$$ where $E$ = number of edges, $N$ = number of nodes, $P$ = number of connected components (typically $P=1$). #### Method 2: Predicate Node Formula $$V(G) = P_{pred} + 1$$ where $P_{pred}$ = number of decision/predicate nodes (e.g., `if`, `while`, `for`, `case` statements). #### Method 3: Bounded Region Formula $$V(G) = \\text{Number of enclosed bounded regions} + 1$$ ### Risk Threshold Interpretation - $V(G) = 1 \\text{ to } 10$: Simple, low risk, highly testable code. - $V(G) = 11 \\text{ to } 20$: Moderate complexity and risk. - $V(G) = 21 \\text{ to } 50$: High complexity, high risk, difficult to test. - $V(G) > 50$: Untestable, unstable code; mandatory refactoring required. --- ## 4.4 Data, Architectural & Procedural Design ### Data Design Translates data model entities into low-level data structures, database schemas, and object attributes. ### Architectural Design Defines structural organization of system components using established architectural styles: - **Data-Centered Architecture**: Central repository (database) surrounded by independent client applications. - **Data-Flow Architecture**: Pipe-and-filter processing pipeline. - **Call-and-Return Architecture**: Main program/subroutine hierarchy and object-oriented layers. - **Layered Architecture**: Outer user interface layers communicating only with adjacent lower service layers. ### Procedural Design Translates structural design elements into step-by-step procedural logic using Flowcharts, Decision Tables, and Program Design Language (PDL/Pseudocode). --- ---

View Cheat Sheet & MCQs
Topic 68 Key Rules

Software Engineering Unit 5: Object-Oriented Analysis, Design & UML Diagrams

# UNIT 5: Object-Oriented Analysis (OOA) & Design (OOD): OOA Modeling, Data Modeling, OOD Concepts, Class & Object Relationships, Object Modularization, Introduction to UML ## 5.1 Object-Oriented Analysis & Modeling OOA focuses on identifying domain objects, their responsibilities, and relationships from real-world problem statements. ### Key OOAD Principles 1. **Encapsulation**: Bundling attributes and methods into a single class unit while protecting data via private access modifiers. 2. **Abstraction**: Exposing essential contract features while suppressing internal algorithms. 3. **Inheritance**: Subclasses acquire properties and methods of superclasses (`is-a` taxonomy). 4. **Polymorphism**: Ability of a single interface to invoke dynamic method behaviors at runtime. --- ## 5.2 Class & Object Relationships ### 1. Association A general semantic link between two independent classes (e.g., `Student` attends `Course`). Can be Unidirectional or Bidirectional with Multiplicity (`1..1`, `1..*`, `0..*`). --- ### 2. Aggregation A weak `"has-a"` structural relationship where child objects can exist independently of parent object lifecycles. - *Visual Notation*: Line with an **Open (unfilled) Diamond** at parent end. - *Example*: `Department` and `Professor`. Deleting a Department does NOT destroy Professor objects. --- ### 3. Composition A strong `"part-of"` structural relationship where child object lifecycles are bound strictly to parent object lifecycles. - *Visual Notation*: Line with a **Filled (black) Diamond** at parent end. - *Example*: `Building` and `Room`. Deleting a Building automatically destroys all its Rooms. --- ### 4. Generalization / Inheritance An `"is-a"` taxonomy relationship where a specialized subclass inherits attributes and methods from a general superclass. - *Visual Notation*: Line with an **Open Triangular Arrowhead** pointing towards superclass. - *Example*: `Car` is a `Vehicle`. --- ## 5.3 Introduction to Unified Modeling Language (UML) UML is a standardized graphical modeling language developed by Grady Booch, James Rumbaugh, and Ivar Jacobson (Object Management Group - OMG). ### Categorization of UML Diagrams ```text UML Diagrams | +-----------------+-----------------+ | | Structural Diagrams Behavioral Diagrams - Class Diagram - Use Case Diagram - Object Diagram - Sequence Diagram - Component Diagram - Activity Diagram - Deployment Diagram - State Machine Diagram - Package Diagram - Communication Diagram ``` --- ## 5.4 Detailed Breakdown of Key UML Diagrams ### 1. Class Diagram (Structural) Static structural diagram depicting system classes, attributes, operations (methods), access visibility (`+` public, `-` private, `#` protected), and relationships. --- ### 2. Use Case Diagram (Behavioral) Models user functional goals and system scope. - **Actor (Stick Figure)**: External entity interacting with system. - **Use Case (Oval)**: Named sequence of actions delivering measurable value to actor. - **Relationships**: - `<<include>>`: Mandatory sub-use case executed *every time* base use case runs (e.g., `Withdraw Cash` *<<includes>>* `Authenticate PIN`). - `<<extend>>`: Optional/conditional sub-use case executed *only when specific conditions occur* (e.g., `Withdraw Cash` *<<extends>>* `Print Receipt`). --- ### 3. Sequence Diagram (Behavioral / Interaction) Emphasizes **Time Ordering** of messages passed between object lifelines. - **Lifeline (Vertical Dashed Line)**: Represents existence of an object instance over time. - **Activation Box (Rectangle on lifeline)**: Indicates time period during which object is performing an operation. - **Synchronous Message (Solid Arrow head)**: Sender waits for response. - **Asynchronous Message (Half-stick Arrow head)**: Sender does not wait for response. - **Return Message (Dashed Arrow head)**: Returns control/result to caller. --- ### 4. Activity Diagram (Behavioral) Work-flow diagram depicting operational activities, decision branching (`<>`), and parallel concurrency using **Forks** (split 1 flow into parallel flows) and **Joins** (merge parallel flows into 1 flow). --- ### 5. Statechart / State Machine Diagram (Behavioral) Depicts state transitions of a single reactive object in response to discrete events throughout its lifecycle. Includes Initial State (filled circle), Transitions, and Final State (bullseye circle).

View Cheat Sheet & MCQs

High-Yield Practice Questions

Sample practice MCQs with step-by-step verified explanations.

Problem #1MEDIUM

Who is known as the father of Artificial Intelligence (AI)?

View Verified Answer
Problem #2MEDIUM

______ is an indirect measure of software development process.

View Verified Answer
Problem #3MEDIUM

______ specification is also known as SRS document.

View Verified Answer
Problem #4HARD

Which of the following is a first computer virus?

View Verified Answer
Problem #5MEDIUM

If we implement the heap as a Max Heap, and add a new node with value 15 to the leftmost node of the right subtree, what will be the values ​​at the leaf nodes in the right subtree of the heap?

View Verified Answer
Problem #6MEDIUM

Which of the following is not a symmetric key cryptography algorithm?

View Verified Answer
Problem #7HARD

Which method is used for both error detection and error correction method in computer networking?

View Verified Answer
Problem #8HARD

Select the false statement about CDMA technology – I. CDMA technology optimizes the use of available bandwidth as it transmits over the entire frequency range. II. Each user in a CDMA system uses a different code to modulate their signal. III. CDMA technology offers less security as compared to the GSM technology. IV. A SIM card is always required for the working of a CDMA device.

View Verified Answer