Chapter 2 of The Mythical Man-Month by Fred Brooks
Deployment
Lab 1 steps you through the process of installing the gnuchess program
Why should you learn about this?
Deployment is the process of making an implemented system available to its users
This is why Lab 1 also asks you to automate the gnuchess installation process!
We want deployment to be an “engineered” process
What steps do we follow on the production side?
What steps do our users follow on the client side?
What problems can be anticipated and/or eliminated
How do we account for different user needs?
e.g. single user vs. system administrator
Consider the upcoming releases of Vista and MacOS X Leopard, and all that must entail for the software engineers at those companies
Deployment, continued
There is more to deployment than just installation, including:
updates
uninstall
reconfiguration (say from a non-secure mode of operation to a secure mode)
In addition, the modern nature of software applications being assembled from many different components can complicate deployment tasks
Different parts of a single program may need to be deployed in multiple locations on a local machine
Concepts like application bundles can partially address this issue, but not completely
Applications may have dependencies on frameworks or libraries that are owned or maintained by different organizations
Often, multiple versions of the same library need to be deployed on the same machine because some applications may not have been upgraded to take advantage of the more recent release of the library
Issues of Scale must also be considered
For single-user systems, deployment can be quite simple
Place an installer on a website and let users download it and install locally
Or, implement an auto-update function and let your application update itself
There are even frameworks that enable this, e.g., sparkle for MacOS X
But consider the needs of large organizations (e.g. Sun, IBM, Microsoft, Oracle, …)
A vendor issues an update to a program that all employees use and now this update needs to be installed on tens of thousands of machines!
Given this tools such as installers, un-installers, updaters and the like each address only part of the deployment problem
Software Dock
Richard Hall's Ph.D. work at CU Boulder (circa 1998-1999)
Software Dock took a comprehensive approach to deployment
Developed a deployment life cycle
Developed the Software Dock
An agent-based system that implements the entire deployment life cycle
A company maintains a release dock which can provide access to multiple software applications
A field dock sits on a local computer and keeps track of installed components
If an application is updated on the release dock, then agents use the information on both docks to update only those components on the local system that have changed
Brooks' Corner: The Mythical Man-Month
In this chapter, Brooks looks at the unit of the man-month, which is sometimes used in management to help schedule large projects.
The abstract points out several reasons why projects go awry for lack of calendar time
Developers are Optimists: We assume that things will go right, when reality is never that smooth
Our estimating techniques confuse “effort with progress, hiding the assumption that men and months are interchangeable”
Because we are uncertain about our estimates, we are unwilling to defend them
When schedule slippage is detected, we add more people to the project which is like “dousing a fire with gasoline”
The unit of the man-month implies that workers and months are interchangeable.
However, this is only true when a task can be partitioned among many workers with no communication among them!
Brooks points out that cost does indeed vary as the product of the number of workers and the number of months. Progress does not!
When a task is sequential, more effort has no effect on the schedule
“The bearing of a child takes nine months, no matter how many women are assigned!”
And, unfortunately, many tasks in software engineering have sequential constraints!
Especially debugging and system testing (Note: open source development challenges this notion a bit)
Effects of Communication
In addition, most tasks require communication among workers.
In a software development project, communication consists of
training
sharing information (intercommunication)
training will effect effort at worst linearly (i.e. if you have to train N people individually, it will take N*trainingTime minutes to train them)
intercommunication adds n(n-1)/2 to the effort if each worker has to communicate with every other worker
Comparison Graphs:
Scheduling
Brooks' Rule of Thumb for Scheduling Software Development Projects
1/3 planning
1/6 coding
1/4 component test
1/4 system test
More time devoted to planning than normal; Half of the time devoted to testing!
In looking at other projects, Brooks found that few planned on spending 50% of their time on testing, but most spent 50% of their time on testing!
Most of these projects were on schedule when testing began!
Coming Up Next
Lecture 6: Pattern Matching (Wildcards and Regular Expressions)