Hi Harekrishna,

Yes models (and by extention, if coded, software) enable the prediction of decay (or growth for that matter). A pretty well known example is the decay of radiative isotopes Each type of isotope has a specific decay half-time which can vary from fractions of seconds to millions of years. I am not sure whether it is that type of process you are referring to, but it is a straightforward and well known example from nuclear physics.

Organic matter in soils also decays in this example it decays into carbon dioxide. This process is more complex than than the previous one I cited, because it is forced by meteorological conditions and variables (which are never stable by the way) as well as the (bio)chemical composition of the soil organic matter (SOM), which is quite variable as well. Hence, this is a typical example of the ecophysiology of soils. This has also been modeled and coded into software and is also very well known by biologists and ecophysiologists.

To provide users models and software which, as you state it,  "guide the project managers with clarity", these models as well as the software have to be validated. Validation is intended to make the model and the software output be conform with the realities of nature, at least in the natural sciences. For social and many other types of sciences (excluding the natural sciences) , models are more difficult to validate. It is even impossible to validate, when we are dealing with metaphysical models or better even, concepts. Hence, I don't consider metaphysics as a scientific discpline, exactly because it cannot be validated and hence is not conform with the scientific method. Science always requires proof, repeatabality  and validation.

You state that::"Dynamic conditions imposed by real life projects look for mid-course corrections". Hence there is a need for stability or steady-state in the model".  I think Harekrishna, that your concept does at least not apply for models in the natural sciences. I cannot judge for the other types of sciences you may have in mind, like management or HR psychology for example. Especially the decay of radioactive isotopes never reaches a steady-state during the life-time of the isotope. In natural systems like forest ecosystems as well, a steady-state is never reached, since meteorological variables and anthropogenic fatcors continuously change the ecophysiological state of the ecosystem. Hence these systems never reach a steady-state.

I think that you will have to live with a multitude of natural processes and systems, which never reach a steady-state and hence stability. Look at yourself as a human being, Do you think that human physiology, functioning and ageing will ever reach a steady-state? In metaphysics, yes. In natural sciences, no. Typically humanity has always strived for stability in whatever process or system. Stability has and still is worshipped. The history of natural sciences has however illustrated that stability never occurs, even not at the level when the differential is studied at the femtosecond level !

So I am sorry to disagree. Nature imposes itself on our sciences, not the reverse. These are real life condtions, sine qua non.

Cheers,

Frank

Yes, there are some work in the area of "software evolution" in which they predict that a software is undergoing decay or it is already dead.

The approach is metric-based. They collect some metrics, and use those metrics to predict that the maintenance cost has already become too much and that it would continue to grow.

 I know Nazim madhavji (Univ of Western Ontario) doing some work in this regard.

Some people in SEI (Software Engineering Institute) have also donen some work in this regard.

Your question may encourages one to come up with a CDM (software Decay Model) using which one can periodically rate a software in the range [1..5].

--M. Satpathy/ IIT Bhubaneswar

There are several models for ensuring improvement of software processes, and prof Manoranjan Satpathy mentioned some of them. In addition there is an increasing number of SPI studies, which is also an indicator that software process are fundamental for overall performance of software organizations.

However I feel that it is not possible to ensure steady state on long term because software organizations and their processes are highly dynamic, the influence of other external factors cannot be anticipated. In this course, I agree with professor Frank Veroustraete that it is possible to predict decay, but not to prevent each time it occurs (the law of the nature).

And finally my opinion for dealing with this issue:

The enormous amount of published studies requires great effort to analyze process models. Maybe to reduce the search on highly ranked software engineering journals (e.g. Empirical Software Engineering, Journal of Software: Evolution and Process, IEEE Transactions on Software Engineering, or Journal of Systems and Software) to find some focused articles that will guide you in conducting your own empirical research - resulting in a model. In that case, you will have the full control and can adapt the model to different contexts.

Regards,

Zeljko

In the field of Maturity models there has been quite some progress in establishing measurable process models that can be used to assess the increase or decay of quality. We have developed a new kind of maturity model, called Focus Area maturity model, which is a fine-grained maturity assessment model for, in principle, any softwre process. Unlike the shallow staged maturity models like CMM, the focus area maturity models are more explicit in addressing weaknesses and areas for improvement. We have developed maturity matrices for Software Product management (SPM), Information System Security (ISFAM) and Enterprise Architecture (DYAM). Underneath some of our works in this area.

Article Software Product Management – An Industry Evaluation

Conference Paper Evaluating the Software Product Management Maturity Matrix

What do you mean by decay ? I could be about actual context (e.g equipment obsolescence or people's skills) or the validity of software.

I second Remy Fannader's question. Decay as in degradation of maintainability, to be countered by refactoring possibly? 

Yes, there are some researchs carried out by Experimental software engineering group at COPPE/UFRJ about software decay. I can exemplify with 

https://www.researchgate.net/publication/265068222_A_System_Dynamics_Model_based_on_Cause_and_Effect_Diagram_to_Observe_Object-Oriented_Software_Decay

http://www.lbd.dcc.ufmg.br/colecoes/eselaw/2006/002.pdf

https://www.researchgate.net/profile/Guilherme_Travassos/publication/221359980_An_Environment_to_Observe_Object-Oriented_Software_Evolution/links/00b7d51475c811d081000000.pdf

Article A System Dynamics Model based on Cause and Effect Diagram to...

Conference Paper An Environment to Observe Object-Oriented Software Evolution.

You may look at the link below about it may help you "static dependency structure is an important element to understand the state of large software system."

Litte bit "No single human can fully understand a system of high complexity. To help ameliorate this problem, systems are decomposed into subsystems, libraries, modules, and classes. Most of these components have interdependencies, in order to provide services, one to another. However, in systems of great size, the dependencies often become a dense web of relationships. "

http://ecs.syr.edu/faculty/fawcett/handouts/research/MuratsResearch/MuratsDefense/StructuralModelsForLargeSoftwareSystems.htm

Article Structural models for large software systems

Article New change impact factor estimation in software development

I'm guessing by "alignment" you are referencing alignment with objectives and needs that were originally driving the project ?  If yes, then you're question is a bit more complex to answer since the real problem is one of degradation with respect to the requirements and their relevancy over time (which is especially true of large projects). 

Software degradation / decay is fairly straight forward to measure (you can get a high level metric by reviewing FPU - function point utilization and component maintenance costs over time). The challenge here is the lack of formality that exists with CFA (causal factor analysis) which often leads back to changing requirements (many of which are never taken into account ...like environmental factors since the scope of requirements is often constrained due to cost containment). 

I "try" to design systems that are comprised of stable function points with an adaptable decision point capability (using abstracted rules and metadata) aligned to a given set of capabilities (typically a point in time). When sufficient funds are available, the rules harmonized using metadata that is contextually relevant for a given scenario. Some folks call this scenario based modeling (you can arrive at this from a top-down or bottom up perspective ...again based on the availability of funds). The goal is to reduce the likelihood of decay by ensuring the stable function points are assembled properly (via orchestration) to address a given scenario instance (presumably these change over time as reflected in the metadata and contextual relevance - a.k.a. situational need).

I believe more systems are moving in this direction, which is good. However, most organizations have very little formality when it comes to harmonization of requirements and customer needs. This is typically where I see decay happen. 

Yes models (and by extension, if coded, software) enable the prediction of decay (or growth for that matter),. 

Software degradation / decay is fairly straight forward to measure (you can get a high level metric by reviewing FPU - function point utilization and component maintenance costs over time).

As we are aware that, Change in software is always an essential part of software development and maintenance. Change could impact on decay, so estimating a code decay as well as  proposed change's effect on the later phases of the development helps project managers and developers with decision-making and predicting future progress.

During development and decay, on some occasions, speedy solutions are necessary to meet project schedules. Such quick changes may lead to major quality flaws in the long term, even though they solve local problems in the short term. 

I think the first thing to establish is the difference that must exist between a model to predict the fall of a software development process (construction phase) and a model to predict the fall of a software when it is in production.

In the first case, today the reference models are related to the so-called "function points" and management effort, time and cost to achieve them. I think the key to developing a good model for predicting potential falls in the development process is related to the management of the "factors", depending on the development environment (platform, personnel) and project characteristics. For example, review models: COCOMO and COSMIC.

For the second case, maintenance management is the key. Should develop a model to monitor the maturity of maintenance processes, including: version management, change management, management of testing before the start of production, etc.

Given that models can be assessed with regard to extensional and intensional capabilities, decay could be predicted (even prevented) by checking for discrepancies.

https://caminao.wordpress.com/2015/01/21/models-disproof/

As Frank V. has clearly demonstrated, decay is a physical sciences analogy for discussing a phenomenon in the life of software products. As it slowly becomes a scientific and engineering discipline, we in the field of software production and management have often drawn upon other disciplines for analogies. They serve our discussions well initially, but the challenge is to provide enough definition that they are precise enough to support research. Witness the discussions of technical debt and of code smells. We need further definition of "software decay." Some of the comments in this stream suggest that such definition has been offered, but works are not cited.

To illustrate this point of a need for definition, a couple of the comments in this stream allude to decay during development. Thinking of an analogy to bio-decay, as opposed to radioactive decay, can software decay occur during development (growth) in which need for rework is created? Perhaps creation of poor designs, for example, is not a decay process, though the results may facilitate decay.

Dear Harekrishna,

That's a great question. It may interest you to know that there is indeed some work in entropy, rather some papers I have been reading have been precisely on this topic recently. 

Refer to:

jmlr.csail.mit.edu/papers/volume13/hennig12a/hennig12a.pdf

www.sersc.org/journals/IJMUE/vol9_no3_2014/36.pdf

ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5542858

dl.acm.org/citation.cfm?id=141354

The entropy of conventional models in software lifecycle is pretty interesting as it is influenced by so many technical and non-technical factors. The sheer rapidity in software output today may probably even invoke such cycles due to compatibility and complexity. Particularly if we're working with legacy systems and cloud. Migration, in itself, could be one of the factors. Or perhaps, it is the end user that instigate the chaos of entropy? Hope this helps.