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

1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with UML and the Unified Process McGraw-Hill, 2004 Stephen R. Schach srs@vuse.vanderbilt.edu

3 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter Overview l Team Organization l Traditional Chief Programmer Teams l Modern Hierarchical Teams l Other Ways of Organizing Teams

4 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Teams l Every information system development project needs competent, well-trained information technology professionals l Having the right people is not enough –Teams must be organized so that the team members work productively in cooperation with one another

5 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Team Organization l 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

6 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Team Organization (contd) l Suppose that the analysis workflow has to be performed within 3 months l 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)

7 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Team Organization (contd) l 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 l 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

8 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Team Organization (contd) l 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 l However –One elephant can produce a calf in 22 months, but –Twenty-two elephants cannot produce a calf in 1 month

9 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Team Organization (contd) l Tasks like strawberry picking can be fully shared l Tasks like elephant production cannot be shared at all

10 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Team Organization (contd) l Unlike elephant production –It is possible to share analysis tasks between members of a team l Unlike strawberry picking –Analysis team members have to interact with one another in a meaningful and effective way

11 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Brooks’s Law l Keith, Lisa, and Mary are working on the project l A deadline is rapidly approaching, but –The task is not nearly complete l The obvious thing to do –Add a fourth professional (Norman) to the team

13 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Brooks’s Law (contd) l When Norman joins the team –The other three to explain in detail what has been accomplished to date and what is still incomplete l 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

14 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Team Organization (contd) l In large organizations, teams perform every workflow –But especially the implementation workflow –Programmers work independently on separate modules l 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 l The implementation workflow is therefore a prime candidate for task sharing

15 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Team Organization (contd) l Teams are most heavily used for the implementation workflow –The problems of team organization are most acutely felt during implementation l 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

16 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Traditional Chief Programmer Teams l There are eleven 2-, 3-, and 4-person communication paths in this four-person team –(See textbook for details)

17 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Traditional Chief Programmer Teams (contd) l 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)

19 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Traditional Chief Programmer Teams (contd) l This is the basic concept behind what now is termed the chief programmer team –First put forward more than 30 years ago l 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

20 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Traditional Chief Programmer Teams (contd) l In theory, this seemed to be a good idea l In practice, it was a tremendous success the first time it was used –Computerizing the clippings files of the New York Times in 1972 l 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

21 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Traditional Chief Programmer Teams (contd) l A chief programmer is a combination of –A highly skilled programmer and –A successful manager l Such individuals are extremely difficult to find

22 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Traditional Chief Programmer Teams (contd) l There is a shortage of highly skilled programmers l There is a shortage of successful managers l A chief programmer requires both abilities in equal measure

23 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Traditional Chief Programmer Teams (contd) l The qualities needed to be a highly skilled programmer differ from those needed to be a successful manager l The chances of finding a chief programmer are small l Traditional chief programmer teams are therefore almost impossible to implement in practice

24 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Traditional Chief Programmer Teams (contd) l What is needed is a more practical way of organizing programming teams –That can be extended to the implementation of larger information systems

25 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Modern Hierarchical Teams l 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 l 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

27 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Modern Hierarchical Teams (contd) l The matrix organizational structure does not violate the fundamental managerial principle that –No employee should report to more than one manager

28 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Modern Hierarchical Teams (contd) l The areas of responsibility are clearly delineated l 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 l 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

29 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Modern Hierarchical Teams (contd) l 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

30 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Modern Hierarchical Teams (contd) l 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 l Surely two managers makes the modern programming team prohibitively expensive?

31 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Modern Hierarchical Teams (contd) l 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 l The total cost of the traditional chief programmer team is therefore about the same as that of the modern hierarchical team

33 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Modern Hierarchical Teams (contd) l This approach scales up as shown in the figure –Only the technical managerial organizational structure is shown –The nontechnical side is similarly organized l For simplicity, the figure does not show nonprogramming personnel, such as the quality assurance group

34 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Modern Hierarchical Teams (contd) l 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 l For even larger systems, additional levels can be added

35 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Modern Hierarchical Teams (contd) l The figures in this chapter show teams of 3 or 4 information technology professionals –This is to achieve clearer, less cluttered diagrams l In practice, teams are usually larger than this –Example: »When the Unified Process is used, teams of size six to eight are recommended

36 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Other Ways of Organizing Teams l 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

37 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Synchronize-and-Stabilize Teams l 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 l Team organization is a vital aspect of the successful construction of products of this size

38 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Synchronize-and-Stabilize Teams (contd) l 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

39 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Synchronize-and-Stabilize Teams (contd) l The requirements phase is conducted by –Interviewing numerous potential customers for the COTS package, and –Extracting a list of features, prioritized by the customers l A specification document is now drawn up that reflects the customers’ responses to the interviews

40 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Synchronize-and-Stabilize Teams (contd) l 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

41 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Synchronize-and-Stabilize Teams (contd) l Each build is carried out by a number of small teams working in parallel l At the end of each day all the teams synchronize –They put the partially completed components together, and –Test and debug the resulting product l 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)

42 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Synchronize-and-Stabilize Teams (contd) l 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

43 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Synchronize-and-Stabilize Teams (contd) l 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 l 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

44 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Synchronize-and-Stabilize Teams (contd) l 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 l 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

45 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Synchronize-and-Stabilize Teams (contd) l 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. l 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

46 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Synchronize-and-Stabilize Teams (contd) l Will use of the synchronize-and-stabilize model guarantee that every other software organization will be as successful as Microsoft? –This is extremely unlikely l 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

47 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Synchronize-and-Stabilize Teams (contd) l Use of many of the features of the model in other organizations could lead to process improvement l 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

48 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Extreme Programming Teams l Extreme programming (XP) is a controversial new approach to information system development –It utilizes iteration and incrementation

49 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Extreme Programming Teams (contd) l The team determines the various features (stories) that the client would like the target information system to support l 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)

50 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Extreme Programming Teams (contd) l 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 l The proposed build is broken down into increments –Here termed tasks

51 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Extreme Programming Teams (contd) l A programmer first draws up test cases for a task l 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 l The task is then integrated into the current version of the information system

52 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Extreme Programming Teams (contd) l 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 l The test cases used for the task are retained and utilized in all further testing

53 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Extreme Programming Teams (contd) l A number of features of XP are unusual: l The computers of the XP team are set up in the center of a large room lined with small cubicles l A client representative works with the XP team at all times l No individual can work overtime for two successive weeks

54 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Extreme Programming Teams (contd) l There is no specialization—all members of the XP team work on requirements, analysis, design, code, and testing l There is no overall design phase before the various builds are constructed—the design is modified while the information system is developed (refactoring) l 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

55 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Pair Programming l A particularly unusual feature of XP is pair programming –All code is implemented by a team of two programmers sharing a single computer l There are a number of reasons why this is done

56 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Pair Programming (contd) l 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 l 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

57 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Pair Programming (contd) l Working in pairs enables a less experienced programmer to learn from the more experienced team member l Thus, there can be distinct advantages to pair programming

58 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Extreme Programming Teams (contd) l XP has been successfully used on a number of small-scale projects l There have also been a number of failures l XP has not yet been used widely enough to determine whether it will fulfill its early promise

59 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Extreme Programming Teams (contd) l Extreme programming is one of a number of new paradigms that are collectively referred to as agile processes l 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

60 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Extreme Programming Teams (contd) l 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

61 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Extreme Programming Teams (contd) l 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 l 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

62 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Extreme Programming Teams (contd) l 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 l The lesson: Building large-scale information systems requires far more specialized and sophisticated skills than those needed to cobble together small-scale information systems

63 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Extreme Programming Teams (contd) l 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.

Similar presentations

Presentation on theme: "Slide 12.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

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

Similar presentations

Presentation on theme: "Slide 12.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with."— Presentation transcript:

Similar presentations

About project

Feedback