PROJECT MANAGEMENT-2017 SUPPLY

2) (a) 4 Key Components of Effective Teams:

First, the team differs in form and structure.
Since the model we present attempts to generalize across all
varieties of teams, you need to be careful not to rigidly apply the
model’s predictions to all teams. The model should be used as a
guide, not as an inflexible prescription.
Second, the model assumes that it’s already been determined that
teamwork is preferable over individual work. Creating “effective”
teams in situations in which individuals can do the job better is
equivalent to solving the wrong problem perfectly.
The key components making up effective teams can be subsumed
into 4 general categories:

1. Work Design: The first category is work design.

2. Composition: The second relates to the team’s composition.
3. Context: Third Is the resources and other contextual
influences that make teams effective.
4. Process: Finally, process variables reflect those things that go
on in the team that influences the effectiveness.
 2) (b) Peer Inspections :

Errors and mistakes are common occurrences in the software

development process. Throughout the Software Development Life
Cycle (SDLC), developers and testers come across innumerable
errors, defects, bugs and other discrepancies, which if left
undetected and unresolved can harm the functionality and
performance of the software.
Moreover, any complexities found in the code can become a greater
hurdle, as it prevents developers from getting software’s intended
results. Therefore, to overcome these discrepancies and errors,
both software practitioners and researchers need to improve the
reputation of the software. The best way to do this is through
inspection, which is the only way to improve the quality as well as
performance of a software. This method of software inspection can
be extremely effective, however its success depends on having a
complete and systematic procedure for conducting the inspection.
Hence, here is an elaborated discussion on Software Inspection and
its process, role and participants, which will help you get the best
software inspection results.
Peer reviews are considered an industry best-practice for detecting
software defects early and learning about software artifacts. Peer
Reviews are composed of software walkthroughs and software
inspections and are integral to software product engineering
activities. A collection of coordinated knowledge, skills, and
behaviors facilitates the best possible practice of Peer Reviews.
The elements of Peer Reviews include the structured review
process, standard of excellence product checklists, defined roles of
participants, and the forms and reports.
Software inspections are the most rigorous form of Peer Reviews
and fully utilize these elements in detecting defects. Software
walkthroughs draw selectively upon the elements in assisting the
producer to obtain the deepest understanding of an artifact and
reaching a consensus among participants. Measured results reveal
that Peer Reviews produce an attractive return on investment
obtained through accelerated learning and early defect detection.
For best results, Peer Reviews are rolled out within an organization
through a defined program of preparing a policy and procedure,
training practitioners and managers, defining measurements and
populating a database structure, and sustaining the roll out
infrastructure. Effective peer reviews of all types of software work
products are essential if software development organizations are to
reduce their cost of producing software. Formal inspections of
requirements specifications, designs, source code, and other work
products are a proven means for finding errors and improving the
quality of software pr

With its assistance one can find defects and deficiencies in a

developed software product and ensure that it is fulfilling client’s
requirements. Software inspections can be applied in every
software development phase and is commonly used to inspect
software requirements specification and test plans. Due to the fact
that inspections can be applied early in the development process,
quality problems can be found and corrected directly where they
have been introduced. Moreover, inspections shorten delivery period
by reducing the time spent in the integration and system test/debug
phases.
In an inspection, a work product is selected for review by a team of
experts, who are gathered for an inspection meeting to review the
work product. Furthermore, a moderator is chosen to moderate the
meeting, where inspectors prepare for the meeting by reading the
work product and noting each defect. In short, in an inspection, a
defect is any part of the work product that keeps an inspector from
approving it.
During software inspection, the number of participants range from a
minimum of three to a maximum of six. The minimum number of
participants is derived from the required roles that are assigned to
each individual. Having more than six participants does not increase
the number of defects uncovered, but it does increases the cost of
effectiveness. In short, having more than six participants during
inspection increases the cost per defect discovered to
unacceptable levels.
4)
5) (a)
(b) Iteration planning process:

Iteration planning is the process of discussing and planning the next

cycle, phase or iteration of a software application that is under
development. It is conducted through a meeting of the entire software
development team at the starting point of each iteration to formally plan
technical and non-technical processes.

Like software development, project planning requires an iterative process. Like software, a
plan is an intangible piece of intellectual property to which all the same concepts must be
applied. Plans have an engineering stage, during which the plan is developed, and a
production stage, when the plan is executed. Plans must evolve as the understanding
evolves of the problem space and the solution space. Planning errors are just like product
errors: The sooner in the life cycle they are resolved, the less impact they have on project
success.

Comprehensive project plans are highly dependent on numerous parameters, any one of
which can have a significant impact on the direction of a project. Nevertheless, generic
planning advice is sought by every software project manager as a skeleton from which to
begin. This chapter is not a plan, a cookbook for a plan, nor a recipe for a plan. It is simply
a rough model of a few dimensions, perhaps a starting point for a plan.

Key Points

▲ Projects can underplan and they can overplan. Once again, balance is paramount in the
level of planning detail and the buy-in among stakeholders.

▲ The work breakdown structure is the "architecture" of the project plan. It must
encapsulate change and evolve with the appropriate level of detail throughout the life
cycle.

▲ Cost and schedule budgets should be estimated using macroanalysis techniques (top-
down project level) and microanalysis techniques (bottom-up task level) to achieve
predictable results.
6) (a)
(b)
version of the status assessment are advantageous.
7) The Seven Core Metrics:
Many different metrics may be of value in managing a modern process. I have settled on
seven core metrics that should be used on all software projects. Three are management
indicators and four are quality indicators.

Management Indicators

• Work and progress (work performed over time)

• Budgeted cost and expenditures (cost incurred over time)

• Staffing and team dynamics (personnel changes over time)

Quality Indicators

• Change traffic and stability (change traffic over time)

• Breakage and modularity (average breakage per change over time)

• Rework and adaptability (average rework per change over time)

• Mean time between failures (MTBF) and maturity (defect rate over time)

Table 13-1 describes the core software metrics. Each metric has two dimensions: a static
value used as an objective, and the dynamic trend used to manage the achievement of that
objective. While metrics values provide one dimension of insight, metrics trends provide
a,more important perspective for managing the process. Metrics trends with respect to
time provide insight into how the process and product are evolving. Iterative development
is about managing change, and measuring change is the most important aspect of the
metrics program. Absolute values of productivity and quality improvement are secondary
issues until the fundamental goal of management has been achieved: predictable cost and
schedule performance for a given level of quality.

Overview of the seven core metrics

The seven core metrics can be used in numerous ways to help manage projects and
organizations. In an iterative development project or an organization structured around a
software line of business, the historical values of previous iterations and projects provide
precedent data for planning subsequent iterations and projects. Consequently, once
metrics collection is ingrained, a project or organization can improve its ability to predict
the cost, schedule, or quality performance of future work activities.

The seven core metrics are based on common sense and field experience with both
successful and unsuccessful metrics programs. Their attributes include the following:

• They are simple, objective, easy to collect, easy to interpret, and hard to misinterpret.

• Collection can be automated and nonintrusive.

• They provide for consistent assessments throughout the life cycle and are derived from
the evolving product baselines rather than from a subjective assessment.

• They are useful to both management and engineering personnel for communicating
progress and quality in a consistent format.

• Their fidelity improves across the life cycle.

The last attribute is important and deserves further discussion. Metrics applied to the
engineering stage (dominated by intellectual freedom and risk resolution) will be far less
accurate than those applied to the production stage (dominated by implementation
activities and change management). Therefore, the prescribed metrics are tailored to the
production stage, when the cost risk is high and management value is leveraged. Metrics
activity during the engineering stage is geared mostly toward establishing initial baselines
and expectations in the production stage plan.