[email protected] … · sapm overview in this lecture we review the topics we have covered this...

Semester Summary

Dr. James A. [email protected]

http://homepages.inf.ed.ac.uk/jbednar

SAPM Spring 2012: Semester summary 1

SAPM OverviewIn this lecture we review the topics we have covered this

semester, focusing on what I consider the most important

points to remember.

The lecture slides on each topic, coupled with the required

readings listed alongside each lecture on the web site,

contain all of the basic material required to prepare for the

exam.

The suggested readings also listed there, plus experience

gained during the practical assignments, will help you

surpass this minimum standard.


Project management

You should know what projects are, and how to draw and

interpret the basic charts used in PM: Work Breakdown

Structure, Network diagram, and Gantt chart. You

should also be very familiar with their limitations.

You should know the basic PM terms, such as critical

path, slack, crashing.


Tools (1)

You should know several categories of useful tools, and

have some familiarity with at least one suitable tool in

each category:

Version control (e.g. Subversion)Build control (e.g. make)Debuggers (e.g. gdb)Unit/regression testing (e.g. JUnit)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 pageSAPM Spring 2012: Semester summary 4

Tools (2)

You should know why revision control is important, how it

works, the basic differences between first, second, and

third generation tools, how basic operations are specified

using git, and how revision control works with software

releases.

Web: Eric S. Raymond, Understanding Version-Control

Systems.


Estimating size and effort

You should know several methods for estimating software size:

Consensus methods: e.g. Delphi

Population data methods: e.g. Fuzzy

Standard component methods: e.g. Component estimating

Function based methods: e.g. Function point analysis

And the basics of how COCOMO can be used to estimate

effort, given the size.

Book: Humphrey 2002 chapter 5


Design Patterns

You should know what a design pattern is, how to use

them, why they are useful for large teams, and the basic

properties of several example patterns (e.g. Composite

and Proxy).

Book: Gamma et al. 1995 (optional)

Web: ’Design pattern’ entry in Wikipedia


Architectural Patterns

You should know what a high-level architectural pattern is,

and how to choose and apply several specific high-level

patterns suitable for different types of systems.

Book: Buschmann et al. 1996, A System of Patterns, Chapter 2

Web: ’Architectural pattern’ entry in Wikipedia.


Scripting Reusable Components

You should know why reuse is difficult and rare, some

properties that make some languages more suitable for

building components and others for gluing them together,

and how the Scripted Components pattern facilitates

component reuse.

Article: Ousterhout 1998

Web: http://www.doc.ic.ac.uk/˜np2/

patterns/scripting/scripting.html


Methodologies (1)

You should know the essentials of at least three

development methodologies, including their strengths,

disadvantages, and basic tenets:

The Waterfall Model

The Unified Process (UP)

Extreme Programming (XP)


Methodologies (2)

Book: Jacobson, Booch, and Rumbaugh (1998) The Unified

Software Development Process, Chapter 1

Web: The UP according to IBM/Rational Software:

www-306.ibm.com/software/awdtools/rup

Web: www.extremeprogramming.org gives an

introduction to XP


Software failuresYou should know about many of the typical pathological

problems which occur on large projects:

Organization problems: e.g. Poor reporting structuresManagement problems: e.g. Political pressuresProblems conducting the project at each phase: e.g.

being technology focused in the initial phase

Book: Flowers 1996

Article: www.spectrum.ieee.org/sep05/1685

Web: www.cs.nmt.edu/˜cs328/reading/

Standish.pdf: Summary of the 1995 Standish Group report

Web: catless.ncl.ac.uk/Risks/: the Risks DigestSAPM Spring 2012: Semester summary 12

Risk management

You should be able to analyze typical risks faced by particular

projects and organizations, including how to reduce them

and how to tell when too much correction has been applied:

Knowledge inadequacies: e.g. PrototypeTeaming: e.g. Holistic diversityProductivity: e.g. Gold rushOwnership: e.g. Owner per deliverableDistractions: e.g. Team per taskTraining: e.g. Day care

Web: members.aol.com/acockburn/riskcata/

riskbook.htm: Cockburn’s risk patterns


Human factorsYou should be able to discuss intelligently the role of

human factors in software development, including:

• How communication limits team size, due toexponential scaling in communication requirements

• The effect of distributed work sites

• 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


Teams

You should be able to reason about the dynamics of small

teams, including the types of roles people take on and the

stages that teams go through, primarily based on your

own experience. You will not need to memorize the Belbin

team roles or the Tuckman group stages.


Process Standards

You should be able to discuss the purpose, applicability,

and limitations of CMM and ISO-9001. You should also be

able to describe root cause analysis, and how it might be

done.


Open sourceYou should know the assumptions behind open-source

and closed-source approaches, the advantages and

disadvantages of each, and several ways in which

successful open-source development efforts have been

structured:

Benevolent dictatorship: e.g. LinuxOpen committee: e.g. ApacheRing-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


Software Evolution (1)

You should know the definition of and difference between:

Reverse engineering: You should know when reverseengineering is necessary, and what it entails

Refactoring: You should know what refactoring is, andhow to do it (alone and with testing and revision control)

Reengineering: You should know how and why toreengineer a software system

Legacy code: You should be know the main techniquesfor dealing with legacy code (refactoring andencapsulating), and why it is worthwhile to keeprunning systems working even as they are changed


Software Evolution (2)

You should also know the basic types of testing, and how

they fit in with software evolution.

Book: Fowler et al. (1999), Chapter 2, plus

Demeyer et al. 2003, preface and Chapter 1


Exam preparationOld exams are at the library site, but remember that thecontent of the course is different every year. Compared towhen I last taught it, there is more material on softwareevolution and distributed version control.

In general, you should review the lecture slides and therequired reading, following up with your own webexploration or other books wherever your interests takeyou.


Summary

• Large-scale, long-term software development isextremely difficult and unpredictable

• In SAPM you have been exposed to some usefulapproaches and tools

• These approaches and tools can help, but are notguaranteed cures

• Always be on the lookout for risks and indications thatyour project is headed for failure, so that you canaddress the issues or abort the project when appropriate.

• Good luck beating the odds!


References

Demeyer, S., Ducasse, S., & Nierstrasz, O. (2003). Object-OrientedReengineering Patterns. San Francisco: Morgan Kauffman.

Flowers, S. (1996). Software Failure: Management Failure: AmazingStories and Cautionary Tales. Reading, MA: Addison-Wesley.

Fowler, M., Beck, K., Brant, J., Opdyke, W., & Roberts, D. (1999). Refac-toring: Improving the Design of Existing Code. Reading, MA: Ad-dison Wesley.

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 studiesof open source software development: Apache and Mozilla. ACMTransactions on Software Engineering and Methodology, 11 (3),309–346.

Ousterhout, J. K. (1998). Scripting: Higher level programming for the21st century. Computer, 31 (3), 23–30.


[email protected] … · sapm overview in this lecture we review the topics we have covered this...

Documents