SAPM Overview In this lecture we review the topics we have covered - PowerPoint PPT Presentation

SAPM Overview In this lecture we review the topics we have covered this Semester Summary semester, focusing on what I consider the most important points to remember. Dr. James A. Bednar The lecture slides on each topic, coupled with the required jbednar@inf.ed.ac.uk readings as distributed in class or listed at the end of http://homepages.inf.ed.ac.uk/jbednar some lectures, contain all of the basic material required to prepare for the exam. The background readings listed on the course web page, plus experience gained during the practical assignments, will help you surpass this minimum standard. SAPM Spring 2008: Semester summary 1 SAPM Spring 2008: Semester summary 2 Project management Tools (1) You should know what projects are, and how to draw and You should know several categories of useful tools, and have some familiarity with at least one suitable tool in interpret the basic charts used in PM: Work Breakdown each category: Structure , Network diagram , and Gantt chart . You Version control (e.g. Subversion ) should also be very familiar with their limitations. Build control (e.g. make ) You should know the basic PM terms, such as critical Debuggers (e.g. gdb ) Unit/regression testing (e.g. JUnit ) path, slack, crashing. Bug/issue tracking (e.g. BugZilla ) Documentation generation (e.g. JavaDoc ) Project management (e.g. MS Project ) Integrated suites (e.g. RUP ) Web : See tools.html on the course web page SAPM Spring 2008: Semester summary 3 SAPM Spring 2008: Semester summary 4

Tools (2) Estimating size and effort You should know why revision control is important, how it You should know several methods for estimating software size: works, the basic differences between first, second, and Consensus methods: e.g. Delphi third generation tools, how basic operations are specified Population data methods: e.g. Fuzzy using SVN, and how revision control works with software Standard component methods: e.g. Component estimating releases. Function based methods: e.g. Function point analysis Web : Eric S. Raymond, Understanding Version-Control And the basics of how COCOMO can be used to estimate Systems. effort, given the size. Book : Humphrey 2002 chapter 5 SAPM Spring 2008: Semester summary 5 SAPM Spring 2008: Semester summary 6 Design Patterns Architectural Patterns You should know what a high-level architectural pattern is, You should know what a design pattern is, how to use and how to choose and apply several specific high-level them, why they are useful for large teams, and the basic patterns suitable for different types of systems. properties of several example patterns (e.g. Composite and Proxy). Book: Buschmann et al. 1996, A System of Patterns , Chapter 2 Web: ’Architectural pattern’ entry in Wikipedia. Book: Gamma et al. 1995 (optional) Web: ’Design pattern’ entry in Wikipedia SAPM Spring 2008: Semester summary 7 SAPM Spring 2008: Semester summary 8

Scripting Reusable Components Methodologies (1) You should know why reuse is difficult and rare, some You should know the essentials of at least three properties that make some languages more suitable for development methodologies, including their strengths, building components and others for gluing them together, disadvantages, and basic tenets: and how the Scripted Components pattern facilitates The Waterfall Model component reuse. The Unified Process (UP) Extreme Programming (XP) Article: Ousterhout 1998 Web: http://www.doc.ic.ac.uk/˜np2/ patterns/scripting/scripting.html SAPM Spring 2008: Semester summary 9 SAPM Spring 2008: Semester summary 10 Methodologies (2) Open source You should know the assumptions behind open-source Book : Jacobson, Booch, and Rumbaugh (1998) The Unified and closed-source approaches, the advantages and Software Development Process , Chapter 1 disadvantages of each, and several ways in which Web : The UP according to IBM/Rational Software: successful open-source development efforts have been www-306.ibm.com/software/awdtools/rup structured: Web : www.extremeprogramming.org gives an Benevolent dictatorship: e.g. Linux introduction to XP Open committee: e.g. Apache Ring-fenced committee: e.g. Mozilla Web: www.opensource.org/ : OSI site Web: http://www.catb.org/˜esr/writings/cathedral-bazaar/ Article: Mockus et al. 2002 SAPM Spring 2008: Semester summary 11 SAPM Spring 2008: Semester summary 12

Software failures Risk management You should know about many of the typical pathological You should be able to analyze typical risks faced by particular problems which occur on large projects: projects and organizations, including how to reduce them Organization problems: e.g. Poor reporting structures and how to tell when too much correction has been applied: Management problems: e.g. Political pressures Knowledge inadequacies: e.g. Prototype Problems conducting the project at each phase: e.g. Teaming: e.g. Holistic diversity being technology focused in the initial phase Productivity: e.g. Gold rush Ownership: e.g. Owner per deliverable Book : Flowers 1996 Distractions: e.g. Team per task Article : www.spectrum.ieee.org/sep05/1685 Training: e.g. Day care Web : www.cs.nmt.edu/˜cs328/reading/ Web : members.aol.com/acockburn/riskcata/ Standish.pdf : Summary of the 1995 Standish Group report riskbook.htm : Cockburn’s risk patterns Web : catless.ncl.ac.uk/Risks/ : the Risks Digest SAPM Spring 2008: Semester summary 13 SAPM Spring 2008: Semester summary 14 Software Evolution (1) Software Evolution (2) You should know the definition of and difference between: You should also know the basic types of testing, and how they fit in with software evolution. Reverse engineering: You should know when reverse engineering is necessary, and what it entails Book : Fowler et al. (1999), Chapter 2, plus Refactoring: You should know what refactoring is, and Demeyer et al. 2003, preface and Chapter 1 how to do it (alone and with testing and revision control) Reengineering: You should know how and why to reengineer a software system Legacy code: You should be know the main techniques for dealing with legacy code (refactoring and encapsulating), and why it is worthwhile to keep running systems working even as they are changed SAPM Spring 2008: Semester summary 15 SAPM Spring 2008: Semester summary 16

Human factors Teams You should be able to discuss intelligently the role of You should be able to reason about the dynamics of small human factors in software development, including: teams, including the types of roles people take on and the • How communication limits team size, due to stages that teams go through, primarily based on your exponential scaling in communication requirements own experience. You will not need to memorize the Belbin • The effect of distributed work sites team roles or the Tuckman group stages. • Programmer motivations, incentives, and rewards • Resistance to reuse, formal methods • Effect of users with fuzzy, drifting requirements Article : members.aol.com/acockburn/papers/ adchange.htm SAPM Spring 2008: Semester summary 17 SAPM Spring 2008: Semester summary 18 Process Standards Exam preparation Old exams are on inf.ed.ac.uk, but remember that the You should be able to discuss the purpose, applicability, content of the course is different every year. and limitations of CMM and ISO-9001. You should also be Compared to last year, there is more material on software able to describe root cause analysis, and how it might be evolution, version control, organizational standards, and done. teams. Compared to a couple of years ago, there is more material on project management, change management, and legacy systems, and less emphasis on formal modeling of quality tradeoffs and programming standards. Compared to even earlier years, there is less emphasis on formal methods, automation/synthesis, agents, and UML. In general, just review the lecture slides and required reading, following up with your own web exploration or other books wherever your interests take you. SAPM Spring 2008: Semester summary 19 SAPM Spring 2008: Semester summary 20

Summary References • Large-scale, long-term software development is Demeyer, S., Ducasse, S., & Nierstrasz, O. (2003). Object-Oriented extremely difficult and unpredictable Reengineering Patterns . San Francisco: Morgan Kauffman. • In SAPM you have been exposed to some useful Flowers, S. (1996). Software Failure: Management Failure: Amazing approaches and tools Stories and Cautionary Tales . Reading, MA: Addison-Wesley. • These approaches and tools can help, but are not Fowler, M., Beck, K., Brant, J., Opdyke, W., & Roberts, D. (1999). Refac- guaranteed cures toring: Improving the Design of Existing Code . Reading, MA: Ad- • Always be on the lookout for risks and indications that dison Wesley. your project is headed for failure, so that you can Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1995). Design Pat- address the issues or abort the project when appropriate. • Good luck beating the odds! SAPM Spring 2008: Semester summary 21 SAPM Spring 2008: Semester summary 21 terns: Elements of Reusable Object-Oriented Software . Reading, MA: Addison-Wesley. Humphrey, W. S. (2002). A Discipline for Software Engineering . Reading, MA: Addison-Wesley. Mockus, A., Fielding, R., & Herbsleb, J. D. (2002). Two case studies of open source software development: Apache and Mozilla. ACM Transactions on Software Engineering and Methodology , 11 (3), 309–346. Ousterhout, J. K. (1998). Scripting: Higher level programming for the 21st century. Computer , 31 (3), 23–30. SAPM Spring 2008: Semester summary 21