Software engineering is appropriate when it comes to developing applications that are allowed large budgets, scopes and timelines. Because of the lack of constraints in these three areas, a different process for developing the software would be appropriate than for, say, a project that is under a tight and abrupt deadline. Larger scale projects, safety critical projects, or projects that involve a hardware component being developed concurrently, have the necessity to take more time in the planning aspects of development.

Waterfall

The typical method of development used in software engineering is the waterfall method. The name comes from the way in which the workflow passes over each step of the process, cascading like a waterfall. The number of steps can differ between models, but the generally accepted steps mirror those of the software development lifecycle:

• Requirements analysis
• Design
• Implementation
• Testing
• Maintenance

This model was adopted into the software industry after having been proven successful in the manufacturing industry. The principle idea of the waterfall method is that each step of the process is conducted and completed before the next step is started. For instance by this standard, no coding would be completed until a fully devised plan was established and documented. The extensive planning and documentation aspects of the waterfall method make this a workable choice for which these things would be important, such as for aerospace designs or medical devices.

Developing an application using the waterfall method requires a long time commitment because none of the steps are conducted concurrently. Because of this, projects developed in this manner tend to be very expensive. This methodology does not allow for flexibility, so requirements added, removed or changed are cumbersome to the process.

Agile

Flexibility is something that a project being managed in an agile fashion can expect and handle. Software projects are unpredictable because there is a human element to every project. Requirements change, designs are tweaked, and business needs shift. This is because in addition to the project being regularly evaluated, the stages of the software development lifecycle are constantly being revisited during the project.

Agile software development, as opposed to the waterfall method, allows for continuous delivery of small parts of the application. These smaller iterations give clients and users more opportunities to evaluate the existing requirements and make changes as they see necessary. This also facilitates communication between the developers and clients.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

A great resource about the agile process is the Agile Manifesto, which is supported by several important figures in modern computer programming. They recognized a need to move away from sequential programming and to focus more on “individuals and interactions, working software, customer collaboration, and responding to change).

Extreme Programming

Extreme programming is an extension of agile development, as all of the principles noted in the Agile Manifesto are followed in Extreme Programming (XP). XP goes further to reinforce the need and benefit for testing all parts of the application. Another common practice in XP is developers working in pairs to increase the software’s quality, which saves time in the long run.

Extreme program was envisioned with 12 key principles, grouped into four focus areas: fine scale feedback, continuous process rather than batch, shared understanding, and programmer welfare. Modern software is often built using this method because it introduces these “best practices” in consideration of more than just the end product.

Conclusion

There are certainly many ways to build an application, these are just three commonly used methods. The method that your team chooses should be appropriate to the scale, budget and timeframe of the project. Additional considerations should be made regarding the size of the team available, how experienced it is, and whether the developers are centrally located. The amount of face time available with clients both at the project’s inception and throughout the project will play a role in the method used. There are many factors in choosing a methodology; there is no one size fits all. Every team should take some time to evaluate what works best for them and the project.