Wyde introduces its proven application development methodology, WAGRAM.
WAGRAM, a pragmatic component-based methodology, is designed for Business Analysts to specify their applications and to facilitate their dialog with Development Teams. It uses the WSpecs specification tool and the Wyde Framework.
Key to the success of WAGRAM is the logical separation of development from deployment. In order to build the application as fast as possible, technical tasks should be delayed as long as possible, allowing the Business Analysts and Development Teams to focus first on the business aspects of the application to build. Many development projects suffer because technical issues are introduced too early in the development cycle, hampering the specification and creation of business functionality.
Tasks such as the following should be held off until the application is ready to deploy.
All of these tasks are best handled after the application is defined and running. By so doing, energy can be better concentrated on business objects, business processes, business rules and graphical interfaces.
To reduce complexity, the application should be separated into N development units which each share a single architecture. A development unit represents a functional module that can be built by a team of 3 to 6 people in 3 to 6 months. The architecture contains common components that are used in each development unit. Ideally, each development unit is autonomous, only relying on the common architecture and not on the on-going work from other development units.
By sub-dividing a project in such a fashion, managers can maintain a maximum of visibility concerning progress and schedules, permitting the timely delivery of selected modules.
It is impossible to write definitive specifications before building the application. Specifications are continually discovered during development, and the greatest risk is that specifications keep being added to the project, perpetually delaying delivery.
The sole solution against this risk is to determine beforehand the budget, the delivery date, and the functional objective that can be built in that time-frame. Thus, indispensable functions are developed first and are delivered in the first version. Additional functionality and new specifications are introduced into future versions of the application.
Business Analysts are responsible for non-ambiguous specifications. They should build Active Models (functioning prototypes) of their specifications to get end-user feedback and to show to management to persuade them to finance the project. Because the delivered specifications are independent of the deployment technology, it isn’t necessary to wait for the definitive technical architecture to be chosen and deployed.
Technical Teams, on the other hand, are responsible for purely technical issues. They must choose and deploy the technical architecture, and they must build and maintain the common components. They receive detailed specifications from the Business Analysts, and they develop the application according to the specifications.
Business Analysts follow a certain number of steps to build their specifications.
The glossary feature of WSpecs helps the Business Analyst in this approach. Topics are defined in terms of other topics which automatically are flagged with hyper-links to their respective definitions. Additionally, these glossary topics reference existing components, allowing the Business Analyst to determine which are the new concepts to develop and which already exist.
Once the Business Objects are defined, it is easy with WSpecs and e-WAM to build the first Active Model. As a function of feedback, successive versions of the model are built iteratively until the application is fully specified.