Cloud Computing: Developer's View (Part III)

2 software development process

During 1980-2000, the industry was focusing on traditional development process methodologies such as Waterfall and Spiral methods. In these approaches, Rapid Application Development excluded, a stable version needed to be released firstly as alpha and beta versions. After that and in order to have the SaaP bugs fixed, customers had to either play around with the software or utilize it inside a production period. This was a long and risky process from customers’ point of view, since some bugs could have unrepeatable damages to data and Operating Systems beside the software itself. The latter was due to the fact that in traditional software development methodologies, verification phase and quality assurance was mainly being done after implementation phase. While there were some successful cases of software products with traditional methodologies, the following was a list of major issues in developing based on them.

• Before developing the software, designers needed to come up with a detailed full design plan. The issue was that some requirements were raised as the development process was evolving and could not be forecasted in the earlier design phase of the project.¹

• Beta releases needed months to become stable versions and attract all customers without worrying them.

• Changes in software were costly and infrequent, therefore customers could not have the set of features they needed in short period of time. Due to criticism of developer communities and many examples of software running over time and budget, this approach was nearly abandoned over time. In 2001, a group of developers aimed to come up with a lighter-touch lifecycle. Agile Alliance stated the following in the Agile Manifesto:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan that is, while there is value in the items on the right, we value the items on the left more.

While working on a SaaS project, developers will be asked to change the code frequently. Customers signing a contract for a SaaS want constant improvement of their service. Frequently developers are greeted with new requirement which changes components of the project. Also, in case a SaaS developer develops a perfectly architectured and coded application, it shall not be accepted by the customers without his verification. That is the reason that in Agile methodologies, verification is separated from validation. Since validation is how to architect and code a software correctly, verification is the question of following scenarios as customer needs their service to be. It should be noticed that a service is coupled to a domain, bringing so much emphasis on agile verification methods.

1 Steve McConnell in his book ’Code Complete” refers to design as a ”wicked problem”, i.e. a

problem whose requirements and limitations cannot be entirely known before completion.