| ... |
... |
@@ -9,7 +9,6 @@ |
| 9 |
9 |
| Awareness | A class A is aware of class B if it contains a reference to class B in its source code. If no such reference exists, class A is unaware of class B. | |
| 10 |
10 |
| Behavior | Counterpart to implementation. It refers to the observable actions performed by a component. For example: A class may have the only observable method `sort(Collection: SomeCollection)`, which says what it does, but no implementation details like what concrete sorting algorithm is used. | |
| 11 |
11 |
| Best Practices | Widely accepted guidelines designed to enhance programming productivity and code quality. Adherence can prevent many potential issues. | |
| 12 |
|
-| Business | Non-technical decision makers in the organization developing the software. | |
| 13 |
13 |
| Business Value | The worth of a feature in terms of its benefit to the business. | |
| 14 |
14 |
| Compile Time | The period when the code is compiled. Often used to distinguish from runtime. | |
| 15 |
15 |
| Concretion | The counterpart to 'abstraction', also known as 'implementation'. In OOP, refers to non-abstract classes that implement the methods of interfaces or abstract classes. A concretion provides the 'concrete' code defining the workings of these abstract functions. | |
| ... |
... |
@@ -18,7 +18,6 @@ |
| 18 |
18 |
| Commitment | Binding promise to complete a specific task within a set period of time. | |
| 19 |
19 |
| Component | Often used to refer to a set of units, modules, or "architectural" components without a clearer specification. In software architecture, it refers to a module capable of independent operation, often compiled or packaged into an executable such as a `.jar` or `.exe` file. | |
| 20 |
20 |
| [[Continuous Integration|doc:Software Engineering.Agile.Extreme Programming.Continuous Integration.WebHome]] (CI) | See link. | |
| 21 |
|
-| Customers | Individuals who use the software product, focusing on the value it provides to meet their needs. | |
| 22 |
22 |
| Daemon | A program running in the background of a system, often without a GUI. | |
| 23 |
23 |
| Data Structure | A class primarily meant to hold data and provide basic operations to access and manipulate that data. May contain only public fields, or private fields with associated getter and setter methods. | |
| 24 |
24 |
| [[Definition of Done|doc:Software Engineering.Agile.Extreme Programming.Acceptance Tests.WebHome]] | See link. | |
| ... |
... |
@@ -43,7 +43,6 @@ |
| 43 |
43 |
| Logic | Any code with non-trivial complexity. For instance, getters and setters have trivial complexity and are usually not considered 'logic'. | |
| 44 |
44 |
| Logical | The counterpart to physical. The abstract representation of something in software. For example, deleting a file from the desktop only logically deletes it, but actually moves it to the Recycle Bin, while the file physically remains on disk until the Recycle Bin is emptied. | |
| 45 |
45 |
| Magic | Code that performs complex tasks while abstracting away the complexity, presenting a simple interface to the user. | |
| 46 |
|
-| Manager | Individuals responsible for planning, organizing, leading, and controlling a software project's resources, schedule, and deliverables to meet stakeholder expectations. | |
| 47 |
47 |
| Operating System (OS) | The foundational system software that manages and coordinates all computer resources. Examples are Windows, MacOS and Linux. | |
| 48 |
48 |
| Pain | An unpleasant experience caused by unnecessary efforts that could have been mitigated with better design of the original code. | |
| 49 |
49 |
| [[Pair Programming|doc:Software Engineering.Agile.Extreme Programming.Pair Programming.WebHome]] / Pairing (up) | See link. | |
| ... |
... |
@@ -65,7 +65,6 @@ |
| 65 |
65 |
| Snapshot | A saved state of a system or data at a specific point in time. Can be used for rollbacks. | |
| 66 |
66 |
| Software Engineer | Technical expert with in-depth knowledge in many areas, including high-level topics such as software architecture and system design. | |
| 67 |
67 |
| Specification | A detailed description of the requirements under which a user story is considered complete. Much more detailed than the original user story. | |
| 68 |
|
-| Stakeholders | Individuals with an interest in the success of a software project, which may include customers, developers, investors, externals and others who are affected by the projects outcome. | |
| 69 |
69 |
| Static | Behaviors/properties determined before or at compile time. Examples: static code analysis tools inspect source code; statically-typed languages determine an object's type at compile time. | |
| 70 |
70 |
| [[Story / User Story|doc:Software Engineering.Agile.Extreme Programming.Planning Game.WebHome]] | See link. | |
| 71 |
71 |
| Story Card | A physical card containing a user story and other relevant information such as an effort estimate and a business value. See also [[here|doc:Software Engineering.Agile.Extreme Programming.Planning Game.WebHome]]. | |
