Software Engineering Concepts and Process Models

Comprehensive vocabulary flashcards generated from lecture notes covering introductory software engineering topics, framework activities, process models, CMMI, CBSE, and Agile methodologies.

Software

The product developed and maintained by software professionals, including programs or instructions, data structures that allow programs to store and manipulate information, and descriptive documentation explaining program operation.

System Software

A category of software that manages computer hardware and provides services to other programs, such as Android, Windows 11, Linux, and macOS.

Application Software

Software designed to help users perform specific personal or business tasks, such as Microsoft 365, Adobe Photoshop, and TallyPrime.

Engineering and Scientific Software

Software that supports calculations, simulations, modelling, and technical analysis, such as MATLAB, Simulink, AutoCAD, and ANSYS.

Embedded Software

Software that operates inside devices or machines to control their functions, such as smartwatch software, vehicle-control software, and medical-device software.

Product-Line Software

A standard software product developed for use by many customers, such as Microsoft Word, Microsoft Excel, and Adobe Premiere Pro.

Web Applications

Software that runs through a web browser and provides services over a network, such as Gmail, Google Maps, Amazon, and Canva.

Artificial-Intelligence Software

Software that uses intelligent algorithms to perform tasks such as learning, reasoning, and recognition, such as ChatGPT, Google Gemini, and Microsoft Copilot.

Software Engineering (IEEE Definition)

The application of a systematic, disciplined, and quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software, as well as the study of these approaches.

Dual Role of Software

Software acting simultaneously as a Product (used directly by users to perform tasks) and as a Vehicle for Delivering a Product (controlling hardware, supporting communication, and helping create other software).

Software Myths

Incorrect beliefs or misleading assumptions about software development, management, and maintenance that can create unrealistic expectations, poor planning, and project failures.

Management Myths

Misleading beliefs held by managers, such as assuming existing standards are sufficient, adding programmers to a late project speeds it up, or outsourcing removes management responsibility.

Customer Myths

Misleading beliefs held by customers, such as assuming a general statement of objectives is enough to start development or that requirement changes are easy because software is flexible.

Practitioner Myths

Misleading beliefs held by developers, such as assuming work is finished once the program runs, quality cannot be checked until execution, or documentation slows development.

Software Process Framework

The overall structure for software development that defines how activities, actions, tasks, work products, quality checks, and milestones are organized.

Communication (Framework Activity)

The initial framework activity where the development team interacts with customers and stakeholders to collect requirements, define project scope, and produce SRS documents.

Planning (Framework Activity)

The framework activity that defines the project roadmap, including cost estimation, scheduling, resource allocation, and risk management.

Modelling (Framework Activity)

The framework activity focused on analysing requirements and designing software architecture, database structure, and user interfaces before coding.

Construction (Framework Activity)

The framework activity involving software development through coding, unit testing, integration testing, and debugging to create executable software.

Deployment (Framework Activity)

The framework activity that delivers completed software to users, performs installation, provides user training, collects feedback, and handles maintenance.

Umbrella Activities

Supporting activities performed throughout the entire software process across all framework activities, including tracking, risk management, SQA, reviews, measurement, SCM, reusability management, and documentation.

Software Quality Assurance (SQA)

An umbrella activity that ensures software meets quality standards and operates correctly according to user requirements.

Software Configuration Management (SCM)

An umbrella activity that controls changes in software and maintains different versions of the system throughout its life.

Layered Technology

An approach defining software engineering in four distinct layers: Quality Focus (foundation), Process, Methods, and Tools.

Quality Focus Layer

The foundational layer of software engineering that ensures software is reliable, maintainable, efficient, and satisfies user requirements.

Computer-Aided Software Engineering (CASE)

An environment formed when automated or semi-automated tools supporting software development activities (design, testing, version control) are integrated.

Capability Maturity Model Integration (CMMI)

A process improvement framework originally developed by the Software Engineering Institute (SEI) at Carnegie Mellon University to assess maturity and process capability across 5 levels.

CMMI Level 1 – Initial

The maturity level where software processes are unpredictable, ad hoc, and poorly controlled, relying primarily on individual skills and efforts.

CMMI Level 2 – Managed

The maturity level where basic project management practices are established, requirements are managed, project schedules are tracked, and practices can be repeated.

CMMI Level 3 – Defined

The maturity level where standard software processes are well documented, standardized, and followed across the entire organization.

CMMI Level 4 – Quantitatively Managed

The maturity level where processes and software quality are measured and controlled using quantitative metrics and data analysis.

CMMI Level 5 – Optimizing

The highest maturity level, focused on continuous process improvement through innovation, feedback, root-cause analysis, and adoption of new technologies.

Waterfall Model

A classic linear sequential software development model introduced by Dr. Winston W. Royce in 1970, where progress flows downward sequentially through predefined phases.

Prototype Model

An SDLC model where an early sample or rough working model of the system is built quickly, evaluated by customers, and refined iteratively before final system development.

Spiral Model

An evolutionary and risk-driven software process model proposed by Barry Boehm in 1986, combining Waterfall and Prototyping features in repeated spiral cycles.

Incremental Process Model

A software development model where the project is divided into time-boxed increments, each delivering a working, functional version of the software through analysis, design, coding, testing, and deployment.

Concurrent Development Model

A software process model (also called Concurrent Engineering) where different development activities progress simultaneously across multiple active states.

Component-Based Software Development (CBSE)

A software development approach focused on building systems by selecting, adapting, and integrating existing reusable software components.

White-Box Adaptation

A component adaptation technique where the source code of a component is accessible and directly modified to meet system requirements.

Grey-Box Adaptation

A component adaptation technique where internal parts of a component are modified using configuration, inheritance, or extension mechanisms without altering full source code.

Black-Box Adaptation

A component adaptation technique used when source code is unavailable, modifying external interactions using wrappers, connectors, or interfaces.

Agile Manifesto

A declaration created in February 2001 at Snowbird, Utah, by seventeen software professionals, establishing 4 core values and 12 principles for iterative software development.

Extreme Programming (XP)

An Agile methodology created by Kent Beck that focuses on short development cycles, frequent releases, pair programming, TDD, refactoring, and active customer involvement.

User Stories

Short descriptions of user needs and functionality written by customers on individual cards to guide development in Extreme Programming.

Pair Programming

An XP practice where two programmers work together on the same code at one workstation, with one writing code while the other reviews and suggests improvements.

Test Driven Development (TDD)

An XP software practice where automated unit tests are written before writing the actual functional source code.

Refactoring

The practice of improving the internal structure and design of existing source code without altering its external behavior.

Scrum

An iterative Agile framework that structures development into short time-boxed iterations called Sprints (lasting 1 to 4 weeks) managed through specific roles, events, and backlogs.

Product Backlog

A prioritized master list of all features, requirements, enhancements, and bug fixes needed in a software product, managed by the Product Owner.

Sprint Backlog

A set of Product Backlog items and specific tasks selected by the development team to be completed during an upcoming Sprint.

Daily Scrum Meeting

A short, 15-minute daily meeting where team members share progress, plan work for the next day, and identify any blockers.

Product Owner

The Scrum role responsible for representing customer requirements, maintaining the Product Backlog, prioritizing tasks, and maximizing product value.

Scrum Master

The Scrum role responsible for facilitating Scrum activities, clearing obstacles, enforcing Agile practices, and supporting team performance.

Kanban

An Agile workflow management framework that visualizes tasks on a board, restricts Work In Progress (WIP), and supports continuous delivery without fixed sprint cycles.

Work In Progress (WIP) Limits

An essential Kanban rule that restricts the number of active tasks allowed in any given workflow stage to prevent bottlenecks and system overload.