Architecture-Centric Software Project Management: A Practical Guide

Description

• Copyright 2002
• Dimensions: 7-3/8" x 9-1/4"
• Pages: 320
• Edition: 1st

• Book
• ISBN-10: 0-201-73409-5
• ISBN-13: 978-0-201-73409-6

To fully leverage the value of software architecture in enterprise development projects, you need to expressly and consciously link architecture with project management. This book shows how, drawing on powerful lessons learned at Siemens, one of the world's leading software development organizations. The authors offer insight into project management for software architects, insight into software architecture for project managers, and above all, insight into integrating the two disciplines to maximize the effectiveness of both of them. Learn how to develop cost and schedule estimates for development projects, based on software architecture; how to clarify architecture so projects can be more effectively planned and managed; and then how to use architecture to organize, implement, and measure the project iteratively as work progresses.



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

