CPT 816 SE

Comprehensive vocabulary flashcards covering the CPT 716 Software Engineering syllabus, past examination papers, diagrams, metrics, architecture, and project management.

Software Engineering

The application of a systematic, disciplined, engineering-based approach to the design, development, testing, maintenance, and management of software systems to deliver high-quality, reliable, and cost-effective software on time.

Software Evolution

The continuous process of modifying a software system after it has been delivered—including fault fixing, adapting to new environments or regulations, adding enhancements, and improving performance—until retirement.

S-type (Static) Software

A software category defined by Lehman and Belady (1974) where the problem is fully and formally specified; correctness is defined strictly by meeting the specification, and requirements remain stable with little evolution (e.g., factorial or sorting routines).

P-type (Practical) Software

A software category where the problem cannot be completely specified and the program is an approximation of the real world, refined continuously through feedback and improved understanding (e.g., chess software, weather forecasting).

E-type (Embedded) Software

A software category where the system operates directly inside the real world and alters its operational environment; it must continuously evolve to adapt to changing laws, users, and contexts or lose value (e.g., banking or payroll systems).

Software Development Life Cycle (SDLC)

A structured framework that divides the end-to-end software delivery process into manageable, assignable, and measurable stages (Plan, Design, Implement, Test, Deploy, Maintain) to deliver quality software within budget and schedule while minimizing risks.

Systems Analysis and Design (SAD)

A subset of the SDLC focused specifically on studying the initial business problem and existing system to specify, model, and design the logical and physical blueprints for the proposed solution.

Waterfall Model

A plan-driven, sequential software development life-cycle model in which activities cascade systematically through distinct phases (Requirements, Design, Implementation, Testing, Maintenance), with each phase signed off before the next starts.

Iterative Model

A development model where work begins with a small subset of requirements and incrementally enhances software versions across successive cycles, with each iteration producing a working release.

Spiral Model

A risk-driven software development process model represented as concentric loops, where each loop corresponds to a distinct phase (feasibility, requirements, design) and incorporates explicit risk analysis and evaluation.

Agile SDLC Model

An iterative and incremental methodology emphasizing flexibility, continuous stakeholder feedback, rapid development cycles, and customer collaboration using small increments.

Formal System Development

A variant of the waterfall process where a mathematical model of a system specification is created and refined into executable code using mathematical, consistency-preserving transformations.

Requirements Engineering (RE)

The systematic process of gathering, analyzing, negotiating, documenting, and validating the services, constraints, and operational goals of a target software system to produce an agreed System Requirements Specification document.

Feasibility Study

The initial stage of requirements engineering that evaluates whether a proposed system is technically, economically, and operationally practical, concluding with a formal go or no-go recommendation report.

Requirements Elicitation

The process of discovering system requirements by actively communicating with clients, end users, and other stakeholders through techniques such as interviews, questionnaires, surveys, observation, and prototyping.

Software Requirement Specification (SRS)

A formal contract document created by the system analyst that outlines user requirements in natural language and technical/system requirements in structured language, specifying functional and non-functional requirements, interfaces, and design constraints.

Requirements Validation

The formal check conducted before software construction to ensure that documented requirements are implementable, valid, complete, unambiguous, and demonstrable.

Functional Requirements

Statements that explicitly define the specific behaviors, operations, calculations, and functions that the software system must perform (e.g., authenticating users, sending monthly reports).

Non-Functional Requirements

Implicit qualities and operational constraints governing how well the system performs its functions, including performance, security, reliability, maintainability, usability, and disaster recovery.

Must Have Requirements

Critical requirements without which the software product cannot be considered operational; mandatory for system implementation.

Should Have Requirements

Requirements that enhance core system functionality; negotiable and incorporated during development whenever possible.

Could Have Requirements

Non-essential requirements that provide minor conveniences; the software functions adequately without them, so they are typically reserved for later releases.

Wish List Requirements

Requirements with no direct link to core project objectives, retained purely as speculative considerations for future updates.

Software Metric

A quantitative measurement of countable software attributes and processes used to assess performance, estimate work, track productivity, and monitor product quality.

Control Metrics (Process Metrics)

Software measurements associated with software engineering processes used to guide process management, such as the average time or effort required to fix reported defects.

Predictor Metrics (Product Metrics)

Measurements associated directly with the software product itself used to forecast software characteristics, such as cyclomatic complexity or the number of methods per class.

Project Metrics

Tactical metrics that allow project managers to assess ongoing work, evaluate risks, uncover bottleneck areas before they turn critical, and track quality control across milestones.

Function Point (FP)

A programming language-independent metric measuring software size by calculating external inputs, outputs, inquiries, internal files, and external interface files, adjusted by complexity factors: $\text{FP} = \text{UFP} \times (0.65 + 0.01 \times \sum F_i)$.

McCabe Cyclomatic Complexity

A complexity metric derived from a program's control flow graph that establishes an upper bound on independent logical execution paths using the formula $V(G) = E - N + 2$.

Three-Point Estimation Formula (LOC)

A weighted sizing formula that calculates expected lines of code ($E$) from optimistic ($a$), most likely ($m$), and pessimistic ($b$) values via $E = \frac{a + 4m + b}{6}$.

McCall's Software Quality Factors

A software quality framework developed by McCall, Richards, and Walters categorizing attributes into three distinct perspectives: Product Operation, Product Revision, and Product Transition.

Software Architecture

The overarching organization of software components (modules), their external interfaces, their interactions, and the data structures they manipulate, providing conceptual integrity to the system.

Layered Architecture

An architectural pattern that divides an application into horizontal tiers (such as Presentation/Web, Service/Business, and Persistence/Database), where each tier is restricted to specific duties and communicates with adjacent tiers.

Microservices Architecture

An architectural style structuring an application as a collection of loosely coupled, independently deployable, and scalable services, each bound to a specific business capability and communicating via APIs.

Modular Monolith

An architectural approach where an entire software system is deployed as a single unified deployable artifact, but internally segmented into distinct, loosely coupled, self-contained functional modules.

Event-Driven Architecture (EDA)

A software architecture design pattern that decouples services by triggering and communicating state changes asynchronously through emitted events managed by an intermediary event broker.

Architecture Description Languages (ADLs)

Formal syntactic specifications used to represent, model, and analyze software architectures and facilitate technical communication among stakeholders (e.g., UML, AADL, Acme).

Pattern-Oriented Software Architecture (POSA)

An architectural approach that applies proven, standardized, reusable design templates and patterns (such as Model-View-Controller or Microservices) to recurring system design problems.

Component-Based Development (CBD)

A development methodology emphasizing the construction of software systems through the integration of pre-existing, reusable, and modular software components (e.g., JavaBeans, COM/.NET).

Enterprise Application Integration (EAI)

The technical practice of connecting multiple independent enterprise software applications (such as HR, payroll, and inventory systems) into a coordinated workflow using middleware, APIs, or messaging.

Unified Modeling Language (UML)

An Object Management Group (OMG) standard visual modeling language providing standardized graphical notations to specify, visualize, construct, and document software system artifacts.

Use Case Diagram

A behavioral UML diagram representing user requirements by showing the boundary of a system, the external actors, and the specific use cases depicting system-user interactions.

Actor (UML)

An external entity—such as a human user, automated hardware device, or external system—that interacts with the software system, typically denoted as a stick figure in use case diagrams.

«include» Relationship

A UML use case dependency depicted as a dashed arrow from a base use case to an included use case, denoting mandatory shared behavior that is reused rather than duplicated.

«extend» Relationship

A UML use case relationship represented as a dashed arrow directed toward the base use case, adding optional or conditional behavior at explicitly specified extension points.

Class Diagram

A structural UML diagram showing the static design of a system by presenting classes, their attributes and operations, visibility modifiers ($+$ public, $\#$ protected, $-$ private), and relationships.

Generalization (UML)

A taxonomic relationship in object orientation representing an inheritance hierarchy between a general superclass (parent) and a specialized subclass (child), drawn with a hollow triangular arrowhead.

Aggregation (UML)

A weak 'has-a' or container-containee relationship between classes where the part class can exist independently of the container and has no shared lifecycle with it, denoted by an open diamond.

Composition (UML)

A strong part-whole association where the part class is owned exclusively by the composite whole and shares its lifecycle; if the container is destroyed, the parts are deleted, denoted by a solid filled diamond.

Sequence Diagram

An interaction diagram showing how objects collaborate over time, arranging objects horizontally and mapping sequential message exchanges and activation bars along vertical lifelines.

Collaboration Diagram

An interaction diagram functionally equivalent to a sequence diagram that emphasizes structural object relationships and organization over explicit chronological timing.

State Diagram

A behavioral diagram that models the dynamic lifecycles of an object, detailing the sequence of states it transitions through in response to external stimuli and events.

Entity Relationship Diagram (ERD)

A conceptual data model representing data entities (rectangles), their attributes (ellipses), relationships (diamonds), and numerical cardinalities ($1:1$, $1:N$, $M:N$).

The Four Ps of Software Project Management

The four foundational elements required for effective project governance: People (stakeholders and teams), Product (scope and decomposition), Process (life cycle and milestones), and Project (execution and control).

Software Configuration Management (SCM)

A formal administrative discipline for tracking and controlling modifications to software artifacts, source code, documentation, and baselines across the entire development lifecycle.

Baseline (SDLC)

A formal milestone review point denoting the verified completeness of a project phase or deliverable; changes beyond this point require formal change management approval.

Change Control

A formal configuration management workflow comprising identification, validation, impact analysis, control/approval, execution, and formal request closure to prevent uncontrolled scope creep.

Gantt Chart

A horizontal bar chart developed by Henry Gantt (1917) used in project scheduling to map activities, dependencies, and planned durations against time.

Verification

The static quality assurance process of checking whether interim work products conform to predetermined specifications without running code ('Are we building the product right?').

Validation

The dynamic quality assessment process of executing the completed software to ensure it satisfies user requirements and operational needs ('Are we building the right product?').

Patent (Software)

A legal right granted by a government protecting novel, non-obvious software inventions and automated processes, typically for a duration of $20$ years.

Copyright (Software)

A form of intellectual property law that automatically protects original source code, binaries, system documentation, and visual layouts against unauthorized copying.

Open Source Software

Software whose source code, models, and development artifacts are publicly accessible under licenses (e.g., GPL, MIT) permitting inspection, modification, and redistribution through peer review.