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 / programming2. 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 designThe 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. CodingThe coding is the realization of the design in a programming language.
4. Testing and TroubleshootingAfter 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. DocumentationStructure, 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 developmentTask 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.
V-modelThe 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.
Conclusion
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.
2 Comments
