This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
dido:public:ra:1.4_req:2_nonfunc:20_maintainability:analysability [2020/11/11 01:14] nick created |
dido:public:ra:1.4_req:2_nonfunc:20_maintainability:analysability [2022/08/31 15:34] (current) nick |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== 4.2.3.3 Analysability ===== | + | ====== 4.3.3.3 Analysability ===== |
[[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>** | ||
- | * **<color #FF0000><todo @DDSFmember>Please Review</todo></color>** | ||
===== About ===== | ===== About ===== | ||
- | [[ddsf:private:cookbook:02_body:02_projreq:nonfunctional:20_maintainability:analysability| Return to Top]] | + | [[dido:public:ra:xapend:xapend.a_glossary:a:analysability]] is defined by the [[https://ieeexplore.ieee.org/document/159342 | IEEE glossary of Software Engineering]] as “the ease with which a software system or component can be modified to correct faults, improve [[dido:public:ra:xapend:xapend.a_glossary:p:performance|performance]] or other attributes, or adapt to changes to the environment”. |
- | + | ||
- | [[ddsf:private:cookbook:06_append:glossary:a:analysability]] is defined by the [[https://ieeexplore.ieee.org/document/159342 | IEEE glossary of Software Engineering]] as “the ease with which a software system or component can be modified to correct faults, improve [[ddsf:private:cookbook:06_append:glossary:p:performance|performance]] or other attributes, or adapt to a changes to the environment”. | + | |
- | + | ||
- | One way to understand the Analysability of a system or a program is to understand the size of the system or program. As a rule of thumb, the larger a system or a program, the harder it is to successfully modify the software to correct faults, improve performance, or to adapt to changes in the operating environment. This Analysability can be performed any time while using either the [[ddsf:private:cookbook:06_append:glossary:w:waterfall]] or the [[ddsf:private:cookbook:06_append:glossary:a:agile]]. During the early stages, analysis and design. As projects mature and use a larger code base, the models can either be based directly on the [[ddsf:private:cookbook:06_append:glossary:s:sourcecode|source code]] or [[ddsf:private:cookbook:06_append:glossary:u:uml]] models created using reverse engineering. The metrics can also be used during both [[ddsf:private:cookbook:06_append:glossary:g:greenfield]] or [[ddsf:private:cookbook:06_append:glossary:b:brownfield]] deployments. | + | |
- | Another possibility would be to collect and use similar metrics on Distributed Computing systems. Instead of using classes (i.e., as in [[ddsf:private:cookbook:06_append:glossary:o:oop]]) the number of [[ddsf:private:cookbook:06_append:glossary:n:netnode | Nodes]], the number of [[ddsf:private:cookbook:06_append:glossary:e:endpoint | Endpoints]] and the number of messages types could be used. For **Structural Complexity**, the connections between processes can be used. | + | One way to understand the Analysability of a system or a program is to understand the size of the system or program. As a rule of thumb, as the size of system or program increases, it becomes increasingly harder to successfully modify the software to correct faults, improve performance, or to adapt to changes in the operating environment. This Analysability can be performed any time during the [[dido:public:ra:xapend:xapend.a_glossary:s:software_development_model]] (i.e., [[dido:public:ra:xapend:xapend.a_glossary:w:waterfall]] or the [[dido:public:ra:xapend:xapend.a_glossary:a:agile]], etc.) during the early stages of analysis and design. As projects mature and use a larger code base, the models can be based directly on either the [[dido:public:ra:xapend:xapend.a_glossary:s:sourcecode|source code]] or [[dido:public:ra:xapend:xapend.a_glossary:u:uml]] models created using reverse engineering. The metrics can also be used during both [[dido:public:ra:xapend:xapend.a_glossary:g:greenfield]] or [[dido:public:ra:xapend:xapend.a_glossary:b:brownfield]] deployments. Another way to examine Analysability could be to collect and use similar metrics on Distributed Computing systems where, instead of using classes (i.e., as in [[dido:public:ra:xapend:xapend.a_glossary:o:oop]]), the number of [[dido:public:ra:xapend:xapend.a_glossary:n:netnode | Nodes]], [[dido:public:ra:xapend:xapend.a_glossary:e:endpoint | Endpoints]] and message types could be used. To address **Structural Complexity**, the connections between processes can be used. |
<table analyticMetric> | <table analyticMetric> | ||
- | <caption>Metrics for Class complexity(( | + | <caption>Metrics for [[dido:public:ra:xapend:xapend.a_glossary:c:class|Class]] complexity(( |
Marcela Genero, Mario Piattini and Ronda de Calatrava, __Empirical validation of measures for class diagram structural complexity through controlled experiments__, Accessed 4 August 2020, [[https://pdfs.semanticscholar.org/dd52/5d80c1f370258e56cd956bcb903706c216dc.pdf]] | Marcela Genero, Mario Piattini and Ronda de Calatrava, __Empirical validation of measures for class diagram structural complexity through controlled experiments__, Accessed 4 August 2020, [[https://pdfs.semanticscholar.org/dd52/5d80c1f370258e56cd956bcb903706c216dc.pdf]] | ||
))</caption> | ))</caption> | ||
Line 33: | Line 26: | ||
</table> | </table> | ||
- | ===== DDS Specifics ===== | + | ===== DIDO Specifics ===== |
- | [[ddsf:private:cookbook:02_body:02_projreq:nonfunctional:20_maintainability:analysability| Return to Top]] | + | [[dido:public:ra:1.4_req:2_nonfunc:20_maintainability:analysability| Return to Top]] |
- | The main way that [[ddsf:private:cookbook:06_append:glossary:d:data_distribution_service_dds]] can help Analysability of a system or product is through the elimination of a portion of the [[ddsf:private:cookbook:06_append:glossary:c:codebase]] by outsourcing the functionality to DDS. | + | : <wrap hi><color red> To be added/expanded in future revisions of the DIDO RA </color></wrap> |
/**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- |