Slide 12.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.

Slide 12.1

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

An Introduction toObject-Oriented

Systems Analysis and Design with UML and

the Unified Process

McGraw-Hill, 2004

Stephen R. Schach

[email protected]

Slide 12.2


CHAPTER 12

TEAMS

Slide 12.3


Chapter Overview

Team Organization Traditional Chief Programmer Teams Modern Hierarchical Teams Other Ways of Organizing Teams

Slide 12.4


Teams

Every information system development project needs competent, well-trained information technology professionals

Having the right people is not enough– Teams must be organized so that the team members work

productively in cooperation with one another

Slide 12.5


Team Organization

Most information systems are too large to be completed by a single information technology professional within the given time constraints– The work must be assigned to a group of professionals

organized as a team

Slide 12.6


Team Organization (contd)

Suppose that the analysis workflow has to be performed within 3 months

Suppose further that 1 person-year of analysis is involved– (A person-year is the amount of work that can be done by

one person in 1 year)

Slide 12.7



The solution is apparently simple: – If one systems analyst can perform the workflow in 1 year– Four systems analysts can do it in 3 months

In practice, however,– the four systems analysts may take nearly a year, and – The quality of the resulting information system may be

lower than if one systems analyst had coded the entire information system

Slide 12.8



Some tasks can be shared, but others must be done individually– If 1 farmhand can pick a strawberry field in 10 days,– The same strawberry field can be picked by 10 farmhands

in 1 day

However– One elephant can produce a calf in 22 months, but– Twenty-two elephants cannot produce a calf in 1 month

Slide 12.9



Tasks like strawberry picking can be fully shared

Tasks like elephant production cannot be shared at all

Slide 12.10



Unlike elephant production– It is possible to share analysis tasks between members of

a team

Unlike strawberry picking– Analysis team members have to interact with one another

in a meaningful and effective way

Slide 12.11


Brooks’s Law

Keith, Lisa, and Mary are working on the project

A deadline is rapidly approaching, but– The task is not nearly complete

The obvious thing to do – Add a fourth professional (Norman) to the team

Slide 12.12


Brooks’s Law (contd)

Communication channels

Slide 12.13


Brooks’s Law (contd)

When Norman joins the team– The other three to explain in detail what has been

accomplished to date and what is still incomplete

That is, adding personnel to a late information system project makes it even later– This principle is known as Brooks’s Law – Fred Brooks observed it in the 1960s while managing the

development of OS/360» An IBM mainframe operating system

Slide 12.14



In large organizations, teams perform every workflow– But especially the implementation workflow– Programmers work independently on separate modules

In some smaller organizations– One individual performs the requirements, analysis, and

design workflows– The implementation workflow is performed by a team of two

or three programmers

The implementation workflow is therefore a prime candidate for task sharing

Slide 12.15



Teams are most heavily used for the implementation workflow– The problems of team organization are most acutely felt

during implementation

In the rest of this chapter, team organization is presented within the context of implementation– However, the problems and their solution are equally

applicable to all the other workflows

Slide 12.16


Traditional Chief Programmer Teams

There are eleven 2-, 3-, and 4-person communication paths in this four-person team– (See textbook for details)

Slide 12.17


Traditional Chief Programmer Teams (contd)

A team organized this way is unlikely to be able to perform 24 person-months of work in 6 months– Many hours are wasted in meetings involving two or more

team members at a time» (A person-month is the amount of work one person can do in one

month)

Slide 12.18



There are only 3 communication paths in this four-person team

Slide 12.19



This is the basic concept behind what now is termed the chief programmer team– First put forward more than 30 years ago

The chief programmer was both a successful manager and a highly skilled programmer– He or she did the design and any critical or complex

sections of the code– The other team members did the coding, under the

direction of the chief programmer

Slide 12.20



In theory, this seemed to be a good idea

In practice, it was a tremendous success the first time it was used– Computerizing the clippings files of the New York Times in

1972

There have subsequently been other successful projects that used chief programmer teams– None of them reached the heights of the New York Times

triumph– The reason lay in the skill sets of chief programmers

Slide 12.21



A chief programmer is a combination of– A highly skilled programmer and – A successful manager

Such individuals are extremely difficult to find

Slide 12.22



There is a shortage of highly skilled programmers

There is a shortage of successful managers

A chief programmer requires both abilities in equal measure

Slide 12.23



The qualities needed to be a highly skilled programmer differ from those needed to be a successful manager

The chances of finding a chief programmer are small

Traditional chief programmer teams are therefore almost impossible to implement in practice

Slide 12.24



What is needed is a more practical way of organizing programming teams– That can be extended to the implementation of larger

information systems

Slide 12.25


Modern Hierarchical Teams

The problem with traditional programmer teams– It is all but impossible to find one individual who is both a

highly skilled programmer and successful manager

The solution– Use a matrix organizational structure – Replace the chief programmer by

» A team leader who is in charge of the technical aspects of the team’s activities, and

» A team manager who is responsible for all nontechnical managerial decisions

Slide 12.26


Modern Hierarchical Teams (contd)

Matrix organizational structure

Slide 12.27



The matrix organizational structure does not violate the fundamental managerial principle that – No employee should report to more than one manager

Slide 12.28



The areas of responsibility are clearly delineated

The team leader is responsible for only technical management– Examples: Budgetary and legal issues are not handled by

the team leader, nor are performance appraisals

The team leader has sole responsibility on technical issues– Example: The team manager has no right to promise that

the information system will be delivered within 4 weeks – Promises of that sort have to be made by the team leader

Slide 12.29



Before implementation begins, it is important to demarcate clearly those areas that appear to be the responsibility of both the team manager and the team leader– Example: Team leave

Slide 12.30



Cost Issue– The traditional chief programmer team has one manager

(the chief programmer)– The modern hierarchical team has two managers

» The team manager, and» The team leader

Surely two managers makes the modern programming team prohibitively expensive?

Slide 12.31



There are two reasons why this is not the case– The salary of a chief programmer (if one could be found) is

much greater than that of either a team manager or a team leader

– Each team has its own team leader, but a team manager can usually manage more than one team

The total cost of the traditional chief programmer team is therefore about the same as that of the modern hierarchical team

Slide 12.32



Larger projects

Slide 12.33



This approach scales up as shown in the figure– Only the technical managerial organizational structure is

shown– The nontechnical side is similarly organized

For simplicity, the figure does not show nonprogramming personnel, such as the quality assurance group

Slide 12.34



Hierarchy– The project leader is in charge of implementation of the

information system as a whole– The programmers report to their team leaders– The team leaders report to the project leader

For even larger systems, additional levels can be added

Slide 12.35



The figures in this chapter show teams of 3 or 4 information technology professionals– This is to achieve clearer, less cluttered diagrams

In practice, teams are usually larger than this– Example:

» When the Unified Process is used, teams of size six to eight are recommended

Slide 12.36


Other Ways of Organizing Teams

Two other ways of organizing teams are now described– One has proved itself to be relatively successful

» But so far in only one company

– The other is still controversial

Slide 12.37


Synchronize-and-Stabilize Teams

Microsoft, Inc. is the world’s largest manufacturer of COTS packages– These are generally large-scale products– Example:

» Windows 2000 consists of more than 30 millions of lines of code» Developed by over 3000 programmers and testers

Team organization is a vital aspect of the successful construction of products of this size

Slide 12.38


Synchronize-and-Stabilize Teams (contd)

Microsoft COTS packages are developed using the synchronize-and-stabilize life-cycle model– This model has features in common with the Unified

Process– In particular, incrementation is heavily used

Slide 12.39



The requirements phase is conducted by – Interviewing numerous potential customers for the COTS

package, and– Extracting a list of features, prioritized by the customers

A specification document is now drawn up that reflects the customers’ responses to the interviews

Slide 12.40



Next, the product is designed and implemented

– The work is divided into three or four increments» (Termed builds by Microsoft)

– The first build consists of the most important features

– Once the first build is complete, the second build is started

– The second build consists of the next most important features, and so on

Slide 12.41



Each build is carried out by a number of small teams working in parallel

At the end of each day all the teams synchronize– They put the partially completed components together,

and – Test and debug the resulting product

Stabilization is performed at the end of each build– Any remaining faults are fixed – The build is now frozen

» (No further changes will be made to the specification document)

Slide 12.42



The repeated synchronization step ensures that the various components always work together– The developers also obtain early insights into the

operation of the product– They can modify the requirements if necessary during the

course of a build

Slide 12.43



The success of the life-cycle model is largely a consequence of the way the teams are organized– Each build is constructed by a number of small teams,– Led by a program manager, and – Consisting of 3 to 8 developers together with 3 to 8 testers

who work one-to-one with the developers

The team is provided the specifications of their overall task– The team members are given the freedom to design and

implement their portion of the task as they wish

Slide 12.44



The reason this does not rapidly devolve into chaos is – The synchronization step performed each day– The partially completed components are tested and

debugged on a daily basis

The strength of this approach is that– Individual programmers are encouraged to be creative and

innovative, but– The daily synchronization step ensures that the hundreds

of developers work together toward a common goal

Slide 12.45



Microsoft developers must adhere strictly to the time laid down to enter their code into the product database for that day’s synchronization– This has been likened to telling children that they can do

what they like all day but have to be in bed by 9 P.M.

If a developer’s code prevents the product from being compiled for that day’s synchronization– The problem must be fixed immediately so that the rest of

the team can test and debug that day’s work

Slide 12.46



Will use of the synchronize-and-stabilize model guarantee that every other software organization will be as successful as Microsoft?– This is extremely unlikely

Microsoft, Inc., is more than just the synchronize-and-stabilize model– The organization consists of a highly talented set of

managers and software developers with an evolved group ethos

Slide 12.47



Use of many of the features of the model in other organizations could lead to process improvement

On the other hand, it has been suggested that the synchronize-and-stabilize model is simply a way of allowing a group of hackers to develop large products

Slide 12.48


Extreme Programming Teams

Extreme programming (XP) is a controversial new approach to information system development– It utilizes iteration and incrementation

Slide 12.49


Extreme Programming Teams (contd)

The team determines the various features (stories) that the client would like the target information system to support

For each such story, the team informs the client– How long it will take to implement that story, and – How much it will cost

» (These steps roughly corresponds to the requirements and analysis workflows of the Unified Process)

Slide 12.50



The client selects the stories to be included in each successive build using cost–benefit analysis– That is, on the basis of the time and the cost estimates

provided by the development team, and– The potential benefits of the story to his or her business

The proposed build is broken down into increments– Here termed tasks

Slide 12.51



A programmer first draws up test cases for a task

The programmer works together with a partner on one computer (pair programming)– The programmers implement the task– Ensuring that all the test cases work correctly

The task is then integrated into the current version of the information system

Slide 12.52



Implementing and integrating a task should take no more than a few hours– A number of pairs will be implementing tasks in parallel, so

integration can take place essentially continuously

The test cases used for the task are retained and utilized in all further testing

Slide 12.53



A number of features of XP are unusual:

The computers of the XP team are set up in the center of a large room lined with small cubicles

A client representative works with the XP team at all times

No individual can work overtime for two successive weeks

Slide 12.54



There is no specialization—all members of the XP team work on requirements, analysis, design, code, and testing

There is no overall design phase before the various builds are constructed—the design is modified while the information system is developed (refactoring)

If a test case will not run, the code is reorganized until the team is satisfied that the design is simple, straightforward, and runs all the test cases satisfactorily

Slide 12.55


Pair Programming

A particularly unusual feature of XP is pair programming– All code is implemented by a team of two programmers

sharing a single computer

There are a number of reasons why this is done

Slide 12.56


Pair Programming (contd)

It is highly inadvisable for a programmer to test his or her own code– One pair programmer in a team draws up the test cases

for a task– These test cases are then used by the other programmer

to test the code after they have jointly implemented it

In more conventional life-cycle models, if a developer leaves during a project, all the knowledge accumulated by that developer leaves as well– If one member of a pair programming team leaves, the

other knows enough to continue working on the same part of the information system with a new pair programmer

Slide 12.57


Pair Programming (contd)

Working in pairs enables a less experienced programmer to learn from the more experienced team member

Thus, there can be distinct advantages to pair programming

Slide 12.58



XP has been successfully used on a number of small-scale projects

There have also been a number of failures

XP has not yet been used widely enough to determine whether it will fulfill its early promise

Slide 12.59



Extreme programming is one of a number of new paradigms that are collectively referred to as agile processes

They are characterized by – Considerably less emphasis on analysis and design than

in the Unified Process, and – With implementation starting much earlier in the life cycle

Slide 12.60



Even if XP turns out to be good for small-scale information systems– That does not necessarily mean that it can be used for

medium- or large-scale information systems

Slide 12.61



Consider the following analogy:– Anyone can successfully hammer together a few planks to

build a doghouse– But it would be foolhardy to build a 3-bedroom home

without detailed plans– In addition, skills in plumbing, wiring, and roofing are

needed to build a 3-bedroom home

The lesson: Being able to build small-scale information systems does not necessarily mean that one has the skills for building medium-scale information systems

Slide 12.62



The analogy continues:– A skyscraper is the height of 1000 doghouses– This does not mean that one can build a skyscraper by

piling 1000 doghouses on top of one another

The lesson: Building large-scale information systems requires far more specialized and sophisticated skills than those needed to cobble together small-scale information systems

Slide 12.63



Conclusion: – It seems unlikely that agile processes will prove to be

more than a nontraditional way of building small-scale information systems

Slide 12.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.

Documents

team slide

year slide

month slide

mcgrawhill companies

effective way slide

team organization contd

information systems

unified process mcgrawhill