Вы находитесь на странице: 1из 10

Assignment 4: There is No Universal Software Process, Soh Wei Yu, 43036024

Introduction

Each of the software projects developed across the world are built with very different context, circumstances and requirements. Each of these situations call for different software development methodologies and come with different sets of challenges and issues. It is through these varying problems, factors and considerations that different kinds of software processes have been developed and evolved through the years in order to address these considerations. Software developers have to weigh in all the factors in order to decide which is the software development process that fits their project most.

This essay discusses what some of these processes in depth and how each processes addresses the various considerations and concerns of software developers, taking into account some of the examples of real life software projects. This will in turn show that there is not one universal software process in which all software development will go through, but many different processes, each suitable for certain contexts, with its pros and cons.

Factors Affecting Software Projects

The basic requirement of a software development process is that it has to cater to the necessities of the project. Therefore, the suitable software development process for a project always depends on the context, factors and considerations surrounding the software project. When this principle is understood, it becomes very clear that the idea of a universal software process which fits all is in fact a myth. (Clarke, 2012)

Before commencing on development, software development and process managers will need to look into a list of factors before choosing the software process which they deem to be most suitable given the particular context or situation surrounding the software project.

Some of the factors affecting software process and projects include:

- Clarity of initial requirements: whether the developers are able to get hold of very clearly defined software requirements right at the beginning, which could influence the necessity for agile methodologies

- Accurate initial estimation of costs and development time: certain methodologies are able to allow more accurate estimation of costs and development time, however, usually it is difficult to have a clear estimation with agile methodologies due to lack of clarity of requirements at the initial phase

- Incorporation of requirements changes during the development process: another consideration is whether it is important in ones context to be able to make changes to adapt to new requirements in the middle of the development process. Different methodologies provide different levels of flexibility or dynamicity

- Obtaining functional versions of the system during the development process: certain methodologies are more able to allow users to interact with prototypes before the final version, which lets users be in the know of any developments and offer valuable feedback

- Software criticality: different methodologies have different ways of ensuring that the project is fully functional, including project management and testing

- Development costs: different methodologies have different financial requirements due to factors such as varying development time and development cycles

- Length of the delivery time of the final system: different methodologies require different amount of time to complete its tasks, as some methodologies may involve in large number of activities which could lead to extended delivery time, while others may allow reduction of requirements in order to meet deadlines

Assignment 4: There is No Universal Software Process, Soh Wei Yu, 43036024

- System complexity: certain methodologies are more suitable for large projects with complex technicalities and project management involved, whereas some methodologies do not work well with complex systems

- Communication between customers and developers: some methodologies only require customers to provide requirements at an initial phase while some methodologies require customers to be actively involved in the developmental process throughout the cycles.

- Size of the development team: some methodologies are suitable for small teams, some are suitable for large teams

- Flexibility in timetable or setting of datelines: some methodologies require strict following of time tables to the effect of reducing functionalities in order to meet datelines, while others allow schedule to be adjusted

(Cristina Venera GEAMBAŞU, 2011)

When choosing the right software process for a project, one should carefully consider these various considerations, and find a process that best suits the various factors and context one is working with, or helps in addressing some of those factors and considerations.

Waterfall

Most software projects follow either one of the major software development methodologies: the Waterfall methodology, or the Agile methodology, and most of the methodologies used today are variants of the waterfall and agile methods. As such, the whole issue of waterfall vs agile is a very common and hot subject of debate and discussion among software developers. (Ross, 2014) Based on various sources, it can be observed that although waterfall is seen as a more traditional form of software process in contrast to agile methodology, many software projects these days are still developed with waterfall methodology for good reasons.

The waterfall methodology approaches software implementation systematically in linear stages, in which the system is built through a cycle of predictable stages such as planning and analyzing business and system requirements, designing IT solutions, building, and testing, and then the process is repeated to refine the system until completion. (WATERFALL vs. AGILE METHODOLOGY, 2008) The benefits of this approach is its predictability, and a clear vision of the developmental process being carefully planned out. Waterfall methodology tends to allow projects to be developed rather quickly, allowing better estimation of timetable and budgets, and development processes can be more secure due to planning. However, the waterfall method does not allow changes to requirements to be adapted easily during its developmental process. This approach may be suitable for projects that have very static, well-understood requirements that are not expected to evolve too much during the development process. (Mikoluk, 2013)

There are many cases where waterfall is more suitable for development of certain projects than using agile software process. For example, companies like Accenture, IBM, etc, that deals with custom development and services, typically tend to use traditional waterfall approach. The reason for this is because these companies tend to deliver projects based on contract. Or, these projects may have a fixed scope for a fixed price. (Pincus, 2014) Waterfall methodology is more suitable for this as waterfall software development hinges on detailed and fixed requirements right from the beginning of the process. Also, in cases where software systems may be used in environments that can endanger lives and has to be bug free, it is advisable to use software development process that are similar to waterfall method instead of agile methodology. In such situations, a list of safety standards must be followed so that one’s actions can be defensible in the court of law, and all of the

Assignment 4: There is No Universal Software Process, Soh Wei Yu, 43036024

safety standards recommend following a developmental process similar to the waterfall method. It is not easy to defend ones choice in applying an agile development process in a safety critical setting may not be easily defensible or justifiable in a court if there is an incident. Furthermore, detailed documentation and specifications must be produced, otherwise one cannot take credit for the product later in a court of law. (McComb, 2014)

Another good point about waterfall methodology is that it allows for accurate estimation of costs and development time right from the beginning of the project, because generally all the requirements for a waterfall project are already known at an initial phase.

For all these reasons, software that is contract based, or require high degree of safety standards, or may face scrutiny by a court of law, or require clearly stated documents and specifications would do well to be implemented through waterfall method instead of agile method.

Examples of other forms of waterfall-based methodologies discussed in this paper includes V-Model.

Although the traditional waterfall methods suit many software projects even today, it has its down sides and limitations. Waterfall-based methodologies lack the ability to deal with the dynamic nature of software requirements, wherein requirements are hard to establish all at once. Due to the dynamic nature of software development, many software projects may not have clearly delineated requirements right at the beginning, which would be expected of projects undertaken with waterfall software process. As such, agile methods offer an alternative solution.

Agile

In contrast to the waterfall method, the agile methodology approaches software implementation without relying on predictable, planned or defined methods or steps, but instead the developers regularly reevaluate and changes their priorities at the end of each cycle, which can happen weekly or monthly. (WATERFALL vs. AGILE METHODOLOGY, 2008)

Due to its flexibility, this approach is more suitable for projects that have requirements which are not completely understood yet, or which may be subject to changes throughout development. Customersfeedback and software testing occurring simultaneously with software development means that problems with the software will not be discovered only in a late phase of software development. Agile approaches are generally considered more suitable for projects with high degree of uncertainty (Emam Hossain, 2009).

Although agile approaches are great for supporting the needs of dynamic software development, it is also not without criticism. For example, criticisms against agile include that they are only suitable for small software development teams, or that they may require premium software engineers. (Clarke, 2012)

Variants of Agile methodologies discussed in this paper include Extreme Programming, Scrum and Kanban.

V-Model

The V-model is a software development process that is considered to be an extension of the waterfall model. It is in many ways similar to waterfall method as the process still deals with the various steps like system requirements, coding, to testing, etc. However, instead of following a strictly linear path such as the waterfall method, the V model’s process steps bend upwards after the coding phase to form a typical V shape. The V model is designed for concurrent relationships

Assignment 4: There is No Universal Software Process, Soh Wei Yu, 43036024

between development steps and related testing phases. ( V-Model Software Development Life Cycle Model, n.d.)

( V-Model – Software Development Life Cycle Model, n.d.) (Cornish, 2014) V-model software development model was

(Cornish, 2014)

V-model software development model was used in the development of projects like the OneSchool (Cornish, 2014), which is an education software used by thousands of teachers and states schools throughout Queensland. In the V-model software process, instead of proceeding through a series of steps in a totally linear manner, each of the steps are co-related to an associated phase of testing. Under such a software process, they undergo a V and V (validation and verification) process, where written requirements are used for testing purposes. The validation part corresponds to the left hand side of the V diagram, whereas the verification part corresponds to the right hand side. Validation and testing are performed throughout the software process in order to ensure that the software meets the user requirements. The test cases on the right hand side of the V diagram is populated as they go along the trajectory on the left hand side. As such, they can start iteratively developing the solution and exposing the functionalities to the users in an early phase so that the software does not turn out to be surprising to the users at the end of the development process. Thus, verification and validation is very important in the V model. This helps saving costs potentially amounting to millions by correcting problems at an early stage of the development. (Rice, 2013)

The main benefits of the V-model over the traditional waterfall model is that because the various forms of testing are done concurrently with the designing and coding of the system, the number of defects that occur are less than in the normal waterfall methodology. This is because due to concurrent testing and designing/coding, defects are fixed before proceeding onto the next stage. (Satalkar, 2011) On the other hand, for the traditional waterfall model, the testing phase occurs at a very late phase, therefore errors may proliferate incrementally throughout the development cycle as they were not detected and remedied earlier.

Extreme Programming

Customers may not always have a very clear and precise picture of what they want on their software during the first meeting. Furthermore, one may be developing a system whose functionality is

Assignment 4: There is No Universal Software Process, Soh Wei Yu, 43036024

subject to frequent changes. In such circumstances, only Extreme Programming is able to solve these developmental issues. The aim of XP is to deliver functionalities required by users as and when they are needed. (Wells, 1999)

Extreme programming (XP) is an agile software process that emphasizes responding to changing customersrequirements by following a principle of excellent application of programming techniques, clear communication and teamwork. This process encourages communication and customer feedback throughout its development. In fact, a representative of the future user must be present throughout development to answer questions to the developers. It is characterized by short development cycles, an incremental planning approach that evolves gradually, and flexible schedule to implement functionalities and changes to requirements along the way of development. A software life cycle of Extreme Programming has six phases: exploration, planning, iterations to release, production, maintenance and death.

iterations to release, production, maintenance and death. (Cristina Venera GEAMBAŞU, 2011) Planning involves

(Cristina Venera GEAMBAŞU, 2011)

Planning involves customers meeting with development team to create stories, which are user requirements. Stories are then converted into iterations that deals with small portions of the functionalities, which does not amount to much individually but when combined together becomes the full package. This is followed by designing, which emphasizes simplicity, expressing each design only once and not anticipating functionalities, using system metaphors or standards on naming, allowing for all members of the project teams to contribute ideas, and creating solutions to mitigate problems and concerns.

The coding phase involves developing code based on agreed standards, using a policy of collective code ownership. Coding is done with pair programming, which involves developing code by two programmers working collaboratively on a single machine in order to produce higher quality code at similar or less cost. There is also a standard to strictly adhere to 40-hour workweeks with no overtime, which ensures that developers work with good mental and physical wellness. There is also frequent integration of code to the dedicate repository. After coding, there is testing with unit and customer acceptance test to ensure the system is free from bugs and satisfies the customers specifications and expectations. (Nayab, 2011) This is then followed by incremental releases.

As can be seen, there is emphasis throughout the process on teamwork between programmers,

Assignment 4: There is No Universal Software Process, Soh Wei Yu, 43036024

clear communication with users and application of programming techniques in order to achieve optimal performance during the software development.

Automated tests are used to monitor progress and catch errors early in development. (Kent Beck, 2004) Working versions of developed system are frequently obtained, allowing customers to know the progress of development and even stop the project if he is out of funds. Furthermore, due to short development cycles, lower costs are required to adapt to changes in requirements. (Cristina Venera GEAMBAŞU, 2011)

Apart from its main goal, XP projects also unanimously report higher levels of productivity in comparison to other projects. A case study conducted with an industrial team from Sabre Airlines Solution indicates that using XP practices result in better post-release quality than average, as well as similar or better productivity than average. (Lucas Layman, 2006)

In a another case study during adoption of XP methodology for software development in an eleven- week long course projects, it is found that the majority found XP process favorable, furthermore they produced more functionalities with less work, response to changes in requirements were more successful when applying XP methodology over Waterfall methodology. (Ghazy Assassa)

Although Extreme Programming is suitable for situations which call for heavy involvement and collaboration between user and developer, there are also drawbacks to this approach. For example, it may be difficult to come up with an initial estimate on the effort, development time and costs required for the software project in Extreme Programming, as not all requirements are known at the beginning of the project. Furthermore, Extreme Programming is not recommended for large projects due to difficulty in communications when dealing with large groups, and complications that arise due to complex interdependencies. Extreme Programming is meant for small development team of between 2 to 10 people. (Cristina Venera GEAMBAŞU, 2011)

Scrum

Scrum is a form of agile software development process that is iterative and incremental. (What is Agile? What is Scrum?, n.d.) The scrum methodology is generally designed for small teams, however, some argue that Scrum can also be used for large and distributed teams. (Emam Hossain, 2009) It consists of an initial phase whereby the team creates an architecture and selects a chief architect. After which, a series of short development phases called sprints are carried out in order to produce regular releases, and one sprint usually lasts between one to four weeks. Each sprint builds on previous increments to deliver valuable functionalities within a fixed delivery timeframe. The team may reduce deliverables during the sprint but cannot change the delivery date. Finally there is the closure phase which usually means the finishing of product development. A Scrum master frequently leads Scrum meetings to identify an initial backlog, which is a list of identified tasks to be completed in the sprint. (Janoff, 2000)

Assignment 4: There is No Universal Software Process, Soh Wei Yu, 43036024

is No Universal Software Process ” , Soh Wei Yu, 43036024 Case studies on scrum have

Case studies on scrum have shown that projects implementing scrum results in positive impacts. For example, Intel Corporation have transitioned from a waterfall-based software process to scrum and noted that it resulted in positive impacts in four ways: major reduction in cycle time, increased performance and better ability to meet schedules and commitments, improved morale due to better communication and job satisfaction, as well as increased transparency, adoption of formal standards, and uncovering of various bugs and problems.

Most of the observed impacts were very positive, with the exception of a few issues that did not went too well. For example, Product Owners are allowed to participate in the team to facilitate communication, which worked quite well in some cases. However in other cases the POs micromanaged the teams, preventing honest communication between team members, resulting in secret meetings to discuss real organizational impediments outside the view of their PO. This prevented self-organization. Another con is managing a huge backlog that can be overwhelming if it is not managed well. Therefore, they segmented and differentiated the newsprints from the acceptedsprints, and implemented a freezerfor user stories that they will only get to a few sprints down the road. (Elwer, 2008)

Kanban

Although scrum has many benefits as listed above, it also has its own cons, which is why some companies chose an alternative software process that is quite similar to scrum but improves on some of the flaws of scrum. For example, a scrum project has regular releases every few weeks, and those sprints are of fixed length. As such, in order to meet those imposed false datelines, developers may rush for datelines which leads to a substandard product. This happens to be the biggest criticism of scrum.

Kanban is able to solve this problem, as the length of the sprint is not fixed, and the team puts together a best estimate to come up with the length of the next sprint. A Kanban software process still consists of datelines, but makes datelines more realistic. (Escott, 2014) Furthermore, Kanban does not have prescribed roles like scrum masters, and changes can be made at any time in contrast to no changes being allowed in mid-sprint in scrum projects. (What is Kanban? Kanban Software Tools , n.d.)

Assignment 4: There is No Universal Software Process, Soh Wei Yu, 43036024

Kanban is a software process that derived from Lean Manufacturing based on Just-in-Timeproduction, a process developed by Toyota in the 1950s. In a Kanban process, one first visualizes the flow of work before implementing the plan. Unlike sprint approach, one does not need to spend time at the beginning of every sprint to estimate and plan another batch of work, and although one can still deploy completed code every few weeks, one simply move work through the system without needing to arrange weeks of work at a time. Planning and estimating, designing, building and testing can occur whenever an item becomes top of the priority in the backlog. Kanban encourages members of team to take each item to its completion by allowing them to submit whatever is ready to be delivered, therefore there is no over emphasis on meeting arbitrary datelines. (Kanban and Agile , n.d.)

Hence, another factor that software developers consider is flexibility in its timetable or setting of datelines, and avoiding the problems that arise from setting arbitrary datelines, and Kanban allows such flexibility.

Conclusion

The suitability of a software development process to a project is highly dependent on the contextual situation and considerations surrounding the software project. Different software projects have different requirements and circumstances that favours different software processes. For example, waterfall methodologies are more suitable for projects with static and well understood requirements, or projects that are contract based, requires high safety standards or clearly written documentation. Agile methodologies on the other hand require flexibility and ability to adapt to changing requirements, thus is more suited to situations where requirements are not yet set in stone. Many variants of the waterfall and agile methodologies have been developed to suit various needs.

From all the different kinds of software process methodologies and the various examples, we can conclude that there is indeed no universal software process meant for all and every software projects. Instead, what we find is that every company and every software project utilizes different kinds of software processes that suits their particular purposes and solve their problems or addresses various factors and considerations they may have. We also find that no software process is perfect or flawless that although each software process has its pros and benefits, each of them also have different cons or flaws, and from these flaws comes further evolutions to the software processes, resulting in newer and improved software methodologies. On the other hand, pros and cons can be interchangeable, what may be a confor one context may not be an issue in another. In the end it all depends on the users context, requirements and the various factors to be considered for software development. Depending on the various considerations one may have, it is also possible that one could mix and match aspects of the different software processes in order to suit ones requirements.

Assignment 4: There is No Universal Software Process, Soh Wei Yu, 43036024

Bibliography

V-Model Software Development Life Cycle Model. (n.d.). Retrieved from http://qeworks.com/v- model-software-development-life-cycle-model/

Clarke, P. (2012). The situational factors that affect the software development process: Towards a comprehensive reference framework.

Cornish, C. (2014, March 20). Guest Lecture (Week 3 Lecture 3). Seddon D Building 82D, University of Queensland, Brisbane.

Cristina Venera GEAMBAŞU, I. J. (2011). Influence Factors for the Choice of Software Development Methodology.

Elwer, P. (2008). Agile Project Development at Intel: A Scrum Odyssey.

Emam Hossain, M. A.-y. (2009). Using Scrum in Global Software Development: A Systematic Literature Review.

Escott, E. (2014, April 10). Guest Lecture (Week 6 Lecture 3), Software Methadologies. Seddon D Building 82D, University of Queensland, Brisbane.

Ghazy Assassa, H. M. (n.d.). Extreme Programming: A Case Study in Software Engineering.

Janoff, L. R. (2000). The Scrum Software Development Process for Small Teams.

Kanban and Agile . (n.d.). Retrieved from http://leankit.com/kanban/kanban-agile/

Kent Beck, C. A. (2004). Extreme Programming Explained: Embrace Change.

Lucas Layman, L. W. (2006). Motivations and measurements in an agile case study.

McComb, D. T. (2014, March 27). Guest Lecture (Week 4 Lecture 3), Software Safety Engineering. Seddon D Building 82D, University of Queensland, Brisbane.

Mikoluk, K. (2013, September 9). Agile Vs. Waterfall: Evaluating The Pros And Cons. Retrieved from https://www.udemy.com/blog/agile-vs-waterfall/

Nayab, N. (2011). The Extreme Programming Life Cycle. Retrieved from

http://www.brighthubpm.com/methods-strategies/88996-the-extreme-programming-life-

cycle/

Pincus, S. (2014, April 3). Guest Lecture (Week 5 Lecture 3). Seddon D Building 82D, University of Queensland, Brisbane.

Rice, R. (2013, October 9). Software Testing Training - V Model. Retrieved from

https://www.youtube.com/watch?v=zzPDHqR2qhU

Ross, D. K. (2014, March 13). Guest Lecture (Week 2 Lecture 3), Why didn't they test it? Seddon D 82D, University of Queensland, Brisbane.

Satalkar, B. (2011, June 28). Waterfall Model Vs. V Model. Retrieved from http://www.buzzle.com/articles/waterfall-model-vs-v-model.html

WATERFALL vs. AGILE METHODOLOGY. (2008, January 4). Retrieved from

http://agileintro.wordpress.com/2008/01/04/waterfall-vs-agile-methodology/

Assignment 4: There is No Universal Software Process, Soh Wei Yu, 43036024

Wells, D. (1999). When should Extreme Programming be used? Retrieved from http://www.extremeprogramming.org/when.html

What is Agile? What is Scrum? (n.d.). Retrieved from https://www.cprime.com/resources/what-is- agile-what-is-scrum/

What is Kanban? Kanban Software Tools . (n.d.). Retrieved from http://www.versionone.com/what- is-kanban/