Comparison of Software Development Methodologies based on the SWEBOK by El´ısio Maciel Sim~ao Supervisor PhD. Jo~aoMiguel Fernandes October 27, 2011 Contents List of Figures iii List of Tablesv Acronyms viii 1 Introduction1 1.1 Context . .1 1.2 Goals . .2 1.3 Structure of the Document . .2 1.4 Terms Elucidation . .3 2 State of Art5 2.1 Software Engineering . .5 2.2 Brief History of SDM . .6 2.3 Software Qualities . .7 2.3.1 Correctness . .8 2.3.2 Reliability . .9 2.3.3 Robustness . 10 2.3.4 Performance . 10 2.3.5 User Friendliness/Usability . 11 2.3.6 Verifiability . 12 2.3.7 Maintainability . 12 2.3.8 Re-usability . 13 2.3.9 Interoperability . 13 2.3.10 Productivity . 14 2.4 Knowledge Areas in Software Engineering . 14 2.4.1 Software Requirements . 15 2.4.2 Software Design . 18 2.4.3 Software Construction . 22 2.4.4 Software Testing . 23 i 2.4.5 Software Maintenance . 27 2.4.6 Software Configuration Management (SCM) . 30 2.4.7 Software Engineering Management . 32 2.4.8 Software Engineering Process . 34 2.4.9 Software Engineering Tools and Methods . 35 2.4.10 Software Quality . 36 3 SDM Descriptions 38 3.1 Software Development Methodologies . 38 3.2 Traditional Development Methodologies . 39 3.2.1 Waterfall Methodologies . 39 3.2.2 Transformation Methodologies . 44 3.3 Evolutionary Methodologies . 45 3.3.1 The Win-Win Approach . 45 3.3.2 Spiral Methodologies . 48 3.4 Rapid Application Development . 51 3.4.1 Changing Plans . 51 3.4.2 RAD . 51 3.5 Agile Development Methodologies . 56 3.5.1 Agile Manifesto . 56 3.5.2 Scrum . 58 3.5.3 eXtreme Programming . 64 4 Results 70 4.1 Method . 70 4.2 Waterfall . 71 4.3 Spiral . 75 4.4 Rapid Application Development . 79 4.5 Scrum . 83 4.6 eXtreme Programming . 87 5 Conclusions and further work 92 5.1 Conclusions . 92 5.2 Further Work . 94 Bibliography 99 ii List of Figures 3.1 The waterfall model . 40 3.2 Spiral Model, Boehm,1988 (CC) . 49 3.3 Rapid Application Development . 54 3.4 The Scrum Sprint [1]......................... 62 3.5 The Scrum Life Cycle [1]....................... 63 3.6 The Extreme Programming Life Cycle [1]............. 69 4.1 Waterfall: SoftwareKA satisfaction bar chart . 75 4.2 Spiral: SoftwareKA satisfaction bar chart . 79 4.3 RAD: SoftwareKA satisfaction bar chart . 83 4.4 Scrum: SoftwareKA satisfaction bar chart . 87 4.5 XP: SoftwareKA satisfaction bar chart . 91 iii List of Tables 3.1 Top-Down and Bottom-Up Strategies . 49 3.2 Risk in software projects . 49 3.3 Agile Manifesto . 56 3.4 The Twelve principles behind the Agile Manifesto . 57 3.5 Pig and Chicken roles: the joke . 59 4.1 Waterfall: Software Requirements, Software Design and Software ConstructionKA........................... 72 4.2 Waterfall: Software Testing, Software Maintenance and Software Configuration ManagementKA................... 73 4.3 Waterfall: Software Engineering Management, Software Engi- neering Process and Software QualityKA............. 74 4.4 Spiral: Software Requirements, Software Design and Software ConstructionKA........................... 76 4.5 Spiral: Software Testing, Software Maintenance and Software Configuration ManagementKA................... 77 4.6 Spiral: Software Engineering Management, Software Engineering Process and Software QualityKA.................. 78 4.7 RAD: Software Requirements, Software Design and Software Con- structionKA............................. 80 4.8 RAD: Software Testing, Software Maintenance and Software Con- figuration ManagementKA..................... 81 4.9 RAD: Software Engineering Management, Software Engineering Process and Software QualityKA.................. 82 4.10 Scrum: Software Requirements, Software Design and Software ConstructionKA........................... 84 4.11 Scrum: Software Testing, Software Maintenance and Software Configuration ManagementKA................... 85 4.12 Scrum: Software Engineering Management, Software Engineering Process and Software QualityKA.................. 86 iv 4.13 XP: Software Requirements, Software Design and Software Con- structionKA............................. 88 4.14 XP: Software Testing, Software Maintenance and Software Con- figuration ManagementKA..................... 89 4.15 XP: Software Engineering Management, Software Engineering Process and Software QualityKA.................. 90 v Agradecimentos Gostaria de agradecer ao meu orientador o Prof. Doutor Jo~aoMiguel Fernandes pela paci^enciae cr´ıticaconstrutiva dada durante a execu¸c~aodeste documento realizado em simult^aneocom uma actividade profissional intensa o que aumen- tou ainda mais o desafio para mim e para ele. Gostaria tamb´emde agradecer `aminha fam´ılia(M~ae,Pai e Irm~ao)pelo apoio incondicional dado que reflecte o verdadeiro conceito de fam´ıliae que promove o que de melhor h´aem mim. Finalmente `aLiliana, por ser uma companheira de vida, e por estar sempre pre- sente nos bons e maus momentos tanto para criticar quer para motivar, quando ´epreciso. Obrigado! vi Abstract We are facing a period where software projects have a huge dimension involving small resources, high risk and a wide range of available approaches. In this scenario the Software Development Methodologies (SDMs) can prove to be a useful ally, but very dangerous and even fatal if misused. The big issue around this matter is how to choose the appropriated SDM that fits a specific project. In the given scope, this dissertation describes a framework for comparing SDMs delivering a set of procedures that should be followed when the choice of an SDM is made. The dissertation approaches the framework by applying it to a group of SDMs that were selected by their popularity and significance. This exercise is done to prove the concept of the framework and to provide a base comparison, with each chosen SDM, that can, and should, be extended by those who choose to use the framework. The classification is achieved by defining a scale that goes from total satisfaction to no satisfaction, with an intermediate level of partial satisfaction, that is ap- plied to a set of keys. These keys are based in SWEBOK (Software Engineering Body Of Knowledge) that describes and explains the different Knowledge Areas (KA) stating their common issues and best practices. To explain the frame- work, the dissertation analyzes eachKA and evaluates the selected SDMs by assessing how their approach complies with SWEBOK's knowledge areas, using the previous stated scale. The framework delivered can be enriched by its user who should provide weights to eachKA regarding the project in which the SDM will be used and previous experiences. vii Resumo Actualmente atravessamos um per´ıodo em que os projectos de software t^emuma grande dimens~ao,envolvendo baixos recursos, alto risco e com um variado leque de abordagens a escolher. Nestes casos as Metodologias de Desenvolvimento de Software (MDS) pode ser um bom aliado, contudo se mal escolhido pode ser extremamente perigoso ou at´efatal. A quest~aoque se levanta ent~ao´e,qual a metodologia a escolher. Neste contexto, este documento descreve um conjunto de procedimentos a seguir para comparar MDS. Os procedimentos s~aoent~aoaplicados a um conjunto de populares MDS provando o conceito aqui apresentado, disponibilizando uma compara¸c~aode base com uma explica¸c~aopara cada metodologia escolhida que pode, e deve, ser estendida por quem utilizar o conjunto de procedimentos aqui descritos. A classifica¸c~ao´econseguida atrav´esde uma escala que vai da satisfa¸c~aototal `a n~aosatisfa¸c~ao,com um n´ıvel interm´ediode satisfa¸c~aoparcial, para cada uma das chaves. As chaves escolhidas s~aobaseadas no SWEBOK (sigla de Soft- ware Engineering Body of Knowledge, em Portugu^es,Corpo de Conhecimento para a Engenharia de Software), que descreve e explica as diferentes ´areasde conhecimento da engenharia de software com refer^encia`asmelhores pr´aticas e problemas comuns para cada uma delas. Para o conjunto de procedimentos apresentado, cada uma das ´areasde conhecimento ´eanalisada e as MDS s~ao avaliadas de acordo com a forma como abordam cada uma das `areasde conhec- imento do SWEBOK utilizando a escala anteriormente referida. Estes procedimentos podem ser enriquecidos por quem o escolha utilizar atribuindo pesos a cada uma das ´areasde conhecimento com base no projecto a que a MDS ser´aaplicada e a experi^enciasanterirores. viii Acronyms ADM Agile Development Methodologies BDUF Big Design Up Front CASE Computer Aided Software Engineering CASL Common Framework for Algebraic Specification CMMI Capability Maturity Model Integration DSDM Dynamic systems development method FDD Feature Driven Development ITIL Information Technology Infrastructure Library KA Knowledge Area KLOC Kilo Line of Code PMBOK Project Management Body of Knowledge RAD Rapid Application Development RIPP Rapid Iterative Production Prototyping ROI Return of Investment SAGE Semi-Automated Ground Environment SCM Software Configuration Management SDLC Systems Development Life Cycle SDM Software Development Methodology SQM Software Quality Management SSADM Structured Systems Analysis and Design Methodology ix SWAT Skilled Workers With Advanced Tools SWEBOK Software Engineer Body of Knowledge TDM Traditional Development Methodologies UML Unified Modeling Language VDM Vienna Development Method XP eXtreme Programming x Chapter 1 Introduction 1.1 Context The importance of software in the world is constantly increasing, and with the increase of its importance also the size of the software systems is increasing as well as the effects of its development. These effects have consequences on the way software is developed. Software development of huge projects involves huge amounts of money and time, which have to be used in the correct way for delivering the final product with the minimal cost. With the evolution of software development, different approaches have been pre- sented and used to deliver a software product with aim of reducing time and cost of its development, without impairing the quality of the product. Each approach has its benefits and criticism but they all have similar goals, delivering a quality product in the fastest and cheapest way possible. When we look for a Software Development Methodologies (SDM) we have a set of very different perspectives, and even different approaches for the same perspectives, to choose from.