Index
A
Absolute criticality, color coding floats, 203–204, 267
Abstract structural dependencies. See also Activity dependencies, 339
Actions, corrective. See Corrective actions
Activities. See also Activity dependencies; Scheduling activities
activity network. See Project network
color-coding for risk, 240–243
creating a list of, 158, 260–261
formula for effort of an activity for tracking, 392
god. See also God service, 15, 30, 68, 307–308
life cycle and project tracking, 388–392
quality-assurance activities, 381–382
quality-control activities, 380–381
TradeMe project design case study, 346–347
what is an activity, 195
Activity dependencies. See also Project network
arrow versus node diagrams, 197–198
critical path analysis, 168–169
dummy activities, 197
and milestones, 262
in the network diagram, 195
the node diagram/arrow diagram, 196
project design, TradeMe project design case study, 339–341
resources and, 176
working in parallel, removing, 211–212
Activity diagrams. See also Use cases
the business logic layer, 62–63
TradeMe system design case study, 105
Activity life cycle
Activity risk
calculation pitfall, 247
versus criticality risk, 248
geometric activity risk, 317–320
introduction to and formula, 245–246
project design, in action, 293–294
TradeMe project design case study, 356
Actor model, future-looking design, 121
Amos Tversky. See Prospect theory (Kahneman, Tversky)
Analysis, avoiding paralysis in, 7–8
Anti-design effort
functional decomposition, 20–21
TradeMe system case study, 106–108
Architects
importance of having a single, 147–148
job description, 150
role and responsibility, 194
Architecture. See System design
Arithmetic risk, versus geometric risk, 316–319
Arrow diagram
versus the node diagrams, 197–198
project design, in action, 261–262, 272, 273, 278, 287, 351
project design in action, 283
TradeMe project design case study, 342, 347
Assembly, instructions, project design, 141
Assigning resources. See Resources
Atomic business verbs, 64, 69, 81, 93, 115, 417
Atomic business verbs, in naming, 66
Axes of volatility. See also Volatility-based decomposition
decomposition of a house, 39–40
volatilities list and, 42
B
Bad habits. See Siren song of bad habits
Behavioral dependencies. See also Activity dependencies
versus values, 370
Behaviors, required. See also Use cases
business logic layer and implementing required, 61–62
classification guidelines, 65
not values, risk tipping point, 370
rather than required functionality, 56–57
Best practices. See also Design standard
to accelerate projects, 207–210
importance of following, 159
quality-assurance and, 381–382
risk metrics, 253
Big projects. See Large projects
Broadband estimation
in design of project design, 370
in TradeMe project design case study, 338
Brooks, Frederick Dr., 8–9, 401
Business logic
calling ResourceAccess by, 78
in clients with functional decomposition, 15–16, 29
in clients with open architecture, 75
C
Calendar dates, scheduling activities, 176
Call chain diagrams. See also Use cases
architecture validation and, 87–88
and creating dependencies, 339
project design in action, 257–259
TradeMe system design case study, 124–135
Changes, in requirements. See Requirements analysis
Chimera, multiple architects issue, 148
Classification guidelines
introduction to, 65
Managers-to-Engines ratio, 67–68
Clients
bloat and coupling in functional decomposition, 15–17, 107
client designs and working in parallel, 278–279
compression with simulators, 284–285
infrastructure and client designs first, 280–283
integration process, 146
open architecture example, 75–76
opening the architecture, 79
relevant design questions, 66–67
TradeMe system design case study, 117, 119–120
volatility decreases top-down, 68
volatility in TradeMe system design case study, 114–115
Closed architecture. See also Open architecture
introduction to, 76
opening, 79
semi-closed architecture, 76–77
Color-coding
activities by risk, 240–243, 271, 316
Communication
with developers and managers, 8–9, 55, 65, 68, 198
optionality, in design standard, 428
through network diagrams, 198
Competitors, identifying volatilities, 50–51
Complexity, project
cyclomatic. See Cyclomatic complexity
parallel work, 213
reducing for TradeMe project, 340–341
reducing with The Method, 76
Components. See Services
Composable design
definition, in complexity, 326
definition, in TradeMe project design case study, 129
in design standard, 425
Composition. See also Requirements analysis
introduction to, 83
requirements and changes, 83–85, 92–93
smallest set of components, 89–90
Compression, of schedule. See also Parallel, working in; Project network
compared with normal solution, 287–289
full compression solution, 216
infrastructure and client designs first, 280–283
introduction to, 210
network compression, 231
parallel work and cost, 213–214
with top resources, 368
TradeMe project design case study, 346–350
trimming the fuzzy front end, 369
using a second top developer, 278
using a top developer, 276–278
working in parallel, 211–213, 278–280, 322
working with better resources, 210–211
Connection volatility, trading system, 43
Connectivity, cyclomatic complexity, 321
Constraints, through design decision tree, 8
Construction
benefits of incremental, 70–72
layers and, 334
Contracts, designing service contracts. See Service contract design
Conventions, naming services, 65–66
Conway’s law (Melvin Conway), countering, 331
Core team
cost elements, 229
designing the fuzzy front end, 151
initial project staffing, 149–150
and staffing distribution, 177–178
TradeMe project, normal solution, 341
Core use cases. See also Use cases
diagrams supporting support of, 88–89
smallest set of components, 86–87, 89–90
TradeMe system design case study, 104–105
Corrective actions
Correlation models, time-cost, 291–292
Cost. See Direct cost; Project costs
Coupled client, functional decomposition, 15–17, 107
Coupled design, tight vs. loose, 156
Coupled services, functional decomposition, 14, 17–19
Critical path analysis. See also Effort estimations
compressing activities, 231–232
history of, 199
network diagrams. See Network diagrams
proactive project management, 204
Criticality risk. See also Risk
versus activity risk, 248
introduction to and formula, 241–244
metrics, 253
project design in action, 295
subcritical staffing, 272–274, 322
TradeMe project solution comparison, 355
visualizing total floats by, 203–204
Crossover point, of risk
acceptable risk and design options, 312
Customers
interview using axes of volatility method, 37–38
product managers relationship with, 150
Cyclomatic complexity
in design standard, 429
designing a network of networks, 329
designing by layers to reduce, 333, 350
formula for, 321
measuring service contracts, 420
problems with functional design, 16–17
project type and complexity, 322
D
Deadlines
importance of staying on the plan, 399
overestimating, 403
underestimating, 400
Death zone, in time-cost curve, 218–220, 223
in project design in action, 292
Debriefing, project design, 378–379
Decision-making, educated decisions, 151–152
Decomposition. See also Domain decomposition; Functional decomposition; Volatility-based decomposition
introduction to, 13
maintenance and development and, 32–33
Decompression target. See also Risk decompression
recommended ideal, 301
Demarco, Tom, 174
Dependencies. See Activity dependencies
Dependency chart. See also Network diagrams
project activity network, 167–168
project design in action, 258–260
Design, project. See Project design
Design standard
directives, 426
introduction to, 425
project design guidelines, 427–429
project tracking guidelines, 429–430
service contract design guidelines, 430
system design guidelines, 426–427
Design, system. See System design
Developers
assigning services to, 153–155
assigning to critical path activities, 172–173
design and team efficiency, 155–157
float-based assignment, 173, 205–206
importance of design communication, 8
junior versus senior developers, 210–211
junior versus senior project hand-off, 374–376
project managers relationship with, 149
senior developers as junior architects, 376–377
training and improving skills new technology, 208–209, 381–382
Diagrams
activity. See Activity diagrams
network. See Network diagrams
Direct cost
versus indirect cost, 229
introduction to, 222
and risk, 241
and risk decompression, 297
risk models and minimum, 301
time-cost curve and minimum, 299–300
total, direct and indirect costs, 223–224
Discrete modeling, time-cost curve, 217
Domain decomposition
building a domain house, 23–24
TradeMe system design case study: anti-design effort, 108
Dummy activities, 197
Dunning-Kruger effect, 36
Duration, project. See Project duration
E
Earned value planning
discerning mistakes through, 189–190
in project design in action, 266, 271, 274
as a project design tool, 187–189
in throughput analysis, 287–289
for tracking with project progress, 393–394
TradeMe project compressed solution, 348
TradeMe project normal solution, 344
TradeMe project subcritical solution, 353
Educated decisions, making, 151–152
Efficiency. See Project efficiency
Effort estimations. See also Critical path analysis
architecture versus estimations, 365–366
estimation techniques, 160–162
estimation tools, 163
importance of debriefing, 378
overall project estimation, 162–165, 394
overestimating and corrective actions, 402–403
resource leak and corrective actions, 401–402
TradeMe project design case study, 335–338
underestimating and corrective actions, 400–401
Effort, versus scope calculations, 372–373
Elasticity of staffing, project efficiency and, 186
Emulators development. See also Simulators, 212
Engines
the business logic layer, 62–63, 117
relevant design questions, 66–67
in TradeMe system design, 114–117
Estimations, effort. See Effort estimations
Execution complexity, resulting from compression. See also Complexity, project; Cyclomatic complexity, 213, 228, 249
Experts, external
providing access to, 209
TradeMe project design case study, 342
Exponential criticality, visualizing floats, 203
Extensibility, benefits of, 72
External service protocols, 74
F
Facets, contracts as, 412
Factoring contracts
factoring up, 419
Feasibility, time-cost curve and. See also Death zone, in time-cost curve, 218–220
Feast or famine cycles, staffing distribution, 177
Feed Me/Kill Me meetings. See also Educated decisions, making; SDP Review, 153
Fibonacci risk
compared with criticality and activity risk, 248
formula for and introduction, 244–245
geometric, 317
Financial analysis, project, 364
Floats
assigning resources, 173
dedicated resources and, 275
float-based assignment, 173, 175, 205–206
proactive project management, 204
Formulas
activity risk, 246
criticality risk, 242
cyclomatic complexity, 321
effort of an activity, 392
geometric activity risk, 318
geometric criticality risk, 316
geometric Fibonacci risk, 317
The Method, 4
PERT (Program Evaluation and Review Technique), 162
planned earned value, 187
progress of an activity, 391
project cost, 184
project effort, 394
project progress status, 392
time for completing an activity, 169
total cost, 223
Functional decomposition
avoid, in design standard, 426
compared with volatility-based decomposition, 32–33
example of functional house, 21–22
example of functional trading system, 27–30
handling requirement changes, 92
physical versus software systems, 26–27
TradeMe system design case study: anti-design effort, 106–108
Fuzzy Front End
compressing, 369
core team responsibilities, 151
with cost elements, 229
gathering assumptions, 265
introduction, 151
G
GE (General Electric), time-cost curve history, 225
Geometric risk
Fibonacci risk, 317
God activities. See also Geometric risk; God service, 307–308, 319–320, 429
Golden ratio. See also Phi
in Fibonacci risk, 244
Guidelines, classification. See Classification guidelines
H
Hand-off, design
with contract design, 423
in design standard, 430
introduction to, 374
junior hand-off, 375
senior developers as junior architects, 376–377
senior hand-off, 375
Hierarchy of needs, project design, 141–144
Historical records, project estimation, 163
Homer’s Odyssey. See Siren song of bad habits
HTTP, microservices, 74
I
IDesign
customer network drawing tool, 197
introduction to, 3
managers to engines ratio, 68
number of core use cases, 86
TradeMe project design case study, 95
TradeMe system design case study, 335
Indirect costs
versus direct cost, 229
and risk, 228
versus total cost, 230
total, direct and indirect costs, 223–224
Infrastructure
at the beginning of the project, 267–268, 341
and client designs first, 280–283
first, with limited resources, 269
investing in, 208
Inherited dependencies
introduction, 258
in TradeMe project, 341
Interaction rules. See Design don’ts
J
Junior architects
supporting the architect, 149
Junior developers
K
Kahneman, Daniel. See Prospect theory (Kahneman, Tversky)
L
Large projects
complex systems and fragility, 325–327
designing a network of networks, 328–331
Layered design
introduction to, 58–59, 332–333
layers and construction, 334
open and closed architectures, 75–79
reuse, 69
TradeMe system design case study, 116–119
typical layers in The Method, 60–61
Life cycle, of activity
Load leveling, 184
Locale volatility
TradeMe system design case study, 115
trading system example, 44
Logistic function
compression and complexity, 323
decompression target, 251–252, 313
overview of, 192
M
Management
communicating in optionality to, 366–367
presenting multiple project plans, 153
presenting projections, 404–405
Manager, product, job description, 150
Manager, project, job description, 149
Managers
calling Engines, 78
compression with simulators, 284–285
creating subsystems, 70
in TradeMe system design, 114–117
Megaprojects. See Large projects
Message bus
for extensibility and flexibility, 109
in Message Is (application), 120
for notification, 115
in TradeMe project design case study, in abstract dependencies, 339
in TradeMe project design case study, in nonstructural activities, 337
in TradeMe project design case study, in overriding dependencies, 340–341
in TradeMe project design case study, in structural activities, 336
in TradeMe system design case study operational concepts, 119–121
Message Is (application)
with actor model, 121
in TradeMe system design case study, 131
Metcalfe’s law, 326
The Method
classification guidelines, 65–70
eliminating analysis-paralysis, 7–8
time crunch, 6
typical layers in The Method, 60–61
Metrics
collecting and analyzing, 382
contract design metrics, 419–423
risk metrics, 253
Microservices
Microsoft Project, 170, 176, 202
Milestones
arrow diagrams and, 197
project design in action, 262
public and private milestones, 262
TradeMe project design case study, 341
Minimum cost, services, 411, 412
Minimum direct cost
in project design in action, 299–300, 301
in TradeMe project design case study, 310, 358–-359
Minimum duration solution, time-cost curve, 216, 218
Models
project design in action risk models, 300–302
project design in action time-cost model, 291–292
TradeMe project design case study risk models, 356
TradeMe project design case study time-cost models, 358–-359
Modules. See Services
N
Naming conventions, services, 65–66
Network compression. See Compression, of schedule
Network diagrams. See also Critical path analysis
arrow versus node diagrams, 197–198
introduction, 167
node diagram, 196
project design in action, 261–262, 271, 273, 278, 283, 287
TradeMe project case study, 342, 347, 351
Network of networks
benefits of, 328
countering Conway’s law, 331
Network, project. See Project network
Node diagram
versus the arrow diagram, 197–198
introduction to, 196
Nonbehavioral dependencies, TradeMe project, 340
Noncoding activities, TradeMe project, 338
Nonstructural coding activities, TradeMe project, 336–337
Normal solution
decompression, 250
introduction to, 215
and minimum direct cost, 251–252
and minimum total cost, 225–228
project design in action, 265–276
and the risk curve, 238
risk metric guideline, 253
O
On the Criteria to Be Used in Decomposing Systems into Modules (Parnas), 34
Open architecture. See also Closed architecture
issues of calling up and sideways, 107
Operational concepts, TradeMe project, 119–122, 340
Operational dependencies. See also Activity dependencies, 339–340
Optimal project design point
with risk, 252
in project design in action, 301
in TradeMe project design case study, 359–360
Optionality, communication with management, 366–367
Outliers floats, adjusting
with geometric activity risk, 318
project design in action, 295
in TradeMe case study, 356
P
Parallel life cycles, 374
Parallel, working in
compression with simulators, 284–285
infrastructure and client designs first, 280–283
multiple developers per service, 154
parallel work candidates, 212–213
project complexity and, 322
project design in action, 278–280
senior developers as junior architects, 376
splitting activities, 211, 280
TradeMe project design case study, 346–347
work and cost, 213
Parkinson’s law
increased risk, and, 239
overestimation and, 158
probability of success, and, 159
time crunch, 6
Parnas, David. See On the Criteria to Be Used in Decomposing Systems into Modules (Parnas)
Peer reviews, importance of, 148, 210, 381
PERT (Program Evaluation and Review Technique), 162, 422
Phases, project
project design in action, 264
TradeMe project design case study, 342
Phi. See also Golden ratio, 244–245, 317
Planning assumptions
calendar dates and, 176
in debriefing, 378
in design of project design, 271–272
in design standard, 428
in project design in action, 263–265
in TradeMe project design case study, 341
Plans/planning. See also Earned value planning; SDP (Software Development Plan) review
benefits of having multiple, 152
importance of staying on, 399
STP (service test plan), 389
Practicing
identifying areas of volatility, 34–36, 52–53
Presentation layer, architecture, 60–61
Process lead. See Architects
Product manager, job description, 150
Program Evaluation and Review Technique (PERT), 162, 422
Progress. See Project progress; Project tracking; Reporting progress
Project complexity
cyclomatic. See Cyclomatic complexity
reducing for project design in action, 259, 267
reducing for TradeMe project, 340–341
reducing with The Method, 76
Project costs. See also Compression, of schedule; Effort estimations
decompression targets relation to, 251–252
financial analysis, 364
importance of educated decisions, 151–152
importance of having multiple plans, 152–153
modular system design and, 409–411
in project design in action, 265, 274, 278, 283, 285–286
project efficiency, 186
staffing distribution chart and calculating, 184–185
total, direct and indirect costs, 222–224
in TradeMe project design case study, 345–346, 349–350, 354, 358–359
Project design
choosing the normal solution, 275–276
communicating with developers/managers, 8–9
compression, throughput analysis, 287–289
creating a design for the project design, 370–372
critical path analysis. See Critical path analysis
the death zone, 218–220, 223, 292–293
earned value planning, 187–194
effort estimations. See Effort estimations
general guidelines, 365
hierarchy of needs pyramid, 141–144
importance of debriefing, 378–379
importance of practice, 377–378
introducing parallel work, 278–280
introduction to, 139
project cost/efficiency, 184–187
quality. See Quality
risk. See Risk
risk crossover point. See Crossover point, of risk
roles and responsibilities, 194
scheduling activities, 176–183
services and developers, 153–157
standard design guidelines, 427–429
when to design a project, 361–363
Project design, in action
compression using a second top developer, 276–278
diagrams, 283
earned value planning in, 271
efficiency analysis, project design in action, 289–290
milestones, 262
network diagrams, 261–262, 278, 287
outliers floats, adjusting, 295
planning assumptions in, 263–265
SDP (Software Development Plan) review, 303–304
staffing, 266
time-cost curve, 290–292, 298–300
Project design, TradeMe case study
comparing the options, 355
dependencies and project network, 339–341
individual activity estimations, 335–338
introduction to, 335
overall project estimation, 338
planning assumptions, 341
preparing for the SDP review, 359–360
Project duration
accelerating software projects, 207–210
parallel work and cost, 213
schedule compression introduction, 210
time-cost curve. See Time-cost curve
working with better resources, 210–211
Project efficiency
efficiency analysis, project design in action, 289–290
in TradeMe project, 345–346, 349–350, 354
Project hand-off. See Hand-off, design
Project life cycles, 374
Project managers
assigning floats, 204
estimations and tracking, 160–161
overview of job description, 149
Project metrics, collecting and analyzing, 382
Project network
network diagrams. See Network diagrams
project efficiency and, 187
Project phases, 264
Project plans. See Plans/planning
Project progress. See also Tracking projects
combined with tracking effort, 395–396
progress and earned value, 393
tracking progress and effort, 395–396
Project tracking. See Tracking projects
Projections. See also Tracking projects
building trust with management, 404–405
overestimating and corrective actions, 402–403
project tracking and, 404
resource leak and corrective actions, 401–402
staying on the plan, 399
underestimating and corrective actions, 400–401
Projects, large. See Large projects
Property-like operations, service contracts and, 421
Prospect theory (Kahneman, Tversky), 236
Protocols, internal and external service protocols, 74–75
Pub/Sub
in closed architecture, 78, 79
introduction, 46
in message bus, 118
in project design in action, 267, 281
in Utilities bar, 65
Q
Quality
accelerating the project through quality assurance, 207–208
failure of large projects, 327
quality-assurance activities, 381–382
quality-control activities, 380–381
Queueing
design don’ts, 80
message bus, 118
R
Ratio
developers to services, 153–155
direct cost to indirect cost, 229
golden, 244
Regression testing
impossibility in functional system, 26
with infrastructure investment, 208
quality-control activities and, 381
with test engineers, 208
volatility-based decomposition, 34
Relative criticality, visualizing floats, 203
Repeatability level, hierarchy of needs, 142–143, 209
Reporting progress
integration versus features, 146–147
project manager’s function, 149
Required behaviors. See also Use cases
business logic layer and, 61–62
classification guidelines, 65
rather than required functionality, 56–57
Requirements analysis
changes in requirements, 83–85, 92–93
creating a volatilities list, 42
functional decomposition, 14
functional trading system example, 27–30
solutions masquerading as requirements, 40–42
TradeMe system design case study, 112–116
volatility-based decomposition, 34–35
volatility-based example, 42–47
ResourceAccess layer
closed architecture problems, 77
compression with simulators, 284
open architecture example, 75–76
relevant design questions, 66–67
reuse increases top-down, 69
TradeMe system design case study, 115
volatility decreases top-down, 68–69
Resources
assigning services to developers, 153–157
compressing with top resources, 368
core team. See Core team
critical path analysis, 171–173
efficiency and staffing elasticity, 186
floats-based scheduling, 205–206
leaks and corrective actions, 401–402
reasons for project design, 139–141
staffing and cost elements, 228–230
staffing distribution chart, 177–179
staffing distribution mistakes, 179–183
task continuity and, 157
TradeMe project design case study, 341–342, 345–346, 348–350, 351–352
underestimating and adding, 401
REST/WebAPI, microservices, 74
Return on investment (ROI)
debriefing project design, 378
network compression, 231
when to design a project, 361
Reuse
contracts as elements of, 414–415
factoring contracts and, 415–419, 422
increases top down, 69
ResourceAccess reuse, 64
Reviews, system level, 381
Risk
activity risk. See Activity risk
criticality risk. See Criticality risk
crossover point. See Crossover point, of risk
and direct cost, 241
execution risk, 249
Fibonacci risk. See Fibonacci risk
and floats, 199–200, 203–204, 206, 240–241
geometric activity risk, 317–318
geometric criticality risk, 316–317
geometric Fibonacci risk, 317
geometric risk. See Geometric risk
importance of having an architect, 147–148
and indirect cost, 228
introduction to, 235
metrics, 253
planning and, 370
project design in action, 293–294, 302–303
reasons for project design, 139–141
TradeMe project design case study, 355–359
Risk decompression
decompression target, 251–252, 313–315
how to, 250
project design in action, 295–298
TradeMe project design case study, 355–359
ROI. See Risk
Roles and phases table
project design in action, 264
TradeMe project design case study, 342
S
S curve, shallow. See Shallow S curve
Scheduling activities. See Compression, of schedule; Critical path analysis; Effort estimations; Floats; Project network
Scope
projections and changes in, 404–405
SDP (Software Development Plan) review
cost elements, 229
overview of, 153
project design in action, 262, 303–304
staffing distribution chart, 177–178
TradeMe project design case study, 341, 359–360
Security
in TradeMe system design case study, 115
in Utilities bar, 65
volatility, trading system example, 42–43, 47
Semi-closed/open architecture, 76–77
Senior developers
working with better resources, 210–211
Sequence diagrams
TradeMe system design case study, 133
Service contract design
design challenge, 423
design standard guidelines, 430
factoring contracts introduced, 415–416
factoring up, 419
introduction to, 412
services and contracts, 411–415
Service protocols, internal and external, 74–75
Service requirement specification (SRS), 389
Service test plan (STP), 389
Services
assigning developers to, 153–157
bloating and coupling, functional services, 17–19
business logic service, 117–119
clients: bloating and coupling, 15–17
development life cycle, 388–389
granular in actor model, 121
service-level testing, 380
smallest set of components, 89–90
using services to cross layers, 59–60
Shallow S curve. See also Earned value planning
in project design in action, 266, 271, 274
throughput analysis, 287
tracking project progress, 395
in TradeMe project design case study, 344, 349, 353
Simulators
compared with the normal solution, 286
compression using the, 284–286
for god activities, 308
removing dependencies, 212
simulators solution in project design in action, 284–286
Siren song of bad habits, 47–48
Skills
identifying areas of volatility, 34–36, 52–53
improving development skills, 208–209
practicing project design, 377–378
Smoke tests, daily, 380
Software architect. See Architects
Software Development Plan review. See SDP (Software Development Plan) review
Splitting activities, 211, 280
SRS (service requirement specification), 389
Staffing. See also Resources
calculating project cost, 184–185
distribution mistakes, 179–183
elasticity of, 186
initial staffing in project design, 147–151
planning requirements, 263–265
project design in action, 266, 285–286
smooth staffing distribution, 183
TradeMe project design case study, 341–342, 345–346, 348–350, 351–352
Standard operating procedures (SOPs), quality assurance, 382
Standards
for design. See Design standard
Static architecture
project design in action, 256–257
TradeMe system design case study, 116
Status, of projects. See Project progress
Status reports. See Reporting progress
Storage volatility, trading system example, 43, 46
STP (service test plan), 389
Structural activities, TradeMe project, 336–337
Structural dependencies, abstract. See also Activity dependencies, 339
Structure
classification guidelines, 65–70
client and business logic layers, 60–63
introduction to, 55
open and closed architectures, 75–79
subsystems and services, 70–75
typical layers in The Method, 60–61
use cases and requirements, 56–58
Subcritical staffing
compared with load leveling, 183
introduction, 172
project complexity and, 322
project design in action, 272–274
in staffing distribution chart, 180
TradeMe project design case study, 353–354
Subsystems
Success
probability as a function of estimation, 158–159
Swim lanes, activity diagrams, 105, 112, 124–130
System design. See also Layered design; Requirements analysis
architecture versus estimations, 365–366
benefits of extensibility, 72
composition. See Composition
decomposition. See Decomposition
design standard guidelines, 426–427
introduction to The Method, 4–5
modular system design, 409–411
structure. See Structure
System design, TradeMe case study
design validation, 124
glossary: four classic questions, 112
identifying areas of volatility, 112–116
introduction to, 95
legacy system: use cases, 100–104
Message Is (application), 120–121
new system/the company, 99
System-level reviews, quality-control activities and, 381
T
Target, decompression
project design in action, recommended, 301
TradeMe project and finding the, 358–359
Task continuity, assigning resources, 157
Team. See also Core team
debriefing, 379
design and team efficiency, 155–157
Technical manager. See Architects
Technology, training developers in new technology, 208–209, 381–382
Test engineers
accelerating the project, 208
in quality control activities, 380
Testing. See also Quality
functional and domain decomposition, 25–26
quality-control activities, 380–381
software testers, 208
STP (service test plan), 389
system testing, 380
volatility-based decomposition, 34
The Method. See Method
Thermodynamics, law of, 20
Throughput analysis, compression and, 287–289
Time-cost curve
avoiding classic mistakes, 217–218
discrete modeling, 217
finding normal solutions, 220–221
first actual time-cost curve, 225–226
introduction to, 214
project design in action, 290–292, 298–300
Time crunch, benefits of a, 6
Time, project. See Project duration
Time-risk curve
actual time-risk curve, 237–239
project design in action, 295–298, 300–301, 303
TradeMe project design case study, 356–358
Timeline, subsystems and, 373–374
Tools, estimation, 163
Total cost
versus indirect cost, 230
normal solution and minimum, 225–228
total, direct and indirect costs, 223–224
Total float. See also Floats
proactive project management, 204
Tracking projects
accumulated effort, 394
accumulated indirect cost, 394–396
activity life cycle and status introduction, 388–389
effort estimations and, 160–161
overestimating and corrective actions, 402–403
project progress and earned value, 392
projections and corrective actions, 398–399
projections introduction, 396–398
resource leak and corrective actions, 401–402
standard design guidelines, 429
tracking progress and effort, 395–396
underestimating and corrective actions, 400–401
TradeMe case study. See Project design, TradeMe case study; System design, TradeMe case study
TradeMe project design case study. See Project design, TradeMe case study
Training developers, in new technology, 208–209, 381–382
Transparency, communication and, 8
Trend lines
project design in action, time cost, 291
project design in action, time risk, 300
TradeMe project design case study, time risk, 357
U
UI (user interface) development, task continuity, 157
UML activity diagram. See Activity diagrams
UML sequence diagram. See Sequence diagrams
Underestimating projects
Uneconomical zone, time-cost curve, 216
Unit testing, decomposition, 25–26
Universal principles
design iteratively, build incrementally, 71
features as aspects of integration, 91
Never design against the requirements, 84
volatility-based decomposition, 32–33
Use cases
call chain diagrams and, 87–88
distilling dependencies from, 339
introduction to swim lanes, 105
smallest set of components, 86–87, 89–90
TradeMe system design case study, 100–105, 124–135
User interface (UI) development, task continuity, 157
Utilities
introduction, 65
problems in a closed architecture, 77–78
TradeMe system design case study, 115
V
Validation. See also Call chain diagrams; Sequence diagrams
architecture, 87
TradeMe system design case study, 124
Values, behavior vs., 370
Variable, volatile vs., 37
Vision, TradeMe system design case study, 109–110
Volatility-based decomposition
compared with functional decomposition, 32–33
definition and benefits of, 30–32
design for your competitors, 50–51
in design standard, 426
house (axes of volatility) example, 39–40
solutions masquerading as requirements, 40–42
testing, 34
TradeMe system design case study, 112–116, 122–123
volatile versus variable, 37
volatility and the business, 48–50
volatility-based trading system example, 42–47
Von Moltke, Helmuth. See Tracking projects
W
WCF (Windows Communication Foundation), 73
Wideband Delphi estimation technique, 163–164
Windows Communication Foundation (WCF), 73
Workdays, calendar dates to, 176
Workflow Manager
choosing a workflow tool, 123
definition, 122