Comparison Of Software Development Cycles
The iterative cycle of software development separates the activities from the artifacts
, an artifact is the product of an activity. Thus, it applies a cycle of Deming Wheel type on the production of documentation, a code, a test, etc.
Reporting to an activity of the project management type, the first phase will be feasibility, or the acceptance of a new need; development, or imagining how one will achieve it; manufacturing, or construction; and transition, where everything is made to deliver to the customer.
The iterative cycle is not a bijection with the V cycle where feasibility equals specifications, development equals architecture, manufacturing equals development prototype, and transition equals testing. Knowing that each iteration is never more than eight weeks, this tactic is impossible. In fact, the idea is to deliver as soon as something can be tested by the customer. One can indeed perform several iterations of documentation such as architecture. Similarly, if a document is only an artifact among others, there is no need to get a complete document. It is best to use the Pareto law of distribution: do not spend 80% of effort on the remaining 20%. The difference between PDCA and an iteration is the length: it must be short, while a regular Deming Wheel applied to an organization of 300 people takes many months, or even years.
The V cycle originates with heavy industry. The peculiarity of this medium is that the next phase requires more resources than the previous one. For example, to make an object in plastic, a consulting firm will design the product, then the mold cavities are machined and placed in cartridges to receive the plastic by injection, and once the prototype is correct, it goes to production phase.
Even for a simple object such as a plastic cup, the design is a matter of a few weeks (a few thousand dollars) while a mold (impression plus cartridge) requires several months of production, and several hundred thousand. Therefore, in this context, to properly manage the project, it is important not to neglect the validation of each step lest it go awry. This phenomenon works on software projects involving dozens or even hundreds of people. The decisions of the management team or the project architect, impact so many engineers for such a duration of time, that it is better to check the validity of each step.
Furthermore, to limit the entropy (disorder) of the system consisting of the project team, it is necessary to formalize the documents (or tools): the process, the needs, the software specifications, the software architecture, and the tests. In the case of a software project involving a dozen people for one to two years, the configuration is not the same, in fact, with such projects one finds a greater reactivity, due to geographical proximity and relative ease of communication, by a factor of limited cost between each step. Also, it is possible to move toward the development methods called agile by reducing the formality and multiplying the number of cycles in an iterative operation.
by: Lawrence Reaves
Software Development Phases Why Fleet Management Software Is So Important Expedite Innovation With Idea Management Software Homoeopathy Software : A Boon To All Homoeopaths Efficient Software Development Services Delivers By Major Software Development Firm Sms Software: The Changing Contour Of Communication How To Buy The Right Software Discussing Flight Simulation Software Discussing Todays Flight Simulation Software Digital Camera Photo Recovery Software-recover Photo On Mac With Ease How To Use The Tools Of A Shopping Cart Software Purpose Of Augmented Reality Software Development Top Qualities Of Good Client Software Developer