Home > Store > Software Development & Management > Management: Lifecycle, Project, Team

Architecture-Centric Software Project Management: A Practical Guide

Register your product to gain access to bonus material or receive a coupon.

Architecture-Centric Software Project Management: A Practical Guide

Book

  • Your Price: $31.99
  • List Price: $39.99
  • Usually ships in 24 hours.

Description

  • Copyright 2002
  • Dimensions: 7-3/8x9-1/4
  • Pages: 320
  • Edition: 1st
  • Book
  • ISBN-10: 0-201-73409-5
  • ISBN-13: 978-0-201-73409-6

Architecture-Centered Software Project Planning (ACSPP) is an important software development methodology for planning software projects. By utilizing software architecture when managing projects, practitioners experience better success completing projects on time and within budget, while effectively fulfilling the project's requirements.

Written for project managers and software architects, Architecture-Centric Software Project Management demonstrates how to draw on software architecture to design schedules, generate estimates, make scope decisions, and manage the development team for a successful outcome. The book addresses each cornerstone of effective project management—planning, organizing, implementing, and measuring.

Dan Paulish provides a wealth of practical, experience-based advice on such topics as:

  • Using architecture to define project organization
  • Developing realistic schedules
  • Using global analysis for project and test planning
  • Managing expectations and deciding when to commit
  • Building a project culture and an effective team
  • Managing tradeoffs and making project decisions
  • Risk management and avoiding unpleasant surprises
  • Defining project success
  • Using architecture for global development

In addition, real-world case studies illustrate the book's strategies, approaches, and techniques. These case studies help the reader fully comprehend the challenges and struggles inherent in software development, and demonstrate how common obstacles can be more easily avoided using an architecture-centric approach.



0201734095B11202001

Sample Content

Online Sample Chapter

Architecture-Centric Software Project Management: An Introduction

Downloadable Sample Chapter

Click below for Sample Chapter related to this title:
paulishch01.pdf

Table of Contents



Preface.

I. MOTIVATION.

1. Motivation.

What is Project Management?

What is Software Architecture?

Core Beliefs.

Project Management Process.

Architecture-Centric Project Management.

Planning.

Organizing.

Implementing.

Measuring.

0 Summary.

II. PLANNING.

2. Architecture-Centered Software Project Planning.

Developing Realistic Schedules.

Approach.

Benefits.

Experience.

Rules of Thumb.

Summary.

3. Global Analysis.

What is Global Analysis?

Global Analysis Activities.

Using GA for Project Planning.

Using GA for Test Planning.

Benefits.

4. Managing Expectations.

When to Plan and When to Commit.

Managing Upward.

Managing Sideways.

Information Flow.

Using the Software Development Plan.

Summary.

III. ORGANIZING. Chapter 5: The Project Organization.

Using Software Architecture to Define the Project Organization.

Architecture Team Roles during Development.

Project Functions that Support Development.

Responsibilities, Roles, Authority, and Ownership.

Summary.

6. Global Development.

Why Global Development?

Architectures for Supporting Global Development.

Development Processes for Global Development.

Multicultural Variables.

Recommendations for Global Development Teams.

Conclusions.

7. Building a Project Culture <38> Team.

Establishing Project Goals.

Characteristics of Good Teams.

Building a Project Culture.

Building Consensus.

Setting the Amount of Direction.

Summary.

8. The Role of the Software Project Manager.

Creating a Vision.

Coaching.

Making Decisions.

Coordinating.

Working with Your Project Team.

Software Project Management as a Career.

Summary.

IV. IMPLEMENTING.

9. Tradeoffs <38> Project Decisions.

Using the Project Goals to Make Decisions.

Managing Creeping Functionality <38> Architecture Drift.

Taking Responsibility.

When to Accept or Reject Changes.

Ethical Decisions of the Project Manager.

Summary.

10. Incremental Development.

Baselining the Software Development Plan.

Build Planning <38> Management.

Getting Everyone Involved.

Tracking Progress.

Incremental Testing.

Release Criteria Meeting.

Tooling.

Summary.

11. Creating Visibility <38> Avoiding Surprises.

Risk Management.

Communicating Status and Issues.

Building Credibility with Management.

Recognizing and Celebrating Success.

Summary.

12. Staying Calm in the Heat of Battle.

Cheerleading, Micro-management, <38> Discipline.

Remaining Optimistic.

Playing the Quality Card.

Providing Support <38> Removing Obstacles.

Handling Problem Employees.

Emotions <38> Avoidance.

Quality of Work Life.

Summary.

V. MEASURING.

13. Measures to Pay Attention To.

Global Metrics for Project Managers.

Phase Metrics for High-Level Design.

Cost-to-Completes.

Engineering Budgets.

Watching the Test Results.

Summary.

14. What is a “Good Job”?

Trading off Schedule, Functionality, <38> Quality.

Defining Project Success.

Measuring Team Member's Contributions.

Rewards.

Staff Turnover.

Summary.

VI. CASE STUDIES.

15. IS2000.

Background.

System Overview.

Project Planning.

Project Management.

Lessons Learned.

16. DPS2000.

Background.

Global Analysis.

Product Line Design Strategies.

DPS2000 Architecture.

Project Planning.

Project Management.

Lessons Learned.

17. Conclusions.

Sharing Best Practices.

Benefits.

Summary.

VII. APPENDIX.

Appendix - Forms.
Glossary.
Bibliography.
Index.

Preface

As computer hardware provides more functionality at a lower cost, the need for new applications software is exploding. The world-wide-web is providing more information to more people at an ever-faster rate. Software products must be developed quicker, with increased functionality, performance, and quality. The pressure on the software engineers who are developing new products and maintaining existing products is increasing.

This book provides some support to the software project managers who are attempting to juggle the demands of meeting their schedule while delivering features with good quality. Our experience with observing and participating in many software development projects indicates that good design and project management skills go a long way in achieving successful projects. What is very clear is that it is unlikely that projects will be successful when the software architecture is not well designed or project management skills are missing. We have observed the connections between good software architecture and good project management on many projects, and we hope that some of the tips provided will result in better products.

Motivation

As an industry, we have not been very successful in managing successful software projects. Successful projects are those that meet their planned development schedule, provide the functionality promised, and deliver good quality software. From the 1995 Standish Group CHAOS report, their research on software projects reported that 16% of projects were completed successfully, 31% were cancelled outright, and 53% were substantially over budget and schedule and delivered less functionality than specified. By 1998, more projects were successful, with 26% completed successfully, 28% cancelled, and 46% over budget and schedule with less functionality Johnson 1999. Thus, things are improving, but we still have a terrible track record in our industry for successfully completing software development projects.

Background

The experience for writing this book was gained while managing software design and development projects in Siemens. As part of the Siemens Software Architecture R&D Program, a large number of Siemens projects have been investigated in order to capture how Siemens software architects design software systems. The knowledge gained from this research has been embodied within the four views architecture design approach described in the Applied Software Architecture book written by Christine Hofmeister, Rod Nord, and Dilip Soni Hofmeister 2000. As the four views approach was being developed, we had opportunities to participate as architecture design team members for new products being designed in various Siemens businesses. In some cases, we were also asked to plan and manage these new product developments and implement subsystems of components of the architecture. Thus, our project planning and management methods were developed in parallel with the four views design approach.

A concrete example of this correlation between architecture design methods and project planning methods is our architecture centered software project planning (ACSPP) approach described in chapter 2. We used this approach to develop cost and schedule estimates for the development projects, based on the software architecture. Since we were heavily involved with participating in software architecture design teams, we began to believe in the advantages to be gained when project planning was done in parallel with design. We were also called into Siemens companies as reviewers, from time to time, and we consistently observed warning flags for projects that either were not planned well or were missing a software architecture that could be easily communicated to the reviewers or the development team.

Over this same time period, the importance of software products and good development practices increased. We began to observe that our project planning and management methods were having a significant business impact in that they helped get software products to the market quicker and more predictably. Thus, our initial research interest was focussed more towards design methods and tools, but also we began to see the importance of good project management practices for meeting project goals.

As we became involved with real design and development projects, we realized that the key to effectively applying our methods rested with the working relationship between the project manager and the chief architect. These roles are described respectively within chapter 8 of this book and chapter 12 of Hofmeister 2000. When the chief architect and project manager work together as a decision making team, it's much easier to introduce and tailor the methods we describe herein within a specific development project. We also got to observe the problems that can arise when one individual tries to fulfill both of these roles for development teams that are bigger than a few people.

Not all the project management tips we present in this book are directly related to architecture design. But, enough of them are related, and we feel that a good software architect needs to understand some simple project management techniques in order to be successful within the chief architect/project manager leadership team. Good architects are primarily involved in making technical decisions, but they also appreciate the soft factors involved with leading projects. They often serve as sounding boards or critics of the project manager concerning any decisions that may affect the morale of the developers. Furthermore, we believe that project managers should provide a supportive environment to the chief architect and the entire development team, such that good design practices are consistently applied.

The biggest benefit of working within an industrial laboratory is that you have opportunities to do both research and development. In our case, we've had the opportunity to research methods such as the ones that are described in this book. But, we've also had the chance to apply the methods to real projects. As a result, the methods have been tweaked to be practical such that they are relatively easy to apply. Along the way, we've had the opportunity to design, plan, and develop Siemens software products that have been successfully sold in the market. We have attempted to conceal the real identity of these products in our examples and case studies, since we often describe real world problems that we have had to overcome. But, for the most part, the products that we have applied our design and project management methods to have been successfully developed and sold in the market.

The projects that we have worked on tend to be mid-sized projects. Typically, they have been in the order of ten to twenty software engineers. We cannot claim that our project management methods will work for very large or very small projects, since we have limited experience. Furthermore, since software development projects can last a year or more in duration, we have limited personal experience even for the types of projects that we have worked on. We will conveniently ignore these facts, and we will explain the various tips and methods as if they are great things that every project manager should do. However, there are no silver bullets within what we describe, although it may sound that way at times. A "leap of faith" will be required on the part of the reader to experiment with applying the methods we describe. Unfortunately, this is a persistent problem within most of software engineering since real experimentation is often very limited. Thus, our tips are mostly anecdotal in nature.

How to Use this Book

The primary audience for this book is software project managers. The secondary audience is software architects who must work closely with project managers. The third audience is software developers who are looking for insights on how to work within a project team, and who may be considering career changes to the first two groups. The book is mainly a collection of tips that could be used for software development projects. Each tip must be tailored to the unique circumstances of the project being worked on.

The tips are structured roughly in the sequence of planning, organizing, implementing, and measuring for which a project manager will be involved. However, there is no strict sequence of steps implied, since these management tasks will be iterated up until the product is released.

It's probably best to begin reading the planning Part II of the book, particularly the description of architecture centered software project planning (ACSPP) in Chapter 2. Once you understand the steps involved with estimating the schedule for your project, you can read the other chapters. The case studies in Part VI of the book should probably be read last. These may or may not be interesting to you, depending on the type of software that you develop. Examples from the case study projects are also included throughout the book.



0201734095P09052001

Index

A

Application Service Provider (ASP), 236
Architects, software
assignment of team leaders, 85-87
code writing and, 87
development of project teams and role of, 82-85
relationship of project manager with chief, 139-141
Architecture, software
DPS2000 example, 237-240
loosely coupled, 220
scalability, 239
three-tiered, 237-239
Architecture-centric project management,
overview of, 7-10
Architecture-centered software project planning (ACSPP) See also Planning
benefits, 247-248
sharing best practices, 245-247
Architecture drift, 150151
Architecture evaluation, 58-59
Architecture layer diagram, 23, 24-25, 39, 82
Architecture Tradeoff Analysis Method (ATAM), 58-59, 199, 237
Athena, 235, 237
Austin, Robert, 197
Author, 108
Avoidance, 187-189

B

Baseball, 71, 197
Best practices, sharing, 245-246
Billing determinants, 231
Boehm, Barry, 19-21
Bonuses/rewards, 211-213
Boss watchers, 188
Bottom-up estimates, 28-32, 83-84
form for, 260
ISO2000 example, 223
Budgets
over or under, 202-203
tracking, 203
Bugs. See Defects
Buildmeister, 92-93, 94
Build plan, 32, 33, 161-162
form for, 260
Buy-in, 137

C

Capability Maturity Model (CMM), 6
Carleton, Anita, 196, 198, 214
Carnegie Mellon University, Software Engineering Institute at, 58, 237
Changeability, 46-48
Characteristics of good teams, 121-123
Cheerleading, 180-181
Coaching/mentoring by project managers, 136-137
Cocomo Model, 21, 26, 224
Code inspections
goals of, 106-107
guidelines for size and timing of, 109-110
reasons for, 106
roles of teams, 107
steps for, 107-108
Code walkthroughs, 106
Coding standards, 107
Commercial off-the-shelf (COTS), 51
Communication, importance of, 174-175
Component
conceptual, 24-25
estimation form, 259
source, 24
Component release specification (CRS), 32, 37
Computation engine, 239
Conceptual components, 25
Confidence, instilling, 127-128
Configuration management (CM), 94
global development and, 104-105
incremental development and, 169
Connectors, 24
Consensus, building, 129-130
Constructive Cost Model (Cocomo), 21, 26, 224
Constructive testing, 90-91
Consumer tree, 238-239
Convention checking of code, 108
Coordinating role, of project managers, 138
Cost-to-complete estimation, 200-202
form for, 260
C++, 220
Creating a vision, 136
Credibility, building, 175-176
Credit card authorization terminal, 209
Creeping functionality, 149-150
Crisis du jour, 182-183
Critical design review (CDR), 59
Cross-functional team, 220
Cry-wolf manager, 182
Cultural barriers and resistance, 123-125
Cultural issues, global development and, 111-113
Customer change requests, measuring, 198

D

Data Acquisition System, 220-221, 235-236, 238
Data Processing System 2000 (DPS2000)
architecture, 237-240
background of, 231-232
design strategies, 235-237
global analysis, 232-235
lessons learned, 242-243
planning, 240-241
project management, 241-242
Database, 237-239
Decision making
ethical issues, 155-157
gut reactions, 154
importance of flexibility, 148-151
just-in-time, 188-189
project managers and, 137-138
responsibility for, 151-152
using goals for, 148
when to accept or reject changes, 152-154
Defects
defined, 197
measuring, 197-198
other terms for, 197
tracking, 169, 203-204
Denver Airport baggage handling system, 245
Deregulation, 231
Design
DPS2000 example, 235-237
high-level, 22-25, 199-200, 222
ISO2000 example, 221-222
paper, 13, 28
strategies and
global development, 100
Design
changes/drift, 150-151
when to accept or reject changes, 152-154
Development status teleconferences, 102-104
Direction/support of teams, 130-133, 180-183
Discipline, 182
Distributed project management, 101-102
Downsizing, 214

E

Earned value (EV), 202
E-commerce, 236
Emotions, handling your own, 187-189
Employees
firing/terminating, 156-157
handling problem, 187
personality conflicts, handling, 125-126
turnover of, 214-215
Engineering change orders (ECOs), 153
Engineering change requests (ECRs), 153
Engineering review boards (ERBs), 153
Errors. See Defects
Estimation
bottom-up, 28-32, 223
for budgets, 202-203
cost-to-complete, 200-202, 260
forms for, 29, 259-260
models, 26-27
rules of thumb, 41-43
spreadsheet, 31
Ethical issues, decision making and, 155-157
Europe, 114
Experienced, 132
Extreme programming, 6

F

Factor tables, 48, 49-51
Fagan, Michael, 106
Fagan inspections, 106, 109-110
Feature release specification (FRS), 32, 37
Firing employees, 156-157
Fiscal year, 211
Flexibility, importance of, 148-151
Forms, examples of, 253-260
Four-eyes principle, 90
Four views of software architecture, 22-25, 237
Function point analysis (FPA), 26, 194

G

Germany, 97, 110, 112-113
Getting to know you meeting, 126-127
Global analysis (GA)
activities, 48-55
architecture evaluation, 58-59
benefits, 65
defined, 46-48
DPS2000 example, 232-235
factor tables, 48, 49-51
global development and, 98-99
issue cards, 48, 51-52, 53
organizational factors, influence of, 52-55
planning and use of, 56-64, 222
product factors, influence of, 55
product strategy conclusions, 57-58
risk analysis, 59-61
steps, 48
technological factors, influence of, 55
test planning and use of, 64-65
Global development
architectures for supporting, 100
code inspections, 106-110
configuration management and, 104-105
distributed project management, 101-102
holidays and vacations, 110-11
managers, 102
meetings, 105
multicultural issues, 111-113
processes for, 101-111
reasons for, 98-100
teams, recommendations for, 113-116
tracking projects, 102-104
travel, 111
Global metrics
customer change requests, 198
defects, 197-198
productivity, 196-197
schedule deviation, 195-196
size, 194-195
versus phase metrics, 194
Goals
development of, 61-62, 120-121
for release criteria meetings, 168
use of, for decision making, 148
Godfather, 152
Golden Glove award, 197
Graphical user interface (GUI), 55, 234

H

Hardball, 71
Head count, 196
Heat of battle, 179
High-level design, 22-25
ISO2000 example, 222
phase metrics for, 199-200
High-level design document (HLDD), 23, 37
Hofmeister, Christine, 5, 24, 46, 87, 237
Holidays,
global development and, 110-111
Humphrey, Watts, 197

I

Image processing, 25
Imaging System 2000 (IS2000)
background of, 219-220
lessons learned, 228-229
overview of, 220-221
planning, 221-225
project management, 225-228
Implementing
description of, 4
role of project manager in, 13-14
steps, 14
Incentives, 212-213
Incremental development, 6
baselining software development plan, 160-161
build and release planning, 161-162
involvement of everyone, 162-163
release criteria meetings, 167-168
role of, 159
tools for, 169
tracking progress, 163-166
Incremental testing, 166-167
Influencing factors, 46
Information flow, 74-75
Intermediate, 132
Issue cards, 48, 51-52, 53
form for, 256-257
Iterative development. See Incremental development

J

Jones, Capers, 27, 194
Just-in-time decision making, 188-189

K

Kazman, Rick, 58, 237
KLOC (thousands of lines of code), 41
Kopper, Enid, 111

L

Language, working, 113
Layoffs, 214
Leveson, Nancy, 246
Lines of
code
chief architect writing of, 87
measuring, 109-110, 194-195
Load profile, 239

M

Making decisions. See Decision making
Management/managing See also Project management
by objectives (MBO), 211
information flow and, 74-75
matrix, 88-89
sideways, 72-74
software development plan and, 75-77
upward, 70-72
when to plan and commit, 68-70
Management direction
defined, 131
of teams, 130-133, 180-182
Management support
defined, 131
providing, 186-187
Marketing managers
relationship of project managers and, 91-92
responsibilities of, 94
Mars Polar Lander, 246
Matrix managers, 88-89
Measuring
See also Metrics
contributions of team, 210-211
description of, 4
role of project manager in, 15-16
steps, 15
Meetings
global development and, 105
introductory, for teams, 126-127
Meetings,
release criteria, 167-168
weekly status, 164-165
Mentoring by project managers, 136-137
Meter data-processing station, 232
Metrics
See also Global metrics; Phase metrics
cost-to-complete, 200-202
staff turnover, 214-215
Micro-management, 181-182
Microsoft
COM, 234
Excel, 235, 239
Project, 36
Mid-course corrections, 7
Middleweight processes, 6, 246
Milestone dates, pick release, 33-34
Moderator, 107
Modules, 24, 25, 82
Moeller, Karl, 194, 196, 198
Monitoring. See Measuring
Morale, 128
Multicultural variables,
global development and, 111-113
Multisite development, 34, 236
Murphy's Law, 137

N

Nord, Robert, 5, 24, 46, 87, 237
Nicknames, 93
Novice, 132
Nuremberg, 113

O

Openness, 123
Optimism, 183-185
Oracle, 234
Organization
description of, 4
product development and, 81-95
role of project manager in, 12-13
software architecture to define, 81-85
steps, 12
Organizational
factors, influence of, 52-55
DPS2000 example, 233
form for, 253-254
global development and, 99
Organizing
architecture team, 85-86
development team, 81-83
Ownership, 93

P

Paper design, 13, 28
Park, Robert, 194
Patent disclosures, 211
Paulk, Mark, 6
Performance. See Success and performance
Personality conflicts, handling, 125-126
Personal schedules, 38-39
ISO2000 example, 224-225
Phase metrics
for high-level design, 199-200
versus global, 194
Pizza party, 177
Planning
applications/experiences, 40-41
approaches used in, 21-30
benefits, 39-40
bottom-up estimates, 28-32
build, 32, 33, 161-162
description of, 3-4
developing realistic schedules, 19-21
DPS2000 example, 240-241
global analysis and, 56-64
high-level design, 22-25
ISO2000 example, 221-225
personal schedules, 38-39
phases, 20
project schedule, 34-36
release plans, 32-34, 62-64, 162, 223
role of project manager in, 10-12
rules of thumb, 41-43
software development plan, 37-38
steps, 10
test, 64-65
top-down schedule, 25-28
Planning, organizing, implementing and measuring (POIM), description of, 3-4
Platform, DPS2000, 232
Postmortem reviews, 15-16
Power, 89-90
PRICE-S, 26
Princeton, New Jersey, 84
Product factors, influence of, 55
DPS2000 example, 234-235
form for, 255-256
Productivity, measuring, 196-197
Product line architecture (PLA), 220, 231
Professional sports, 77, 119
Programmable read-only memories (PROMs), 138
Project developers,
responsibilities of, 94
Project development
functions that support, 88-93
ISO2000 example, 224
role of development team in, 85-87
roles and responsibilities during, 93-94
Project management See also Management/managing
as a career, 142-143
defined, 3-5
distributed, 101-102
DPS2000 example, 241-242
global development and distributed, 101-102
ISO2000 example, 225-228
process, 7
Project managers
coaching/mentoring by, 136-137
code inspections and, 109
code writing and, 87
coordinating role, 138
decision making and, 137-138
relationship with team members, 139-141
roles and responsibilities of, 93-94, 144
vision of, 136
Project managers, support functions and
buildmeister, 92-93
marketing, 91-92
matrix of, 85-86
power of, 89-90
testing and quality assurance, 90-91
Project schedule, 34-36
ISO2000 example, 224
Project strategies
conclusions, 56, 57-58
development of, 61-62
form for summarizing, 258
Project success. See Success and performance
PROMs. See Programmable read-only memories
Prototyping, 232
Putnam, Larry, 27

Q

Quality
decision making and issues of, 185-186
of work life committee, 189
Quality assurance (QA), 90-91

R

Rational Unified Process (RUP), 6
Release criteria, 138
Release criteria meetings, 167-168
Release dates
incremental, 167
picking, 33-34
in project titles, 70
Release plans, 32-34, 162
global analysis and, 62-64
ISO2000 example, 223
Realistic schedules,
developing, 19-21
Requirements
analysis, 8-11
churn, 149
Research and development (R&D), 72
Resistance,
cultural barriers and, 123-125
Responsibilities and roles
of buildmeister, 92-93, 94
of developer, 94
of marketing managers, 94
of project managers, 93-94, 138, 144
of team leader, 93-94
of teams, 107
of test managers, 94
Review
critical design, 59
engineering review boards (ERBs), 153
postmortem, 15-16
Reviewer, 108
Rewards, 211-213
Risk analysis, 59-61, 172-174
Roles. See Responsibilities and roles
Rules of thumb, 41-43

S

Safety-critical applications, 249
Scalability, 239
Scenarios, use of, 59
Schedules
developing realistic, 19-21
deviations, measuring, 195-196
importance of visible, updated, 36
ISO2000 example, 222-225
personal, 38-39, 224-225
project, 34-36, 223-224
skeleton, 34, 35
top-down, 25-28, 222
Self-fulfilling prophesy, 162
Self-starters, 133
Sexual harassment, 155
Sharing best practices, 245-246
Siemens, 42, 70, 111, 196, 198
Size, measuring, 194-195
SLIM, 26
Softball, 71
Soft factors, 7
Software
commercial off-the-shelf (COTS), 51
development process, 7
engineering, 245
experiments, 245
Software architecture
defined, 5-6
views of, 23, 24
Software development plan (SDP), 9, 37-38
baselining, 160-161
global analysis and, 64
managing and use of, 75-77, 240-241
Software Engineering Institute at Carnegie Mellon University, 58, 237
Soni, Dilip, 5, 24, 46, 87, 237
Source component, 24-25
Specifications
component release (CRS), 32, 37
feature release (FRS), 32, 37
Staff  See also Employees
day, 196
turnover, 214-215
year, 221
Standards, coding, 107
Standish Group, xviii
Strategies. See Project strategies
Subsystems, 25
Success and performance
defining, 209-210
factors influencing, 208-209
measuring contributions of team, 210-211
project versus individual, 210
recognizing, 176-177
rewards, 211-213
staff turnover, 214-215
Support, providing, 186-187
Support functions. See Project managers, support functions and Surprises
avoiding, 171-178
reacting to, 184-185
Switzerland, 97, 112-113, 242
System testing, 64-65

T

Tariff agreement, 232
Team(s)
assignment of leaders, 85-87
building training, 124
celebrations, 176-177, 189
characteristics of good, 121-123
confidence, instilling, 127-128
consensus among, building, 129-130
cultural barriers and resistance, 123-125
development of, 82-85
goals and, 120-121
inspection, 109
introductory meetings for, 126-127
management direction of, 130-133, 180-183
measuring contributions of, 210-211
personality conflicts, 125-126
recommendations for global, 113-116
relationship of project managers with, 139-141
responsibilities of, 85-87, 93-94
trust, openness and communication in, 123
Team leaders
assignment of, 85-87
responsibilities of, 93-94
Technological factors, influence of, 55
DPS2000 example, 233-234
form for, 254-255
Teleconferences, use of, 102-104
Terminating employees, 156-157
Test (testing)
for defects, 90-91, 203-204
incremental, 166-167
planning, 64-65, 73
procedures, 64
system, 65
watching for results, 203-204
Test managers,
responsibilities of, 94
Therac-25, 246
Three-tiered architecture, 237-239
Time to market, 53
Tooling, 169
Top-down schedule, 25-28
ISO2000 example, 222-223
Top-10 bug list, 168
Tracking
budgets, 203
defects, 169, 197-198, 203-204
progress, 163-166
Tracking projects,
global development and, 102-104
Trade-offs, 15, 121, 243
Training, team-building, 124
Travel,
global development and, 111
Trust, 123
Turnover, staff, 214-215

U

Unified Modeling Language (UML), 114
Uniform resource locator (URL), 242

V

Vacations,
global development and, 110-111
Values, 127
Vertical slice, 32, 127, 240
Visibility, schedule, 36
Voting with their feet, 214

W

Walkarounds, 124-125, 164
Walkthroughs, code, 106
Web
based GUI, 234, 236, 238-239
browser, 238
pages, 237
server, 238
Whiffleball, 71
Working conditions, improving, 189

Updates

Submit Errata

More Information

Unlimited one-month access with your purchase
Free Safari Membership