Software Development Methodologies Effective Software

¶ … Software Development Methodologies

Effective software engineering requires a decent knowledge of software development approaches along with the related tools which make them work. This section presents a study of three software methodologies namely the waterfall model, the unified software development process using UML and prototyping. This includes a description of how they function and their major features which make some of them better than the other.

Waterfall model:

The waterfall model proposes an approach to software development that contains several stages of the processes, one following the other sequentially and being undertaken only after the previous stage has been fully completed, signed off and adopted as the reference for the development of the rest of the project. The idea of the waterfall model was first introduced by Winston Royce in 1970 in his work "Managing the Development of Large Software Systems," in which the analyst in fact criticizes the model.

The most important disadvantage that he finds to the model is described in figure 4 of his article. According to this, "design iterations are never confined to the successive steps" and the problem with the model appears in the testing phase, which will tend to affect, in Royce's opinion, not only the coding phase that it is meant to verify, but also the program design and, earlier back, the software requirements phase. According to this judgment, the model fails to achieve exactly what it has proposed to do in the first place: separate each different phase in the product development process and ensure that each phase is completed before the next one begins. Due to the fact that testing implies a complete overhaul of previous phases, it cannot be completed without affecting previous phases as well and without changing some of the initial requirements if that is required.

This is probably the main disadvantage that is mentioned by numerous other theoreticians as well: the fact that some of the phases cannot be treated as single units in a logical sequence and that, quite often, the initial requirements and the design proposed is no longer valid by the time the implementation phased is developed. David Parnas in his "A Rational Design Process: How and Why to Fake It" mentions that backtracking is a normal and logical part of the software development process and the waterfall model, which rejects backtracking, cannot be valid because of that.

Partially, this is addressed by a version of the waterfall model that includes seven stages and where the last stage is, in fact, a new requirements phase. This phase is actually designed to bridge the working relation between the client and the developer and allow the client to bring in new requirements, as the business expands and the application needs to be further improved. This last phase can be adapted so as to include any potential changes in the initial requirements that the testing phase has potentially introduced.

The waterfall model does have a series of advantages. Despite the logical discussion previously presented and some of the practical difficulties of the model, it is a simplified model, mainly because of its linearity. Ideally and if no backtracking is involved in the process, the waterfall model will provide an excellent framework for the development of the application. Additionally, the waterfall model can involve a testing stage after each phase is completed, which may limit the potential errors in the final implementation stages. Overall, the fact that each phase is addressed as a separate entity will tend to make this an organized approach, which each stage including its own documentation and allocated resources.

SECTION3: Unified software development process using UML

The key element and, at the same time, advantage, of a software development process that uses UML is that this is a standardized approach, which means not only that it provides an industry norm, but also that this is a language and common denominator that can be understood by other participants in the software development process, apart from programmers and actual developers. With the documenting and modeling approach that UML proposes, the initial requirements of the software product can be modeled into something that is understood both by the business clients and the developers of the application. UML literally connects the two different levels of the development process, namely the requirements and the programming phases.

Another important advantage of UML is the fact that the modeling approach it proposes creates a functional structure for the entire software development process, but also a flexible one that can be easily adjusted or completed at a future time. If the sequence characteristic of the waterfall model implied a difficulty in reverting to phases that had been deemed as completed, with the UML structure, new phases can simply be added into the model and treated in connection to the phases that are actually impacted and to which these new phases relate to.

One of the disadvantages of UML is that the entire modeling process is, in fact, just an auxiliary activity of the actual development phase that will eventually create the finite product. In that sense, the development company needs to be a fairly large organization, able to manage the diagrams involved in the modeling process and ensure this activity despite the fact that it only makes a marginal contribution to the final development process.

Another disadvantage is the fact that the semantics used in UML and, from a larger perspective, the necessary language used to connect the different elements in the diagrams, is often limited and either does not reflect all the conditions or it does not convey the actual sense or status that needs to be included in the model. With this fact, confusions may actually arise in the development phase as to what the original sense and connection was meant to be.

Finally, some argue that the XML is too costly, with more resources being needed for training purposes, as well as for the implementation of the system in the company that decides to use such an approach. Other resources have been previously mentioned and include the fact that separate human resources may be needed to manage the diagrams.

SECTION4: Prototyping

With prototyping, the developer provides intermediary products to the user, referred to as prototypes. These intermediary products have some of the characteristics and functionality of the final product, but have not been entirely completed. There are two main advantages that one can identify with prototyping. The first one is the fact that prototyping improves the relationship and communication between the developer and the client and can better involve the client in the different phase of the software development process. This is essential in the second advantage that prototyping provides, ensuring that any changes in the product requirements are introduced at a stage where the implied costs are not too high.