UNIT-IV

Project Organizations
Line-of- business organizations, project organizations, evolution of organizations, process automation.
Project Control and process instrumentation
The seven core metrics, management indicators, quality indicators, life-cycle expectations, Pragmatic
software metrics, and metrics automation.

Part-1 Project Organizations and Responsibilities

Project Organizations and Responsibilities

Organizations engaged in software Line-of-Business need to support projects with the infrastructure
necessary to use a common process.
Project organizations need to allocate artifacts & responsibilities across project team to ensure a
balance of global (architecture) & local (component) concerns.
The organization must evolve with the WBS & Life cycle concerns. Software lines of business &
product teams have different motivation. Software lines of business are motivated by return of
investment (ROI),
new business discriminators, market diversification &profitability.
Project teams are motivated by the cost, Schedule &quality of specific deliverables
1) Line-Of-Business Organizations:
The main features of default organization are as follows:
• Responsibility for process definition & maintenance is specific to a cohesive
line of business.
• Responsibility for process automation is an organizational role & isequal in
importance to the process definition role.
• Organizational role may be fulfilled by a single individual or several different teams. Fig: Default roles
in a software Line-of-Business Organization. Software Engineering Process Authority (SEPA)
The SEPA facilities the exchange of information & process guidance both to & from project practitioners
This role is accountable to General Manager for maintaining a current
assessment
of the organization’s process maturity & its plan for future improvement
Project Review Authority (PRA)
The PRA is the single individual responsible for ensuring that a software project

Software process and project management Page 65

 complies with all organizational & business unit software policies, practices & standards A
software Project Manager is responsible for meeting the
requirements of a contract or some other project compliance standard Software Engineering
Environment Authority( SEEA )
The SEEA is responsible for automating the organization’s process,
maintaining the organization’s standard environment, Training projects to use the Environment
&maintaining organization-wide reusable assets The SEEA role is necessary to achieve a significant ROI
for common process.
Infrastructure
An organization’s infrastructure provides human resources support, project- independent research &
development, &other capital software engineering assets.
2) Project organizations:
Artifacts Activities
 Business case Customer interface, PRA interface
 Software development plan Planning, monitoring
 Status assessments Risk management
 Software process definition
 Process improvement
Figure 11-2. Default project organization and responsibilities
Software Management
Software Development Software Architecture Software Assessment System engineering
Administration
• The above figure shows a default project organization and maps project-level roles and
responsibilities.
• The main features of the default organization are as follows:
• The project management team is an active participant, responsible for producing as well as
managing.
• The architecture team is responsible for real artifacts and for the integration of
components, not just for staff functions.
• The development team owns the component construction and maintenance activities.
• The assessment team is separate from development.

Software process and project management Page 66

 • Quality is everyone’s into all activities and checkpoints.
• Each team takes responsibility for a different quality perspective.
3) EVOLUTION OF ORGANIZATIONS:
Transition Construction
Inception:
Software management: 50%
Software Architecture: 20%
Software development: 20% Software
Assessment
(measurement/evaluation):10%
Elaboration:
Software management: 10%
Software Architecture: 50%
Software development: 20% Software
Assessment
(measurement/evaluation):20%
Construction:
Software management: 10%
Software Architecture: 10%
Software development: 50% Software
Assessment
(measurement/evaluation):30%
Transition:
Software management: 10%
Software Architecture: 5%
Software development: 35% Software
Assessment
(measurement/evaluation):50% The
Process Automation
Introductory Remarks:
The environment must be the first-class artifact of the process.
Process automation& change management is critical to an iterative process. If the change is expensive
then the development organization will resist it.
Round-trip engineering& integrated environments promote change freedom & effective evolution of
technical artifacts.
Metric automation is crucial to effective project control.
External stakeholders need access to environment resources to improve interaction with the
development team & add value to the process.
The three levels of process which requires a certain degree of process automation for the corresponding
process to be carried out efficiently.

Software process and project management Page 67

Software process and project management Page 68
 MANAGEMENT INDICATORS:
1. There are three fundamental sets of management metrics: technical progress, financial status, and
staffing progress
2. By examining these perspectives, management can generally assess whether a
project is on budget and on schedule
3. Most managers know their resource expenditures in terms of costs and
schedule. The problem is to assess how much technical progress has been made.
4. Following three are management indicators:

STAFFING A N D TEAM DYNAMICS:

1. Tracking actual versus planned staffing is a necessary is well-understood management metric.
2. There is one other important management indicator, the relationship between attrition and
additions.
3. Increases in new staff can slow overall project progress as new people consume the more
productive time.
4. Low attrition of good people is a sign of success.
5. If progress motivation is not there, good engineers will migrate elsewhere.
6. An increase in unplanned attrition-namely, people leaving a project prematurely-is one of the
most obvious indicators that a project is destined for trouble.
7. The causes of such attrition can vary, but they are usually personnel dissatisfaction with
management methods, lack of teamwork, or probability of failure in meeting the planned
objectives.

Software process and project management Page 69

 BREAKAGE AND MODULARITY:

Breakage is defined as the average extent of change, which is the amount of software that needs
rework.
1. Modularity is the average breakage trend over time.
2. For a healthy project, the trend expectation is decreasing or stable. (Figure 13
3. This indicator provides insight into the benign (not harmful) or malignant (harmful) character of

software change.
4. In a mature iterative development process, earlier changes are expected to result in more
scrap than later changes.
5. Breakage trends that are increasing with time clearly indicate that product maintainability is

REWORK AND

1. Rework is defined as the average c o s t of change.

2. Which is the effort t o analyze, resolve, and retest all changes to software b a s e l i n e s .
3. Adaptability is defined as the rework trend over time.
4. For a healthy project, the trend expectation is decreasing or stable.
5. Not all changes are treated equal. Some changes can be made in a staff-hour, while others take
staff-weeks.
6. This metric provides insight into rework measurement.
7. In a mature i t e r a t i v e d e v e l o p m e n t process, e a r l i e r c h a n g e s a r e expected to require
more rework than later changes.
8. Rework trends that are increasing with time clearly indicate that product maintainability is
difficult.

1. Software errors can be categorized into two types: deterministic and nondeterministic. Physicists
would characterize these as Bohr-bugs and
Heisen-bugs, r e s p e c t i v e l y .
2. Bohr-bugs represent a class of errors th at always result when the software i s used in a same way.
These errors are predominantly caused by coding errors, and changes are typically isolated to a single
component.
1. Heisen-bugs a r e software faults that are coincidental situation. These errors are almost always
design errors and typically are not repeatable even when the software is used in the same apparent way.
2. Conventional software programs executing a single program on a single processor typically
contained only Bohr-bugs.

Software process and project management Page 70

 3. Modern, distributed systems with numerous interoperating components executing across a network
of processors are vulnerable to Heisen-bugs, which are far more complicated to detect, analyze, and
resolve.
4. The best way to mature a software product is to establish an initial test infrastructure that allows
execution of test early in the life cycle.

Software process and project management Page 71

 Write note on lifecycle expectations.(13.3 table)

There is no mathematical evidence for using the seven core metrics. However, there were specific reasons
for selecting them:
• The quality indicators are derived from the activity of ongoing process.
• They provide insight into the waste generated by the process. Scrap and rework metrics of manufacturing
processes.
• Rather than focus on the value, they explicitly concentrate on the trends or changes with respect to time.
• The combination of insight from the current value and the current trend provides sufficient information for
management.
Write note on pragmatic software metrics
Basic characteristics of good metric are as follows:
1. It is considered me an in gf ul by the customer, manager, and performer. If any one of these
stakeholders does not see the metric as meaningful, it will not be used.
2. It demonstrates quantifiable correlation between process perturbations (problems) and business p e
rfo rmance .
3. It is objective and unambiguously defined. Objectivity should translate into some form of
numeric representation (such as numbers, percentages, ratios) as opposed to textual representations
(such as excellent, good, fair, poor).
Ambiguity is minimized through well-understood units of measurement (such as staff-month, SLOC,
change, function point, class, scenario, and requirement),
4. It displays trends. This is an important characteristic. Understanding the change in a metric's value
with respect to time, subsequent (later) projects, subsequent r e l e a s e s , and so forth is an extremely
important perspective.
. 5. It is a natural by-product of the process. The metric does not introduce new artifacts or overhead
activities; it is derived directly from the mainstream engineering and management workflows.
6. It is supported by automation.

Software process and project management Page 72

 Experience has demonstrated that the most successful metrics are those that are collected and
reported b y automated tools.

Following examples shows why the values of metrics should be interpreted correctly.
• A low number of change requests to a software baseline may mean that the software is mature and error-
free, or it may mean that the test team is on vacation.
• A software change order that has been open for a long time may mean that the problem was simple
to diagnose and the solution required large rework, or it may mean that a problem was very time-
consuming to diagnose and the solution required a simple change to a single line of code.
• A large increase in personnel in a given month may cause progress to increase proportionally
if they are trained people who are productive from the outset. It may cause progress to down if they
are untrained new hires who demand extensive support from productive people to get up to speed.

1. There are many opportunities to automate the project control activities of a software
project.
2. To analyze the data, software project control panel (SPCP) that maintains an on-line version of
the status of s/w provides the key advantage.
3. This concept was first recommended by the Airlie Software Council [Brown,1996], using
the "dashboard”.(displaying metrics /score)
4. The idea is to provide a display panel that integrates d a t a from multiple sources to show the
current s tatu s of the project.
5. For example, the software project manager would want to see a display with overall project
values, a test manager may want to see a display focused on metrics specific to an upcoming
beta release, and development managers may be interested only in data concerning the
subsystems and components for which they are responsible.
6. The panel can support standard features such as warning lights, thresholds, variable scales,
digital formats, and analog formats to present an overview of the current situation.
7. This automation support can improve m a n a g e m e n t insight i n t o p r o g r e s s a n d quality
trends and improve the acceptance of metrics by the engineering team.
To implement a complete SPCP, it is necessary to define and develop the following
• Metrics primitives: indicators, trends, comparisons, and progressions
• A graphical u s e r interface: GUI support for a software p r o j e c t m a n a g e r role and flexibility to
support other roles.
• Metrics collection agents: data extraction from the environment tools.
• Metrics data management server: stores the data.
• metrics definitions: actual metrics presentations for requirements progress (extracted from
requirements set artifacts), design progress (extracted from design set artifacts), implementation
progress (extracted from implementation set artifacts), assessment progress (extracted from deployment
set artifacts), and other progress dimensions (extracted from manual sources, financial management
systems, management artifacts, etc.)
• Actors: typically, the monitor and the administrator.

Software process and project management Page 73

 What are four graphical objects of top level display

1. Project activity status. The graphical o b j e c t in the upper left provides an overview of the status of
the top-level WBS elements. The seven elements could be coded red, yellow, and green to reflect
the current e a r n e d v a l u e status. (In Figure 13-10, they are coded with white and shades of gray.)
For example, green would represent ahead of plan, yellow would indicate within 10% of plan,
and red would identify elements that have a greater than 10% cost or schedule variance.
2. Technical artifact status . The graphical ob j e ct in the upper right provides an overview of the status
of technical artifacts. The Req light would display current state of requirements specifications. The
Des light would do the same for the design models, the Imp light for the source code baseline, and the
Dep light for the test program.
3. Milestone progress. The graphical object in the lower left provides a progress assessment of the
achievement of milestones against plan.
4. Action item progress. The graphical object in the lower right provides a different perspective of
progress, showing t h e current n u m b e r o f open and closed issues.

Software process and project management Page 74