SAPM Overview Semester Summary In this lecture we review the topics we have covered this 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 2006: Semester summary 1 SAPM Spring 2006: Semester summary 2 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 use and apply several high-level architectural 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). High level decompositions: e.g. Layers Book: Gamma et al. 1995 Distributed systems: e.g. Broker Web: Search for “design patterns”, etc. Interactive systems: e.g. Model-view-controller Adaptable systems: e.g. Microkernel Configurable systems: e.g. Scripted Components Book: Buschmann et al. 1996, A System of Patterns , Chapter 2 SAPM Spring 2006: Semester summary 3 SAPM Spring 2006: Semester summary 4
Scripting Reusable Components Managing Change You should know why reuse is difficult and rare, some Revision control: You should know why revision control properties that make some languages more suitable for is important, how it works, how basic operations are building components and others for gluing them together, specified using CVS, and how revision control works with software releases. and how the Scripted Components pattern facilitates component reuse. Refactoring: You should know what refactoring is, and how to do it (alone and with testing and revision control) Article: Ousterhout 1998 Web: http://www.doc.ic.ac.uk/˜np2/ Legacy code: You should be know the main techniques for dealing with legacy code (refactoring and patterns/scripting/scripting.html encapsulating), and why it is worthwhile to keep running systems working even as they are changed SAPM Spring 2006: Semester summary 5 SAPM Spring 2006: Semester summary 6 Methodologies (1) Methodologies (2) You should know the essentials of at least four Book : Jacobson, Booch and Rumbaugh 1998 The Unified development methodologies, including their strengths, Software Development Process , Chapter 1 disadvantages, and basic tenets: Web : The Waterfall Model www-306.ibm.com/software/awdtools/rup The UP according to IBM/Rational Software The Unified Process (UP) Extreme Programming (XP) Web : www.extremeprogramming.org gives an The Cleanroom Process introduction to XP Only basic knowledge is expected for the Cleanroom process; we covered the others in some detail. SAPM Spring 2006: Semester summary 7 SAPM Spring 2006: Semester summary 8
Open source Estimating size and effort You should know the assumptions behind open-source You should know several methods for estimating software size: and closed-source approaches, the advantages and Consensus methods: e.g. Delphi disadvantages of each, and several ways in which Population data methods: e.g. Fuzzy successful open-source development efforts have been Standard component methods: e.g. Component estimating structured: Function based methods: e.g. Function point analysis Benevolent dictatorship: e.g. Linux Open committee: e.g. Apache And how COCOMO can be used to estimate effort, given the size. Ring-fenced committee: e.g. Mozilla Book : Humphrey 2002 chapter 5 Web: www.opensource.org/ : OSI site Web : sunset.usc.edu/research/COCOMOII : Web: http://www.catb.org/˜esr/writings/cathedral-bazaar/ COCOMO site Article: Mockus et al. 2002 SAPM Spring 2006: Semester summary 9 SAPM Spring 2006: Semester summary 10 Measurement Verification and validation You should know the sorts of things to include in a You should know the difference between verification and software measurement plan. In particular, you should know: validation, why both are important, and the basics, pros, Some key issues to address: e.g. Growth measures and cons for several techniques for V & V, e.g. black/clear Means of identifying issues: e.g. Risk assessments box testing and formal proofs of correctness. You also What to measure for various issues: e.g. Number of know the different levels at which V & V is applied, and components some ways to do tests at each level: Limitations of measurement: e.g. Incremental design • Unit tests means measuring incomplete functions. • Integration testing Basic estimators: e.g. Plot of staff months against • System testing number of lines of source code. • Regression testing Book : Humphrey 2002 chapter 4 Book : Sommerville 1996 Software Engineering Chapters 22, 23, and 24 SAPM Spring 2006: Semester summary 11 SAPM Spring 2006: Semester summary 12
Risk management SW Project Management Tools You should be able to analyze typical risks faced by particular You should know several categories of useful tools, and projects and organizations, including how to reduce them have some familiarity with at least one suitable tool in and how to tell when too much correction has been applied: each category, particularly the first two: Build control (e.g. make ) Knowledge inadequacies: e.g. Prototype Revision control (e.g. CVS ) Teaming: e.g. Holistic diversity Debuggers (e.g. gdb ) Productivity: e.g. Gold rush Unit/regression testing (e.g. JUnit ) Ownership: e.g. Owner per deliverable Bug/issue tracking (e.g. GNATS ) Distractions: e.g. Team per task Documentation generation (e.g. JavaDoc ) Training: e.g. Day care Project management (e.g. MS Project ) Integrated suites (e.g. RUP ) Web : members.aol.com/acockburn/riskcata/ riskbook.htm : Cockburn’s risk patterns Web : See tools.html on the course web page SAPM Spring 2006: Semester summary 13 SAPM Spring 2006: Semester summary 14 Software failures Project management You should know about the sorts of pathological problems You should know what projects are, and how to draw and which can occur on large projects: interpret the basic charts used in PM: Work Breakdown Organization problems: e.g. Poor reporting structures Structure , Network diagram (and that it is sometimes Management problems: e.g. Political pressures called a PERT or CPM chart), and Gantt chart . Problems conducting the project at each phase: e.g. You should know the basic PM terms, such as critical being technology focused in the initial phase path, slack, crashing. Book : Flowers 1996 Note: This material is covered in projman.pdf , an Web : www.cs.nmt.edu/˜cs328/reading/ extra set of slides on the lecture notes page added as Standish.pdf : Summary of the 1995 Standish Group report background for the guest speakers. Web : catless.ncl.ac.uk/Risks/ : the Risks Digest SAPM Spring 2006: Semester summary 15 SAPM Spring 2006: Semester summary 16
Exam preparation Summary Old exams are on inf.ed.ac.uk, but remember that the • Large-scale, long-term software development is extremely difficult and unpredictable content of the course is slightly different every year. Compared to last year, there is new material on project • In SAPM you have been exposed to some useful approaches and tools management, change management, and legacy systems, and less emphasis on formal modeling of quality tradeoffs • These approaches and tools can help, but are not and programming standards. Compared to other recent guaranteed cures years, there is less emphasis on formal methods, • Always be on the lookout for risks and indications that automation/synthesis, agents, and UML. your project is headed for failure, so that you can address the issues or abort the project when appropriate. In general, just review the lecture slides and required reading, following up with your own web exploration or • Good luck beating the odds! other books wherever your interests take you. SAPM Spring 2006: Semester summary 17 SAPM Spring 2006: Semester summary 18 References Transactions on Software Engineering and Methodology , 11 (3), 309–346. Flowers, S. (1996). Software Failure: Management Failure: Amazing Ousterhout, J. K. (1998). Scripting: Higher level programming for the Stories and Cautionary Tales . Reading, MA: Addison-Wesley. 21st century. Computer , 31 (3), 23–30. Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1995). Design Pat- 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 SAPM Spring 2006: Semester summary 18 SAPM Spring 2006: Semester summary 18
Recommend
More recommend
