Skip to Content
Author's profile photo Former Member

Traditional application development and new concepts

Traditional application development and new concepts

In my Paradigms of business standard software and Visual Composer of the SAP Community as enabler for the new Visual Composer book I have tried to answer the question whether Visual Composer is just another tool for creating business applications based on the paradigm shift of business software. The answer of the question was a clear no. I came to the conclusion that SOA and Visual Composer enables the business users, the so-called business process experts (BPX), to develop business applications themselves. The possibility that the BPX can create their own applications within a very short time by modeling the application raises the question whether the traditional practices in application development do not have their permission. In this blog I will discuss the classical approaches in application development.

Every beginning is difficult: The Model “Code and Fix”

This model dates from the early days of application development. This model is characterized by rapid code generation, without planning, with direct coding, and requires as needed error correction. This model is especially used by beginners and casual programmers. The procedure can be divided into two steps:

1. Coding / programming
2. Find and fix the errors in the program

The disadvantages of this approach are obvious. The fix leads to structural defects in the programs. Structural defects complicate the elimination of sequence errors. The consequence was the introduction of a design phase. Another disadvantage of this approach is that even well-designed software was not accepted by the user, simply because the user’s needs were not fully covered. As a result the definition phase was introduced. The discovery of errors in these programs also presents a disadvantage that affects, among other things, the acceptance of the end user. The consequence was the introduction of a testing phase. In summary, it can be stated that the deficiencies of the “Code and Fix” procedure have led to the introduction of project phases in application development.

Phases of the traditional software development

The traditional software development consists of the following phases:

1. System Analysis

The system analysis begins with a study and evaluation, which role and position the software has in its environment. The system analysis is concerned with components of the real world and its realistic abstractions. Program components normally play no role. The system analysis will initially deal with the client side objectives, feasibility and economic viability of the project. Then follows a first task specification in dialogue with potential suppliers, which will “matures” to the contractually binding specification.  The results are generally captured in text format and partly supplemented by graphics.  On completion of the system analysis phase is the contract award.

2. Program design

The program design begins after the contract award. In this phase, the functions of the program are defined in detail in the so-called functional design. The architectural design will decide about the allocation of functions to the program components (modules). Moreover, the data elements and the main data and control flow is decided according to the possibilities and limitations of available hardware and software systems.

3. Coding

The coding is the realization of the design in a programming language.

4. Testing and Troubleshooting

After the coding phase the program is checked in a comprehensive review whether it meets the requirements during the testing and troubleshooting phase. If this is not the case, the necessary changes are to be done. These relate, in most cases not only the coding, but in many cases dating back to the design phase and system analysis.

5. Documentation

Structure, function and operation are described in the documentation of the created and tested program. The same program may be documented for different target groups in various forms.

6. Operation and Maintenance / maintenance and further development

Task of program maintenance is the elimination of errors that are not noticed during the test and troubleshooting phase. Also the adjustment of the program according to any changes regarding the functional requirements and the technical development is part of the maintenance phase.

The assessment of the traditional model to software development is a simple model that is divided into clear phases. However, the presentation is less realistic, as is expected from a clean, error-free completion of the previous phase. Another disadvantage is that at very late phase the first workable version exists and the approach also leads to a long dwell time of errors caused by the subsequent tests. Despite the weaknesses of this model, it was the basis for all other approaches mentioned in the literature. Below I want to present some models that are based on this basic model and discuss their suitability for the creation of applications using Visual Composer and an SOA.

Waterfall model as an example of a linear phase model

In the literature, the waterfall model is often the first called, which belongs to the linear phase models. It consists of the initialization phase, functional specification, technical design, implementation, testing, installation and maintenance.


Each phase is separated very strict and it only comes into the next stage after completing the previous phase, usually by approval. Regression to previous phase is possible but undesirable. If this approach would be used in practice the product will be presented to the customer only after the test period, so if the product is already finished. This is the main drawback of the waterfall model, because when changes occur on the customer side all phases must be carried out again. This model integrates the end user with very late and is therefore not only unsuitable for projects based on SOA and Visual Composer, but also for all other IT projects, because the model is idealized and unsuitable for practical use at all. It is suitable only as a theoretical introduction to the phase models and is therefore also very often cited in the literature. It shows very clearly the separation between the different phases and the idea of phase models is clearly and perfectly so that this simple linear model is perfect for education purposes.


The waterfall model has been developed further to the V-model. The major weakness was eliminated by the V-model, because only activities and results are defined and it does not require a strict temporal sequence. In particular, the typical approval at the end of every project phase was abolished. The V-model integrates the customer more in the project, by now also building blocks are defined for the customer. Despite the orientation toward more agile and incremental approaches this approach lacks the flexibility and integration of the end user in order to benefit from application development based on SOA and Visual Composer. Another major drawback of this process model is the very high level of detail that is demanded by the application modeler during the design phase.


Spiral model as an example of an incremental model

The spiral model is no longer designed as a linear model, but as the name suggests, like a spiral. It is also known as iterative and incremental phase model because the phases of the waterfall will be passed through several times. The result of each phase is a prototype and then finally the finished product as a result of the last phase. This approach is characterized by the fact that the various phases are iteratively passed through, the end user can check at regular intervals through the prototype at the end of each phase, whether developed the project in the right direction and are thus relatively inexpensive to correct any errors yet. This model works very well for the development of applications based on SOA and Visual Composer, however, the model was described at a time (1988) as you have had very often bad experiences with software projects. For this reason, the model was driven very strong by risk and it is repeated after each run a risk analysis. This means in practice a significant additional effort by the new risk analysis and verification of the intermediate steps.



Based on the presented examples it can be seen that the classical approaches have many flaws. These are in particular the very strong separation of requirements analysis and implementation as well as the very late involvement of the end user in the project. In most cases, the end user’s have to define their very complex requirements in the form of a book or also called the functional business blueprint (FBB). At its base is then written a new book that is called solution business blueprint (SBB). When FBB and SBB are approved then the application will be developed. If the end user has forgotten something or has something changed in the requirements, this is simply bad luck. Usually the application will not be equal to the desired result. Proponents of classical approaches would say that this is a result of poor project management and poor specifications or even justify the fact that end-users and developers have less experience in application specification and development. But honestly, that does not help us further? – Applications are not developed for fun. They should have an added value for the end user. For this reason, the end user should be involved as early as possible and also the end user should not spoon-feed by covering thousands of pages of specifications and at the end of the project the end user will not receive what he wanted to have.

The benefits of SOA-based application creation with Visual Composer such as the very rapid creation of prototypes based on less specification and therefore the early counteraction of undesirable development of the project can only be exploited if the classical approaches and their weaknesses will be waived. Despite everything, in practice, unfortunately, too often these approaches are used and a lot of time and budget are consumed to produce paper without any added value. In my next blog I want to introduce new innovative approaches, exploiting the strengths of SOA and Visual Composer.

The german version of this blog can be found on the FIVE1 Blog.

Assigned tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      Every method evolves - and so did waterfall and oher classic methods. It should also be noted that these methods worked and still work fine when "correctly" managed.

      Traditional methods do not preclude end user interaction early on. Where else will the requirements come from apart from users?
      In today's world - users are spread all over the globe. And in this economy, most users have a full time business role, and they have to juggle their project roles alongside. So even if they want to be involved all along, it is not easily possible. So specifications save the day for them.

      Consider remote development - which is usually necessary to save cost for big projects, or to make use of skills available only in certain regions. Without specifications, it is difficult to communicate between geographically disbursed teams.

      Same with testing. If you want to be ready with test scripts by the time dev is done - you cannot wait for several prototypes to finish and then start making the test scripts.

      The extent of specifications is the deal breaker in my opinion - non-value adding specs are a result of people following a process without knowing why something is done that way. This is where experienced team members need to guie the less experienced ones.

      SOA is not a magic bullet that solves all the evils in SDLC - and Visual composer, while being a easy-to-use tool does not solve 80% of a project's needs. They have a rightful place - but that is not to say they can replace all the "old" things, at least not yet. In any case - most users of VC at the moment are the technical people in a project, and not the business users.

      One of the key features of a succesful project is predictability - of schedule, budget etc. Traditional models make predicting a whole lot easier - also because a lot of metrics are available to estimate effort.

      And finally - traditional methods all have a change control process that runs with it. So if users change their minds at some point - they can raise a change order, and the project can do an analysis on impact to design, timelines, budget etc and decide whether to implement or not.

      I think I ranted more than I should have - but all I am trying to say is that we should not take a text book view that old is bad and new is good.

      Author's profile photo Former Member
      Former Member
      Blog Post Author
      Hi Vijay,

      first of all thank you for your feedback. I agree that requirements are needed and I didn’t say that you can start the implementation without any specification. My conclusion is also not that the traditional approaches are bad and the new are good. What I have tried to say is that the IT architecture and how the applications are created today have changed – there was an evolution in the last years. That’s the reason why I think that also the traditional approaches are replaced by new innovative approaches that are the result of improved traditional approaches.

      My experience shows that still in many projects the V-model or waterfall approach is used. If you check the project plan of these projects you can believe or not that there are months spent only for specifying things and that there is no prototype. Especially if you introduce a new software or system and the end users or the business have no experience with the system they are very often not able to deliver the needed specification that you need to implement the solution. Not only my experience shows that it is helpful to create a prototype based on less requirements and then go deeper in more details. With the first prototype you give the business people the opportunity to get a feeling of the software resp. system and it is much easier to define the specifications based on that experience. In my opinion it’s better to develop iteratively like the SCRUM approach that I want to discuss in my next blog. Also the big software companies like SAP or IBM are using the SCRUM approach and my friends from the SAP development can confirm you that this approach is very good. 

      Also in remote development it should not be an issue that the project members are located across the continents as a virtual team, because you can still have some web-meetings and other innovative tools to collaborate. I agree that you need of course requirements, but these can be gathered after the first prototype and you can also start with the test scripts later in the project ongoing to the development.

      Also with new approaches the time, budget and quality is predictable because there is still project governance in place. Anyway, I think at the end you are right that approaches are evolved over the years and at the end the most important is that you deliver in time, budget and in quality and it doesn’t matter which approach you are using – the customer must be satisfied at the end. In my opinion I can guarantee this with the new approaches.