The software development methods are usually perceived to be composed of various practices set for software development whose creation is attributed to practitioners who are experienced. In these methods, there is a clear prove of their break from the traditional methods in which the emphasis has been an approach based on rationalized engineering (Qumer & Henderson, 2006) based on which the problems are claimed to be specifiable on full basis. This article provides a comprehensive methodology of agile software development through an approach which comprehensively handles various stages. The first stage offers a comprehensive overview of the introduction to the SDLC. The second section provides the agile software development methodology followed with the Scrum methodology.
SDLC
Software Development Life Cycle (SDLC) is basically a systems development structured approach whose onset is the system developing planning phase right through the system support once there is implementation and the system is functional. This process involves various steps together with tasks that can be followed by the system developers in ensuring that the system is built in a faster rate through utilizing minimal costs together with ensuring that the chances of risks are minimized as much as possible. The steps that are involved in the System Development Lifecycle are summarized below:
Preliminary investigation:
This is the project investigation initial step with the objective which is usually geared towards identification of the system that is required, what is to be included as the broad scope, the time, the costs together with other resources that are required. After the collection of information which is broad and tentative, there is the decision making which determines whether the system development process is going to proceed or not.
Feasibility study:
This step is highlighted as critical with an aim of ensuring that the organization will be benefited by the computer system. This stage usually involves the investigation of the economic, social and technical feasibility by the technical team which is followed by preparation of a report of feasibility study. In this report, there is a recommendation to the management on whether or not to undertake the project. Therefore this feasibility study acts as a basis through which the way forward is determined coupled with providing information that is sufficient through which the decision is to be qualified.
The design of the system:
This stage is actually aimed at development of the whole architectural process high level design, which is inclusive of the software, hardware, procedures as well as the interfaces. This step will require sufficiency in the details degree in order to ensure that the management is able to make a decision on whether the requirements of the user are to be met and if this requirement s of the user is to be met, it is also at this step where the evaluation will be done to establish if the process is in accordance with the plan and strategies of the company. The various techniques and tools that can be used and which ensure high design level are; project planning and scheduling, high level flowcharts software together with the high level diagrams of data flow.
Detailed design:
This is the stage which involves drawing the details for the software. This will involve producing each detail of the procedure of the software, together with the controls and the databases. This stage will have various outcomes which will include; flowcharts of the software that are detailed, data flow diagrams that are detailed, relationship diagram of the entity for the design of the database and pseudocode that are structured, report and screen design together with a document containing detailed specification of the program.
Development:
This phase is actually marked as the most intensive in the project and it is at this stage that a maximum number of people are involved directly with the project. This is the step which involves writing and testing of the programs, together with the documentation of the procedures and preparation of a system document. This phase may also involve commencement of the user personnel training.
Implementation:
This is what is also commonly referred to as the phase of deployment or installation phase. This phase involve installation and deployment of the system that has been newly built. This step can involve use of various techniques to ensure that the system that is existing (may be a manual or computerized system) is replaced and transformed into a databases of a new system. This is followed by conducting of final test on the system to ensure that the higher management and the users are satisfied.
Maintenance:
At this phase, the users use the system in the organization. The commencement of this step is implemented after the system deployment has been completed until the retirement of the system. After the system has been deployed, it is usually used on continuous basis until the management makes the decision of retiring the solution. This can be after several years. The reason for this phase being referred to as maintenance is because it is during this phase that is characterized by frequent changes in the requirements of the users and the policies of the company together with the system having to be introduced to these changes. At times, there may be a few problems or bugs in the system which may be discovered and raise the need for fixation, together with sometimes new procedures and technologies having to be introduced.
The review of the post implementation is where the maintenance usually starts; a phase during which the system performance audit is usually done, and as soon as there has been deployment, there is implementation of the audit. The main purpose of this step is actually to ensure that the system standards are in accordance with all the requirements coupled with meeting the user’s expectations. The problems are usually fixed as soon as their discovery. After the review of the post implementation, what follows is the commencement of the use of the software. This is usually characterized by regular IT audit which will be carried out during the useful life of the system in order to make an evaluation of its performance. This is what is commonly referred to as the system monitoring. In case of any requirement of this system use at any time during the lifetime of the system, this will call for the repetition of the SDLC cycle.
During the application system SDLC, there are various risks which are likely to be experienced. These risks are inclusive of the adoption of application system in the SDLC that are not appropriate, control that is not adequate to the process of the SDLC, the possibility of the application system not being able to meet the objectives and requirements of the user, the problem of management support, project management that is not adequate, architecture and technology incorporation that is not appropriate, variation in the scope, overruns in costs and time, application system with quality that is not adequate, lack of sufficient attention to the controls and security, failure to meet the criteria of performance, together with lack of adequate adherence to the SDLC that is chosen. Other risks that may arise during the SDLC are failure to fully focus on the other processes and applications interdependencies together with lack of sufficient planning for the cutover and conversion of the data.
During the feasibility study, there are various participants that are usually involved. These will be inclusive of the team to conduct the feasibility study, the steering committee, the programmer, the engineers to be involved with quality assurance, the support staff and auditors in the IT.
AGILE SOFTWARE DEVELOPMENT METHODOLOGY
In the agile development methodology, iterations are usually embraced. This will be enhanced by small teams working together with the stakeholders in the process of defining the concepts proof, quick prototypes or other visual methods through which the problem to be solved is going to be described. The requirements for the iterations are defined by the team coupled with the development of the code together with definition and running the tests scripts that are integrated. This is followed by the verification of the results by the users. Briefly, this is what this methodology revolves about. Earlier in the process of development, there is verification which ensures that the requirements are fine-tuned by the stakeholders at the stage at which they can still be easily changed.
The simple set of rules and practices are incorporated through which transparency, adaptation and inspection is encompassed in the Scrum, with these requirements being inherent in the control empirical process. In project management, this process is iterative incremental which is used in software development involving inspection and adaptation on frequent basis, following the methodology of Agile software development. Through the leadership philosophy in Agile software development, teamwork is encouraged together with accountability and self-organization; the best practices on the engineers set through which high quality software rapid delivery is allowed together with being a business approach through which the development is aligned with the needs of the customer and goals of the company.
Adopting the agile process requires the development team being with the soft skills, which are also referred to as the people- skills. More values are usually placed on the talented individuals’ interaction over the tools and process. The proscriptive methodology key themes are the tools and the process. In the agile methods, the team members are required to poses communication skills that are appropriate in order to enable there to be collaboration in a situation of the team and the customers together with having talent and friendly approach through which it can be possible to relate well with others (Cockburn & Highsmith, 2001). The traits of the agile team member are listed by Pressman (2004) to be inclusive of; common focus, competence, ability of decision making, collaboration, respect and mutual trust together with the ability of solving fuzzy problems. This provides an important move away from the skills that are technical using the prescriptive methodology for any team member.
Two agile software methodologies are used. The methodologies are based on the philosophy of agile and are Scrum and XP. Based on the particulars, these methods usually differ, but however, the iterative approach that has been highlighted above is usually shared.
XP
The term XP is usually used to denote Extreme Programming. The concentration of the XP is based on the development and not on the software projects managerial aspect. The commencement of the XP project is usually marked by the planning phase release, which is usually followed by various iterations; with each of the iterations concluding with the testing of the user acceptance. Once there are enough features in the product through which the users can be satisfied, the iteration is terminated by the team followed afterwards by the software release.
The ser stories are usually written to the users with an aim of describing the need that is going to be fulfilled by the software (Henrik, 2007). Through the user stories, it is possible for the team to make an estimation of the resources and time that is required to enhance building and definition of the user acceptance tests. Actually, the representative or the user is usually marked as part of the team of XP, therefore giving them the ability to add the details to the requirement in the process of building the software. Through this process, it is possible for the evolution of the requirements based on the fact that the developers and the users are able to make a clear definition of the look of the product.
In order for the release plan to be created, the development tasks are broken by the team into iterations. The iteration plan is defined by the release plan, through which the development is driven for iteration. At the iteration end, the acceptance tests are performed by the users against the user stories. In case the bugs are found, the nest iteration incorporates the bugs as a step. Theoretically, the iterative testing of the user acceptance can result in the software release. In case of the decision by the user that there has been delivery of enough stories, a choice can be made by the team to have the project terminated before the implementation of the entire user stories that were planned originally.
The simplified XP version is shown in the figure below. In full XP’s many plans are included in the release planning, acceptance testing and iteration.
There are various XP rules and concepts that are usually market as important in this methodology. At least once every day, the changes must be integrated in the development base line by the development teams. This results to what is usually referred to as the concept of continuous integration. There is also the concept of project velocity which offers measurement of the progress of the work in the project. Through metric which is marked as important, the updates scheduling is enhanced together with driving the release planning. Another concept is that of pair programming based on which, it is clearly highlighted that the release of the production is created by two people whose work is based on one computer. The proposition of the XP is that through the working together of two coders, it will be possible to enhance satisfaction of the user stories at a rate that is similar to individual working by two coders, together with guaranteeing quality that is much higher.
In the XP methodology, the user story enhances description of the problems which the system being built will be able to solve. The writing of these stories must be done by the user and the length should be about three sentences. The solution is usually not described in the user story but technical language is usually used.
Scrum
The origin of the Scrum software development is traced out of the rapid community of prototyping based on the fact that there was need for a methodology through which there would be support to the environment not only characterized with inadequacy but also being exposed to rapid changes during the development (Schwaber, 2004). In the scrum methodology, there are both the development and management processes.
Scrum management:
At each of the Scrum project center, there is a work backlog which requires to be done. During the release phase of planning, there is characterization of the backlog as being populated coupled with defining the release scope. After the completion of the high level design and project scope by the team, the development process is divided into sprints; which are short iteration series. With each of the sprints, the aim is implementation of blog items which are fixed in number. There is identification of the backlog items by the team members before each sprint. At each sprint end, there is review of the sprint with an aim of articulating the lessons that are learned together with checking the progress.
During the sprint, there is a daily meeting by the team which is referred to as the scrum. The work that is to be done that day is described by each of the team members, the previous day progress together with any blocks that may require clearing. In order for the meeting to be kept short, conducting of the scrum must be when everyone is in the room. Once there has been implementation of enough backlogs to an extent that there is conviction in the team that there is justification of the release being put into production, the development is closed by the management. Integration testing is performed by the team, followed by documentation together with the training which is required for the release of the product.
Scrum development:
In the process of Scrum development, the concentration will actually be on the sprints management. Before the commencement of each sprint, there is planning by the team, coupled with identification of the backlog items and teams assignment to these items. Each of the backlog items is developed, wrapped, reviewed together with being adjusted by the teams.
During the development, the changes that are necessary are determined by the team to ensure that the backlog item is implemented. This is followed by writing the code, testing it and documenting the changes. The review is characterized by the team demonstrating the new features, assessing the risk and adding new backlog items, the data is finally consolidated by the team from the review in order for the changes that are necessary to be updated.
Following each sprint, the progress is demonstrated by the entire team from the spring followed by reviewing the progress of the backlog. The remaining backlog is then reviewed by the team followed by the adding, removing and reprioritizing the necessary items in order for new information to be accounted for.
The scrum methodology incorporates various concepts. One of such concepts is the burndown chart. The updating of this chart is done on daily basis and through this updating; it is possible to show the work that remains within the sprint. The burndown chart enhances tracking of the progress of the sprint together with deciding when the removal of the items from the sprint backlog will be necessary and next sprint deferring. There is also the product backlog which provides the requirements complete list; which is inclusive of the enhancement requests, the bugs and the performance improvements that the product release does not currently contain.
In addition there is the ScrumMaster who is the person that has the responsibility of managing the project of Scrum. The ScrumMaster sometimes refers to the certified person, enhanced through training in order to take the ScrumMaster. This process also involves the sprint backlog which contains the items list which is allocated to the sprint although it is not yet complete. The common practice does not provide for a sprint item taking two days before completion. Through the sprint backlog, the team is able to make a prediction of the level of effort that is needed for the completion of the Splint.
The agile software development has the positive and the negative sides. Through the agile process, the unpredictable world challenge is addressed through a reliance on the creativity instead of the process. As Erickson et al (2005) note, the agile software development is geared at change and feedback and the development of the methodology is aimed at embracing rather than rejecting the rate of change which is higher. Leanness and flexibility is what Conboy and Fitzgerald (2004) uses in the description of the agile development methodology.
This methodology is also noted by Conboy and Fitzgerald (2004) as enhancing high quality development of software by the small teams through the use of constant enhancement and testing principle on the basis of change and rapid feedback. Sighting the agile software development as having some negative sides, Schwaber (1995) insists on the need for conductive improvement within the team. Schwaber (1995) adds that although an adaptation of iterative process is suggested by many methodologies, there is lack of clear and specific procedure through which such activities can be conducted.
Other shortcomings that have been identified are lack of effective involvement of the customer and difference in the personality among the individuals resulting in barriers in formation of a team that is effective. In addition, it is difficult to prioritize on the requirements for the systems that are large and which have many stakeholders (Sommerville, 2004).
SCRUM METHODOLOGY
The onset of the Scrum process is marked with the creation of the product backlog. The backlog is usually a system requirement expressed as a product backlog items prioritized list. The software development team is then handed over the prioritized list in order for them to develop the time line for the product development which is actually negotiable. After the approval of the product backlog by both the client and the developers, the next step marks the onset to the process creating the Sprint Backlog.
Basically, a sprint is work iteration, with a period which is usually 15 days, and during this period, there is implementation of the product functionality increment. The work for the Sprint is usually defined by the sprint backlog where there is the movement of the backlog items into the spring from the product backlog; based on the priorities of the owner. At the onset of the sprint, there is a one day meeting for sprint planning. This is followed by a sprint review meeting at the end of the sprint, after which the retrogressive meeting follows.
The next stage involves the sprint planning meeting which triggers negotiation between the owner of the product and the team about what is going to be done by the team in the next sprint. After every fifteen days, the release of the intermediate product gives the clients and team a product development perspective. The release usually provides a transition of a possibly shippable product increase, from the teams that are involved with the development to the customers for routine use. The release is typically done when the product has resulted from the sprints with enough value through which the deployment costs can be outweighed.
Conclusion
From the argument approach that is developed in this paper, it is clear that the tailoring of a scrum is usually done to a specific environment, therefore it may not be easy to argue over the practice that can be perceived as the best. The approaches used will always differ. This article has provided an evaluation to the methodology of agile software development. It has also highlighted the various pros and cons of agile software development which needs to be addressed. In light to these cons, there is need for the agile teams to be equipped with appropriate information level which can help them in making decisions that are rational and informed to enhance optimal business value development. In addition, there is need to ensure that refining and updating is done on the guiding vision model in accordance with the requirements.
Scrum has been highlighted as an incremental framework that is iterative, for the product development of application. The sprints are the work cycles which the development is structured into, with these iterations being highlighted to be not more than a month old each, and occurrences being on their own pause. This article is proving that agile is the latest approach which has replaced the previous waterfall approach and in the future, it will also evolve and change.
