The spiral methodology, due to the prototyping technique, and the introduction of iterations and the revision in each provide a great satisfaction in the design and testing KA and a very reasonable one in software configuration manage-ment and software engineering process and managemanage-ment.
The lack of metrics and quantifications, besides the risk assessments, and the not commitment for simplicity and code verification are responsible for lower satis-faction points in software construction and software engineering management.
Also a no definition of a specific phase or activities concerning maintenance re-flected in the lower satisfaction for this methodology.
Next the tables and satisfaction bar chart for the spiral methodology are pre-sented.
Figure 3.2: Spiral: SoftwareKAsatisfaction bar chart
Table 3.4: Spiral: Software Requirements, Software Design and Software Con-structionKA
Table 3.5: Spiral: Software Testing, Software Maintenance and Software Con-figuration ManagementKA
Table 3.6: Spiral: Software Enginering Management, Software Engineering Pro-cess and Software QualityKA
3.4 Rapid Application Development
The RAD methodology with the use of tools and its management approach got a total satisfaction of the software construction KA and with the use of modelation a total satisfaction of the requirementsKA.
An insufficient concern with the testing and maintenance phase were reflected in the lowest satisfaction for this methodology. The design lacked a notation and standard definition and the methodology lacked measurements and quantifiable reviews.
Figure 3.3: RAD: SoftwareKAsatisfaction bar chart
Table 3.7: RAD: Software Requirements, Software Design and Software Con-structionKA
Table 3.8: RAD: Software Testing, Software Maintenance and Software Config-uration ManagementKA
Table 3.9: RAD: Software Enginering Management, Software Engineering Pro-cess and Software QualityKA
3.5 Scrum
The Scrum methodology due to its role distribution and with the use of arte-facts such as backlogs and burn-down charts was the only methodology to fully satisfy the software engineering management and software engineering process KA(although eXtreme programming also fulfilled the software engineering pro-cess).
Scrum approach on maintenance as another iteration of the process and the lack of effort on minimizing the complexity reflected in the lowest satisfaction for this methodology on software construction and maintenances KA. The tables and bar chart satisfaction for the Scrum methodology are stated below.
Figure 3.4: Scrum: Software KAsatisfaction bar chart
Table 3.10: Scrum: Software Requirements, Software Design and Software Con-structionKA
Table 3.11: Scrum: Software Testing, Software Maintenance and Software Con-figuration ManagementKA
Table 3.12: Scrum: Software Enginering Management, Software Engineering Process and Software QualityKA
3.6 eXtreme Programming
A dedicated phase to maintenance, and a concern with activities that extend the development issues, as the philosophy stating the principles of simplicity, a very detailed review and roles reflecting those principle turned into eXtreme Programming being the only methodology to totally satisfy the software main-tenance and software construction KA. Adding the roles of tester and tracker the proper Software Configuration Management was also only fully satisfied by this methodology.
It was also interesting noticing that one of the main critics to this methodology being the design process, it was also, together with software engineering manage-ment and process KA, the lowest satisfiedKAfor this methodology. Although getting a very high satisfaction on all of them. The fact of not considering the different levels of design and not providing the measures or assessments of the procedures and process was the reason for those satisfaction levels.
More detailed descriptions for each sub-KAcan be found in the tables and bar charts for this methodology that are now presented.
Figure 3.5: XP: SoftwareKAsatisfaction bar chart
Table 3.13: XP: Software Requirements, Software Design and Software Con-structionKA
Table 3.14: XP: Software Testing, Software Maintenance and Software Config-uration ManagementKA
Table 3.15: XP: Software Enginering Management, Software Engineering Pro-cess and Software QualityKA
Conclusions and further work
4.1 Conclusions
The work performed during this thesis, was very useful to my self in concerns of academic and professional aspects. While my base formation is in Mathemat-ics and Computer Science, even though some of the topMathemat-ics addressed here were visited during my degree, it was never deeply extended. Also my professional activity, as working in IT consulting projects the topics studied here provide to consolidate some of the empirical knowledge gained in a yet short career.
When concerning the results, and when confronting to critics and similar works was interesting to find out that most of the results were similar, even though different approaches have been taken. The results seem to point that when considering the software engineering process and management the more modern methodologies satisfy thisKAwithout disregarding theKAthat theTDMwere mainly concerned with. Although the main critic pointed to the ADM is that they should work in theory but when actual implementations of the method-ologies tend to fall into a great concern into those the way the activities are performed disregarding that the actual activities will fall into chaos and that the final product can be delivered with several problems. Translating into the terminology of this thesis, regarding more theKA dedicated to software engi-neering process and management but failing into correctly outputting the needs addressed by the KA of software construction, requirements, design and test-ing. This kind of critic it cannot be supported or declined by the work done in this thesis, for proving the work done here and to clarify some of the doubts and opinions addressed by the different authors an statistical work, trying to
assess and to ask for input over different projects using different methodologies, should be done as a support to this thesis. Of course as was stated previously, this work should be done, taking in consideration the specific constraints of the project, team and stakeholders involved.
Another important aspect when reviewing the work done in this document is to address the subjectivity of the results. The analysis is performed by a person, who carries opinions, experiences and interpretations, although and effort on minimizing this by trying to provide factual verifications and analysis was done.
When reviewing this work and confronting to similar works, even though with different approaches, scopes and goals, was good to verify that the results, even that they differ in the metric, they tend to be similar in the overview (the main goal of this thesis) given for the sameKA/SDM.
In concern of the range and extension of the analysis, because the work is within a thesis with a purpose of achieving a master degree with deadlines, size limi-tations and the fact that the thesis has been done in parallel with an intensive professional activity, limited the quantity ofSDManalysed and the extensions of theSDMandKAdescriptions/definitions. In overall, the necessary description of the SDM and KA was provided to understand the results and its justifica-tions. When regarding the extension an intentional confront between different approaches ofSDM(TDMandADM) with the inclusion of a methodology that would not fit into neither of the group representing the link between them, of course some very popularADMcould also be described (e.g. DSDM(Dynamic systems development method), FDD (Feature Driven Development) or Agile Modeling), but the popularity factor of Scrum and eXtrememe Programming was chosen among other factors. The confrontation ofTDM/ADMwas/is very common in several papers, forums, books and other ways of communication within the software engineering community. Other confrontations, more mod-ern, such as an increase of discussion between the lean software development methodologies and agile development methodologies could be addressed, but for the same reasons stated above it was not done.
When referring to the software qualities relationship with theSDM, being also derived from the constraints stated previously, would also require a different approach, because it would be very risky and probably wrong to try to asset a software quality from a definition or description of aSDM. A more empirical ap-proach that could be performed together with the statistical proving, mentioned previously in this chapter. Another interesting addition to this work, providing a more complete overview of theSDMwas to analysed from the project manage-ment point a view, performing an analogous work with the PMBOK(Project Management Body of Knowledge).
The goal of providing an software engineering overview of theSDMwas achieved
with the constraints already stated, providing an good aid when choosing a methodology for a certain project and with certain aspects of its development in mind.
When looking back at the goals of this thesis and giving it an corporate con-text for the work performed we can retrieve from this paper, now only a way of proceeding when choosing anSDM (i.e. using the same framework for a set of SDM and then based on the results and the characteristics of the software project choose theSDMthat fits those characteristics), but also a base work for further analysis, such as extending the SDMfor a bigger set. For that matter, even though this paper has academical purposes, can be useful for my (and the companies I’m involved with) professional activity to guide the choice to an SDMfor a certain project, and to incorporate the framework as a standard when starting a project. This work can also be extended considering thePMBOKand giving the missing link between theSDM and the software quality obtained in the project. Answering the answer which software qualities are better assured with a certainSDM. So no only it was an intensive research, studying different topics on Software Engineering, analysing theKAandSDM, but is a work that can be directly applied in professional activities and has a potential for exten-sion and further works. When comparing the results with some problems with experienced software project managers had through the years, was a good indi-cator, but also gave the idea to incorporate statistical or stochastic analysis of SDM which could be an enhance the framework and when used with a backlog can indicate tendencies between staff members, augmenting the potential of the framework, even though it has to be done with caution, remembering that one of the goals of the framework was to be the non-subjective.
In conclusion, the work performed during this thesis was rewarding in different aspects and I intend to develop further the analysis performed and actively use the results obtained in this thesis.
[1] P. Abrahamsson, J. Ronkainen, and J. Warsta. Agile development methods - review and analysis. Technical report, University of Oulu, 2002.
[2] D. E. Avison and G. Fitzgerald. Information Systems Development:
Methodologies, Techniques, and Tools. McGraw-Hill Higher Education, 2nd edition, 1998.
[3] V. R. Basili. Quantitative evaluation of software methodology. Technical report, Deparment of Computer Science, University of Maryland, 1985.
www.cs.umd.edu/~basili/publications/proceedings/P29.pdf. [4] V. R. Basili and R. R. JR. A controlled experiment quantitatively
com-paring software development approaches. IEEE Transactions on Software Engeneering, VOL. SE-7(NO. 3), May 1981. http://www.cs.umd.edu/
~basili/publications/journals/J10.pdf.
[5] K. Beck. Extreme Programming Explained: Embrace Change. Addison-Wesley Professional, 2nd edition, 2005.
[6] B. Boehm. A spiral model of software development and enhancement. 1988.
[7] B. Boehm. Tutorial on software risk management. 1989.
[8] F. P. Brooks. No silver bullet. Proceedings of the IFIP Tenth World Com-puting Conference, 1986.
[9] Common framework for algebraic specification.http://www.informatik.
uni-bremen.de/cofi/wiki/index.php/CoFI.
[10] E. Comer. Alternative software life cycle models. 1997.
[11] E. Dijkstra. The humble programmer. ACM Turing Lecture.
[12] E. W. Dijkstra. Notes on structured programming. Technical report, Tech-nological University Eindhoven,The Netherlands, 1969. http://www.cs.
utexas.edu/users/EWD/ewd02xx/EWD249.PDF.
[13] W. R. Duncan, editor. Guide to Project Management Body of Knowledge.
Project Management Institute - Standards Committee, 1996.
[14] C. Ghezzi, M. Jazayero, and D. Mandrioli. Fundamentals of Software En-gineering. Prentice-Hall International Editions, 1991.
[15] K. Gilb. EVO - Evolutionary Management and Product Developement.
2007.
[16] T. Gilb. Principles Of Software Engineering Management. Addison-Wesley, 1988.
[17] IEEE, editor. Guide to Software Engineering Body of Knowledge. IEEE Computer Society - Professional Practices Committee, 2004.
[18] F. P. B. Jr. The Mythical Man-Month: Essays on Software Engineering.
Addison-Wesley, 1995.
[19] S. H. Kan. Metrics and models in software quality engineering. Pearson Education, 2nd edition, 2009.
[20] J. M. Kerr and R. Hunter. Inside RAD: How to Build a Fully Functional Computer System in 90 Days or Less. McGraw-Hill, 1994.
[21] R. Klopper, S. Gruner, and D. G. Kourie. Assessment of a framework to compare software development methodologies. 2007.
[22] H. Kniber. Scrum and XP from the trenches - How we do Scrum. In-foQ - Enterprise Software Development Series, 1999. http://infoq.com/
minibooks/scrum-xpfrom-the-trenches.
[23] C. Larman. Agile and iterative development: a manager’s guide. Addison-Wesley Professional, 2004.
[24] N. Leveson. Medical devices: The therac-25. Appendix of: Safeware:
System Safety and Computers.
[25] J. Martin. Information Engineering: Desing and Construction. Prentice-Hall, 1990.
[26] J. Martin. Rapid Application Development. Prentice-Hall, 1991.
[27] L. Meertens. Category theory for program construction by calculation.
1995.
[28] J. N. Oliveira. Especifica¸c˜ao e desenvolvimento formal de programas. 1995.
[29] D. Parnas and D. Weiss. Active design reviews: principles and practices.
1987.
[30] B. Randell. The 1968/69 nato software engineering reports.
http://homepages.cs.ncl.ac.uk/brian.randell/NATO/NATOReports/
index.html.
[31] K. Schwaber. Scrum guide. 2009.
[32] K. Schwaber and M. Beedle. Agile Software Development with Scrum.
Prentice Hall, 2001.
[33] Ken schwaber google talks. http://video.google.com/videoplay?
docid=-7230144396191025011.
[34] H. G. Sol. A feature analysis of information systems design methodologies:
Methodological considerations.
[35] X. Song and L. J. Osterweil. Toward objective, systematic design-method comparisons. 1992.
[36] R. Sorensen. A comparison of software development methodologies.
[37] M. Stephens and D. Rosenberg. Extreme Programming Refactored: The Case Against XP (Paperback). 2003.
[38] V. subscribers. Agile manifesto, 2001. http://agilemanifesto.org.
[39] H. Takeuchi and I. Nonaka. The new new product development game. Jan 1986.
[40] Unified modeling language. http://www.uml.org.
[41] Vienna development method. http://www.vdmtools.jp/en/.