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/01/11 17:27] ian [Table] |
dido:public:ra:1.4_req:2_nonfunc:20_maintainability:modifiability [2022/01/27 06:04] (current) nick |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== 4.2.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 13: | Line 11: | ||
| * Deletability | * Deletability | ||
| - | In other words, it is a system or products ability and receptiveness to adapt to future and often unexpected changes. Planning for Modifiability is a bit like looking into a crystal ball about the product, its place within the ecosystem and its ability to adapt to changes in the environment. An easy way to consider Modifiability of a system or product is to ask a series of questions: McGovern et al. (( | + | In other words, it is a system or products ability and receptiveness to adapt to future and often unexpected changes. Planning for Modifiability is a bit like looking into a crystal ball about the product, its place within the ecosystem and its ability to adapt to changes in the environment. An easy way to consider Modifiability of a system or product is to ask the following series of questions suggested by McGovern et al. (( |
| James McGovern, Sameer Tyagi, Michael E. Stevens and Sunil Mathew, | James McGovern, Sameer Tyagi, Michael E. Stevens and Sunil Mathew, | ||
| __Java Web Services Architecture__, | __Java Web Services Architecture__, | ||
| 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]] | ||
| - | )) suggested the following questions: | + | )) 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. | | + | ^ **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 has to do with how conservative the attitude is towards changes. For example, changes made to an end-user entertainment application such as TicTok are easily tolerated while changes made to accounting records that can adversely effect an individual's wealth are not frowned upon. <todo @nick>Do you mean "frowned upon"</todo> | | + | ^ **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 the changes are to 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 context of the domain. In essence, the better the governance over changes, the higher the success (see [[dido:public:ra:1.3_gov]]). An individual can be extremely disciplined and can be a positive when it comes to adapting to changes. Organizations can be sloppy. So, the maturity of the domain is important, but also the maturity of the organization (even if its 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]]. | |
| - | ^ **Is it necessary for the system to use current platform versions?** | This addresses the [[dido:public:ra:xapend:xapend.a_glossary:e:eol]] issues associated with any product (see [[dido:public:ra:1.4_req:2_nonfunc:28_manageability]] and [[dido:public:ra:1.4_req:2_nonfunc:10_portability:06_replace]]). As the system ages, more and more EoL problems arise. The more [[dido:public:ra:xapend:xapend.a_glossary:c:cots]], [[dido:public:ra:xapend:xapend.a_glossary:g:gots]], [[dido:public:ra:xapend:xapend.a_glossary:m:mots]], and [[dido:public:ra:xapend:xapend.a_glossary:n:nots]] products used by the system and the longer the system exists there is an increase in risk to the system because each subsystem, component or modular need to be managed. As a case in point, in mid-2020, roughly 200 million PCs worldwide will still be running older Windows versions, mostly Windows 7[https://www.zdnet.com/article/how-many-pcs-are-still-running-windows-7-today/]]. Many of these are probably not modifiable any more. | | + | ^ **Is it necessary for the system to use current platform versions?** | This addresses the [[dido:public:ra:xapend:xapend.a_glossary:e:eol]] issues associated with any product (see [[dido:public:ra:1.4_req:2_nonfunc:28_manageability]] and [[dido:public:ra:1.4_req:2_nonfunc:10_portability:06_replace]]). As the system ages, more and more EoL problems arise. As more [[dido:public:ra:xapend:xapend.a_glossary:c:cots]], [[dido:public:ra:xapend:xapend.a_glossary:g:gots]], [[dido:public:ra:xapend:xapend.a_glossary:m:mots]], and [[dido:public:ra:xapend:xapend.a_glossary:n:nots]] products are used by the system and the longer the system exists the risk to the system increases because each subsystem, component or modular needs to be managed. As a case in point, in mid-2020, roughly 200 million PCs worldwide will still be running older Windows versions, mostly Windows 7[https://www.zdnet.com/article/how-many-pcs-are-still-running-windows-7-today/]]. Many of these are probably not modifiable any more. | |
| </table> | </table> | ||
| Line 37: | Line 35: | ||
| Accessed 5 August 2020, | Accessed 5 August 2020, | ||
| Researchgate | Researchgate | ||
| - | )) did a detailed study of 30 applications in 2015 and found the following time and cost characteristics found that almost 45% of the cost of the projects was spent in production. Most of this cause can be attributed to maintenance and support. Underlining the reason why Modifiability is so important. All too often when a project gets started, the problem is "kicked down the road" with the idea that "we'll cross the bridge when we get there". | + | )) did a detailed study of 30 applications in 2015 and found the following time and cost characteristics and that over half (55%) of the cost of the projects can be attributed to maintenance and support. These findings underline the importance of Modifiability. All too often when a project gets started, too many problems are "kicked down the road" with the idea that "we'll cross the bridge when we get there". |
| <table timecost> | <table timecost> | ||
| Line 60: | Line 58: | ||
| <caption>The Cost of Software Maintenance for one project </caption> | <caption>The Cost of Software Maintenance for one project </caption> | ||
| ^ Lifecycle Phase ^ Percent of Cos ^ | ^ Lifecycle Phase ^ Percent of Cos ^ | ||
| - | ^ Requirements Definition | 3% | | + | ^ Requirements Definition | 3% | |
| - | ^ Preliminary Design | 3% | | + | ^ Preliminary Design | 3% | |
| - | ^ Detailed Design | 5% | | + | ^ Detailed Design | 5% | |
| - | ^ Implementation | 7% | | + | ^ Implementation | 7% | |
| - | ^ Testing | 15% | | + | ^ Testing | 15% | |
| - | ^ Maintenance | 67% | | + | ^ Maintenance | 67% | |
| * **Note:** | * **Note:** | ||
| * Another study found at least 50% of the effort spent on maintenance | * Another study found at least 50% of the effort spent on maintenance | ||
| Line 73: | Line 71: | ||
| </table> | </table> | ||
| - | Regardless of the actual numbers for a system or a program, all the numbers point to one conclusion: the cost of maintenance is a major driver in the [[dido:public:ra:xapend:xapend.a_glossary:t:totalcostown|total cost of ownership]] for systems or projects. Much of the maintenance cost for many projects is not planning or considering Modifiability throughout the project lifecycle, especially early on. Modifiability is closely correlated to creating layered, modular and loosely coupled systems or programs. Fortunately, there are tools which can analyze a system or a program during all phases (see [[dido:public:ra:1.4_req:2_nonfunc:20_maintainability:modularity]] and [[dido:public:ra:1.4_req:2_nonfunc:28_manageability]]). | + | Regardless of the actual numbers for a system or a program, all the numbers point to one conclusion: the cost of maintenance is a major driver in the [[dido:public:ra:xapend:xapend.a_glossary:t:totalcostown|total cost of ownership]] for systems or projects. Much of the maintenance cost for many projects can be traced back to not planning or considering Modifiability throughout the project lifecycle, especially early on. Modifiability is closely correlated to creating layered, modular and loosely coupled systems or programs. Fortunately, there are tools which can analyze a system or a program during all its phases (see [[dido:public:ra:1.4_req:2_nonfunc:20_maintainability:modularity]] and [[dido:public:ra:1.4_req:2_nonfunc:28_manageability]]). |
| - | Layering involves separating the system or programs based on technical responsibilities, usually using a [[dido:public:ra:xapend:xapend.a_glossary:n:n-tier]]. Generally, the tiers are the 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, the descriptions provides the context should address the 5-Ws of **who**, **what**, **when**, **where** and **why** and should also consider 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> | ||
| <caption>How the 5-Ws and H can be used to help ensure Modifiability</caption> | <caption>How the 5-Ws and H can be used to help ensure Modifiability</caption> | ||
| ^ W ^ context ^ | ^ W ^ context ^ | ||
| - | ^ who | Who can access the module (peer) including [[dido:public:ra:xapend:xapend.a_glossary:p:privileges|privileges]]. developer, a business user, an analyst, or some combination of these is responsible | | + | ^ who | Who can access the module (peer) including [[dido:public:ra:xapend:xapend.a_glossary:p:privileges|privileges]]: developer, a business user, an analyst, or some combination of these is responsible | |
| - | ^ what | What is the module (peer) name, version, download URI. | | + | ^ what | What is the module (peer) name, version, download URI | |
| - | ^ when | When can the module (peer) be accessed. event, calendar, time, etc. | | + | ^ when | When can the module (peer) be accessed: event, calendar, time, etc. | |
| - | ^ 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> | ||
| - | Expectations of frequent changes driven by business-related changes can be more modifiable if the rules are not codified into software but stored as machine readable rules that can be interpreted at run time. For example, rule engines. However, the downside of a data-rule driven system is that changes in data or rules can result in crashes which will adversely effect stability (see [[dido:public:ra:1.4_req:2_nonfunc:28_manageability]]). | + | Expectations of frequent changes driven by business-related changes can be more modifiable if the rules are not codified into software but stored as machine readable rules that can be interpreted at run time using, for example, rule engines. However, the downside of a data-rule driven system is that changes in data or rules can lead to crashes and adverse impacts to stability (see [[dido:public:ra:1.4_req:2_nonfunc:28_manageability]]). |
| ===== DIDO Specifics ===== | ===== DIDO Specifics ===== | ||
| [[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.1610404050.txt.gz · Last modified: 2021/01/11 17:27 by ian
