Home > Store

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

  • Sorry, this book is no longer in print.
Not for Sale

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

More Information

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020