Software Engineering and Maintenance Lecture Notes

Comprehensive vocabulary flashcards covering software rejuvenation, maintenance, testing, requirements engineering, object-oriented design, project management, and software process models.

Redocumentation

A type of software rejuvenation focused on adding or improving documentation.

Restructuring

A type of software rejuvenation that improves code structure while keeping functions the same.

Reverse Engineering

Recovering or creating lost or deleted design and requirements from existing code.

Reengineering

Rebuilding or improving a system from decades ago by recreating the design and improving the code.

Cyclomatic complexity

A metric that measures code complexity.

Maintenance

Any modification made to software after it has been delivered and is being used.

S-system

A type of software system that undergoes no change, such as formal math software.

P-system

A software system with occasional, sometimes incremental, changes, such as a chess program.

E-system

A software system subject to constant change, typical of real-world software.

Corrective maintenance

Maintenance performed specifically to fix bugs or errors.

Adaptive maintenance

Adapting software to new changes or new environments.

Perfective maintenance

Maintenance focused on improving existing functionality.

Preventive maintenance

Maintenance performed to prevent future issues through code cleanup or refactoring.

Maintainability (Conceptual)

The ease of modifying software.

Configuration management

A process that controls software changes, tracks changes, prevents issues, and maintains system consistency.

Impact analysis

Studying the effect of a proposed change before implementing it to reduce maintenance cost and risk.

MTTF

Mean Time to Failure, a measure used to determine Availability.

MTTR

Mean Time to Repair, a measure used to determine Reliability.

MTBF

Mean Time Between Failures, calculated as $MTTF + MTTR$, used to determine maintainability.

Benchmark test

A type of acceptance testing comparing software against a standard or competitors.

Pilot test

An experimental installation first performed in one working company.

Alpha test

Internal system testing performed inside the company.

Beta test

Testing performed by real customers (e.g., the top 100 customers).

Parallel tests

Running old and new systems together so customers can use both and compare results.

Installation testing

Checks configuration, device connections, and communications with other systems using regression testing.

Function testing

Comparing actual results versus requirements to ensure the system does what requirements specify.

Performance testing

Testing non-functional requirements such as speed, accuracy, response time, and data access.

Stress test

Testing the system under extreme conditions.

Regression testing

Testing performed after modification to ensure that nothing previously working was broken.

Compatibility test

Checks if the software works on different devices and systems like Chrome, Safari, or Firefox.

Reliability

The probability that a system works without failure.

Availability

The probability that software is operational at any given time.

Maintainability (Probability)

The probability that software can be repaired easily within a specific time limit.

Fault

An internal developer mistake made during development, seen by developers.

Failure

An external incorrect system behavior seen by users.

Unit testing

Testing each individual module or node.

Integration testing

Testing that combines individual modules together.

Black box testing

Testing functionality by checking inputs and outputs without examining the internal code.

White box testing

Testing internal code paths and logic.

Bottom-up integration

Starting with the smallest modules and moving upward, using drivers for testing.

Top-down integration

Starting from the main module and moving downward, using stubs for testing.

Information hiding

Hiding implementation details and exposing only what the user needs through the interface.

Abstraction

Showing only important details while hiding unnecessary details.

Generality

Designing modules so they can be reused in different situations.

Class

The blueprint used for creating objects, such as a 'car' class.

Object

An instance of a class.

Inheritance

A mechanism where one class inherits properties from another class to facilitate code reuse.

Composition

Building an object using another object, such as a car having an engine.

Modular design

Dividing a system into independent modules, each with one clear responsibility.

Coupling

A measure of the dependency between modules; a lower value indicates a better design.

Content coupling

The worst type of coupling, where one module changes another module's internals.

Common coupling

When modules share global data.

Data coupling

The best type of coupling, where only the necessary data is passed between modules.

Cohesion

A measure of how closely related the elements inside a module are; higher is better.

Coincidental cohesion

The worst type of cohesion, where unrelated tasks are grouped together randomly.

Functional cohesion

The best type of cohesion, where all parts of a module perform exactly one function.

Validation

Checking if we are building the right system by verifying it meets customer needs.

Verification

Checking if we are building the system right by ensuring document consistency.

SRS

Software Requirements Specification, a document including introduction, scope, general description, and specific requirements.

Functional requirements

Exact behaviors or services the system must provide, such as login or searching.

Non-functional requirements

Quality constraints on the system, such as response time or availability.

Stakeholders

Anyone affected by the system, including users, customers, clients, lawyers, and developers.

Risk Exposure

Calculated as $Risk\,probability \times Risk\,impact$.

Milestone

A point in time signifying the completion of a major activity.

Precursor

A task that must occur before a specific activity can start.

Critical path

The longest path in a project's activity graph, determining the minimum time for completion.

Slack time

Calculated as $Available\,time - Estimated\,time$ or $Latest\,start - Earliest\,start$; if it is 0, the activity is critical.

Waterfall model

A sequential model suitable for well-understood, simple projects with little flexibility.

V model

A model where the left side is design and the right side is testing, which verifies each design level.

Spiral model

A model combining development and risk management through Planning, Goal analysis, Risk evaluation, and Development/Testing.

Agile

A process prioritizing flexibility, quick delivery, working software over documentation, and customer collaboration.