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.