Lecture 05: Deployment

Today's Lecture

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

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

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

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)

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!