The Waterfall Model
The Waterfall Model was worked out by the U.S. Army in the 60s. Its main purpose was to enable development of complex military software. In this model, the project follows an ordered sequence of steps. At the end of each phase the project team completes a review or sign off. Development does not continue until the customer is contented with the results.
If changes are required, it is difficult and costly to retrace the team’s steps. The Waterfall Method is considered as formal and document driven. During the project, production of a great number of documents ensures the implemented software’s high operability robust character and reliability. Another characteristic of this model is the high value placed on planning. This minimizes the need for continuous planning as the project progresses.
There exist a lot of undelivered or delivered but never used softwares because of lacking specification or changing of the requirements during implementation. Although differences and deflections can be really small (e.g. 1%), if they affect parts of the system needing full restart of an entire construction phase because of logic redesign, then costs and needed time can increase remarkably.
Phases of the Waterfall Approach:
- Requirement Analysis and specification
- System and software logic planning
- Coding, implementation
- Thorough system tests
- Operation, service and support
We follow the phases of the Waterfall model during the software modules’ development and implementation cycle. We also produce all the required documents to guide future improvements and safe upkeep.
It is crucial for us to plan and develop softwares that are highly usable –even without reading the manual. According to our references, the complexity and coherence of the requirements remains hidden till the coding phase, when every change takes much more time.
To avoid this, we design and draw all important screens to implement during the coding phase. When drawing these, we consider all requirements and technical restrictions. We discuss the completed screen drawings with our procurers and complete the changes asked. Screen plans and their function descriptions approved by the procurers are part of the specification. As a result of this process, a well specified, comprehended and accepted plan will be born.
By drawing the prototype screens, we managed to increase procurer’s contentment according to project results and softer functionality remarkably.
The age of softwares developed with no communication is over. The Staged Delivery Method is based on the waterfall model. Softwares will be delivered before they are entirely ready: in predefined stages.
During the requirement analysis, priority order of core functions and features will be set. According to this, steps and milestones of deliverance will b worked out. Most important and critical modules will be delivered first.
Advantages of Staged Delivery:
- Most important functions are available and testable at first
- Risk minimizing
- Problems come to light earlier
- Administration related to status reports remarkably decreased
- Development time estimated more exactly
- Higher flexibility
Due to Staged Delivery, our procurers can get to results and use core software functions in shortest time.
In the recent 10 years, several agile programming methodologies appeared on the market. These hold some key principles in common: e.g. changes of life will be accepted as a fact of life. For that, they stay open to constantly changing requirements and try to flatten alteration costs.
A popular representative of agile, lightweight methodologies is XP (eXtreme Programming). Kent Back, the famous Smalltalk consultant got 1996 leadership in a dying payroll calculation project. The project was restarted following his own methodologies – the first XP project to work successful under Beck’s control.
The agile methodologies have succeeded to introduce numerous best practices and principles, which are capable of managing and enhancing acceptation of changes, flexibility and high quality coding as well.
Best practices facilitating the above mentioned are the following:
Planning game: a high level, rapidly executable plan will be laid down for the next coding period.
Short coding periods: they enable procurers to give quick feedback. Software parts bearing the highest business value get the highest priority at all times.
Metaphor: using common terms and symbols with procurers
- Test driven development: Tests are written before the code. The code is only ready if the automated tests run without error.
Refactoring: increasing of code efficiency without function changes.
Continuous code checking: its extreme variant is pair programming. Programmers of the team must constantly revise each others codes.
Collective Code ownership: any programmer of the team can modify any part of the code so that they can substitute each other perfectly. Each member of the team is familiar with a preponderant part of the entire code and the basic principles.
Constant integration: system components will be built together and all day and tested with an automated method.
Intensive communication with procurers: co-workers of the procurer will be considered as team members so that to sustain an intensive communication with them.
Coding conventions: a collection of rules ensuring a more standardized code. It is accepted and followed by all team members during the project.
We adopt most of the best practices of eXtreme Programming to increase code quality and software flexibility.
In the figure below, we’re comparing the methodologies in aspect of flexibility and quality of each approach.
As we can see, there is no harsh opposition between the approaches above (except for Code Fix). In case of projects requiring less documentation, XP is the most efficient method, but all approaches have their advantages.
Our coding practice incorporates advantages of Staged Delivery, Waterfall, Prototyping and eXtreme Programming. By combining these, we ensure flexible, rapid, high quality and well documented work and softwares.