SAPM: Lecture slides and notes

[Slides]

This lecture provides a general introduction to the SAPM (Software Architecture, Process, and Management) course.

[Slides]

This lecture introduces "traditional" project management techniques, such as work breakdown structures, network diagrams, critical paths, Gantt charts, etc., and evaluating whether and how they can be used in software projects. Mainly sets the stage for later discussions.

Required Readings

• A.B. Pyster, R.H. Thayer. Software Engineering Project Management 20 Years Later. IEEE Software September/October 2005. [DOI link]
• S. Garcia. How Standards Enable Adoption of Project Management Practice. IEEE Software September/October 2005. [DOI link]
• W. Royce. Successful Software Management Style: Steering and Balance. IEEE Software September/October 2005. [DOI link]
• R.N. Charette. Large-Scale Project Management Is Risk Management. IEEE Software July 1996. [DOI link]
• Michael C. Glen. A Guideto Network Analysis. [link]

Suggested Readings

• B. Boehm, R. Turner. Management Challenges to Implementing Agile Processes in Traditional Development Organizations. IEEE Software September/October 2005. [DOI link]
• P.C. Clements, L.G. Jones, L.M. Northrop, J.D. McGregor. Project Management in a Software Product Line Organization. IEEE Software September/October 2005. [DOI link]
• IEEE Std 1058-1998. IEEE Standard for Software Project Management Plans.
• SEOC 2006/2007 Lecture Notes 07 on Project Management.

[Slides]

This lecture discusses automated tools helpful for running large software projects.

Required Readings

• Eric S. Raymond, Understanding Version-Control Systems (ignoring dates and details of specific tools, of course!).

[Slides]

This leacture briefly discusses how, what, and why to measure quantities needed for project planning and execution. The main message is that you need data to run your project properly, but you can't usually measure what you really want to know, and measuring something you can trust takes a lot of time and effort, so you need to focus on measuring the few key things on which the success of your project most depends.

Required Readings

• S.L. Pfleeger, R. Jeffery, B. Curtis, B. Kitshenham. Status Report on Software Measurement. IEEE Software, March/April 1997. [DOI link]
• B. Clark. Eight Secrets of Software Measurement. IEEE Software, September/October 2002. [DOI link]
• J. Boegh, S. De Panfilis, B. Kitchenham, A. Pasquini, A Method for Software Quality Planning, Control, and Evaluation. IEEE Software, March/April 1999. [DOI link]
• J. Clapp. Getting Started on Software Metrics. IEEE Software, January 1993. [DOI link]

Suggested Readings

• S.L. Pfleeger. Software Metrics: Progress after 25 Years?, IEEE Software, November/December 2008. [DOI link]
• R.J. Offen, R. Jeffery. Establishing Software Measurements Programs. IEEE Software, March/April 1997. [DOI link]
• SEOC 2006/2007 Lecture Notes 20 on Software Quality.

[Slides]

This lecture discusses techniques for estimating how much effort will be required for a project. The basic problem: estimates are needed at the start of the project, in order to make decisions, yet data is available at the end of the project, when it doesn't matter any more. Yet one must do something!

Required Readings

• Boehm, B., Clark, B., Horowitz, E., Madachy, R., Shelby, R., and Westland, C., Cost models for future software life cycle processes: COCOMO 2.0. Annals of Software Engineering, 1995. [DOI link]

Team discussions; Question/Answer session.

[Slides]

This lecture briefly introduces design patterns focusing on one example pattern (Composite). For more detail, see the required reading mentioned in the slides. The main focus is on how design patterns can help large teams communicate more efficiently and effectively.

Required Readings

• T. Winn, P. Calder. Is This a Pattern?. IEEE Software, 19(1):59-66, January/February, 2002. [DOI link]
• F. Buschmann, K. Henney, D.C. Schmidt. Past, Present, and Future Trends in Software Patterns. IEEE Software, 24(4):31-37, July, 2007.[DOI link]

Suggested Readings

• D. Manolescu, W. Kozaczynski, A. Miller, J. Hogg. The Growing Divide in the Patterns World. IEEE Software, 24(4):61-67, July 2007. [DOI link]
• M.P. Cline. The pros and cons of adopting and applying design patterns in the real world. Communications of the ACM, 39(10):47-49, October, 1996. [DOI link]
• SEOC 2008/2009 Lecture Notes 05 on Design Patterns.

[Slides]

This lecture introduces architectural patterns. It focuses on how they can allow large systems to be broken up into chunks that developers or small teams can understand and implement somewhat independently.

Required Readings

• M. Stal. Using Architectural Patterns and Blueprints for Service-Oriented Architecture. IEEE Software, March/April 2006. [DOI link]
• N.B. Harrison, P. Avgeriou, U. Zdun. Using Patterns to Capture Architectural Decisions. IEEE Software, July/August 2007. [DOI link]

Suggested Readings

• M. Hafiz, P. Adamczyk, R.E. Johnson. Organizing Security Patterns. IEEE Software, July/August 2007. [DOI link]
• L. Rising. Understanding the Power of Abstraction in Patterns. IEEE Software, July/August 2007. [DOI link]

[Slides]

This lecture discusses the Scripted Components architectural pattern in detail, covering some of the motivitating factors behind it (particularly reuse), its benefits and its risks. A wide range of instances are highlighted, and a couple of “war stories” recounted.

Required Readings

• J.K. Ousterhout. Scripting: Higher Level Programming for the 21st Century. IEEE Computer magazine, March 1998.
• N. Pryce. Scripted Components.

• I. Sommerville. Software Engineering (7th edition). Addison-Wesley. (chapters 4 & 18).

[Slides]

This lecture introduces material on the Waterfall Model, focusing on why it is an inappropriate metaphor for software development, and reviewing material on the Unified Process, focusing on how UP uses modeling to discover problems as early as possible, before software is coded and set in stone. It also discusses XP and other agile methodologies, focusing on how they strive to keep software from ever being set in stone, remaining flexible and responsive to changing requirements, rather than trying to do everything up front.

Required Readings

• B. Boehm. Get ready for agile methods, with care. IEEE Computer 35(1):64-69, 2002. [DOI link]
• B. W. Boehm. A Spiral Model of Software Development and Enhancement. IEEE Computer, May 1988. [DOI link]

Suggested Readings

• M. C, Paulk. Extreme Programming from a CMM Perspective. IEEE Software, November/December 2001. [DOI link]
• P. Schuh. Recovery, Redemption, and Extreme Programming. IEEE Software, November/December 2001. [DOI link]

[Slides]

This lecture discussed some of the differences between traditional manufacturing processes and software development, and how these create an opening for the notion of Open Source software. Differences to Free Software, and the implications of licence variation, both as licensor and licensee, were raised. Finally a brief overview was presented of how a few different OSS projects organise themselves.

Required Readings

• E. S. Raymond (1997-2002). The Cathedral and the Bazaar. Published and occasionally updated online.

Suggested Readings

• A. Mockus et al. (2001). Two Case Studies of Open Source Software Development: Apache and Mozilla. ACM Transactions on Software Engineering and Methodology. [DOI link]

[Slides]

This lecture ran through a litany of software project failures, trying to tease out the sources of failure. Ultimately the same reasons crop up again and again, but there are many of them, ranging from social/organisational through unmanaged technical risk, poor design and implementation to bad delivery, rollout and support. Awareness of some these possibilities might, one hopes, mitigate their likelihood in future.

Required Readings

• R. N. Charette (September 2005). Why Software Fails. IEEE Spectrum. [DOI link]
• R. Guth (September 2005). Battling Google, Microsoft Changes How It Builds Software. Wall Street Journal.

Suggested Readings

• S. Flowers (1996). Software Failure: Management Failure: Amazing Stories and Cautionary Tales. Addison-Wesley.
• R. L. Glass (1998). Software Runaways: {L}essons Learned from Massive Software Project Failures. Prentice Hall.
• R. Bennett (3 May 2007). Chaos as register offices are told to abandon £6m computer system. [Times Online].

[Slides]

This lecture discusses techniques for anticipating and planning around major risks to the success of your project.

Required Readings

• B.W. Boehm. Software Risk Management: Principles and Practices. IEEE Software, January 1991. [DOI link]
• R.N. Charette. Large-Scale Project Management Is Risk Management. IEEE Software, July 1996. [DOI link]
• E.H. Conrow, P.S. Shishido. Implementing Risk Management on Software Intensive Projects. IEEE Software, May/June 1997. [DOI link]

Suggested Readings

• R. Fairley. Risk Management For Software Projects. IEEE Software, May 1994. [DOI link]
• R.E. Fairley. Software Risk Management. IEEE Software, May/June 2005. [DOI link]

[Slides]

This lecture discusses methods for dealing with changes to software systems over time, including reverse engineering, refactoring an existing design into a more suitable one, and how to add features to or interface with legacy systems.

Suggested Readings

• M. M. Lehman. Software's Future: Managing Evolution. IEEE Software 15(1):40-44, 1998. [DOI link]

[Slides]

This lecture discusses human factors in software development, at the level of individuals, small teams, and large organizations (including the Capability Maturity Management model, ISO-9000, and root cause analysis).

[Slides]

Reviewed the course, and gave some advice for the exams — basically, review the course slides, the required reading, and your coursework (don't assume that because you did something for the coursework it won't turn up in the exam).

Assignment 1 Review

Gave a short review of assignment 1 work during the lecture slot today.