Software Development Process Selection Approaches

The Journal of Applied Science Vol. 11 No. Vol. 2:45-50 11 No. 2 [2012] ISSN 1513-7805 Printed in Thailand Review Article Software Development Process Selection Approaches Phongphan Danphitsanuphan Department of Computer and Information Science King Mongkut's University of Technology, North Bangkok Email address: phongphand@kmutnb.ac.th Abstract In the world of software development, there are 2 main software process categories which are the Plan driven model and the Agility model. For decades, there have been many arguments about the advantages/disadvantages regarding these models and how to select the right set of processes for each particular software project. In 21th century, Hybrid model which is the combination of the Plan-driven and the Agility has emerged to cope with larger size and more complex software projects. However, there is still no silver bullet solution for software development as a whole when attempting to acquire good product quality and performance with a limited budget and timeframe. Keywords: Software process selection, Plan driven model, Agility Model, CMMI Plan driven model This model emphasizes a predefined solid set of software development procedures which pose questions such as what, when, how and who for each development step. Examples of the Plan driven model are Waterfall, CMMI, Rational development and TSP. Waterfall and CMMI are very popular in the software industry. Waterfall model, which originated in 1970s, is one of the oldest software development models and it engineers software like hardware machine. It is considered the simplest model of it kind. It is necessary for practitioners to proceed the following phases in a fix order. These steps consist of Requirement, Design, Coding, Integration testing, System testing, User acceptant testing and Operation & Maintenance as shown in figure 1. Figure 1: Water fall model [http:// www.cse.lehigh.edu ] 45

This model is suitable for small, less-complex software projects that have clear requirement. It does not recommend each step to be reversed when fixing or making change to pieces of software once it has already been completed. This strategy encourages users to carefully consider what they are doing at each step thus ensuring a lot less defects when it comes to the finish product. Prior to the system design project, the project manager can plan the schedule and estimate the size of the team along with finalizing the resources in term of cost and time. Nevertheless, what if we cannot anticipate all the requirements and software specifications at the early phases of development? We might not be able to answer following questions. How much should we charge the customer? How many developers should be allocated? How long will the project last? These questions have been classic problems of this industry for decades. The embedded system (software application on hardware) is a good example to successfully implement the waterfall model since it has a solid set of specifications along with the output of each step. On the assembly line, a product cannot be rolled back to be fixed if a defect occurs. Another good example of using the waterfall model is contract-based (small & less-complex) software development due to predefined the project s scope of work, timeframe and fixed budget. Most government units around the world still draw up a contract based on Water fall model and tighten up each process with terms of payment and project deliverable items. CMMI [1] stands for Capability Maturity Model Integration, the most well-known process improvement approach of Plan driven models. CMMI believes that a set of good processes result in a high quality product even if the project size is big in terms of team members, number of delivered features, or its complexity. It looks at the software business it would any normal manufacturer. Fundamentally, CMMI does not tell the implementer how to do each process but rather it requires what needs to be done by providing a check list. A software organization must come up with its own procedures for individual step. Lots of companies can take years to acquire their own set of solid processes and rules. CMMI tends to have firm foundation before moving on to the next phase of development in the same way of the waterfall model. For example, product requirement needs to be completed and signed off by the customer before starting the design phase; architecture and design have to be mutually agreed before moving on to coding phase. This scheme will be hard if we have an ambiguous and uncompleted set of requirements at the very beginning of the project, or if requirements keep changing all the time. It is possible the customer might not know what they want until they see the final product. It is hard to decide when there has been enough reviewing of requirement and architecture improvements. If we can make this decision, we can then start coding confident that there will be less rework. Figure 2: CMMI model [http://www.cmmilevels.com/] 46

CMMI has 5 maturity levels which higher level implicates the better of product quality and the clearer of project visibility. All software companies already get level 1 by requiring nothing. Processes initiation and implementation are focused in level 2 and 3. In level 4, important statistical data, while implementing software projects in previous levels, will be recorded such as programmer performance (number of source line of code / hour), defect density rate (number of bugs), distribution time consumption per each phases. After that, these data will be analyzed to improve current software development processes of level 2 and 3 to achieve a better cost & time estimation and to optimize resource usage. CMMI uses documents as a tool to reinforce its quality processes and to transfer project knowledge which drives common understanding among project team member. The model can handle large scale of project with complication. However, about 30-40% of human effort will be used for producing and fixing documents. This extra work increases project cost and delay time to market. Agility model Once we cannot afford costly quality processes of the plan driven model and delivery time cannot be waited. Agility people believe that if we have all the best people with experiences and discipline, less documents and quality processes will be needed to acquire to build a good product. Agility is likely to use developer themselves to do knowledge transfer throughout the project and to work very closely to users. Normally, a team size is about 4-6 people. The most important set of requirements are elaborated with users and rushed to code, test and delivery to customer only as a running prototype in order to get early feedbacks and new requirements then the team will make a bigger prototype until it becomes a final software product. If requirement will be changed, the less effort will be required than plan driven model in term of documentation work. However, if the project is too big and complicated, it s hard to estimate the project duration. How much money needed to be allocated? Besides, what if a few key-mans leaves the project at the critical time? Extreme programming [2] is one of the most popular agility models. It provides set of rules and practices according to agility ideas. It believes that understandable source code with thoughtful comments can be a design document and everyone owns every piece of source code. One of the popular practices is pair programming technique which will require 2 programmers who have same level of project knowledge and skills to work together side by side. While coding by a programmer, another one will be doing real-time review a structure of the code and assist to have a better design and test at the same time; so, they can take turn all the time. Project will be finished fast, flawless and predictable if it is small and less complicated. Nevertheless, theses idea is not practical for large number of team member. In addition, the quality of the product relies on the quality of people and their compatibility. Figure 3: Extreme Programming process flow [http://www.extremeprogramming.org] 47

Model comparison Dr Boehm [3] has clearly summarized the comparison in the 4 areas to contrast between the Agility and the Plan-Driven methods as shown in table 1. Characteristics Agile Plan-driven Application Primary goals Rapid value; responding to change Predictability, stability, high assurance Size Smaller teams and projects Larger teams and projects Environment Turbulent; high change; projectfocused Stable; low-change; project/organization focused Management Customer Relations Dedicated on-site customer; focused on prioritizing incremental development As-needed customer interactions; focused on contract provisions Planning and control Internalized plan; qualitative control document plans, quantitative control Communication Tacit interpersonal knowledge Explicit documented knowledge Technical Requirement Development Testing Personal Prioritized informal stories and test cases; undergoing unforeseeable change Simple design short increments; refactoring assumed inexpensive Executable test cases define requirements Formalized project, capability, interface, quality, foreseeable evolution requirements Extensive design longer increments; refactoring assumed expensive Documented test plans and procedures Customer Dedicated, collocated CRACK* performers CRACK* performers, not always collocated Culture Comfort and empowerment via many degrees of freedom (thriving on chaos) Comfort and empowerment via framework and policies and procedures (thriving on order) * Collaborative, Representative, Authorized, Committed and Knowledgeable Table 1: the characteristic of Agility and the Plan-Driven project comparison How to select software development methodology? Regarding to Balancing Agility and Discipline, A Guide for the perplexed [4], There are 5 basic factors used to evaluate whether Agility and Plan drive model is suitable for a particular software project as depicted in figure [3]. 48

Figure 3: Example of software project profile Criticality is the first factor to be considered. If the software project concerns many lives, single life or a lot of money such as nuclear plant, air traffic control system or banking system, Plan driven model should be deployed to implement this kind of projects. On another hand, if we are doing entertainment applications like informative web-sites or games, the Agility model would be preferred to cope with uncertainties of their project nature. The second factor is a size of personal related to the project. If there are many people in the team, disciplined processes and documents of the Plan driven model can be used to promote commonly understanding throughout the project. Moreover, a skill of personal would be the third factor. Regarding to Level of Software Method Understanding and Use by Cockburn [4], If we have experienced people who are able to revised a method (break its rules) to fit an unprecedented new situation, the Agility should be good option to proceed to save time and resources; yet, a software quality is maintained by these people. In contrast, the Plan driven model would be considered if the ratio of average-and-below (less experienced) developers is more than superior developers. Fourthly, dynamism of requirements, if we implement CMMI on the project which owner doesn t know what they want, time and resources would be wasted on architecture and documentation. We would rather do the quick prototype to get customer s feedback as one of the practice in agility scheme. Lastly, in a plan-driven culture (thriving on order), the team members feel comfortable when there are clear and solid procedures that label their responsibilities. In an agile culture (thriving on chaos), person s tasks are defined by current work problems which can be various and unpredictable. Processes can be dynamically adjusted based on what suit the team member s skill set and their availability. By rating a project alone each of five axes, you can assess whether plan driven or agility model suits your project the most. If all the ratings are toward center, agility will be your choice, and vise versa. If the rating is fall in the middle between Agility and Plan driven, hybrid or mixed models should be considered. Incremental Commitment Model [5] is a good example of hybrid kind. It flexibly allows mixed practices of both approaches to address the particular problem. It emphasizes risk-driven and evident base development. People are misleading to select wrong approach all the time. Some believe that Agility does not require to do planning or any documentation. In realities, light weight processes and ground rules are needed to discipline the project team member in order to acquire the quality. Some use the Agility to develop large and complex system by using simple design and architecture due to its lightweight processes. They get very good progress at the beginning 49

of the project. Then, the unexpected difficulty occurs and the current design cannot encounter this problem. They have to throw away everything and re-design and re-code again and again. A lot of companies use CMMI as a marketing tool to win the procurement to implement comfort or noncritical software projects, such as game or entertainment web-sites, which their requirement is usually changed. Moreover, People and their mandatory skill sets are always not enough to fill-up CMMI rules. Time and money are consumed unnecessary against project progress. It has been always a classis selecting-approach problem on the contract base project since its phases of development and the term of payment are always tight up together. For example, 30% of project cost will be paid upon delivery of System and software requirement description (SSRD). More 20% will be issued for the design and test-case documents. The rest will due on User acceptant testing (UAT) and successfully deploy. Obviously, it s term of payment for Water fall model. What if the project is not suitable for the Plan-driven model? What if incremental development; such as the Spiral model, is more promising method to the project characteristic? Procurement and technical people should work and decide together on development approach; and then draw the contract and terms of payment against project character. REFERENCES [1] Software Engineering Institute. "Capability maturity Model Integration (CMMI) Version 1.1", Carnegie Mellon University, 2002. [2] Macias, F.; Holcombe, M.; Gheorghe, M. A formal experiment comparing extreme programming with traditional software constrcution Computer Science, 2003. Enc 2003. Proceedings of the Fourth Mexican International Conference of Digital Object Identifier.Mexico, 2003. [3] Barry Boehm. Software Engineering: Lifetime Contributions to Software Development, Management, and Research (Practioners) Wiley-IEEE Computer Society Pr; 1 edition. ISBN 978-0470148730, Jul 2007. [4] Barry Boehm, Richard Turner, Grady Booch, Alistair Cockburn "Balancing Agility and Discipline: A Guide for the Perplexed" Addison-Wesley USA. ISBN 978-0321186126, Aug 2003. [5] Boehm, B.; Lane, J.A. "New processes for new horizons: the incremental commitment model Software Engineering, 2010 ACM/IEEE 32 nd International Conference. Volumn 2, May 2010. 50