Methodology

Methodology

Basic elements of Xebtech System’s software development process.

Principles

Every aspect of Xebtech System’s development process is subject to fundamental principles and objectives discussed elsewhere. Please remember, while reading this discussion of methodology, that these principles always apply to every project and every stage of development.

Project management

Similarly, every step of the process is also subject to our project management discipline, which is an essential part of our overall development methodology.

Iterative-ness

Sometimes the development process is referred to as a “spiral”, where the spiral’s circular aspect is the repetition of the steps of the development process and its vertical aspect is progress toward completion of the software application.
The iterative approach is a balance between the rigidity of the “waterfall” method (where each step of development must be fully completed before moving to the next step) and the potential lack of discipline of the “evolving prototypes” method (where a prototype is created quickly with minimal design effort, revised based on observed shortcomings, and then the process is repeated until presumably the final desired result is obtained).

Descending order of importance. Every step in the development process is more important than the next. Because each step becomes the basis for the next, the earlier you “get it right”, the more time and money you save.
At the very start of a project incorrect assumptions, omissions, or insufficient understanding can be corrected at little or no cost. With each completed step, correction becomes geometrically more costly and time-consuming. Many projects have failed because of simple misunderstandings that could have been corrected easily at the start of the project.

Rule of necessity

One of the guidelines of the “agile” schools is “do what is necessary, not more, not less.” Because every project is different, it is appropriate to shape the prescribed practices of a methodology to the specific situation at hand.
For instance some projects have teams of 1 or 2 people and cost a few thousand dollars; others may have dozens of developers and cost millions. Some are quick-and-dirty temporary applications, others are in-house systems with limited users, while still others are world-class products with thousands of unrelated users. Some are simple GUI and database applications, others are components of sophisticated mission-critical industrial applications which must never fail.

A description of a methodology is an abstraction. Its application to a specific project should use just those elements of the methodology—no more and no less—that are required by the “rule of necessity” for that project.

Summary

This is not a formal description of a methodology and makes no attempt to be “complete” in any way. The purpose of this section is just to share with you in a general way our view of the software development process.

# #