System Analysis and Design - Vocabulary Flashcards

System Definition and Contextual Frameworks

  • Definition of a System:

    • An organized set of interacting components functioning in a regulated manner to attain specific organizational or operational goals.

    • Fundamentally defined by activity; in the domain of information systems, the central activity is the systematic transformation and processing of data and information.

    • Scale and complexity range from simple personal computer setups (e.g., a single user running a desktop payroll application) to enterprise architectures (e.g., an international banking system servicing millions of concurrent transactions across distributed networks).

    • Integrates both computer-based infrastructure (hardware, operating software) and non-computer elements (human operators, manual guidelines, organizational policies) to deliver services to end users.

  • Delineation of Systems, Products, and Tools:

    • System Context:

    • Consists of two or more integrated components acting synergistically to execute mission objectives that individual elements cannot achieve independently.

    • Combines people, physical products, operational processes, and supporting tools into a cohesive structure.

    • Product Context:

    • Represents an enabling entity or physical device characterized by specific form, fit, function, and performance capabilities.

    • Lacks intrinsic intelligence or self-application capability, requiring human direction or system integration to fulfill higher-level tasks.

    • Examples include procurable equipment catalog items:

      • A hammer possesses form and functional design but cannot execute hammering tasks without human operation.

      • A commercial jet aircraft is a vendor-manufactured product integrated into an airline operational system; it performs automated flight functions only when programmed and monitored by flight personnel.

    • Tool Context:

    • Serves as a supporting product that allows a user or higher-level system to leverage and expand baseline capabilities to improve efficiency or throughput.

    • Examples:

      • A simple pivot and fulcrum leverage physical human force to move objects exceeding unassisted physical strength.

      • Statistical software tools enable data analysts to process massive volumes of statistical variance and data series rapidly.

Analytical Representation and System Characteristics

  • Analytical System Construct:

    • Symbolic abstraction represents a system as a boundary box accepting inputs (stimuli, cues) and generating value-added outputs.

    • The core processing mechanism represents capability, incorporating both explicit functionality (the specific actions performed) and performance (how effectively those actions are executed).

    • Detailed analytical checklist components:

    • Desirable and undesirable inputs.

    • Stakeholders and operational context.

    • Desirable and undesirable outputs.

    • Boundary definitions and environmental constraints.

  • Systems Engineering Requirements:

    • Workflow-based systems (e.g., hospitals, universities, commercial banks, manufacturing operations) require clear administrative structures, resource allocation, and collaborative channels.

    • Systems that affect public safety, health, environmental stability, or critical financial infrastructure require formal systems engineering practices combining electrical, mechanical, systems, and software engineering disciplines.

    • Incorporates mathematical modeling, ROI/profitability calculations, queuing theory, and operational statistical analyses.

  • Essential System Components:

    • Resources: Infrastructure needed for system existence, comprising Hardware (computers, network gear, stationery), Software (operating systems, applications), and Liveware (operators, technical staff, managers).

    • Procedures: Formalized guidelines and governing operational logic (e.g., banking regulations defining interest tiers across specific account categories).

    • Data/Information: Core inputs transformed through processing into structured outputs meeting specified operational requirements.

    • Intermediate Data: Transient state data generated across multi-stage processes before final output generation (e.g., multi-department validation signatures on student registration forms).

    • Processes: Actionable operational steps utilizing resources within defined procedural bounds to transform raw inputs into structured outputs.

  • General System Characteristics:

    • Objective: Clear, predefined target towards which all system sub-components coordinate.

    • Standards: Explicit performance metrics and efficiency thresholds designed into processes (e.g., selecting algorithm complexity bounds to maximize execution efficiency).

    • Environment: Surrounding physical and operational context; long-term system survival requires continuous adaptation to environmental shifts.

    • Feedback: Observational monitoring of system output fed back into operational controls to maintain performance standards.

    • Boundaries and Interfaces: Explicit functional limits defining system scope; interfaces facilitate structured data exchange across system boundaries and user interaction points.

System Classifications and Information Architecture

  • System Classifications:

    • Physical vs. Abstract Systems:

    • Physical: Tangible operational structures; can be static (office furniture, static equipment supporting operations) or dynamic (active computer hardware where data, application code, and operational states change continuously).

    • Abstract: Conceptual models, theoretical representations, algorithms, and mathematical formulas.

    • Open vs. Closed Systems:

    • Open: Continuously interacts with, adapts to, and exchanges information with its external environment (e.g., business information systems).

    • Closed: Isolated completely from external environmental influence; exists purely as an abstract or theoretical construct.

    • Man-Made Information Systems:

    • Formal: Direct administrative channels conveying organizational policies, operational memos, and structured bottom-up feedback.

    • Informal: Ad-hoc employee communication networks created to resolve day-to-day operational issues.

    • Computer-Based Information Systems (CBIS): Integrated systems dependent on computing technology to store, process, and distribute business information. Comprises six interdependent elements: Hardware, Software, People, Procedures, Data, and Information.

  • Information Systems in Organizational Hierarchies:

    • Strategic Level / Decision Support Systems (DSS):

    • Target: Executive management.

    • Function: Evaluates multi-year revenue trends, macro policy choices, long-term strategic positioning, and unstructured decision contexts.

    • Managerial Level / Management Information Systems (MIS):

    • Target: Department heads and middle management.

    • Function: Delivers tactical planning reports, quarterly performance metrics, annual production summaries, and departmental control tools.

    • Operational Level / Transaction Processing Systems (TPS):

    • Target: First-line supervisors, operational clerks, and desktop operators.

    • Function: Handles daily business transactions, order entry, ledger posting, inventory tracking, and routine operational query processing.

Fundamentals of System Analysis and Design

  • Core Concepts:

    • Systems Analysis: Detailed investigation of an existing operational environment or proposed concept to identify structural bottlenecks, define system requirements, and determine the feasibility of computerization or enhancement.

    • Systems Design: Planning and architecting an improved business system, defining module structures, user interfaces, database schemas, and output workflows.

    • Implementation & Maintenance: Deploying the designed system into active service and providing continuous maintenance to address operational environmental changes.

  • Roles and Responsibilities of a System Analyst:

    • Role Scope:

    • 1. System Analysis: Focuses exclusively on studying business workflows and determining functional requirements without technical system architecture design.

    • 2. System Analysis and Design: Combines workflow requirements determination with technical layout and architectural modeling of the solution.

    • 3. Systems Analysis, Design, and Programming: Encompasses complete end-to-end responsibilities, including requirement gathering, system design, and writing source code.

    • Core Competency Framework:

    • Business Knowledge: Comprehensive understanding of general business workflows, financial logic, and management operations.

    • Interpersonal Skills: Communication capabilities needed to interview users, bridge client-developer language gaps, and manage change.

    • Problem-Solving Skills: Quantitative and analytical capabilities to construct alternative technical architectures and resolve lifecycle implementation challenges.

  • Classifications of System Users:

    • Hands-on / Direct End-Users: Staff who directly interact with the software and hardware interface to enter raw data and generate direct outputs (e.g., service counter operators).

    • Indirect End-Users: Personnel who do not directly operate technical interfaces but rely on derived operational reports and analytics to perform duties (e.g., operational managers).

    • User Management: Supervisory personnel who oversee system operations, manage operational resource allocations, and fund system initiatives.

    • Senior Management: Executive leaders responsible for evaluating overall enterprise risk exposures, financial investments, and strategic returns from system implementations.

Case Study: Ambo Public Library System

  • Baseline Operational Profile:

    • Largest public library in Ambo with approximately 300300 registered members.

    • Membership criteria: Age 1818 years or older with an annual membership fee of 50.00 Birr50.00\,\text{Birr}.

    • Paper-based membership registration forms stored manually in file cabinets.

    • Book Borrowing Mechanism: Members are issued up to 33 physical issue cards, with each card allowing the temporary checkout of 11 book.

    • Fine Structure: Overdue returns incur a fine of 0.25 Birr0.25\,\text{Birr} per day per overdue volume.

    • Card Loss Handling: Duplicate issue cards are provided upon request when cards are reported lost.

    • Staffing & Visitor Load: 22 full-time librarians manage checkouts and returns; approximately 100100 members visit daily.

    • Inventory Holdings: 50005000 total cataloged volumes, including 10001000 non-circulating reference works.

    • Record Keeping: Fully manual paper ledgers tracking publisher data, author information, acquisition sources, member checkout histories, and collected fine revenues.

  • Identified Operational Bottlenecks:

    • Ambiguity in duplicate card issuance allows members to claim lost cards fraudulently to bypass the 33-book borrowing limit.

    • High effort and delay in manually determining whether a specific volume is currently checked out or available on the shelves.

    • Cumulative reporting (inventory status, monthly fine ledgers, membership rosters) requires extensive manual paper reviews.

    • Operational stagnation: Membership application processing (5050 to 100100 requests per month) frozen for 22 months at 250250 active members due to administrative paper limits.

  • Expansion Objectives and System Requirements:

    • Target membership growth rate set to 7575 new members per month.

    • Updated Membership Fee Options: 100.00 Birr100.00\,\text{Birr} annually or 50.00 Birr50.00\,\text{Birr} semi-annually.

    • Increased borrowing limit from 33 to 44 books per member.

    • Technical Solution Requirements: Automate catalog searches, eliminate paper issue cards entirely, maintain digital member accounts, track fines automatically, and output managerial summary reports.

Software Development Life Cycle (SDLC) Framework

  • Phases of System Development:

    • 1. Preliminary Investigation:

    • Triggered by formal project requests to isolate problems, define needs, select viable candidate systems, evaluate feasibility, and gain formal project approval.

    • 2. Requirement Analysis:

    • Detailed evaluation of the problem domain to establish explicit operational expectations.

    • Resolves communication gaps between non-technical business clients and software engineering teams.

    • Produces the formal Software Requirements Specification (SRS) document.

    • 3. System Design:

    • Top-Level System Design: Identifies core software modules, module communication paths, high-level data structures, and overall architectural topology.

    • Detailed Design: Specifies file layouts, screen interfaces, exact output report layouts, and programmatic logic algorithms.

    • 4. Software Development (Coding):

    • Translates design layouts into high-quality source code using structured programming standards.

    • Focuses on code readability, structured control flow, simplicity, and low complexity to minimize subsequent testing and maintenance overhead.

    • 5. System Testing:

    • Executes system programs using artificial test cases to uncover requirements, design, and logic syntax errors.

    • 6. Implementation and Maintenance:

    • Installs software into production environments and provides long-term maintenance (corrective and adaptive updates).

Software Lifecycle Models

  • Waterfall Model:

    • Structure: Strictly sequential execution flow: Feasibility Analysis →\rightarrow Requirements Analysis →\rightarrow System Design →\rightarrow Coding →\rightarrow Integration & Testing →\rightarrow Installation →\rightarrow Maintenance.

    • Deliverables Output Baseline: Requirements document, Project plan, System design specification, Detailed design document, Test plan and test execution reports, Production source code, User and technical manuals, Review milestone reports.

    • Advantages: Simple to explain to clients, highly structured, well-defined milestone boundaries, simplifies scheduling and progress tracking.

    • Limitations: Assumes operational requirements can be completely frozen upfront; does not accommodate changing user needs well; delays client viewing of working software until late in the development cycle.

  • Prototyping Lifecycle:

    • Structure: Builds an early, throwaway working prototype based on initial requirement gathering. Clients interact with the prototype to refine functional requirements prior to final architecture construction.

    • Advantages: High user engagement, effectively clarifies ambiguous or missing specifications, demonstrates technical feasibility early.

    • Disadvantages: Risks degenerating into an unorganized "implement and repair" cycle; can expand project scope and system complexity beyond initial plans.

  • Iterative Enhancement Model:

    • Structure: Software is designed, implemented, tested, and delivered in progressive functional increments. Each increment adds functional capabilities to the core operational base.

    • Advantages: Simplifies testing by isolating increments, delivers core functionality early, and continuously integrates user feedback.

  • Spiral Model:

    • Structure: Risk-driven iterative lifecycle framework organized radially into four functional quadrants:

    • Quadrant 1: Identify objectives, operational alternatives, and system constraints.

    • Quadrant 2: Evaluate alternatives, identify operational risks, and execute risk resolution strategies (prototyping, simulation, benchmarking).

    • Quadrant 3: Develop, verify, and test the next-level product.

    • Quadrant 4: Plan subsequent iterative phases.

    • Dimensions: Radial dimension reflects cumulative financial cost incurred; angular dimension reflects progress made along iterative cycles.

    • Advantages: Accommodates risk management directly, combines prototyping and structured waterfall features, and applies equally to new development and legacy software enhancement projects.

Object-Oriented Lifecycle and Paradigms

  • Phases of Object-Oriented System Development:

    • 1. Object-Oriented Analysis (OOA):

    • Analyzes the problem domain to identify real-world objects, their operational responsibilities, and structural relationships without incorporating implementation specifics.

    • 2. Object-Oriented Design (OOD):

    • System Design: Architecturally organizes the software into interacting functional subsystems.

    • Object Design: Specifies detailed data structures, algorithmic operations, and precise inheritance relationships for identified objects.

    • 3. Object-Oriented Implementation (OOI):

    • Translates class models and inter-object structures directly into object-oriented source code and underlying database storage structures.

  • Core Object-Oriented Concepts:

    • Class: A template defining the common attributes and operational methods of a set of similar objects.

    • Abstraction: Selects application-relevant object characteristics while omitting irrelevant real-world details.

    • Inheritance: Allows new child classes to inherit attributes and methods from existing parent classes, increasing code reusability.

    • Encapsulation / Data Hiding: Bundles data and operations within an object, concealing internal data structures from external components and protecting program code from unintended modifications.

  • Three Essential Object-Oriented Models:

    • Object Model: Represents static structural layouts, objects, classes, and their relationships.

    • Dynamic Model: Captures behavioral changes, internal state transitions, and event-driven reactions over time.

    • Functional Model: Maps data transformations, data flow logic, and processing pipelines across the system.

Preliminary Analysis and Feasibility Studies

  • Context of Feasibility Studies:

    • Preliminary evaluation conducted prior to committing financial and technical resources to determine project viability and select optimal technical solutions.

    • Driven by system operational redundancy, technology obsolescence, business volume expansion, client satisfaction issues, or market competition.

  • Four Major Feasibility Dimensions:

    • 1. Technical Feasibility:

    • Evaluates whether required hardware, software, networking technology, and specialized technical personnel (programmers, system testers, database architects) are available.

    • 2. Economic Feasibility (Cost-Benefit Analysis - CBA):

    • Evaluates whether cumulative economic benefits equal or exceed total project development and operational expenditures.

    • Cost Categories:

      • Development Costs: One-time capital expenditures incurred during build phases (wages, initial hardware procurement, tools).

      • Operating Costs: Recurring expenses required for daily running and maintenance (hardware servicing, power, ongoing licensing, support personnel).

      • Tangible vs. Intangible Costs/Benefits: Direct measurable items (hardware costs, labor savings) vs. qualitative factors (enhanced brand image, improved customer goodwill).

      • Direct vs. Indirect Costs: Expenses tied directly to a system module vs. shared infrastructure operational overhead (electricity, facility lease, insurance).

      • Fixed vs. Variable Costs: Non-changing baseline expenses (equipment depreciation) vs. operational volume-dependent costs.

    • Mathematical Evaluation Example:

      • Measured total system project benefits = 300,000 Birr300{,}000\,\text{Birr}.

      • Measured total development/operational costs = 154,000 Birr154{,}000\,\text{Birr}.

      • Net Economic Yield Calculation:         Profit=Benefits−Costs=300,000−154,000=146,000 Birr\text{Profit} = \text{Benefits} - \text{Costs} = 300{,}000 - 154{,}000 = 146{,}000\,\text{Birr}

      • Decision Output: Economically feasible due to a positive net yield of 146,000 Birr146{,}000\,\text{Birr}.

    • 3. Operational Feasibility:

    • Evaluates end-user operational acceptability, management backing, impact on daily workflow velocity, and potential user resistance.

    • 4. Legal Feasibility:

    • Assesses contractual compliance, liability exposure, software licensing laws, data privacy mandates, and corporate regulatory standards.

Fact-Finding Techniques for Requirement Gathering

  • Foundational Fact-Finding Framework:

    • Gathers data across four core information system building blocks:

    • Data: Raw data inputs transformed into operational information.

    • Processes: Activities driving core operational missions.

    • Interfaces: Interaction mechanics connecting human users and subsystems.

    • Geography: Locations where data collection, processing, and storage take place.

  • Primary Fact-Finding Methodologies:

    • 1. Interviews:

    • Direct dialog between the analyst and stakeholders.

    • Structured Interviews: Uses standard question sets applied uniformly across interviewees.

      • Open-response format allows free-form feedback.

      • Closed-response format restricts responses to predefined options.

    • Unstructured Interviews: Flexible question-and-answer format useful for exploratory discussions, though requiring active analyst management to prevent off-topic digressions.

    • 2. Questionnaires:

    • Distributes printed or electronic survey instruments to gather data from large populations quickly and economically while guaranteeing respondent anonymity.

    • Formats include Fill-in-the-blanks, Dichotomous (Yes/No), Ranking scales, Multiple-choice, and Rating scales.

    • 3. Record Reviews:

    • Systematic evaluation of existing organizational documentation, standard operating procedure manuals, transaction logs, and summary reports.

    • Provides baseline operational knowledge, though actual field practices may diverge from documented procedures.

    • 4. On-Site Observation:

    • Firsthand physical observation of operational workflows to gain unbiased insights into actual daily practices.

    • Helps reveal discrepancies between formal documentation and practical field operations, though it requires time and patience.

Decision-Making Documentation Tools

  • Decision Trees:

    • Graphical, tree-like logic representations mapping conditions and subsequent operational actions sequentially from left (root node) to right.

    • Example (Saree Manufacturer Discount Policy):

    • Individual Customer Type:

      • Order quantity ≥12\ge 12 units: Apply 50%50\% discount rate.

      • Order quantity <12< 12 units: Apply 30%30\% discount rate.

    • Retailer/Shopkeeper Customer Type:

      • Order quantity <12< 12 units: Apply 15%15\% discount rate.

      • Order quantity 1313 to 4848 units: Apply 30%30\% discount rate.

      • Order quantity 4949 to 8484 units: Apply 40%40\% discount rate.

      • Order quantity ≥85\ge 85 units: Apply 50%50\% discount rate.

  • Decision Tables:

    • A two-dimensional decision matrix structured into four key quadrants:

    • Condition Stub (lists all decision variables/conditions).

    • Condition Entry (specifies condition states using Y/N/Hyphen).

    • Action Stub (lists all possible operational actions).

    • Action Entry (specifies executed actions using X).

    • Rule Combinations: For NN distinct conditional statements, total potential decision rules = 2N2^N.

    • Rule Reduction / Consolidation: Removes impossible condition combinations and consolidates rules containing "indifferent conditions" (where specific condition values do not alter resultant actions).

    • Example (Payroll System Processing Table):

    • Conditions: Employee Type (SS = Salaried, HH = Hourly), Hours Worked (<40<40, =40=40, >40>40).

    • Condensation Logic: Salaried employee actions (Pay base salary) remain unchanged regardless of hours worked, allowing salaried condition columns to consolidate into a single rule.

  • Structured English:

    • Narrative procedural description using logical control structures (IF-THEN-ELSE, DO-WHILE) and imperative action verbs to eliminate natural language ambiguity.

    • Core Control Structures:

    • Sequence Structures: Unconditional sequential execution statements.

    • Decision Structures: Conditional logic blocks branching based on evaluated criteria.

    • Iteration Structures: Repeated execution loops based on conditional rules.

  • Data Dictionary:

    • Centralized catalog defining all data elements, composite data structures, data flows, and data stores used throughout the system.

    • Data Element: The smallest atomic unit of data that cannot be decomposed further (field/item).

    • Data Structure: A logical grouping of related data elements representing a unified operational entity.

Functional Requirements and Architectural Elements

  • Core System Architectural Elements:

    • Modules: Self-contained operational units organized in a modular hierarchy to eliminate duplicate functional instructions.

    • Processes: Recurring functional operations with defined input parameters, discrete transformation logic, and specified outputs.

    • Inputs and Outputs: Input collection structures, validation checks, user guidance prompts, and output layouts across display, print, or storage media.

    • Databases and Files: Storage structures configured for specific retention needs, including transaction files, master datasets, and historical archives.

    • Interfaces: Human-computer interaction screens, control menus, error feedback displays, and context-sensitive help features.

Functional Modeling via Data Flow Diagrams (DFD)

  • Data Flow Diagram (DFD) Mechanics:

    • Graphical notation depicting the functional flow and transformation of data through an information system.

    • Four Primary Symbols:

    • External Entity (Square/Rectangle): External data origin or destination outside the system boundary.

    • Data Flow (Arrowed Line): Data movement vector ("data in motion").

    • Data Store (Open Rectangle / Parallel Lines): Data repository ("data at rest").

    • Process (Circle / Bubble / Rounded Rectangle): Functional transformation modifying incoming data flows into outgoing data flows.

    • Types of DFDs: Physical DFDs model current operational setups during analysis; Logical DFDs model proposed system functional flows during design.

    • Leveling Hierarchy: Context Diagram (Level 0) →\rightarrow First-Level DFD →\rightarrow Second-Level DFD →\rightarrow Detailed Primitive DFDs.

  • Exemplary DFD Processes from Text:

    • Worker Payment System DFD:

    • Input: Weekly time sheet from worker.

    • Operational Steps: Retrieve employee record →\rightarrow Compute regular/overtime wages $ ightarrow$ Calculate tax deductions via tax rate tables $ ightarrow$ Update employee/company records $ ightarrow$ Issue net pay paycheck to worker.

    • Publisher Present Ordering System DFD:

    • Level 1: Macro ordering overview.

    • Level 2: Order verification, inventory checks, and customer credit check.

    • Level 3: Warehouse order batching, packing authorization, and shipping notice generation.

    • Level 4: Accounts receivable processing and bookstore billing.

Data Modeling and Entity-Relationship (E-R) Framework

  • Data Modeling Principles:

    • Focuses on structural data storage requirements, complementing process-oriented functional modeling.

    • Database Design Steps: Requirement Collection →\rightarrow Conceptual Schema Mapping →\rightarrow DBMS Implementation Selection →\rightarrow Physical Database Design.

  • Data Model Classification Groups:

    • Object-Based Logical Models: Provide flexible structural capabilities with explicit constraint definitions (Entity-Relationship Model, Object-Oriented Model).

    • Record-Based Logical Models: Structure data using fixed-format record layouts (Relational Model [tables], Network Model [graph structures], Hierarchical Model [tree structures]).

    • Physical Data Models: Represent low-level hardware storage layouts (Unifying model, Frame-memory model).

  • Entity-Relationship (E-R) Constructs (Peter P. Chen, 1976):

    • Entity: A distinguishable real-world object or concept about which information is retained (Physical vs. Abstract; Strong/Independent vs. Weak/Dependent).

    • Attributes: Descriptive properties characterizing an entity:

    • Key vs. Non-Key Attributes: Unique identifiers vs. general descriptive features.

    • Required vs. Optional Attributes: Mandatory values vs. optional fields.

    • Simple (Atomic) vs. Composite Attributes: Single indivisible fields vs. composite structures (e.g., Name split into First_Name, Middle_Name, Last_Name).

    • Single-Valued vs. Multi-Valued Attributes: Holds a single value at any instance vs. holds multiple values (e.g., academic degrees).

    • Stored vs. Derived Attributes: Static base data vs. dynamically computed values (e.g., Age derived from Date_of_Birth).

    • Entity Type: Schema construct defining shared attributes across an entity set.

    • Value Set / Domain: The set of permissible values assigned to an attribute.

    • Relationship Degree: The number of participating entity types in a relationship (Unary = 1, Binary = 2, Ternary = 3, N-ary).

    • Connectivity and Cardinality: Mapping constraints defining association bounds (1:11:1, 1:N1:N, M:NM:N).

    • Participation Constraints: Total participation (double lines, mandatory existence dependence) vs. Partial participation (single lines, optional existence).

  • E-R Diagram Graphical Notations:

    • Entity Type = Rectangle.

    • Weak Entity Type = Double Rectangle.

    • Relationship Type = Diamond.

    • Identifying Relationship = Double Diamond.

    • Attribute = Oval.

    • Key Attribute = Underlined text inside Oval.

    • Multi-valued Attribute = Double Oval.

    • Derived Attribute = Dotted Oval.

  • E-R Model Case Design (Library Management System):

    • Book Entity: Book_id (Key), Title, Author, Price, Availability_Status.

    • Member Entity: Member_id (Key), Name, Street, City, Zip_code, Membership_Type, Membership_Date, Expiry_Date.

    • Publisher Entity: Pub_id (Key), Name, Street, City, Zip_code.

    • Supplier Entity: Sup_id (Key), Name, Street, City, Zip_code.

    • Operational Relationships: Publisher publishes Book; Supplier supplies Book; Member borrows Book.

Relational Database Model and Normalization

  • Relational Database Principles (E.F. Codd, 1970):

    • Represents data structures using two-dimensional tables (relations) comprising named columns (attributes) and un-ordered rows (tuples).

    • Table Properties: Column homogeneity, atomic cell values, distinct column names, order of rows/columns is irrelevant, degree nn equals total column count.

  • Relational Key Definitions:

    • Primary Key: An attribute chosen to uniquely identify every tuple within a relation.

    • Composite Primary Key: A combination of multiple attributes used jointly to enforce unique tuple identification.

    • Candidate Key: Any attribute combination that satisfies the unique identification requirements for a relation.

    • Alternate Key: Candidate keys not selected as the primary key.

    • Foreign Key: An attribute matching a primary key in another table to establish logical linkages and enforce referential integrity.

  • Normalization Formalities (Eliminating Update, Insertion, and Deletion Anomalies):

    • First Normal Form (1NF):

    • Criteria: No duplicate tuples; every attribute cell contains a single atomic value; no repeating groups or nested arrays exist. Create separate tables for sets of related data and assign primary keys.

    • Second Normal Form (2NF):

    • Criteria: Relation must be in 1NF AND contain no partial functional dependencies (every non-key attribute must be fully functionally dependent on the entire primary key).

    • Third Normal Form (3NF):

    • Criteria: Relation must be in 2NF AND contain no transitive dependencies (no non-key attribute can be functionally dependent on another non-key attribute).

  • Relational Integrity Rules:

    • Entity Integrity: No primary key attribute component can contain a null value.

    • Referential Integrity: Foreign key values must either match an existing primary key value in the referenced relation or be set to null.

Object-Oriented Database Modeling vs. Relational Model

  • Comparative Evaluation:

    • Data Representation:

    • Relational models link tables using primary/foreign key pairs.

    • Object-Oriented models link objects directly using system Object Identifiers (OIDs), supporting complex nested structures (sets, lists, tuples) and class inheritance.

    • Storage Structures:

    • Relational systems store base relations as flat files, using primary and secondary indexing to speed data retrievals.

    • Object-Oriented systems store complex structured objects as persistent byte strings, reconstructing object structures in memory buffers upon retrieval.

    • Integrity Constraints:

    • Relational models enforce primary keys, entity integrity, and referential constraints declaratively.

    • Object-Oriented models use procedural class methods and system inverse-relationship mechanisms.

    • Data Manipulation Languages (DML):

    • Relational models utilize non-procedural query languages (SQL, QUEL, QBE) based on relational calculus.

    • Object-Oriented models integrate DML operations directly into object-oriented programming languages (e.g., C++).

System Testing Principles and Strategies

  • Testing Fundamentals:

    • Quality assurance process executing software programs using artificial test cases to detect defects.

    • Software development projects typically allocate roughly 40%40\% of total development timelines to testing (33 to 55 times higher for life-critical software like flight controls or reactor monitoring systems).

    • Distinct from debugging: Testing uncovers program errors; debugging isolates root causes and modifies code to fix identified defects.

  • Primary Testing Categories:

    • Black-Box Testing: Functional testing evaluating inputs and expected outputs without examining internal program logic or source code.

    • White-Box Testing: Structural testing examining internal control paths, programmatic logic loops, local data structures, and code syntax.

  • Verification vs. Validation:

    • Verification: Evaluating software outputs against functional specifications in simulated environments ("Are we building the product right?").

    • Validation: Executing software in real operational environments to confirm customer expectations are satisfied ("Are we building the right product?").

  • Testing Strategy Sequence:

    • Unit Testing: Focuses on individual software modules using white-box techniques to verify local data structures, boundary conditions, independent paths, and error handling routes.

    • Stubs: Dummy software modules simulating lower-level subordinate modules called by the unit under test.

    • Drivers: Main programs written to feed test data into the module under test and display output results.

    • Integration Testing: Systematic assembly of unit-tested modules to uncover interface defects.

    • Top-Down Integration: Assembles modules progressively down the control hierarchy, utilizing stubs.

    • Bottom-Up Integration: Assembles low-level atomic modules first, utilizing drivers (eliminating the need for stubs).

    • Validation Testing: Black-box execution testing software behavior against validation criteria established in the SRS document.

    • Alpha and Beta Acceptance Testing:

    • Alpha Testing: Conducted by clients at the developer's site within a controlled environment.

    • Beta Testing: Conducted by end users at their operational sites in an uncontrolled, real-world setting.

Specialized System Tests, Quality Assurance, and Maintenance

  • Specialized System Integration Tests:

    • Recovery Testing: Forces software failures to verify automated re-initialization, data recovery mechanisms, and Mean Time to Repair (MTTR).

    • Stress Testing: Tests system stability by executing programs under severe operational loads (e.g., generating 1010 interrupts/sec when baseline is 11–22/sec, maximum memory allocation, thrashing virtual memory).

    • Security Testing: Simulates unauthorized intrusion attempts to evaluate internal security controls and defenses.

  • Capability Maturity Model (CMM) Framework (Software Engineering Institute - CMU):

    • Level 1 (Initial): Software processes are ad-hoc, chaotic, and undefined.

    • Level 2 (Repeatable): Baseline project tracking mechanisms and management controls are established.

    • Level 3 (Defined): Standardized, documented software development processes are deployed across the organization.

    • Level 4 (Managed): Quantitative process metrics and software quality outcomes are tracked.

    • Level 5 (Optimized): Continuous process improvements, defect prevention techniques, and technological enhancements are implemented.

  • Hewlett-Packard FURPS Quality Framework:

    • Functionality: Evaluates feature sets, general capabilities, and system security.

    • Usability: Evaluates user interface aesthetics, operational consistency, and documentation quality.

    • Reliability: Measures failure frequency, output accuracy, Mean Time Between Failures (MTBF), and failure recovery capabilities.

    • Performance: Measures processing speed, operational response times, resource consumption, and throughput efficiency.

    • Supportability: Assesses code maintainability, testability, extensibility, adaptability, and installation ease.

  • Software Quality Factors and Metrics Formula:

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

    • Quantitative Quality Factor Model:     Fq=c1M1+c2M2+⋯+cnMnF_q = c_1 M_1 + c_2 M_2 + \dots + c_n M_n     Where FqF_q is the evaluated software quality factor, cnc_n represents regression coefficients, and MnM_n represents measured software metrics.

  • Software Maintenance Categories and Distribution:

    • Maintenance represents the post-delivery evolution of software systems to maintain operational survival.

    • Corrective Maintenance: Fixing identified coding, design, or requirement bugs (accounts for 21%21\% of overall maintenance effort).

    • Adaptive Maintenance: Modifying software to function within modified operating system or hardware environments without altering core capabilities (accounts for 25%25\% of overall maintenance effort).

    • Perfective Maintenance: Implementing new functional enhancements or performance improvements requested by users (accounts for 50%50\% of overall maintenance effort).

    • Other/Emergency Maintenance: Unplanned system modifications (accounts for 4%4\% of overall maintenance effort).