====== 4.3.5.3 System Manageability Issues ====== [[dido:public:ra:1.4_req:2_nonfunc:28_manageability| Return to the Manageability]] ===== About ===== ==== Subsystem, Component and Module Lifecycle Issues ==== //"Studies have shown the average software program lifespan over the last 20 years to be around 6-8 years. Longevity increases somewhat for larger programs, so for extremely large complex programs (i.e., over a million Lines of Code – LOC) the average climbs as high as 12-14 years."//((__Software Evolution__, Blog Post, Mitopia Technologies, [[https://mitosystems.com/software-evolution/]] )) Obviously, there is not just the lifespan of the target system, but there are independent lifespans for each version for each subsystem, [[dido:public:ra:xapend:xapend.a_glossary:m:module|module]] or component that is developed externally. For example, the Windows [[dido:public:ra:xapend:xapend.a_glossary:o:os]] first appeared in the mid 1980s with version 1.0.(( __The History of Windows Operating Systems__, Vengie Beal, Webopedia, 2 Sugust 2018, Accessed 16 July 2020, [[https://www.webopedia.com/DidYouKnow/Hardware_Software/history_of_microsoft_windows_operating_system.html#windows-1]] )) and the current version is 10. About every 10 years, Microsoft release another major release of Windows. (( __When will Microsoft end support for your version of Windows or Office?__, Ed Bott, 10 April 2018, ZDNet, Accessed 16 July 2020, [[https://www.zdnet.com/article/when-will-microsoft-pull-the-plug-on-your-version-of-windows-or-office/]] )). [[dido:public:ra:xapend:xapend.b_stds:tech:ietf:ipv4 | IPV4]] was originally available in 1883. Windows 7 was release in October 2009 and IPV4 was the dominate [[dido:public:ra:xapend:xapend.a_glossary:i:ip]]. By 2012, IPV6 gained dominance(( __Six Years Since World Launch, [[dido:public:ra:xapend:xapend.b_stds:tech:ietf:ipv6 | IPv6]] Now Dominant Internet Protocol for Many__, Internet Society, 6 June 2018, Accessed 16 July 2020, [[https://www.internetsociety.org/news/press-releases/2018/six-years-since-world-launch-ipv6-now-dominant-internet-protocol-for-many/]] )). Therefore, if your system was released in 20010 using IPV4 and Windows 7, by 2012 the network protocol needed to be upgraded which can have cascading maintenance effects throughout your system. By 2015, Windows 10 was released again having a cascading effect on upgrades. Figure {{ref>iiotconnect}} developed by the Industrial Internet Consortium(( __IIC Connectivity Framework defines IIoT network architecture for scalable interoperability__, Industrial Embedded Systems, 18 July 2020, [[http://industrial.embedded-computing.com/articles/iic-connectivity-framework-defines-iiot-network-architecture-for-scalable-interoperability/]])) illustrates some of the architectural components required in a generic [[dido:public:ra:xapend:xapend.a_glossary:i:iiot]] system. When a system is deployed, each of these components needs to be managed. Each of these components has its own unique [[dido:public:ra:xapend:xapend.a_glossary:s:syslifecycle]] which evolves independently of the target system.
{{ :dido:public:ra:1.4_req:2_nonfunc:iic_connectivity_framewwork.png?700 |}} The Industrial Internet Consortium’s Connectivity Framework layer provides the foundation for the interoperable transfer of common structured data across systems and [[dido:public:ra:xapend:xapend.a_glossary:d:domain_dds | domains]] [[dido:public:ra:1.4_req:2_nonfunc:28_manageability#fn__7|7)]]
: **Note:** Also see [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:02_state_taxonomy:data_in_motion]] for a further discussion of the DIDO Layers. === System Monitoring === [[dido:public:ra:1.4_req:2_nonfunc:28_manageability:06_system| Return to the Top]] The fundamental [[dido:public:ra:xapend:xapend.a_glossary:r:requirement|requirement]] for [[dido:public:ra:xapend:xapend.a_glossary:m:manageability|manageability]] of any system is the collection of data about the system. This is often done with [[dido:public:ra:xapend:xapend.a_glossary:m:monitorsw]] specifically designed for this task. However, the task of monitoring complex, [[dido:public:ra:xapend:xapend.a_glossary:d:distsystem|distributed systems]] is often difficult and beyond the scope of any particular product. The best place to start is to think of the monitoring in terms of layers. There are considered three layers(( __Tools for Distributed Systems Monitoring__, Kufel, Łukasz, 1 December 2016, Foundations of Computing and Decision Sciences, Vol 41: 10.1515/fcds-2016-0014, [[https://www.researchgate.net/publication/311863266_Tools_for_Distributed_Systems_Monitoring/citation/download]] )).
{{ :dido:public:ra:1.4_req:2_nonfunc:monitoringsystem.png?700 |}} Three major monitoring layers representing sample design of monitoring solution
=== System Logging === [[dido:public:ra:1.4_req:2_nonfunc:28_manageability:06_system| Return to the Top]] The Data Monitoring is the use of [[dido:public:ra:xapend:xapend.a_glossary:d:datalog]] to collect and store data for analysis to discover trends or record the events and actions of an [[dido:public:ra:xapend:xapend.a_glossary:a:application|application]], a system, or a network. This allows for tracking of interactions using messages. Some of the commonly used logging levels are: ^ Logging Level ^ Description ^ ^ debug | Designates fine-grained informational events that are most useful to debug an application. | ^ trace | Designates information about the flow of the execution or threads in an application. | ^ info | Designates informational messages that highlight the progress of the application at coarse-grained level.| ^ warn | Designates potentially harmful situations.| ^ error | Designates error events that might still allow the application to continue running. | ^ fatal | Designates very severe error events that will presumably lead the application to abort. |
Some common logging levels used in applications(( __Log4j - Logging Levels__, Log4J, Accessed 18 July 2020, [[https://www.tutorialspoint.com/log4j/log4j_logging_levels.htm]] ))
=== System Management === [[dido:public:ra:1.4_req:2_nonfunc:28_manageability:06_system| Return to the Top]] [[dido:public:ra:xapend:xapend.a_glossary:p:projmansw]] is software used for project planning, scheduling, resource allocation and change management. It allows project managers (PMs), stakeholders and users to control costs and manage budgeting, quality management and documentation and also may be used as an administration system. Project management software is also used for collaboration and communication between project stakeholders. These tools can help throughout the system lifecycle, from requirement analysis through sun-setting the system. However, in a distributed system, these tools can play a significant role in determining the health of each node, the network and the overall system of nodes. Although the publication on __Software Metrics for Predicting Maintainability__ (( __Software Metrics for Predicting Maintainability__, Marc Frappier, Stan Matwin, and Ali Mili, University of Ottawa, Canadian Space Agency, 1994, References 20 July 2020, [[http://www.dmi.usherb.ca/~frappier/Papers/tm2.pdf]] )) is a bit dated, many of the ideas of capturing metrics to measure [[dido:public:ra:xapend:xapend.a_glossary:m:maintainability]] are still relevant today. By studying these metrics and understanding the formulas and the parameters used in the formulas, a lot of insight can be provided in explaining positive and negative Manageability traits. * **Note:** Many of these metrics were originally targeting for Systems (or projects) that used the [[dido:public:ra:xapend:xapend.a_glossary:w:waterfall]] which has been replaced for many systems (or projects) with [[dido:public:ra:xapend:xapend.a_glossary:a:agile|Agile Models]] and [[dido:public:ra:xapend:xapend.a_glossary:d:devops]]. Many of these metrics can and should be applied to each [[dido:public:ra:xapend:xapend.a_glossary:s:sprint]] to make sure the qualities of the system are maintainable and manageable. In a [[dido:public:ra:xapend:xapend.a_glossary:d:dapp]], word [[dido:public:ra:xapend:xapend.a_glossary:m:module|module]] can be replaced with subsystem or [[dido:public:ra:xapend:xapend.a_glossary:n:netnode | Node]]. ^ 5.1 | UR | Un-referenced Requirements | The number of original requirements not referenced by a lower document in the documentation hierarchy. | ^ 5.2 | NR | Non-Referencing Items | The number of items not referencing an original requirement. | ^ 5.3 | M-MC | Module Coupling | A measure of the strength of the relationships between modules. | ^ 5.4 | M-MS | Module Strength | A measure of how strongly related are the elements within a module. | ^ 5.5 | HK-IF | Information Flow | A measure of the control flow and data flow between modules. | ^ 5.6 | R-IF | Integrated Information Flow of Rombach | A measure of inter-module and intra-module complexity based on information flow. | ^ 5.7 | KPL-IF | Information Flow by Kitchenham et al | A measure of inter-module complexity inspired from Henry & Kafura's information flow metric. Since Kitchenham et al experienced some difficulties in understanding the definition of flows provided by Henry & Kafura, they formulated a new set of definitions. | ^ 5.8 | IF4 | Information Flow Complexity | A measure of inter-module complexity based on information flow | ^ 5.9 | CA-DC | Design Complexity of Card & Agresti | A measure of inter-module and intra-module complexity of a system based on fan-out, number of modules and input/output variables | ^ 5.10 | COCO | Cocomo Inspired Metric | A selection of appropriate adjustment factors of the intermediate Cocomo metric | ^ 5.11 | v(G) | Cyclomatic Complexity Number | The number of independent basic paths in a program. | ^ 5.12 | knots | | The number of crossing lines (unstructured ''goto'' statements) in a control flow | ^ 5.13 | RLC | Relative Logical Complexity | The number of binary decisions divided by the number of statements | ^ 5.14 | Vcd | Comments Volume of Declarations | Total number of characters found in the comments of the declaration section of a module. The declaration section comprises comments before the module heading up to the first executable statement of the module body. | ^ 5.15 | Vcs | Comments Volume of Structures | Total number of characters in the comments found anywhere in the module except in the declaration section. The declaration section comprises comments before the module heading up to the first executable statement of the module body. | ^ 5.16 | Ls | Average Length of Variable Names | Mean number of characters of all variables used in a module. Unused declared variables are not included. | ^ 5.17 | LOC | Lines of Code | The number of lines in the [[dido:public:ra:xapend:xapend.a_glossary:s:sourcecode|source code]] excluding blank lines or comment lines. | ^ 5.18 | E | Software Science Effort | An estimation of programming effort based on the number of operators and operands. It is a combination of other Software Science metrics. | ^ 5.19 | DAR | Documentation Accuracy Ratio | A [[dido:public:ra:xapend:xapend.a_glossary:v:vendorlockin|verification]] of the accuracy of the CEI Spec, RS and SDD with respect to the source code. | ^ 5.20 | SCC | Source Code Consistency | The extent to which the source code contains uniform notation, terminology and symbology within itself. |
Description of Mectrics for Maintainability of Systems (or Projects)[[dido:public:ra:1.4_req:2_nonfunc:28_manageability#fn__10| 10)]]
==== Vendor Lock-in Issues ==== [[dido:public:ra:1.4_req:2_nonfunc:28_manageability:06_system| Return to the Top]] A major management issue for many projects is the avoidance of [[dido:public:ra:xapend:xapend.a_glossary:v:vendorlockin]]. Vendor lock-in restricts the options available to a system (or project) because of the dependency on sole-source proprietary technology, solution or service provided by a single vendor or vendor partner. This technique can be disabling and demoralizing because customers are effectively prevented from switching to alternate sources for the technology, solution or service making the customer-vendor relationship one sided. Vendor Lock-In reduces the ability of manage costs over the life expectancy of the system (or project) or avoid risks when a vendor of a product ceases to maintain a critical component of the system (or project) or even when the product ceases to exist. This can be partially mitigated through the use of [[dido:public:ra:xapend:xapend.a_glossary:o:oss]], however, remember, just because something is OSS, does not mean there is not a vendor. Additionally, if the OSS software is deprecated or evolves in a divergent way from the requirements of the target system (or project), then the responsibility for the care and maintenance of the OSS has to be covered by the system (or project). However, there are OSS solutions which also adhere to standards such as the [[dido:public:ra:xapend:xapend.a_glossary:d:dds]] vendor [[https://www.omgwiki.org/ddsf/doku.php?id=ddsf:private:cookbook:06_append:05_vendors:oci | Object Computing Incorporated (OCI) ]]. An example of an OSS offering that has suffered from a calamity is XeroMQ. Even though ZeroMQ is still around and being used, the ZeroMQ OSS effort was shaken by the death of its prime moving force Pieter Hintjens who died((__The Life, Ideas, and Legacy of Pieter Hintjens (from ZeroMQ to “A Protocol for Dying”)__, Medium, Evan SooHoo, 23 September 2018, Accessed 20 July 2020, [[https://medium.com/@evan_soohoo/the-life-ideas-and-legacy-of-pieter-hintjens-from-zeromq-to-a-protocol-for-dying-fc1673caeaa7]])). There are any spinoffs and derivatives of ZeroMQ. Here are a few reported in Wikipedia(( ZeroMQ, Wikipedia, Accessed 20 July 2020, [[https://en.wikipedia.org/wiki/ZeroMQ]] )) * //In 2012, two of the original developers forked ZeroMQ as Crossroads I/O.(( __ZeroMQ and Crossroads I/O: Forking over trademarks__. LWN.net. Retrieved 14 July 2012.[[https://lwn.net/Articles/488732/]]))((__Crossroads I/O__. Retrieved 14 July 2012, [[http://www.crossroads.io/]]))// * //Martin Sustrik has started nanomsg,((__nanomsg__. Retrieved 8 June 2013 [[http://nanomsg.org/]])) a rewrite of the ZeroMQ core library.((__Why should I have written ZeroMQ in C, not C++ (part I) __, 250bpm, Martin Sústrik, 10 May 2012, Accessed 20 July 2020, [[http://250bpm.com/blog:4]]))// * //In 2012, Dongmin Yu announced his pure Java conversion of ZeroMQ, JeroMQ.(( __jeromq - java pojo zeromq__, zeromq-dev mailing list, Retrieved 23 May 2013, [[http://lists.zeromq.org/pipermail/zeromq-dev/2012-August/018265.html]]))// * //This has inspired further full-native ports of ZeroMQ, such as NetMQ for C#((__NetMQ__, GitHub, Retrieved 23 May 2013, [[https://github.com/zeromq/netmq]])).// * //March 2013, Pieter Hintjens announced a new draft of the ZMTP wire-level protocol bringing extensible security mechanisms to ZeroMQ((__Securing ZeroMQ: draft ZMTP v3.0 Protocol__, Hintjens.com, Retrieved 23 May 2013, [[http://hintjens.com/blog:39]])).// * //Martin Hurton implemented the CurveZMQ [[dido:public:ra:xapend:xapend.a_glossary:a:authentication|authentication]] and [[dido:public:ra:xapend:xapend.a_glossary:e:encryption|encryption]] mechanism((__CurveZMQ - Security for ZeroMQ __, CurveZMQ, Accessedd 20 July 2020, [[http://curvezmq.org/]])) in the core library shortly afterwards.// Not recognizing or managing the risks due this kind of unfortunate occurrence to the system (or project) might be expedient, but is in many ways irresponsible for systems (or projects) with a long lifespan. An alternative to the risks of OSS or proprietary vendor lock-in is the selection components that are standards based from a [[dido:public:ra:xapend:xapend.a_glossary:s:stdorg]] that offers a wider spectrum of vendors to choose from. ===== DIDO Specifics ===== [[dido:public:ra:1.4_req:2_nonfunc:28_manageability:06_system | Return to the Top]] : To be added/expanded in future revisions of the DIDO RA /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- /* To add a discussion page to this page, comment out the line that says ~~DISCUSSION:off~~ */ ~~DISCUSSION:on|Outstanding Issues~~ ~~DISCUSSION:off~~