**10. Benefits & limitations**

System dynamics methods recognize that the real-world is a non-linear web of feedback processes with significant delays and is usually not in equilibrium. We can seek the causes of problems by the interactions of real-world feedback loops. System dynamics provides a way-of-thinking (a paradigm) and associated communication and software driven tools to help design policies that provide durable solutions to pressing problems. Capturing a system's dynamic behavior has a number of significant benefits that include a clear insight into the system, increased control over maintaining and upgrading the system, the capability for better and more timely services, lower maintenance cost, and the ability to progressively maintain satisfactory system outcomes. Therefore, the user retention rates are often high. In addition, the supporting meta-structure also tends to provide significantly more controlled administration and higher manageability towards building reconfigurable systems. Any additional data that can be generated by the meta-system can be utilized further toward supporting or providing credence for additional experts' opinion. It can help us better understand how a problem grew up over time and assist us in finding a longlasting solutions to the problem.

The vital observations of system update requests and usage activities, as described in this chapter, depend on a number of factors. These include: the operational environment, groups of users performing similar functions within a somewhat common time frame, any relevant external influences on the work environment, and the functionality of the system itself.

42 Real-Time Systems, Architecture, Scheduling, and Application

In summary, we may follow these experiments to calibrate the processes, thereby adapting the values of multiplicative constants, probabilities, etc. to the empirical data for the environment of our particular system. However, over a longer period of time the environment itself may change significantly. Therefore, these calibrated values need to be

Implementing an effective measurement program as a meta-structure of its parent system is a big challenge. And overcoming these challenges is worthwhile, because such measures provide insights into the system behavior. Such implementation also improves the ability to plan and track systems evolutionary progress and needed for addressing risks/problems much earlier (Clark, 2002). Therefore, we need to have an underlying methodology that can be applied to formulate a process for evolvable systems. Typically this would include the study and observation of selected set of metrics, development track history, changes in usage track history, and so on. In the previous sections of this chapter, we attempted to explain the necessary elements of such a process in detail. Although the resulting evolution of software mostly appears to be driven and controlled by human decisions, managerial edict and developer's judgement, yet a high-level generalized pseudo code for such a process can be developed, as presented in fig. 8. This is in conformance with the system

System dynamics methods recognize that the real-world is a non-linear web of feedback processes with significant delays and is usually not in equilibrium. We can seek the causes of problems by the interactions of real-world feedback loops. System dynamics provides a way-of-thinking (a paradigm) and associated communication and software driven tools to help design policies that provide durable solutions to pressing problems. Capturing a system's dynamic behavior has a number of significant benefits that include a clear insight into the system, increased control over maintaining and upgrading the system, the capability for better and more timely services, lower maintenance cost, and the ability to progressively maintain satisfactory system outcomes. Therefore, the user retention rates are often high. In addition, the supporting meta-structure also tends to provide significantly more controlled administration and higher manageability towards building reconfigurable systems. Any additional data that can be generated by the meta-system can be utilized further toward supporting or providing credence for additional experts' opinion. It can help us better understand how a problem grew up over time and assist us in finding a long-

The vital observations of system update requests and usage activities, as described in this chapter, depend on a number of factors. These include: the operational environment, groups of users performing similar functions within a somewhat common time frame, any relevant external influences on the work environment, and the functionality of the system

reviewed and re-adjusted recurringly as the system evolves over time.

dynamics approach suggested by Richardson (Richardson, 1999).

**10. Benefits & limitations** 

lasting solutions to the problem.

itself.

**9. Formulating system dynamics as a process** 

```
Status SystemDynamics(SystemSpecifications-Initial) 
BEGIN 
 WrapperSystem  SetupMetaStructure(SystemSpecifications-Initial) 
         ThisSystem  SystemConfiguration(WrapperSystem) // dynamically configure the system 
         System_Initialization(ThisSystem) 
         BEGIN 
                   // in tabular format, collect the complete system workflow paths 
                   SystemControlFlowPath  GetControlFlow(ThisSystem) 
                   // prepare equivalent graph model from the system with initial weights 
                   SystemGraph  GenerateGraphModel(SystemControlFlowPath, Node_Weights, 
                   Edge_Values) 
                   // environment setup: System Usage 
                   Setup_Probing_Stations(SystemControlFlowPath, SystemGraph) 
                   // environment setup: collect update/change requests 
                   Setup_TaskActivity_Stations(SystemControlFlowPath, TaskRequest_Template, 
                   TaskCompletion_Template) 
         END 
         // interconnect the flow with feedback loops (circular causality) 
         WHILE (System is running) 
         BEGIN 
          FOR EACH [TIME-CYCLE] IN System-Lifecycle 
          BEGIN 
                   // get dynamic system behavior and state (feedback loops) 
          sysState  GetSystemState(TimestampNow) 
                   sysUsage  GetSystemUsage(TimestampNow) 
                   sysTasks  GetSystemTasks(TimestampNow) 
                   // formulate model: identify stock (or accumulations) & info flows (rates) 
          Knowledgebase  Record_System_Dynamics(sysState, sysUsage, sysTasks) 
                   // get system status for evaluation 
          SystemStatus  SystemEvaluation(Knowledgebase, TimeStampNow) 
                   SWITCH (SystemStatus) 
                   BEGIN 
                             CASE "EVOLUTION": 
                    PrevSpecs  SystemSpecifications-Initial 
                                       // derive policy insights 
                                       NewSpecs  GenerateNewSpec(Knowledgebase) 
                                       Apply_New_Changes(PrevSpecs, NewSpecs) 
                                       // save changes resulting from model-based updates 
                                       Knowledgebase  Record_New_Changes(PrevSpecs, NewSpecs) 
                                       // recursive call 
                                       RETURN SystemDynamics(NewSpecs) 
                             CASE "INCEPTION": 
                                       Prep_Inception_Phase(Knowledgebase, ThisSystem) 
                             CASE "SYSVALUE_INC": // save data on incremental SV 
                                       thisINC  Generate_Change_Report(Knowledgebase, 
                                       prevCHANGE, TimeStampNow) 
                                       thisCHANGE  thisINC 
                             CASE "SYSVALUE_DEC": // save data on declining SV 
                                       thisDEC  Generate_Change_Report(Knowledgebase, 
                                       prevCHANGE, TimeStampNow) 
                                       thisCHANGE  thisDEC 
                             CASE "NOCHANGE": continue loop 
                   END SWITCH 
                   Prep_Next_Iteration(Knowledgebase) 
          END FOR 
         Prep_Next_Cycle(ThisSystem, SystemSpecifications-Revised) 
         END WHILE 
         RETURN SystemStatus 
END
```
Although the majority of systems fall under these scenarios, there are a number of other classes of systems where a meta-structure either cannot be established or the establishment of such a structure would be cost-prohibitive. For these classes of systems, such evaluations may not support the discovery of system behavior or impact based on updated request history.

Dynamics of System Evolution 45

• Each system will need initialization time to configure itself and fine-tune with correct parametric values – thus a novel approach needs to be sought to generalize the initiation process with necessary delay at each the inception phase of evolution.

We express our sincere gratitude to the Dean's Office of The Graduate School at The University of Alabama for supporting the underlying infrastructure of servers, development

Bennet, K. H. (1990), *An Introduction to Software Maintenance*, Information and Software

Clark, B. (2002). *Eight Secrets of Software Measurement*, IEEE Software, September/October

Coleman, D.; Ash, D.; Lowther, B.; Oman, P. (1994), *Using Metrics to Evaluate Software System* 

Dekkers, C.; McQuaid, P. (2002). *The Dangers of Using Software Metrics*, IT Pro, March/April

Dori, D. (2003), *Conceptual Modeling and System Architecting*, Communications of the ACM,

Ferneley, E. H. (1999), *Design Metrics as an Aid to Software Maintenance: An Empirical Study*,

Grady, R. B. (1994), *Hewlett-Packard – successfully applying software metrics*, IEEE Computer,

Henry, S.; Kafura, D. (1981). *Software Structure Metrics Based on Information Flow*, IEEE

Ives, B.; Olson, M.; Bardoui J. (1983), *The measurement of User Information Satisfaction*,

Jeanrenaud, A.; Romanazzi, P. (1994). *Software Product Evaluation Metrics: A methodological approach*, Transaction on Information and Communications technologies Lehman, M. (1980), *Programs, Life Cycles, and Laws of Software Evolution*, Proceedings of the

Mubin, A.; Luo, Z. (2010a), *Low Overhead and High Yield Integrated Surveys*, Proceedings of

Mubin, A.; Luo, Z. (2010b), *Building a Reconfigurable System with Integrated Meta-Model*,

Mubin, A.; Ray, D.; Rahman, R. (2009), *Architecting an Evolvable System by Iterative Object* 

Port, O. (1988), *The Software Trap – automate or else*, Business Week, Special Report, 9(1) Ramil, J.; Lehman, M. (1999), *Challenges facing Data Collection for Support and Study of Software* 

Proceedings of International Multi-Conference on Engineering and Technological

*Process Modeling*, Proceedings of IEEE and World Congress on Computer Science

*Evolution Process*, ICSE 99 Workshop on Empirical Studies of Software

Transaction on Software Engineering, Vol. SE-7, No. 5, Sep. 1981

Communications of the ACM, 26(10), October 1983

and Information Engineering (CSIE), 2009.

**13. Acknowledgement** 

Technology, 32(4)

October 2003, 46 (10).

John Wiley & Sons, Ltd.

IEEE, 68 (9), Sep. 1980

Innovation 2010

ACM SIGUCCS Fall 2010

Development and Evolution

**14. References** 

2002

27(9)

2002, IEEE

tools and the systems development track history records.

*Maintenability*, IEEE Computer, August 1994.

In addition, many systems will not allow suggested changes to be applied until the system is shut down for some prolonged period of time. Thus, frequent update requests will not be possible. In addition, due to time, money or manpower restrictions, many developers may not venture through setting up such a closely coupled meta-structure within the surrounding system environment.
