This Is Not The Inherent Nature Of Software Development

A Computer Software Engineer develops software systems to be used by their clients, such as a website used to sell the client’s products. Although software engineers spend the majority of their time programming and testing the software, a key component to the success of a software engineer is the ability to write a thorough Software Requirement Specification (SRS). A SRS documents the requirements and dependencies needed for the software, prior to beginning any programming. Therefore, a Software Engineer must po The SRS is so important because engineers can have a wide scope of clients that they regularly work with.

Cost and resource needs are higher for traditional than Agile due to Waterfall’s sequential development phase of all requirements determined in the beginning, software design and finally implementation of master design. The need for all information up front takes substantial time to gather and the sequential design does not allow for project changes as the flow enters into the programming stage. With Agile, costs remain low because there exists an incremental and iterative approach to the project, meaning less time is used to collect all requirements up front, the

The current development process devotes a large amount of time at the front end of development to establishing customer needs and converting them into system level requirements. The client-site team meets with customers, learns their needs, develops specifications, verifies them with the customers, and then sends them offshore for development. This is a very formalized, documented process. (+)

One of the initial steps in researching a problem is to know exactly what the problem is and compose a problem statement that unambiguously identifies and defines the problem to research. Sekaran (2003) said, “No amount of good research can find solutions to the situation, if the critical issue or the problem to be studied is not clearly pinpointed” (p. 69). The area of research for this paper focuses on software development, in particular, the study of agile software development methodologies and if these methodologies are successful in delivering software on time, within budget, and includes the requested features.

The rigid methods employed by the Waterfall approach makes it easy to manage because the team cannot move onto the next stage if all of the

It has been observed that in software development, change is unavoidable and must be accommodated for in the life cycle. A number of alternative process models have been introduced in order to attempt to fix the issues in the Waterfall model. An early modification to the standard Waterfall method introduced prototyping as a feedback and discovery mechanism to identify misunderstandings and omissions early on in the process (Neill, 2004). Other process models attempted to further get rid of the risks of misunderstandings by breaking down projects

Since the method was developed for manufacturing and construction projects, it made sense in these industries that a portion of the project was fixed and unchangeable after a phase completed. Imagine the construction of a road, you prep and lay down a foundation then eventually lay down the final asphalt or concrete layer. It wouldn’t make sense to build in the ability to go back and change the foundation after the top layer was set. Obviously, software engineering is very different and therefore requires a much different approach to development. Besides slow turnaround, there were many other criticisms of the waterfall method. Some included redesign, rework, and retesting due to lack of knowledge about requirements when a project began. Also, due to the extremely long lead and delivery times, requirements changed or projects were dropped altogether leaving a company with a half-built loss on the balance sheet. An industry average put the estimated time for any software project using the Waterfall approach at 3 years. This was the environment that enabled a few forward-thinking developers to meet and design a new and better approach.

The two reports attempt to explore the advantages and disadvantages of utilizing agile software development over the waterfall model. As described in the reports, more and more organizations are considering the agile process approach versus the more traditional waterfall approach. The agile processes evolved in the late nineties and began to emerge as a primary software development method. While organizations are moving towards agile processes, it is unclear which process is the most used. Article A details a survey in which 153 developers were asked to describe their software development processes. The waterfall method was the most used software development method. However, Article B details that 36 out of 66 projects analyzed revolved around the agile methodology. Nonetheless, both articles conclude that one method or approach is not a best fit for all projects.

Choosing a proper method for software design is completely depended upon the requirements and end products of the company. These requirements and goals might change in the process of development of software depending upon the decisions of stakeholders, developers and system analysts.

can stand alone as the sole development strategy. Verner and Cerpa (1997) observed a relationship between the size of a department and the preference to utilize a prototype. They also discovered many of the aspects of a waterfall approach that made it widely used still hold true. Developer communication and project control have long been seen as positive characteristics of the waterfall approach. The increased control is the result of the rigid, phased structure that defines a waterfall development plan. A drawback to this development strategy is the lack of feedback that we see in the scrum or agile method. This lack of feedback makes having a complete requirements essential, the lack of which can mean an unsuccessful or scrapped project.

Also in addition to my studies about Agile, I have made efforts to compare the same with another heavy weight methodology called Waterfall. Comparison include the strength and weakness of the two opposing methodologies and the outcome of a controlled empirical study conducted at Carnegie Mellon University in Silicon Valley by Feng Ji and Todd Sedano.

To this point, one stark contrast between the Waterfall and Agile methods of software development is the degree to which they involve the customer. In this sense it is easier to think of the Waterfall model as being more “predictive” and the Agile model as being more “adaptive”. There are milestones in either case, but the changes that are a result of customer input drive the flow of development in an Agile system (Arken 2008). One can see how the “adaptive vs. predictive” differences can become more of a problem where finances are concerned.

From sequential, heavy weight methodologies which are more predictive in nature and lengthy in process, today there is a shifting focus towards simple, light weight methodologies involving prototyping which provides a part of the final output at every stage of development. Several studies have reported software project failures due to lack of focus on requirements and the extent of dynamism involved in business requirement definition (Gasisas, 2009).

The article mainly focused on comparing an evolutionary method to the waterfall method. The author of the article believed that the waterfall model is very unrealistic and dangerous to use as a primary development tool for any project (Gilb, 1985). The waterfall method is scheduled for a single finished date and all planning, design and analysis is done in the very beginning before the software coding begins (Gilb, 1985). The evolutionary model is based on delivering to a real user, measuring the added value to the user, and adjusting any issues (Gilb, 1985). A key difference emphasized in the article was that a system built in the evolutionary model is real and always changing while the waterfall method is not (Gilb, 1985). The waterfall method is more focused on what the software will do as compared to the evolutionary method which is more focused on how well the software will work for the client (Gilb, 1985). Gilb had the opinion that the waterfall method is no longer a method to follow (Gilb, 1985). Back in 1985, Gilb wanted to show readers that the evolutionary method was the way software should be developed and that the clients were more interested in a technology that was perfected for them (Gilb, 1985). As seen in the waterfall approach, it was very common to have a software developed for a client and the client would not even know who the developer was (Gilb, 1985). The waterfall method was effective but it is a method

The model proposed to be used for the development of the system is the Waterfall Model.