Introduction
The development of programs such as games requires that an organization commit a large amount organizational resources and time. In large projects, it is not uncommon for the budgets to run into millions of dollars and take years of effort before completion (Everett and McLeod 2007). In time it has been observed that to develop a sequence of activities that can be used as a guide can ensure that quality software is always produced within the required time frame.
There are two common terms often used in the context of software development life cycles namely, methodology and tools. Methodology can be used to define a recommended way of tackling a specific task. On the other hand, a tool can be taken to refer a device devices used to accomplish the same task (Everett and McLeod 2007).
Using the example of a construction project, the architect’s blueprint can be taken to construe the methodology while the tools used by the construction workers are the tools needed for the task (Everett and McLeod 2007).
With reference to software development lifecycles for information systems, methodology can be taken to be the series of stages that are followed in the process of development or revision of a software project (Everett and McLeod 2007).
There are several stages in a software development lifecycle and each stage is a segment that consists of specific defining activities. The stages in the lifecycle are normally completed in a specific sequence using a variety of tools. These tools are crucial in that they make the completion of tasks associated with a segment simpler.
For example, when designing the data or processes to be followed in the software development process, the developers will use data or process modeling tools (Everett and McLeod 2007). Some examples of data modeling tools include entity relationship diagrams. These tools will help the developers identify essential aspects within the system and model the data accordingly.
In the case of process modeling some examples of the tools used include data flow diagrams and use case diagrams. Object modeling tools may include sequence and class diagrams while business processing tools may include workflow process diagrams. All these sequences and tools are essential to the final product in that they assist in production of the required system.
The evolution of software development lifecycles can be traced to the early 1960s (Everett and McLeod 2007). During this formative period, a series of do’s and don’ts for software design began to emerge as a standard. Initially, it included four main steps namely, planning, analysis, design, and implementation.
Planning basically consisted of developing specifications for the problem to be solved or developing objectives for the proposed system (Everett and McLeod 2007). The analysis stage involved conducting a thorough analysis with a view to fully understanding the existing system.
In the design process, the main task was to create processes and data to be used in the new system. Lastly, implementation involved the actual preparation of software, construction of data objects, assembly of the new system, and finally the cross-over from the old to the new system. (See Figure I)
Although this sequential approach to software development was logical it came with two significant drawbacks. First, the sequential approach required the completion of each stage before proceeding to the next which meant that projects took a much longer time to complete (Everett and McLeod 2007).
It did not allow for the project team to mix tasks and as such led to time wastage during the software development process. The second major drawback of the sequential approach was the fact that being sequential in nature did not allow the developers to backtrack due to changes in requirements (Everett and McLeod 2007).
This lack of flexibility is seen as a major setback given that it is common for requirements to change at any stage during the software development process. The failure to cope with such changes led to new approaches in software development which will be discussed further in this report.
Agile Processes
It has been noted that around the late 90’s through to the current decade the software development process has seen an explosion of lighter weight more adaptive models. The basis of this has been due to the fundamental changes in software development paradigms such as object orientation, test-driven models, and 3G languages.
These models were formed on the basic idea that when the right development tools and practices were used it was simply more cost-effective to write code quickly and have it evaluated by users (Leffingwell and Widrig 2010). To accomplish this suggests that one can be wrong if necessary so long as they can redo the sections that require attention based on the user feedback.
This assumption was based on the fact that it may be difficult to gather all the user requirements and prepare all the required documentation upfront as is the case in the more traditional approaches to software development. Following this several different lightweight approaches emerged such as Dynamic Systems Development Management (DSDM), Feature Driven Development (FDD), Scrum, and Extreme Programming (XP) among others.
This action to alter the approach to software development came about after the creators of many of these lightweight processes came together in 2001 to discuss how to improve the software development process (Leffingwell and Widrig 2010). In this meeting, the participants decided on a means to uncover better ways of building software and developed the Agile manifesto.
The core beliefs of the underlying movement went further to highlight principles to be used in future system design. One of the observations of the movement was that individuals and interactions were to be given preference over tools and processes (Leffingwell and Widrig 2010).
The traditional approaches tend to lay an excessive emphasis on the role of tools and processes. Also, customer collaboration was to be given preference over customer negotiation (Leffingwell and Widrig 2010). Again in this aspect the role of the customer was changed to include them in the development process as collaborating partners who offer crucial feedback to the process. The manifesto also gave preference to working software over comprehensive documentation (Leffingwell and Widrig 2010).
This again shifted from the traditional outlook that assumed that if the documentation was comprehensive then the job was well done. Instead in the manifesto if the software is working well then that is a job well done. Lastly, the manifesto gave preference to responding to change over following a plan (Leffingwell and Widrig 2010). This also shifts from traditional approaches which were very structured in nature.
The manifesto is backed by a set of core principles which serve as the common framework on which all agile processes are developed. The principles include(Leffingwell and Widrig 2010); customer satisfaction through early and continuous delivery of valuable software; Embracing changes in requirements even late during the production of the product; deliver working software frequently with preference to shorter time span; involving business people and developers in the creation of software; build projects using motivated people; lay strong emphasis on face to face communication; promotion of sustainable development through agile processes; place continuous attention to technical aspects and design excellence; simplicity; promotion of the notion that best architectures, requirements, and designs emerge from self-organizing teams and promote holding regular teams sessions for improvement (Leffingwell and Widrig 2010).
There are a number of agile processes in use currently in the development of software. However, based on a recent survey, it would appear that the most widely used approaches are currently Scrum and XP representing 74% of current agile implementations (Leffingwell and Widrig 2010).
XP Programming
Extreme programming is a discipline of software development that places value on simplicity, communication, feedback, and courage. For successful completion of a software project using this approach, there are three key parties that must cooperate namely the customer, the developer, and the project manager (Jeffries, Anderson, and Hendrickson 2001). Based on the player the discussion will outline the roles of these parties to provide a better understanding of the approach to software development.
The customer has the choice to decide what will deliver business value. Due to this, the customer can choose what tasks to complete first and which ones to defer to later time during development of software. The customer also plays a major role in defining the tests to be performed on the system to indicate that the system actually accomplishes what it was meant to (Jeffries, Anderson, and Hendrickson 2001).
It should be noted that all software projects need to deliver business value. A successful development team needs to build the right things in the right order and ensure what they construct actually works. XP is based on the belief that though this is the task of the developers the customer plays a critical in steering this process to success (Jeffries, Anderson, and Hendrickson 2001).
As a result of this the role of the customer in XP can be filled by an individual or a team. For the development team to be most effective it would be wise for the customer to be available all the time. In this approach the customer or team of customers represents a single voice and it does not matter the whether it is an individual or a team.
The role of this customer is to make decisions on what will have business value and the order with which that value will be delivered. An XP team accomplishes the task of building software through a series of stories (Jeffries, Anderson, and Hendrickson 2001). These stories are just individual accounts of how the system needs to work to accomplish it initial goals.
Each story will describe a single task of the system needs to accomplish. Each section of the story needs to be understood well enough by developers to determine the difficulty of accomplishing the task. In addition to that each story needs to be testable to determine whether it does accomplish what was described (Jeffries, Anderson, and Hendrickson 2001).
As the customer in the team one must be able to narrate each task in terms of a story for the developers to use. For smaller projects that span a few months, there may be fewer stories say 50-100 but larger projects will require much more (Jeffries, Anderson and Hendrickson 2001).
As a result of this XP projects normally will deal will have a fixed feature delivery date as opposed to delivery dates for the entire work. Instead of assuming that the entire task can be completed by a specific date XP assumes that specific features or components are delivered by specific dates. This is one advantage with XP in that it lets the team predict how much work can be done by a specific date and thus makes it easier to trace the progress of a software project (Jeffries, Anderson, and Hendrickson 2001).
This role is significantly influenced by the customer whose role is to identify what has most business value and allow developers to determine how soon they can deliver these components. Upon completion, the customer again plays the crucial role of testing to see whether the stories have been correctly implemented. Acceptance testing is a crucial part of the system and confirms that the customer requirements have been satisfied (Jeffries, Anderson, and Hendrickson 2001).
The programmers have many tasks in this approach including analysis, design, coding, testing, and integration of the completed software project. The programmer is expected to estimate the complexity of implementing the stories and estimate the time it would require to complete each story (Jeffries, Anderson, and Hendrickson 2001).
Based on their estimation they can track the pace at which they can work to deliver finished components to the customer. Keeping in mind that the goal of any software project is to deliver business value it is essential that each story must be understood. For this reason, it is crucial that the customer be available on-site to answer any questions that may arise with regard to the story.
In addition to this, it is the task of the developers to bring all the software from the individual components to coherent whole. In this approach, the main emphasis is placed on programming. All tasks undertaken by the developer revolve around programming and the single point which remains the constant focal point is the software program (Jeffries, Anderson, and Hendrickson 2001). For this reason, it is common to build the system using small releases of software that are periodically released to the customer. These releases also serve to provide crucial customer feedback that can be used in subsequent software releases (Jeffries, Anderson, and Hendrickson 2001).
To achieve this iteration the programmers is expected to base the software on simple, clear design which allows the developers to produce software fast. It is reported that XP is neither slash-and-burn nor a code-and-fix approach to programming. Instead, XP is about careful and continuous design coupled with rapid feedback and extensive testing.
The goal of all this is the production of and maintenance of high quality code (Jeffries, Anderson, and Hendrickson 2001). The programmers work at all times keeping an integrated version of the system to look at. This continuous integration allows for faster implementation and less confusion as the project progresses.
In addition to this it is crucial that the developers make code that is similar so that communication is maximized and focus is maintained. In this approach code ownership is by the team and everyone contributes and no one is kept waiting (Jeffries, Anderson and Hendrickson 2001). Individuality is not encouraged and the main focal point is not in code but in teamwork.
Where possible all production code is written in pairs for maximum speed and cross-training. This approach to software development allows programmers do what they do best and that is program while giving customers what they need most that is business value. The approach suggests a win-win situation for both parties with the original goals being satisfied.
The role of the project manager is to bring the customer and the developer together and build a smoothly operating team. The manager’s goal is not to accomplish the task but to build and manage a good team to accomplish the task (Jeffries, Anderson, and Hendrickson 2001).
It is the work of the manager to settle on what tasks need to be accomplished first and in what fashion the project will progress. In business what delivers value and when it is achieved are extremely crucial. The goal of the manager is to liaise with the parties involved to deliver value and within good time. It is also the task of the manager to develop a path for the team to follow from the beginning to the end of the project.
The manager will be available to handle all meetings and give the final word of how work is expected to be handled within the team (Jeffries, Anderson, and Hendrickson 2001). Based on this it is clear to see that the biggest disadvantage with XP programming arises when there is a breakdown of communication within the team. This is a major hurdle given that there is very little documentation produced as the project moves along.
Feature Driven Development (FDD)
Just like XP programming described above FDD is also an iterative and incremental approach to software development (Haugan 2011). It is claimed that FDD blends a number of industry-recognized best practices such as those outlined in the Agile Manifesto. These principles are all focused on the perspective of a customer-valued set of features (Haugan 2011). As with all Agile systems, the goal of FDD is the production of tangible, working software repeatedly and in a timely manner. (See Figure II)
Feature-driven development can be taken to be a short iteration development process consisting of five basic activities. In the first three activities namely develop the overall plan, building feature list, and plan by feature the scope and plan for the project are identified (Haugan 2011). In the last two activities namely build by feature and complete project there are a number of iterations made until the client is satisfied with the end product.
Feature-driven development has been reported as a combination of the traditional approach to software development and the Agile methodology. This is so because of the fact that the first three steps are similar to the first three steps of the traditional approach to software development (Haugan 2011).
These steps in the traditional approach are as follows; establishment of project objectives, defining the work, and planning the work. These steps can be mapped to the first three steps which include; development of an overall model, construction of feature list, and planning by feature (Haugan 2011).
In the first step of FDD which entails development of the overall model, the customer is taken through a high-level walkthrough. This is performed with the goal of discussing the scope of the proposed system and its context (Haugan 2011).
In addition to this the client and the project team will walk through the overall requirements for the proposed system. The goal of this second walkthrough is to establish sub-objectives and to set the range which can be used to identify specific features of the overall system.
In the second step of FDD, the project team will utilize information gathered from the initial walkthroughs to identify a list of product features. This will be achieved by the decomposition of each objective into specific subject areas that can be dealt with as a unit (Haugan 2011).
Subject areas will typically contain specific business activities and the steps followed to accomplish the activity typically form the feature list. It is assumed that each item on the feature list should not take more than two weeks to complete. If the item should take a longer period to complete then that subject should be further decomposed into other smaller features (Haugan 2011). The development of a suitable feature list is normally the work of the chief programmers and a domain expert (Westfall 2009).
Once the feature list has been completed then the next step would be the production of a suitable development plan. With the completed feature list in hand, the team leader can issue features or feature sets to various members of the project team for completion (Haugan 2011).
This stage also allows the project team to develop priorities and dependencies for the overall software project (Westfall 2009). It is also at this point that the project manager and chief programmers will establish the initial schedule and major milestones for the software project (Westfall 2009).
For this to be achieved the software development team will give consideration to specific factors such as client value level, client dissatisfaction level, and risk reduction impact.
During the fourth stage, the project team begins the work of developing the actual software in earnest. The chief programmer begins by scheduling a small group of features also known as work packages (Westfall 2009). These work packages are selected from the feature sets by identifying the features that use the same classes.
Feature teams who will develop the actual software are formed by selecting class owners involved in the selected features. The feature teams then produce sequence diagrams for the features they have been assigned. Based on these diagrams the domain experts refine object models defined in the first step (Westfall 2009). Each feature team then proceeds to write the class, methods associated with the class and hold design inspections.
In the fifth step as the name suggests the actual software to accomplish the task of a specific feature is built. This includes the completion of tasks such as coding, code inspection, and unit testing (Westfall 2009). In this stage, the chief programmer will use feedback from class owners to track the promoted classes.
In so doing the chief programmer will act as the integration point between feature team and other teams working on the same iteration. After a successful iteration, the completed features of the project are made available for integration into the final build (Westfall 2009).
In the FDD development approach the fourth step namely design by feature and fifth step namely build by feature form the iterative point in the development process (Westfall 2009). During this stage of the process, multiple design teams concurrently design and build the set of features that the team leader has assigned.
The point of assessment between the design-by-feature and build-by-feature stages is the design inspection stage. It should be noted that an individual iteration should not take more than two weeks to complete. At the completion of a specific iteration, the next feature stage begins by beginning the design by feature step.
Conclusion
In this report, the discussion presented has provided some information on software development lifecycles. It begins by highlighting some of the processes that saw the development of software shift from structured traditional approaches to Agile processes. In the report two Agile approaches namely XP programming and FDD have been discussed. We observe that both approaches are incremental and develop software solutions through a series of steps.
It has also been observed that both approaches to software development rely heavily on the customer feedback. In fact XP programming requires that where possible the customer be a part of the development team to provide constant feedback as the project progresses. The same can be said of FDD where the customer feedback is used to repeat the design and implementation of requirements.
However, there are some differences between the approaches such as the fact that FDD is a combination of Agile and traditional approaches to software development. It has been observed that in XP a software project is developed after holding a face-to-face meeting with the customer to establish objectives. XP programming allows the programmers freedom to begin coding specific features based on the customer requirements.
However, in FDD there is a more structured approach to the development process requiring an establishment of objectives, creation of a feature list, and the creation of plan based on features. This approach unlike XP suggests that more time is spent on planning before actual coding work can begin.
Another difference can be traced to the point of iteration in the two approaches. Upon completion of coding a specific feature in XP programming, the programmer and customer test the product and identify potential areas that require attention. However, in FDD at the point of iteration, it is required that before proceeding further the development team again goes through the design stage before development. Based on this it would appear that of the two approaches XP programming will take less time in completing a software development task.
References
Everett, GD, and McLeod, R 2007, Software testing: testing across the entire software development lifecycle, John Wiley & Sons Inc, Hoboken.
Haugan, GT 2011, Project Management Fundamentals: Key Concepts and Methodology, Management Concepts Inc, Virginia.
Jeffries, R, Anderson, A and Hendrickson, C 2001, Extreme programming installed, Addison-Wesley, Upper Saddle River.
Leffingwell, D. and Widrig, D. 2010, Agile software requirements: Lean requirements for teams, programs, and the enterprise, Pearson Education Inc., Boston.
Westfall, L 2009, The certified software quality engineer handbook, American Society for Quality, Quality Press, Milwaukee.