| ... |
... |
@@ -63,7 +63,7 @@ |
| 63 |
63 |
| Refactoring | Modifying code to improve its quality without changing its functionality. It is a subtype of 'Restructuring'. | |
| 64 |
64 |
| Requirement | Statement of what a software must be capable of doing, often outlining features, constraints, and success criteria. | |
| 65 |
65 |
| Resources | Refers to the assets used in the project, including time, money, staff, and effort. | |
| 66 |
|
-| Restructuring | Modifying code to improve some aspect of it, such as its quality or performance. | |
|
66 |
+| Restructuring | Modifying code to change its functionality, or to improve its quality ('refactoring') or performance ('performance optimization'). | |
| 67 |
67 |
| Return of Investment (RoI) | The ratio of the business value gained from implementing a story to the effort/cost involved. A higher RoI means that something is more worth implementing than something with a low RoI. | |
| 68 |
68 |
| Rollback | The act of returning a system or data to a previous state, often using a snapshot. | |
| 69 |
69 |
| Rotting Code | Code that is increasingly difficult to maintain due to multiple changes that accumulate technical debt by not following best practices. | |
| ... |
... |
@@ -75,8 +75,8 @@ |
| 75 |
75 |
| [[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. | |
| 76 |
76 |
| Snapshot | A saved state of a system or data at a specific point in time. Can be used for rollbacks. | |
| 77 |
77 |
| Software Engineer | Technical expert with in-depth knowledge in many areas, including high-level topics such as software architecture and system design. | |
| 78 |
|
-| Solution Domain | The language/terminology used by technical experts to describe the technical solutions to the software requirements described by the problem domain. | |
| 79 |
|
-| Specification | A detailed description of the requirements under which a user story is considered complete. Much more detailed than the original user story. | |
|
78 |
+| Solution Domain | The language/terminology used by technical experts to describe the technical solutions to the software requirements defined by the problem domain. | |
|
79 |
+| Specification | A detailed technical description of the requirements under which a user story is considered complete. Much more detailed than the original user story. | |
| 80 |
80 |
| 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. | |
| 81 |
81 |
| 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. | |
| 82 |
82 |
| [[Story / User Story|doc:Software Engineering.Agile.Extreme Programming.Planning Game.WebHome]] | See link. | |
