Page 103 -

70 Part 1 • SyStemS analySiS FundamentalS

The Work Breakdown Structure
Systems analysts are responsible for completing projects on time and within budget and for
including the features promised. In order to accomplish all three of these goals, a project needs to
be broken down into smaller tasks or activities. These tasks together make up a work breakdown
structure (WBS).
When defined properly, the tasks that compose a work breakdown structure have special
properties:
1. Each task or activity contains one deliverable, or tangible outcome, from the activity.
2. Each task can be assigned to a single individual or a single group.
3. Each task has a responsible person monitoring and controlling performance.
Activities in a work breakdown structure do not need to take the same amount of time or
involve the same number of team members. The activities defined must add up to 100 percent of
the work, however.
The main method for developing a WBS is decomposition, or starting with large ideas and
then breaking them down into manageable activities. This subdivision of ideas into smaller ideas
and eventually tasks stops when each task has only one deliverable.
There are different types of work breakdown structures. A WBS can be product oriented.
In other words, building a website can be broken down into many parts, with each set of pages
having a specific purpose. You could divide a website into its home page, product description
pages, a FAQ page, a contact page, and an ecommerce page. Each of these pages could contain
activities that you could use in your work breakdown structure.
Another way is to create a process-oriented work breakdown structure. An example of this
is shown in Figure 3.15. This type of WBS is typical in systems analysis and design. In this
example, we show the development of a website, but rather than show the development of each
page, this example emphasizes the importance of each phase in the systems development life
cycle.
Time Estimation Techniques
The process of analysis and design can become unwieldy, especially when the system being
developed is large. To keep the development activities as manageable as possible, you can
employ some of the techniques of project management to help get organized. In this section we
discuss keeping a project on schedule by using time management techniques and keeping a proj-
ect on budget by using cost management and control techniques.
One of the difficult tasks is estimating the time it takes to complete each of the tasks. There
are numerous approaches:

1. Relying on experience
2. Using analogies
3. Using three-point estimation
4. Identifying function points
5. Using time estimation software

RELYING ON EXPERIENCE. Experience pays off when it comes to estimating how long an
activity will take. If you have previous experience developing software, you will not only
know how much time some tasks will likely take, you will also know how much time it will
take if something goes wrong. Your experience gives you a most likely estimate as well as a
pessimistic estimate.
USING ANALOGIES. If you don’t have experience developing a particular piece of software but
have worked on other types of projects of any kind, you still may be able to arrive at meaningful
estimates. This approach involves identifying a project that is in some ways similar to the one
you are about to begin and then describe the analogy. This means you will need to build two
models, including two PERT or network diagrams, and compare their similarities. Then you can
have confidence when you provide time estimates for the new project.

USING THREE-POINT ESTIMATION. Three-point estimation has been used for many years and
is still a valid technique for time estimating. You start by developing three time estimates for