 |
 |
|
| Balance |
|
|
The ideal software development methodology strikes a balance between discipline and flexibility. The ability to find and maintain that delicate balance comes only through the experience of managing many development projects.
|
|
|
On the one hand, adherence to methodology – the very deliberate, step-by-step progress through successive rounds of submission and approval which forms the backbone of the software development process – is imperative, not only for staying on schedule and within budget, but for reaching the goal at all.
|
|
|
On the other hand, rigid adherence to an original system design is self-defeating. You always learn as you go. Experienced developers draw up initial designs with the greatest care and attention to detail, knowing perfectly well that their beautiful flowcharts represent nothing more than the state of their knowledge at that particular moment.
|
|
|
The plan always changes. So you plan for change, actively seek the information that will force you to alter course and, above all, make sure that, when you make a turn, everyone involved is turning in the same direction.
|
|
|
| Communication
|
|
|
| Communication is what keeps everyone involved moving in the same direction. Simply stated, quality of communication is what makes the difference between achieving project goals or falling short. You strive for what economists call, “a perfect state of knowledge,” which means that everyone involved has the same information at the same time and all of it is accurate. This ideal is practically impossible to achieve in any but the simplest projects, but you get as close as you can. |
|
|
| User Input |
|
|
The necessity of obtaining regular user input is a corollary to the principle of communication, but important enough to stand as a principle of its own. The people who will operate the system on a daily basis, the middle managers and line workers who perform the business procedures to be embodied in the software, know more about those procedures than anyone else. They are usually the only people who know anything about the details. The purpose of involving them in system design is not to show them the respect they deserve so that they won’t sabotage implementation (although they well may). Rather, it is about getting their real, indispensable, nuts and bolt’s knowledge into the software. Systems designed without the benefit of user knowledge are systems destined to be re-designed. |
|
|
| Phasing |
|
|
Like the businesses they support, software systems of even moderate scope are composed of a number of interrelated sub-systems. During the planning stage of the software development process, it is necessary to envision the grand super-system that will accommodate all of these sub-systems and govern their interactions. But attempting to fully design, much less implement, that entire super-system all at once would be dangerously impractical. Within even a single sub-system, a relatively small number of variables can produce a very high number of unique combinations of those variables. And the number of combinations expands exponentially when all sub-systems relate to, and continuously modify, each other throughout the super-system. It is impossible to predict the outcomes generated by that many complex interactions. |
|
|
For this reason, practically all software development projects are planned as a series of phases, through which individual sub-systems are designed, implemented and tested more or less sequentially. Deciding how to organize the sub-systems and determine their order of implementation is extremely important. In determining order of implementation, we seek a balance between immediate benefit to the business (solving the big problems first) and optimal efficiency for the project as a whole. |
|
|
| Linear vs. Iterative |
|
|
In developing systems of low to moderate complexity, it is possible to move through the steps of the process in a linear fashion. In other words, you can plan a sub-system, design and program it, then implement that sub-system and go on to the next phase. You don’t figure on looping back to make design alterations after observing the sub-system in use. |
|
|
For systems of higher complexity, the strictly linear development model may not work. In such cases, we employ an iterative model, which assumes that we will loop back to make design alterations after an initial implementation. The reason is that, at a certain degree of complexity, it is impossible to design full functionality into the system until you try to use it. (Steve Cantor says, “You don’t know what you want it to do until you do it.”) The advantage of the iterative model is risk reduction. If you try to employ a linear model, proceeding phase to phase, sub-system to sub-system, implementing as you go without correcting basic design flaws, you will eventually have to go back and re-design, only by then the design flaws will have multiplied and compounded each other to the point that you will practically have to start over from scratch. Doing your re-design in manageable pieces is cheaper than that. |
|
|
Manage Scope Creep |
|
|
In progressing through the consecutive phases of a development project, everyone involved acquires more and more knowledge of the businesses processes being automated, and of how those processes interact. As a result, people almost always begin seeing opportunities for improvement, especially since the technology itself opens up new possibilities. |
|
|
| Seizing new, or newly perceived, opportunities for improvement, and incorporating them into the system design, results in what is commonly known as "scope creep" - the gradual expansion of project parameters that can increase costs and draw out schedules. |
|
|
If scope creep is not managed, it will get out of control. And cost overruns are only part of the danger - scope creep can take on a life of its own, tie everyone up in knots and jeopardize the project. On the other hand, drawing a line in the sand at the edge of the original plan is equally counterproductive. That method of control prohibits everyone involved from using what they learn through the development process to build a system that works. And it prevents them from adapting to business changes. |
|
|
| The solution goes back to balance. You must respect the original plan, not worship it. Proceed with great caution but keep an open mind. Carefully evaluate every proposed alteration in terms of its impact, not only on budget and schedule, but on the system design as a whole. Ask, "If we change this, how much else will we have to change?" Some proposed design alterations are unnecessary, others worth the effort, still others unavoidable. |
|
|
Custom Software – Custom Process |
|
|
| OPI builds custom software so, by definition, every project is unique. The software development methodology should therefore be considered a conceptual model, not some unalterable bureaucratic procedure. It can be adapted to any software development project, but it is always the methodology that is adapted to the project, rather than the other way around. |
|
|
Business goals are paramount. Software serves business. Development methodology serves software. |
|
|
|
|
|
|
|
