| ... |
... |
@@ -50,6 +50,7 @@ |
| 50 |
50 |
| [[Pair Programming|doc:Software Engineering.Agile.Extreme Programming.Pair Programming.WebHome]] / Pairing (up) | See link. | |
| 51 |
51 |
| Physical | Counterpart to logical. Refers to hardware. For example, physically deleting a file means removing it from the disk. | |
| 52 |
52 |
| Points / Story Points | A unit of measure used to estimate the effort required to complete a user story. See also [[here|doc:Software Engineering.Agile.Extreme Programming.Planning Game.Effort Estimation.WebHome]]. | |
|
53 |
+| Problem Domain | The language/terminology used to describe the software requirements ("the problems") from the perspective of non-technical stakeholders. | |
| 53 |
53 |
| Production Code | Code that comprises the functioning part of an application, as opposed to test code. | |
| 54 |
54 |
| Programmer | Someone who writes and tests code. The knowledge level of a beginner. | |
| 55 |
55 |
| Requirement | Statement of what a software must be capable of doing, often outlining features, constraints, and success criteria. | |
| ... |
... |
@@ -65,6 +65,7 @@ |
| 65 |
65 |
| [[Setter Injection|doc:Software Engineering.Architecture.Dependency Injection.Types of Dependency Injection.WebHome]] | A type of dependency injection where a dependency is provided to an object through a setter method. | |
| 66 |
66 |
| Snapshot | A saved state of a system or data at a specific point in time. Can be used for rollbacks. | |
| 67 |
67 |
| Software Engineer | Technical expert with in-depth knowledge in many areas, including high-level topics such as software architecture and system design. | |
|
69 |
+| Solution Domain | The language/terminology used by technical experts to describe the technical solutions to the software requirements described by the problem domain. | |
| 68 |
68 |
| Specification | A detailed description of the requirements under which a user story is considered complete. Much more detailed than the original user story. | |
| 69 |
69 |
| 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. | |
| 70 |
70 |
| 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. | |
| ... |
... |
@@ -76,6 +76,7 @@ |
| 76 |
76 |
| Test Code | Code that tests the functionality of production code. Does not contribute to the operational aspects of an application. | |
| 77 |
77 |
| Test-Driven Development (TDD) | A development approach where code is written in small increments, with tests defining functionality written at the beginning of each coding iteration. | |
| 78 |
78 |
| Test Suite | The sum of all the test code used to check that a system meets its requirements. | |
|
81 |
+| Testability | Code is testable, or has good testability, if it is easy to write tests for. | |
| 79 |
79 |
| Unit | The smallest testable part of an application. This is often a single class, but can also be a single function, or a small cluster of tightly coupled classes or functions that together perform a specific task. | |
| 80 |
80 |
| [[Velocity|doc:Software Engineering.Agile.Extreme Programming.Planning Game.Agile and Data.WebHome]] | See link. | |
| 81 |
81 |
| Virtual Machine (VM) | A software emulation of a physical computer, able to run its own OS and applications as if it were a separate physical machine. | |
