Is Modeling a Treatment for the Weakness of Software Engineering?

Is Modeling a Treatment for the Weakness of Software Engineering?

DOI: 10.4018/978-1-61692-874-2.ch001
OnDemand:
(Individual Chapters)
Available
$37.50
No Current Special Offers
TOTAL SAVINGS: $37.50

Abstract

The authors share with some other experts the opinion that the way software is built is primitive. Therefore, this chapter discusses a role of modeling as a treatment for software engineering. The role of modeling became more important after appearance of principles proposed by Model Driven Architecture (MDA). The main advantage of MDA is architectural separation of concerns that showed necessity of modeling and opened the way to software development to become engineering. However, the weakness is that this principle does not demonstrate its whole potential power in practice, because of a lack of mathematical formalism (or accuracy) in the very initial steps of software development. Therefore, the question about the sufficiency of modeling in software development is still open. The authors believe that software development in general, and modeling in particular, based on mathematical formalism in all its stages together with the implemented principle of architectural separation of concerns can become Software Engineering in its real sense. The authors introduce such mathematical formalism by means of topological modeling of system functioning.
Chapter Preview
Top

Introduction

Software developers’ community understands and forcedly accepts that software development in its current state is rather art than an engineering process. This means that qualitative software is a piece-work or a craftwork. Such an item usually is expensive, and cannot be stock-produced. However, in the modern world software users want to see and to use a qualitative and relatively cheap product. This means that software development must become software engineering. The word “engineering” intends a theory approved, completely realized and reused many times in practice that gives a qualitative and relatively inexpensive end product in accurately predictable timeframes.

Software development’s way to software engineering is quite long. Things that make this way long are very different. From one viewpoint, software development lacks commonly accepted theoretical foundations. From another viewpoint, software developers do not want to use “hard” theory (especially mathematical) because in order to win on the market they must provide operating software as fast as possible and even faster, but a lack of theory just slower getting an operating product. From the third viewpoint, clients do not want to pay a powerful lot of money for a product that, first, exists only as a textual document, second, includes “intellectual” work that is hard to measure and to evaluate, and third, usually it is not the same as clients wanted. Clients cannot check how work proceeds, since they cannot see the product at whole before integration of its parts and cannot evaluate (or even understand) the size of introduced efforts.

The content of this chapter is our vision of how to shorten this long way. First, we discuss effectiveness and quality of software engineering, and then differences between traditional engineering disciplines and software engineering. Next, we consider a modeling process and discuss benefits and issues, which could and could not be solved by modeling. At the end, we discuss our vision on what must be done in order to get really revolutionary improvement of software development.

Complete Chapter List

Search this Book:
Reset