dido:public:ra:1.4_req:2_nonfunc:20_maintainability:modifiability
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
dido:public:ra:1.4_req:2_nonfunc:20_maintainability:modifiability [2021/05/30 17:12] char |
dido:public:ra:1.4_req:2_nonfunc:20_maintainability:modifiability [2022/01/27 06:04] (current) nick |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== 4.3.3.4 Modifiability===== | ====== 4.3.3.4 Modifiability===== | ||
| [[dido:public:ra:1.4_req:2_nonfunc:20_maintainability| Return to Maintainability]] | [[dido:public:ra:1.4_req:2_nonfunc:20_maintainability| Return to Maintainability]] | ||
| - | |||
| - | * **<color #FF0000><todo @char>Please Review</todo></color>** | ||
| ===== About ===== | ===== About ===== | ||
| Line 19: | Line 17: | ||
| Accessed 5 August 2020 | Accessed 5 August 2020 | ||
| [[https://www.sciencedirect.com/book/9781558609006/java-web-services-architecture]] | [[https://www.sciencedirect.com/book/9781558609006/java-web-services-architecture]] | ||
| - | )): | + | )) during [[dido:public:ra:xapend:xapend.a_glossary:p:peer_review | Peer Review]]: |
| <table modifyquestiobs> | <table modifyquestiobs> | ||
| <caption>Questions to consider when assessing Modifiability.</caption> | <caption>Questions to consider when assessing Modifiability.</caption> | ||
| ^ Questions proposed by McGovern et al. ^ Considerations ^ | ^ Questions proposed by McGovern et al. ^ Considerations ^ | ||
| - | ^ **How often is it expected that a system change will be required?** | This question is trying to understand the maturity (see [[[dido:public:ra:1.4_req:2_nonfunc:14_reliability:01_matuity]]) associated with the system or product. It is not just about the product, but the maturity of the [[dido:public:ra:xapend:xapend.a_glossary:d:domain_knowledge|domain knowledge]] surrounding the system or product. For example, the accounting domain has been around for thousands of years and is well documented and understood while the use of applications to address Blockchains is less than a decade old. | | + | ^ **How often is it expected that a system change will be required?** | This question is trying to understand the maturity (see [[[dido:public:ra:1.4_req:2_nonfunc:14_reliability:01_matuity]]) associated with the system or product. It is not just about the product, but the maturity of the [[dido:public:ra:xapend:xapend.a_glossary:d:domain_knowledge|domain knowledge]] surrounding the system or product. For example, the accounting domain has been around for thousands of years and is well documented and understood while the use of [[dido:public:ra:xapend:xapend.a_glossary:a:application|applications]] to address Blockchains is less than a decade old. | |
| ^ **What is the usual extent of the change?** | This question also relates to maturity (see [[[dido:public:ra:1.4_req:2_nonfunc:14_reliability:01_matuity]]) of the domain associated with the system or product. It also has to do with how conservative the attitude is towards changes. For example, changes made to an end-user entertainment application such as TikTok are easily tolerated while changes made to accounting records, which can adversely effect an individual's wealth, are frowned upon. | | ^ **What is the usual extent of the change?** | This question also relates to maturity (see [[[dido:public:ra:1.4_req:2_nonfunc:14_reliability:01_matuity]]) of the domain associated with the system or product. It also has to do with how conservative the attitude is towards changes. For example, changes made to an end-user entertainment application such as TikTok are easily tolerated while changes made to accounting records, which can adversely effect an individual's wealth, are frowned upon. | | ||
| ^ **Who is expected to make the changes?** | If changes are made by a single individual with minimal review and testing, the ability to modify the system is high, but the risk of failure is increased. Modifiability must consider these risks in the context of the domain. In essence, the better the governance over changes, the higher the probability of success (see [[dido:public:ra:1.3_gov]]). An individual can be extremely disciplined and positive when it comes to adapting to changes, while organizations can be sloppy. So, the maturity of the domain is important and the organization (even if it's a single person) is important. See [[dido:public:ra:xapend:xapend.a_glossary:i:iso90003]] and [[dido:public:ra:xapend:xapend.a_glossary:c:cmmi]]. | | ^ **Who is expected to make the changes?** | If changes are made by a single individual with minimal review and testing, the ability to modify the system is high, but the risk of failure is increased. Modifiability must consider these risks in the context of the domain. In essence, the better the governance over changes, the higher the probability of success (see [[dido:public:ra:1.3_gov]]). An individual can be extremely disciplined and positive when it comes to adapting to changes, while organizations can be sloppy. So, the maturity of the domain is important and the organization (even if it's a single person) is important. See [[dido:public:ra:xapend:xapend.a_glossary:i:iso90003]] and [[dido:public:ra:xapend:xapend.a_glossary:c:cmmi]]. | | ||
| Line 77: | Line 75: | ||
| Layering involves separating the system or programs based on technical responsibilities, usually using an [[dido:public:ra:xapend:xapend.a_glossary:n:n-tier]]. Generally, these tiers are referred to as the //presentation tier//, //processing tier// and //data management tier//. Often the tiers are both logically and physically separated, with each tier running on its own dedicated platforms. In a [[dido:public:ra:xapend:xapend.a_glossary:d:distsystem|distributed system]], the tiers do not follow the [[dido:public:ra:xapend:xapend.a_glossary:c:client-server|client-server]] architecture but use a [[dido:public:ra:xapend:xapend.a_glossary:p:p2p]] architecture. However, the peers can be categorized as fulfilling presentation, processing, and data management functionality. | Layering involves separating the system or programs based on technical responsibilities, usually using an [[dido:public:ra:xapend:xapend.a_glossary:n:n-tier]]. Generally, these tiers are referred to as the //presentation tier//, //processing tier// and //data management tier//. Often the tiers are both logically and physically separated, with each tier running on its own dedicated platforms. In a [[dido:public:ra:xapend:xapend.a_glossary:d:distsystem|distributed system]], the tiers do not follow the [[dido:public:ra:xapend:xapend.a_glossary:c:client-server|client-server]] architecture but use a [[dido:public:ra:xapend:xapend.a_glossary:p:p2p]] architecture. However, the peers can be categorized as fulfilling presentation, processing, and data management functionality. | ||
| - | In addition, systems or programs that are declarative and configurable are more modifiable, especially if the configuration describes the details of connectivity between the [[dido:public:ra:xapend:xapend.a_glossary:m:module|modules]] (or peers). In other words, these descriptions provide the context and should address the 5-Ws of **who**, **what**, **when**, **where** and **why**; as well as, the **how**. For example: | + | In addition, systems or programs that are [[dido:public:ra:xapend:xapend.a_glossary:d:declarative | declarative]] and configurable are more modifiable, especially if the configuration describes the details of connectivity between the [[dido:public:ra:xapend:xapend.a_glossary:m:module|modules]] (or peers). In other words, these descriptions provide the context and should address the 5-Ws of **who**, **what**, **when**, **where** and **why**; as well as, the **how**. For example: |
| <table 5ws> | <table 5ws> | ||
| Line 87: | Line 85: | ||
| ^ where | Where can the module (peer) be found: paths, endpoints, etc. | | ^ where | Where can the module (peer) be found: paths, endpoints, etc. | | ||
| ^ why | Why is the module (peer) defined: documentation, rules, filters, etc. | | ^ why | Why is the module (peer) defined: documentation, rules, filters, etc. | | ||
| - | ^ how | How is the module (peer) accessed: Library, RESTFul, [[dido:public:ra:xapend:xapend.a_glossary:r:rpc]], DDS, Message queue, etc. | | + | ^ how | How is the module (peer) accessed: Library, RESTFul, [[dido:public:ra:xapend:xapend.a_glossary:r:rpc]], DDS, [[dido:public:ra:xapend:xapend.a_glossary:m:mq|Message queue]], etc. | |
| </table> | </table> | ||
| Line 95: | Line 93: | ||
| [[dido:public:ra:1.4_req:2_nonfunc:20_maintainability:modifiability| Return to Top]] | [[dido:public:ra:1.4_req:2_nonfunc:20_maintainability:modifiability| Return to Top]] | ||
| + | : <wrap hi><color red> To be added/expanded in future revisions of the DIDO RA </color></wrap> | ||
| /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | ||
dido/public/ra/1.4_req/2_nonfunc/20_maintainability/modifiability.1622409175.txt.gz · Last modified: 2021/05/30 17:12 by char
