The One Percent

Introduction
The group are currently using Scrum (Schwaber,1997) for the software development process. This post is going to explain the group’s choice among existing methodologies, the advantages, and the possible issues the group may have with this approach. Determining a methodology that a group should follow is a vital part of producing a project that will fulfill the success criteria. This is due to the project requiring many steps and many contributions from different members. This means that in order for this to occur to a high standard the group must all follow the same method, understand that method, and be able to work as a group to achieve the same goals. Therefore choosing a methodology that suits both the group, the project, and the success criteria is important.

Traditional waterfall model 

Traditionally Software Development Life Cycle, or commonly known as the waterfall model, has been adopted in software development. It is well known of its cascading development stages, in which the stages are be followed in sequential order, as shown in Figure 1 below. These include feasibility study, systems investigation, analysis, design, development, implementation, and maintenance ( E. Avison & Fitzgerald, 2003).

Figure 1 The waterfall lifecycle for software development (Vidgen, 2002).

Before starting the next phase previous phases have to be completed (hence the term waterfall), and each phase has a set of defined outputs or deliverables to be produced before it could be deemed complete ( E. Avison & Fitzgerald, 2003). As the world became fast-paced and technological requirements changed frequently, people soon discovered the weaknesses of this approach and start to embrace the agile methodology.

 Weaknesses of the Waterfall model

Firstly, the waterfall model fails to meet the real needs of the business world (Avison & Fitzgerald, 2003) as the technological efficiency improvements are at the operational level, detracting from the business needs. Consequently the project sponsors also focus on the project investment, as well as the return and benefits through the system.

Secondly, over conservative systems design is an apparent limitation ( E. Avison & Fitzgerald, 2003). Since the model emphasises the existing system as a basis of the new system, there is limited creativity for developers to implement the new one. Thirdly, instability is apparent as the modeling of processes could be unstable due to changing businesses and markets. Subsequently it is difficult to develop a suitable and stable model. It becomes a burden for developer to implement the program as the modeling is varied.

In addition, inflexibility of the model, the inability to change requirements, leads to further limitation (Vidgen, 2002). The methodology makes a number of simplifying yet invalid assumptions (such as a stable environment, a well-documented business strategy, users knowledgeable about their own requirements, or that a consensus of requirements can be achieved). However, such conditions rarely exist in practice.

Next, user dissatisfaction ( E. Avison & Fitzgerald, 2003). According to problems with computer-oriented documentation, users are not allowed to browse the prototype of the system before it is completed. The user involvement is limited and they may feel uncertain since nothing could be seen when the system is incomplete. In addition to this the problems with documentation produce further limitations ( E. Avison & Fitzgerald, 2003) since the document is full of information, developers have to assume they understand what they need, instead of referring users’ needs.

Finally, application backlog is a tangible limitation ( E. Avison & Fitzgerald, 2003) as the maintenance workload can be large. As a result attempts are made to change the system in order to reflect the change of user needs. The above weaknesses raise the urge of methodology evolution. In order to fit in the fast paced environment, the group decides to adopt the agile methodology. The next paragraph will explain why the group choose agile for software development.

Agile’s advantages and limitation (Cohen, et al., 2003)

Unlike traditional waterfall model, agile software development is known as its rapid and iterative approach (Highsmith & Cockburn, 2002). It highlights the most important parts, which the crucial parts will be accomplished first. This can gain confidence to the team, and project sponsor will be easily satisfied with the project in the early stage.

A strength of agile is embracing change and continuous development. As customers are the essential part in the team, they can come up with their ideas and thoughts immediately to the team. There is no communication lag between developers and customers. Time is saved and a prompt responded development can be performed. Next, agile software development enables the team to work effectively as a cohesive unit, which can improve productivity by several times. Team work is highlighted as cooperation enables greater productivity. Team members show their various expertise, understanding of the schedules and work cohesively, so the burden or difficulties can be solved together quickly..

Agile software development is a simple, elegant and correct solution found by true domain expertise and experience. Under this aspect, software can be maintained efficiently,as everything is simple and intuitive. The new comer can easily come up with ideas of the development, which we think is better for maintenance than the waterfall model.

Why the group will use Scrum for the project

Among popular agile approaches, the group decided to use Scrum due to its substantial benefits in comparison to other methodologies. Scrum is an incremental, time-based development (Rising & Janoff, 2002) with frequent meetings (i.e. Sprint). It embraces requirement changes, and is suitable for small team that working individually.  This methodology works the best for the group as group members prefer to discuss and contribute ideas and research, rather than one person focusing on a large part. The group will have one to two meetings each week. In each week, the group will decide the next parts and corresponding job division, similar to the basic questions required in every Scrum meeting. The group meetings will last between 30 and 45 minutes each, one of which the mentor will join the group.

Conclusion

After a comparison of different methodologies the group has adopted the Scrum methodology because of its advantages. Since the application is user-oriented, user involvement in the whole development process is crucial. The group hope the project can achieve success with Scrum.

This post represents that the group has chosen appropriate economic and social Contextual Factors that directly link to the marking criteria, and are vital to understanding how best the group works towards a joint goal. These are based on a literature review which explains why the outcome was chosen and how the group will implement it. There is evidence that the methodology has been chosen intelligently (by reference to literature and analysis) to produce a conclusion of professional quality, leading to a successful product. 

It is also evident that based upon the Contextual Considerations, literature review and analysis that appropriate Design steps for the product have been chosen intelligently. This is shown by the conclusion of picking a suitable methodology for the group and explaining its choice and how it will shape product development. This choice further represents the Structure and Story of the portfolio by dictating the methodology used. 

References

Avison, D. & Fitzgerald, G., 2003. Information systems development: methodologies, techniques and tools. 3rd ed. s.l.:McGraw Hill.

Cohen, D., Lindvall, M. & Costa, P., 2003. Agile software development. DACS SOAR Report, Issue 11.

E. Avison, D. & Fitzgerald, G., 2003. Where now for development methodologies?. Communications of the ACM, 46(1), pp. 78-82.

Highsmith, J. & Cockburn, A., 2002. Agile Software Development:The Business of Innovation. Computer, 34(9), pp. 120-127.

Rising, L. & Janoff, N. S., 2002. The Scrum software development process for small teams. IEEE software, Volume 17, pp. 26-32.

Schwaber, Ken. “Scrum development process.” Business Object Design and Implementation. Springer London, 1997. 117-134.

Vidgen, R., 2002. Developing Web Information Systems: From Strategy to Implementation. s.l.:Butterworth-Heinemann.

By Po Ting Tse