Omar Shatnawi, Ph.D.

CS 0901341

Omar Shatnawi, Ph.D.

Omar Shatnawi, Ph.D.

CS 0901341

Omar Shatnawi, Ph.D.

3.1 Tracking Progresses

Software is useful only if it performs a desired function or provides a needed service. Thus, a typical
project begins when a customer approaches developer to discuss a perceived need. Usually,
customers have several questions to be answered:

Software Engineering
Part 3
In this part, we look at
3.1 Tracking Progress
3.2 Project Personnel
3.3 Risk Management
3.4 The Project Plan
3.3 Process Models and Project Management

Do you understand my problem and my needs?

Can you design a system that will solve my problem or satisfy my needs?
How long will it take you to develop such a system?
How much will it cost to have you develop such a system?

Figure 3.2.

Answering the last two questions requires a well-thought-out project schedule. A project schedule
describes the software development cycle for a particular project by enumerating the phases or
stages of a project and breaking each into discrete tasks or activities to be done. The schedule also
portrays the interactions among these activities and estimates the time that each task or activity will
take. Thus a schedule is a timeline that shows when activities will begin and end, and when the
related development products will be ready.

As we saw in the previous parts, the software development cycle includes many steps, some of which are
repeated until the system is complete and the customer and users are satisfied. However, before
committing funds for a software development or maintenance project, a customer usually wants an estimate
of how much the project will cost and how long the project will take. This part examines the activities
necessary to plan and manage a software development project.

In Part 1, we learned that a system approach involves both analysis and synthesis: breaking the
problem into its component parts, devising a solution for each part, and then putting the pieces
together to from a coherent whole. We can use this approach to determine the project schedule.
We begin by working with customers and potential users to understand what they want and need. At
the same time, we make sure that they are comfortable with out knowledge of their needs. We list all
project deliverables, that is, the items that the customer expects to see during project
developments. Among the deliverables may be

documents
demonstrations of function
demonstration of subsystems
demonstration of accuracy
demonstration of reliability, security or performance.

Next, we determine what activities must take place in order to produce these deliverables.
In our analysis of the project, we must distinguish clearly between milestones and activities. An
activity is a part of the project that takes place over a period of time, whereas a milestone is the
completion of an activitya particular point in time. So an activity has a beginning and an end,
whereas a milestone is the end of a designated activity.

Figure 3.1.

29

30

Omar Shatnawi, Ph.D.

CS 0901341

Omar Shatnawi, Ph.D.

By examining the project carefully in this way, we can separate development into a succession of
phases. Each phase is composed of steps, and each step can be subdivided further if necessary, as
shown in Figure 3.3

Omar Shatnawi, Ph.D.

CS 0901341

Omar Shatnawi, Ph.D.

Tools to Track Progress

There are many tools that can be used to keep track of a projects progress. Some are manual, others
are simple spreadsheet applications, and still others are sophisticated tools with complex graphics.
Many project management software systems draw a work breakdown structure and also assist the
project manager in tracking progress by step and activity. For example, a project management
package may draw a Gantt chart, a depiction of the project where the activities are shown in
parallel, with the degree of completion indicated by a color or icon. The chart helps the project
manager to understand which activities can be performed concurrently, and also to see which items
are on the critical path.

3.2 Project Personnel

To determine the project schedule and estimate the associated effort and costs, we need to know
approximately how many people will be working on the project
what tasks they will perform
what abilities and experiences they must have so that they can do their jobs effectively.

Figure 3.3 Phases, steps, and activities in a project

Work Breakdown and Activity Graphs

Analysis of this kind is sometimes described as generating a work breakdown structure for a given
project, because it depicts the project as a set of discrete pieces of work. Notice that the activities
and milestones are items that both customers and developers can use to track development and
maintenance.
We can describe each activity with four parameters:

the precursor
duration
due date
endpoint.

In this section, we look at how to decide who does what and how the staff can be organized.

Staff Roles and Characteristics

We saw in Par 1, that there are many other roles for personnel on the development or maintenance
team. As we study each of the major tasks of development in subsequent parts, we will describe the
project team members who perform those tasks.

The precursor is an event or set of events that must occur before the activity can begin; it describes
the set of conditions that allows the activity to begin. The duration is the length of time needed to
complete the activity. The due date is the date by which the activity must be completed, frequently
determined by contractual deadlines. Signifying that the activity has ended, the endpoint is usually a
milestone or deliverable.
We can illustrate the relationships among activities by using these parameters. In particular, we can
draw an activity graph to depict the dependencies; the nodes of the graph are the project milestones,
and the lines linking the nodes represent the activities involved.

Estimating Completion

Analyzing the paths the milestones of a project is called the critical path method (CPM). The paths
can show the developer the minimum amount of time it will take to complete the project, given the
developer estimates of each activitys duration. Moreover, CPM reveals those activities that are most
critical to completing the project on time.
31

Figure 3.4.

32

Omar Shatnawi, Ph.D.

CS 0901341

Omar Shatnawi, Ph.D.

Once we have decided on the roles of project team members, we must decide which kinds of people
we need in each role. Project personnel may differ in many ways, and it is not enough to say that a
project needs an analyst, two designers, and five programmers, for example.
Two people with the same job title may differ in at least one of the following ways:
ability to perform the work
interest in the work
experience with
similar applications
similar tools or languages
similar techniques
training
ability to
communicate with others
share responsibilities with others
management skills

Omar Shatnawi, Ph.D.

CS 0901341

Omar Shatnawi, Ph.D.

When communicating ideas, some people tell others their thoughts, and others ask for suggestions
from others before forming an opinion. Jung (1959) calls the former extroverts and the latter
introverts. Clearly, your communication style affects the way you interact with others on a project.
Similarly, intuitive people base their decisions on feeling about and emotional reactions to a problem.
Others are rational, deciding primarily by examining the facts and carefully considering all options.
We can describe the variety of work styles by considering the graph of Figure 3.6, where
communication style forms the horizontal axis and decision style the vertical one.

On every software development or maintenance project, members of the development team

communicate with one another, with users, and with the customer. The projects progress is affected
not only by the degree of communication, but also by the ability of individuals to communicate their
ideas.
Software failures can result from a breakdown in communication and understanding, so the number
of people who need to communicate with one another can affect the quality of the resulting product.
Figure 3.5 shows us how the lines of communication can grow.

Figure 3.6 Work styles.

Project Organization
Software development and maintenance project teams do not consider of people working
independently, uncoordinated. Instead, team members are organized in ways that enhance the swift
completion of quality products. The choice of an appropriate structure for software project depends
on several things:

the backgrounds and work styles of the team members

the number of people on the team
the management styles of the customers and developers

Good project managers are aware of these issues, and they seek team members who are flexible
enough to interact with all players, regardless of work style.

Figure 3.5 Communication paths on a project

Work Style
Different people have different preferred styles for interacting with others on the job and with
understanding problems that arise in the course of their work. You can think of the preferred work
style in terms of two components:

One popular organizational structure is the chief programmer team, first used at IBM (baker 1972).
On a chief programmer team, one person is totally responsible for a systems design and
development. All other team members report to the chief programmer, who has the final say on
decision. The chief programmer supervises all others, designs all programs, and assigns the code
development to the other team members. Assisting the chief is an understudy, whose principal job is
substituting for the chief programmer when necessary. A librarian assists the team, responsible fro
maintaining all project documentation. The librarian also complies and links the code, and performs
preliminary testing of all modules submitted to the library. This division of labor allows the
programmers to focus on what they do best: programming.

the way in which your thoughts are communicated and ideas gathered
the degree to which your emotions affect decisions making.

33

34

Omar Shatnawi, Ph.D.

CS 0901341

Omar Shatnawi, Ph.D.

The organization of the chief programmer team is illustrated in Figure 3.7. By placing all
responsibilities for all decisions with the chief programmer, the team structure minimizes the
amount of communication during the project.

Omar Shatnawi, Ph.D.

CS 0901341

Omar Shatnawi, Ph.D.

For most projects, the biggest component of cost is effort. We must determine how many staff-days
of effort will be required to complete the project. Effort is certainly the cost component with the
greatest degree of uncertainty.
Cost, schedule and effort estimation must be done as early as possible during the projects life
cycle, since it effects resource allocation and project feasibility. (if it costs too much, the customer
may cancel the project.) But estimation should be done repeatedly throughput the life cycle; as
aspects of the project change, the estimate can be refined, based on more complete information
about the projects characteristics.
Cost estimation is the activity where the overall cost requirement for the project and the breakup of
the cost for different phases is estimated. As human resources are the most important for software
development, cost estimates are often given in person-month (PM).

Figure 3.7 Chief programmer team organization

Clearly, the chief programmer must be good at making decisions quickly, so the chief is likely to be an
extrovert. However, if most of the team members are introverts, the chief programmer team may
not be the best structure for the project. An alternative is based on the idea of egoless
programming, as described by Weinberg (1971). Instead of a single point of responsibility, an egoless
approach holds everyone equally responsible.

Effort Estimation
One of the crucial aspects of project planning and management is understanding how much the
project likely to cost. Cost overruns can cause customers to cancel projects, and cost
underestimates can force a project team to invest much of their time without financial compensation.
A good cost estimate early in the projects life also helps the project manager to know how many
developers will be required, and to arrange for the appropriate staff to be available when they are
needed.
The project budget pays for several types of costs:

facilities
staff
methods and tools.

For estimating the cost, cost models that estimate the cost as a function of various parameters are
used. One well-known model is the Boehms COnstruction COst MOdel (COCOMO) model. In this
model, the initial cost estimate is obtained as a function of the size of the final product. Then the cost
estimate is refined based on various properties of the project. The cost for different phases is
specified as a fixed percentage of the overall cost and can easily be obtained from the overall cost
estimate.

3.3 Risk Management

As we have seen, many software managers take steps to ensure that their projects are done on time
and within effort and cost constraints. However, project management involves far more than tracking
effort and schedule. Managers must determine whether any unwelcome events may occur during
development or maintenance, and make plans to avoid these events or, if they are inevitable,
minimize their negative consequences. A risk is an unwanted event that has negative consequences.
Project management must engage in risk management to understand and control the risks on their
projects.

What is a Risk?

The facilities costs include hardware, space furniture, telephones, modems, heating and air
conditioning, cables, disks, papers, pens, photocopiers, and all other items that provide the physical
environment in which the developers will works.

Many events occur during software development. We distinguish risks from other project events by
looking for three things (Rook 1993):

Other project costs involve purchasing software and tools to support development efforts. In addition
to tools for designing and coding the system, the project may buy software to capture requirements,
organize documentation, test the code, keep track of changes, generate test data, support group
meetings and more. These tools, sometimes called computer-aided software/system engineering
(or CASE) tools, are sometimes required by the customer or as part of a companys standard
software development process. CASE tool that works for all kinds of phases is called Workbench.

A loss associated with the event the event must create a situation where some thing negative
happens to the project: a loss of time, quality, money, control, understanding, and so on. The loss
associated with a risk is called the risk impact.
The likelihood that the event will occur we must have some idea of the probability that the event will
occur. The likelihood of the risk, measured from 0 (impossible) to 1 (certainty) is called the risk
probability. When the risk probability is 1, then the risk is called a problem, since its certain to happen.
The degree to which we can change the outcome for each risk, we must determine what we can do
to minimize or avoid the impact of the event. Risk control involves a set of actions taken to reduce or
eliminate a risk.

35

36

Omar Shatnawi, Ph.D.

CS 0901341

Omar Shatnawi, Ph.D.

We can quantify the effects of the risks by multiplying the risk impact by the risk probability, to yield
the risk exposure.
There are two major sources of risk: generic risks and project-specific risks. Generic risks are
those common to all software projects, such as misunderstanding the requirements, losing key
personnel, or allowing insufficient time for testing. Project specific risks are threats that results
from the particular vulnerabilities of the given project.

Risk Management Activities

Risk management involves several important steps, each of which is illustrated in Figure 3.8. First,
you asses the risks on your project, so that you understand what may occur during the course of
development or maintenance.

Omar Shatnawi, Ph.D.

CS 0901341

Omar Shatnawi, Ph.D.

your understanding, including system dynamics models, cost models, performance models, network
analysis, and more.
Now that you have itemized all risks, you must use your understanding to assign priorities to the
risks. A priority schemes enables you to devote your limited resources only to the most threatening
risks. Usually, priorities are based on the risk exposure, which takes into account not only likely
impact, but also the probability of occurrence.
The risk exposure is computed from the risk impact and the risk probability, so you must estimate
each of these risk aspects. Risk exposure helps us to list the risks in priority order, with the risks of
most concern given the highest priority. Next, we must take steps to control the risks. The notion of
control acknowledges that we may not able to eliminate all risks. Instead, we may be able to minimize
the risk or mitigate it by taking action to handle the unwanted outcome in an acceptable way.
Therefore, risk control involves

risk reduction,
risk planning, and
risk resolution.

There are three strategies for risk reduction:

avoiding the risk by changing requirements for performance or functionality.

transferring the risk by allocating risks to another system or by buying insurance to cover any
financial loss should the risk become reality.
assuming the risk by accepting it and controlling it with the projects resources.

To aid decision making about risk reduction, we must take into account the cost of reducing the risks.
We call risk leverage the difference in risk exposure divided by the cost of reducing the risk.
It is useful to record your decisions in a risk management plan, so that both customer and
development team can review how problems are to be avoided, as well as how they are to be handled
should they arise. Then, we should monitor the project as development progresses, periodically
reevaluating the risks, their probability, and their likely impact.

Figure 3.8 Steps in risk management (Rook 1993).

The assessment consists of three activities:

3.4 The Project Plan

identifying the risks,

analyzing them, and
assigning priorities to each of them.

To communicate risk analysis and management, project cost estimates, schedule, and organization to
our customers, we usually write a document called a project plan. The plan puts in writing the
customers needs, as well as what we hope to do to meet them.

To identify them, you may use many different techniques.

If the system you are building is similar in some way to a system you have built before, you may have
a checklist of problems that may occur; you can review the checklist to determine if your new project
is likely to be subject to the risks listed. For systems that are new in some way, you may augment the
checklist with an analysis of each of the activities in the development cycle; by decomposing the
process into small pieces, you may be able to anticipate problems that may arise.
Finally, you analyze the risks you have identified, so that you can understand as much as possible
about when, why, and where they might occur. There are many techniques you can use to enhance
37

A good project plan includes the following items

project: scope; schedule; team organization; and standards, procedures, and proposed techniques and
tools.
plan: quality assurance; configuration management; documentation; data management; resource
management; test; training, risk management; and maintenance.

The scope defines the system boundary, explaining what will be included in the system and what will
not be included. It assures the customer that we understand what is wanted. The schedule can be
expressed using a work breakdown structure, the deliverables, and a timeline to show what will be
38

Omar Shatnawi, Ph.D.

CS 0901341

Omar Shatnawi, Ph.D.

happening at each point during the project life cycle. A Gantt chart can be useful in illustrating the
parallel nature of some of the development tasks. The project plan also lists the people on the
development team, how they are organized, and what they will be doing. As we have seen, not
everyone is needed all the time during the project, so the plan usually contains a resource allocation
chart to show staffing levels at different times.

CS 0901341

Omar Shatnawi, Ph.D.

Anchoring Milestone (The Win-Win Spiral Model)

In Part 2, we examined many process models that described how the technical activities of software
development should progress. Boehm (1996) has identified three milestones (which help establish the

completion of one cycle around the spiral and provide the decision milestones before the software project
proceeds) that common to all software development processes and can serve as a basis for both

technical process and project management:

3.5 Process Models and Project Management

Life Cycle Objectives (LCO)Defines a set of objectives for each major software activity (e.g. a set
of objectives associated with the definition of top level product requirements)
Life Cycle Architecture (LCA)Establishes the objectives that must be met as the as the software
architecture is defined.
Initial Operational Capability (IOC)Represents a set of objectives associated with the preparation
of the software for installation/distribution, site preparations prior to installations, and assistance
required by all parties that will use or support the software.

We have seen how different aspects of a project can affect the effort, cost, and schedule required, as
well as the risks involved. Managers most successful at building quality products on time and within
budget are those who tailor the project management techniques to the particular characteristics of
the resources needed, the chosen process, and the people assigned.

Enrollment Management (Digital Alpha AXP: Enrollment Management Model)

Digital Equipment Cooperation spent many years developing its Alpha AXP system, a new system
architecture and associated products that formed the largest project in Digitals history. During the
course of development, the project managers developed a model that incorporated four tenets,
called the Enrollment Management model (Conklin 1996):

Omar Shatnawi, Ph.D.

To supplement these milestones. Boehm suggests using the Win-Win spiral model, illustrated in Figure
3.10 and intended to be an extension of the spiral model we examined in Part 2. The model
encourages participants to coverage on a common understanding of the systems next-level
objectives, alternatives, and constraints.

Establish an appropriately large shared vision

Delegate completely and elicit specific commitments from participants
Inspect vigorously and provide supportive feedback
Acknowledge every advance and learn as the program progresses

The approach involved establishing a shared vision, delegating completely and eliciting specific
commitments, inspecting rigorously while providing supportive feedback, and acknowledging every
advance. Each project event was used to propel, progress, and gain momentum. Digital delivered the
Alpha AXP program on schedule with significant industry capabilities. The results of adopting this
model, and the dedication of all the players, resulted in a highly successful new product line for
Digital, eventually returning the corporation to a much stronger competitive position. Figure 3.9
illustrate the model.
Figure 3.10 Win-Win sprial model (Boehm 1996).

The model, shown above derives its name from the objective of these negotiations, i.e. win-win. The
client gets the product that satisfies the majority of his/her needs, and the developer wins by
working to realistic and achievable budgets and deadlines. To achieve this objective the model defines
a set of negotiation activities at the beginning of each pass around the spiral. Rather that a single
customer communication activity the following activities are defined:

Identification of the system stakeholders. That is the people on the organization that have direct
business interest in the product to be built and will be rewarded for a successful outcome or
criticized if the effort fails (e.g. user, customer, developer, maintainer, interfacer, etc.).
Determination of the stakeholders win conditions
Negotiations of the stakeholders win conditions to reconcile them into a set of win-win conditions
for all concerned (including the software project team).

Figure 3.9 Enrollment Management model (Conklin 1996).

39

40