Theory Driven Modeling as the Core of Software Development

Theory Driven Modeling as the Core of Software Development

Janis Osis (Institute of Applied Computer Systems, Riga Technical University, Riga, Latvia) and Erika Nazaruka (Asnina) (Institute of Applied Computer Systems, Riga Technical University, Riga, Latvia)
DOI: 10.4018/978-1-7998-3016-0.ch005
OnDemand PDF Download:
No Current Special Offers


Some experts opine that software is built in a primitive way. The role of modeling as a treatment for the weakness of software engineering became more important when the principles of Model Driven Architecture (MDA) appeared. Its main advantage is architectural separation of concerns. It showed the necessity of modeling and opened the way for software development to become an engineering discipline. However, this principle does not demonstrate its whole potential power in practice because of lack of mathematical accuracy in the very initial steps of software development. The sufficiency of modeling in software development is still disputable. The authors believe that software development in general (and modeling in particular) based on mathematical formalism in all of its stages and together with the implemented principle of architectural separation of concerns can become an important part of software engineering in its real sense. They propose the formalism by topological modeling of system functioning as the first step towards engineering.
Chapter Preview

2. Effectiveness And Quality Of Software Engineering Is Low

To improve the understanding of the motivation of this discussion, let us look at the effectiveness and quality of software engineering. Our discussion is grounded on the very important results of the research performed by Capers Jones (2009). Jones and his colleagues from SPR have collected historical data (between 1977 and 2007) from hundreds of corporations and more than 30 government organizations. This historical data is a key source for judging the effectiveness of software process improvement methods. This data is also widely cited in software litigation in cases where the proceedings concern quality, productivity, and schedules.

The main result obtained during the analysis of this historical data can be summarized in one sentence: “The way software is built remains surprisingly primitive” (Jones, 2009, p. 1). This statement is true also nowadays and is based on the following data:

  • Budget and schedule overruns. Even in 2008 majority of software applications are cancelled, overrun their budgets and schedules, and often have hazardously bad quality levels when released. As time passes, the global percentage of programmers performing maintenance on aging software has steadily risen, until it has become the dominant activity of the software world.

  • Product and process innovations. External product innovations (new or improved products) and internal process innovations (new or improved methods for reducing development resources) are at differing levels of sophistication. Even in 2008 very sophisticated and complex pieces of software are still constructed by manual methods with extraordinary labor content (jobs from the United States to India, China, etc.) and very distressing quality levels. Yet software quality and productivity levels in 2007 are hardly different from 1977.

  • Positive and Negative Innovations. Capers Jones and his colleagues have introduced two interesting terms, namely, positive innovations and negative innovations (Jones, 2009). Their meaning is explained on the example of agile techniques. The Agile approaches and eXtreme Programming (XP) were developed to speed up the development of small projects, where small teams working face to face are quite effective. Thus, the Agile approaches are a positive innovation for small projects but sometimes negative for large systems. Moreover, positive innovations tend to become negative innovations in time.

Complete Chapter List

Search this Book: