SPM Superbank

SPM Superbank
Unit 1
1. write a note on project and give the importance and characteristics of
Software Project Management
Project definition
To study project management it is necessary to first understand the
concept of a project.
A project is defined as an undertaking of a non-routine, non-
repetitive nature having prescribed objectives in terms of scope,
time, quality and cost.
A project is to create something new, unique, or to enhance an
existing product, service, or system.
A project is a temporary endeavor undertaken to create a unique
product, service, or result.
A project is an endeavor to accomplish specific objectives through a
unique set of interrelated
Tasks and effective utilization of resources.
Some characteristics of software project that make them more
different to handle are:
Invisibility
When a physical artefact such as a bridge or road is being
constructed the progress being made can actually be seen.
With software, progress is not immediately visible to others
and may be difficult to quantify
In terms of the percentage of work done.
Complexity
Software projects are complex in nature than other
engineering projects and the complexity can be gauged by
the success rate of these projects.
Flexibility
The ease with software can be changed is usually seen as
one of its strengths.
However, this means that where the software system
interfaces with a physical or organizational system, it is
expected that, where necessary, the software will change
to accommodate the other components rather than vice
versa.
This means the software systems are likely to be subject to
a high degree of change.
Conformity
The ‘traditional’ engineer usually works with physical
systems and materials like cement and steel.
These physical systems have complexity, but are governed
by consistent physical laws.
Software developers have to conform to the requirement of
human clients. It is not just that individuals can be
inconsistent.
Organizations, because of lapses in collective memory, in
internal communication or in effective decision making can
exhibit remarkable, ‘organizational stupidity’.
Project Management Lifecycle
The project life cycle describes the various logical phases in the life
of a project from its beginning to its end in order to deliver the final
product of the project.
The idea of breaking the project into phases is to ensure that the
project becomes manageable, activities are arranged in a logical
sequence, and risk is reduced.
The Project Goal
The first step of any project, irrespective of its size and
complexity, is defining its overall goal.
Every project undertaken aims to provide business value to
the organization hence the goal of the project should focus
on doing the same.
Now, the goal of the project needs to be defined initially as
it provides the project team with a clear focus and guides it
through each phase of the project. The project is hazy and
seems risky at the start, but as the project goals get
defined and starts making progress, things start to look
brighter and the probability of success increase.
The Project Plan
Also known as baseline plan. The project plan is developed
to provide answers to various project related queries such
as:
What the project aims to achieve?-The project
deliverables
How does the project team aim to achieve it?-The tasks
and activities
Who all will be involved in the project?-The
stakeholders and the project team
How much will it cost?-The project budget How much
time will it take?
The project schedule
What are the risks involved?
Risk identification
Project Plan Execution
The project plan thus developed needs to now be executed.
The project progress should be compared with the baseline
plan and communication to all of the project's stakeholders.
The project manager has to constantly monitor the project's
progress, schedule, budget, and resources.
Project Closure
Project closure marks the culmination of the project. In the
event of the project having completed all the work as
planned, the project sponsor should formally acknowledge
its successful completion, discharge all resources from the
ongoing project, and make necessary payment of dues of
any external consultants and suppliers.
The project closure is also marked by the presentation of a
project report that documents all the project deliverables.
Project Evaluation
It is not possible to evaluate the true value of any IT project
immediately after its implementation.
Sometimes the goals are long term and the results of the
project can only be gauged after the passage of a certain
period of time.
However, this does not mean that evaluation should not be
undertaken immediately. For starters, the project team
should document all its experience-things it did right, things
it should have done differently, and all the lessons learned
during the entire course of the project.
The project manager should evaluate each team member
and provide feedback to the member as well as the
management, the performance of the project manager
should be evaluated by the senior manager.
Evaluation of the project manager is carried out in terms of;
the project delivering the promised work, abiding by
budgetary provisions, following established processes, and
ability to manage resources.
2. explain the different phases of project management life cycle
- The Software
Project Management methodology comprises of five phases which are as
follows :
 (1) Phase I: Project Conceptualization and Initialization
 The
primary project goal is very important in project methodology as it provides a
basic for future
project decisions and aids in defining the project scope.
 Project Initiation is the first official step or activity in the project methodology
and marks the
commencement of the project. The main idea behind this initiation
is to ensure that the business
need is properly understood by the project
manager and is kept in mind throughout the lifecycle of
the project.
 The
Project Initiation stage enables the creation of the project charter that is the
official document
authorizing the project manager to undertake the project
within the organization.
 (2) Phase II: Developing Project Plan and Charter

The planning process should complement the size and complexity of the project
i.e. the larger and
MUQuestionPapers.com
more complex the project the greater the planning effort while small routine
project requires very
less planning effort.
 Planning is an iterative process, and
may require constant changes in its budget, scope, schedule or
quality, as per
the requirement of the client, stakeholder or the management.
 A project
charter is a detailed official document prepared in line with the company’s vision
and goal
describing in detail the finer nuances of the project and chalking out
deadlines for the milestone
within the project.
 (3) Phase III: Project Execution
and Control
 The product oriented process plays an important role during the
execution phase of the project.
Quality assurance, risk management, team
development, etc. form the core of the supporting
processes in the project
execution.
 The primary objective of the controlling process is to measure and
manage the project activities and
ensure that they are on the right track towards
the goal and adhere to the scope, budget, schedule,
and quality parameters.

Controlling process is present in each of the phase it has more emphasis in this
phase.
 (4) Phase IV: Project Closure
 The primary objective of the closing
process group is to ensure that project reaches its logical
conclusion and to bring
the project to an orderly completion.
 At this phase the project team has to
ensure that the project integrates with the day-to-day
operations of the
organization and delivers information products as required.
 Contract closure
indicates that all the project deliverables have been successfully completed and
all
the agreed upon terms and conditions of the contract have been adhered too.
 (5) Phase V: Project Evaluation
 The first part of the project review should be
conducted to identify the best practices taken for the
project in the whole
methodology of the organization.
 The second part takes place between the
project manager and the whole team members which focus
on reviewing
individual performance of team members as well as that of the project manager.
 The third part of the review should be conducted by a neutral party who
should review the project,
the project manager and the project team which
focuses on the overall performance and the
expectations by the client to the
manager and its whole team.
 The last part of the evaluation process should
determine whether the project succeeded in providing
value to the organization.
 The W5HH principle in software management exists to help project managers
guide objectives, timeline ,
responsibilities, management styles, and resources.
 Created by software engineer Barry Boehm, the purpose behind the W5HH
principle is to work through the
objectives of a software project, the project
timeline, team member responsibilities, management styles, and
necessary
resources.
 Boehm stated that an organizing principle is needed that works for any size
project. So he developed W5HH as a
guiding principle for software projects.

To get the essence of the project, Boehm suggests an approach (W5HH) that
addresses project objectives,
milestones and schedules, responsibilities,
management and technical approaches and required resources.
 He calls it the W5HH principle, after a series of questions that lead to a

definition of key project characteristics
and the resultant project plan:
 Why is
the system being developed?
 Enables all parties to assess the validity of
business reasons for the software work.
 What will be done?

 Establish the task set that will be required.
 When it
will be accomplished?
 Project schedule to achieve milestone. The team
establishes a project schedule by identifying
when project tasks are to be
conducted and when milestones are to be reached.
 Who is responsible?

Role and responsibility of each member of the software team is defined.

Where are they organizationally located?
 Not all roles and responsibilities reside within the software team itself.
Customer, end user and
stake holders also have responsibility.
 How will the
job be done technically and managerially?
 Management and technical strategy
must be defined.
 How much of each resource is needed?
 Develop
estimation.
 Conclusion is that the people by interaction with other people, the
recognition of management and their peers,
and by being given opportunities for
personal development.
 Software development groups should be fairly small
and cohesive. The key factors that influence the effectiveness
of a group are the
people in that group, the way that it is organized, and the communication
between groups and
members.
 Communications within a group are influenced
by factors such as the status of group members, the size of the
group, the
gender composition of the group, personalities and available communication
channels.
3. Write a short note on Portfolio management.

A portfolio is a collection of
projects, programs and other associated work that are grouped together
to
facilitate effective management of that work to meet strategic business
objectives.
-The projects and programs within an organizations portfolio may
not necessarily be associated with
each other and the allotment of funding
and resources is on the sssssssss. As is of priority and
risk/reward equation.
-Organizations manage their portfolio on the basis of specific goals such as
maximizing the value of
the portfolio and excluding projects not meeting the
portfolio's strategic objectives.
-Other goals for
managing portfolio could be balancing the portfolio investment and for
efficient use
of resources.
-IT portfolio management is the application of
management techniques to the investments, projects,
programs and
activities of the company's Information Technology Department.
-The
primary objective of IT project management is the quantification of
previously undertaken IT
projects and programs, enabling measurement and
objective evaluation of investment scenarios.
Three key aspects of PPM are:
Project Portfolio Definition:
-Record in a single repository details
Project
Portfolio Management:
-Details costing of projects and managers hope are
recorded
-Actual performance are tracked
Project Portfolio Optimization:
-
Better balance of project may be achieve
-Profitable, but risky
-Modest
benefits, fewer risks
4. What do you mean by scope and objective of a project? List the activities
involved in identifying project scope and objective'
Project scope management includes the processes required to ensure that the
project includes all the
work required, and only the work required, to carry out
the project successfully. Project scope
management is primarily concerned with
defining and controlling what is and is not included in the
project.
As per the
Project Management Body of Knowledge (PMBOK), the knowledge area of
Project Scope
Management comprises of five processes, namely, scope initiation
process, scope planning, scope
definition, scope verification and scope change
control.
(1) Project Scope Initiation Process
In this process the project sponsor
gives the project manager the authority and resources to define
the project
scope
The authority to commit time and resources to defining the project scope
is given when the project
plan and charter are being developed.
(2) Project
Scope Planning Process
The project scope planning process identifies what work
is and is not part of the project work. It
primarily settles the boundaries of the
project work.
It is essential to also identify what is not a part of the project work
to avoid future problems.
As Olde Curmudgeon has stated, "Failure to define
what is part of the project, as well as what is not,
may result in work being
performed that was unnecessary to create the product of the project and
thus
lead to both schedule and budget overruns".
(3) Project Scope Definition Process

The project scope definition process
identifies the project deliverables and the product deliverables.
Project
deliverables is the work that needs to be accomplished to deliver a product with
specific
features and functions.
Product deliverables are the features and
functions that characterise a product. The boundaries and
deliverables defined
by the scope planning and definition facilitate the development of the project
charter and plan. The requirements of the project defines its boundaries.
(4)
Project Scope Verification Process
The scope verification process checks the
scope for accuracy and completeness.
The project scope needs to be verified.
Scope verification is the process of obtaining the stakeholders
formal
acceptance of the completed project scope and associated deliverables.
Scope
verification ensures that the project deliverables are completed as per the
standards laid in the
delivery definition table (DDT). Scope verification includes
the review of each deliverable and
comparison with the standards specific in the
DDT.
(5) Project Scope Change Control

Although, the project scope has been set with
great deliberation and thought, changes to it are bound
to arise as the project
progresses and new information or need emerges. This warrants the need for
project scope change control to manage these changes. The change control
process has to approve
the change to initiate amendments in project schedule
and budget.
The project scope change control process also protects the scope
boundaries from expanding
unnecessary due demands of additional features and
functions to the project scope.
There is a direct relationship between project scope, budget and schedule. An

increase in the scope
i.e. expansion of scope boundaries leads to a direct
increase in project's budget and schedule and vice
versa. Hence, such change
demands need to be properly scrutinized before being approved.
Define Net Profit, Payback Period and Returns on Investment. Calculate these
values for the following cash flow forecast of a project.
Unit 2
1. What do you understand by the term 'ceremonies' in a scrum project?
Explain Scrum
Scrum is an efficient framework within which you can develop
software with teamwork. It is based on agile
principles. It is a framework for developing and sustaining complex products.

Ken Schwaber and Jeff Sutherland
developed Scrum. Together, they stand
behind the Scrum Rules. Scrum is not a process or a technique for building
products; rather, it is a framework within which you can employ various
processes and techniques. Scrum makes
clear the relative efficacy of your
product management and development practices so that you can improve.
Scrum is:
 Lightweight
 Simple to understand
 Difficult to master
Uses
of Scrum:
 Research and identify viable markets, technologies, and product capabilities;

 Develop products and enhancements;
 Release products and
enhancements, as frequently as many times per day;
 Develop and sustain
Cloud (online, secure, on-demand) and other operational environments for
product
use; and,
 Sustain and renew products.
Scrum has been used to
develop software, hardware, embedded software, networks of interacting
function,
autonomous vehicles, schools, government, marketing, managing the
operation of organizations and almost
everything we use in our daily lives, as
individuals and societies.
In order to provide transparency and regular
communication in the midst of such environments are held. Scrum
ceremonies
are meetings that are unique to scrum teams.
Scrum is executed in what are
called sprints, or short iterations of work lasting usually no more than two weeks.
The scrum ceremonies are outlined below:
 Sprint Planning: This is where the
team meets and decides what they need to complete in the coming
sprint.

Daily Scrum: This is a standup meeting, or a very short – 15-minute mini-meeting
– for the team to make
sure they are all on the same page.
 Sprint Review: This
is another type of meeting, but one in which the team demos what they shipped
in
the sprint.
 Sprint Retrospective: This is when the team reviews their work,
identifying what they did well and what
didn’t go as planned, so they can make
the next sprint better.
Let’s dig a little deeper and explore each scrum ceremony
in depth.
 Spirit Planning
 This ceremony helps to set up the entire team for
the coming sprint, creating a smooth pathway for
a successful sprint. Spirit
Planning requires the participation of all the scrum roles: the development
team,
scrum master and the product owner.
 The product owner comes to the meeting with a prioritized list of the product
backlog items, which is
presented to the group. The items on the list, which are
also called user stories, are then discussed
with the development team.

Together, they estimate what it will take to complete the items on the list. From
this information, the
development team makes a sprint forecast. They will outline
how much work the team can complete
from the product backlog.
 Some sprint
planning ceremonies will flesh out details of each user story. This will make sure
that
everyone involved understands the scope of the work. By doing this, the
actual sprint planning
ceremony is shorter and directed only towards user stories
that will be tackled in the upcoming sprint.
 Daily Scrum
 This short scrum
ceremony makes sure that everyone knows what’s happening. It’s a way to
ensure
transparency across the team.
 A detailed status meeting this is not,
but rather a light and fun informative meeting. It’s a space for
each team member to answer the following questions: what did you complete
yesterday, what are
you working on today and are you blocked by anything?

The daily scrum is, as it says, a daily occurrence, which usually takes place each
morning with the
development team, scrum master and product owner. The
ceremony is short, usually 15 minutes,
which is why it’s also called a standup
meeting.
 The great thing about the daily scrum is that is demands
accountability. People report honestly on
what they did, what they plan on doing
and how they might be getting blocked in the process, and
this is all done in
front of their peers.
 Daily scrum is not limited to teams that share a physical
location. If the teams are working remotely,
the ceremony can be conducted with
video conferencing or another group chat.
 Sprint Review
 After the sprint has been completed, it’s time to get the team
together to demo or showcase their
work. Each team member reviews the newly developed features or whatever it
was that they worked
on during the sprint.
 This provides a space for the team
to congratulate themselves on a successful sprint, which is
important for morale.
It also demonstrates the finished work for the entire team, so they can provide
feedback and also get feedback from the stakeholders in the project.
 Here,
unlike other ceremonies, the review can last as long as it takes to demo all the
work done by
the team. Again, the participants are the development team, scrum
master and product owner, but
also in this instance, other teams involved in the
project and the stakeholders.
 Sprint Retrospective
 The last scrum
ceremony is called the sprint retrospective. It occurs at the end of a sprint, after
the
review, and is usually an hour in duration. The retrospective includes the
development team, scrum
master and product owner.
 Because scrum is part
of an agile process, it is all about change, which includes getting feedback and
quickly acting on it. Scrum seeks continuous improvement and the retrospective
is a method to make
sure that the product and development culture is constantly
improving.
 The retrospective is a way for the team to understand what has
worked well and what didn’t come
together over the previous sprint. The
retrospective is a way for the team to understand what has
worked well and
what didn’t come together over the previous sprint.
 But, if the mantra of scrum is to always seek to improve, then the

retrospective must be critical, too,
but only as a steppingstone to improvements.
3. Write a note on COCOMO II Model

COnstructive COst MOdel II (COCOMO II)
is a model that allows one to estimate the cost, effort, and
schedule when
planning a new software development activity.
COCOMO II is the latest major
extension to the original COCOMO (COCOMO@81) model published in
4. It consists of three sub models, each one offering increased fidelity the
further along one is in the
project planning and design process. Listed in
increasing fidelity, these sub-models are called the
Applications
Composition, Early Design, and Post-architecture models.
COCOMO II is an
alternative to include components of uncertainty according to level of
information
available.
It is a parametric model that establishes mathematical
equations that describe the relationships
between software size-primary
cost factor usually represented in terms of function points- and other
secondary factors that look to identify features of a product, process, people
and platform.
The model provides a complete framework to determine local
productivity factors (productivity
constants) based on time and effort data in
past projects.
One of the main advantages of COCOMO II is to provide estimates of time

and effort, and from that,
suggest the size of the team.
COCOMO II can be
used for the following major decision situations:
Making investment or other
financial decisions involving a software development effort
Setting project
budgets and schedules as a basis for planning and control
Deciding on or
negotiating trade-offs among software cost, schedule, functionality,
performance or
quality factors
Making software cost and schedule risk
management decisions
Deciding which parts of a software system to
develop, reuse, lease, or purchase
Making legacy software inventory
decisions: what parts to modify, phase out, outsource, etc.
Deciding how to
implement a process improvement strategy, such as that provided in the SEI
CMM.
Effort multipliers
Cost estimation of IT project is usually measured in
terms of effort. The most common metric used is
person months or years (or
man months or years).
The effort is the amount of time for one person to
work for a certain period of time.
It is important that the specific
characteristics of the development environment are taking into
account
when comparing the effort of two or more projects because no two
development
environments are the same.
A clear example of differences in
development environments are the amount of time people work in
different
countries; the typical workweek in America is 40 hours per week, while in
India the typical
workweek is more than 40 hours per week. Thus, when
comparing a project from America with a
project from India, a conversion
factor would have to be used to all for an accurate comparison.
Effort multipliers used at early design are:
PERS-
Personnel Capability
PREX-Personnel Experience
RUSE-Required Reusability
RCPX-Product Reliability and Complexity

PDIF-Platform Difficulty
SCED-Required
Development Schedule
FCIL-Facilities
1. write a note on Caper Jones estimating rules of thumb

Rules Formulated by
Capers Jones-
Rule 1: SLOC Function Point Equivalence
When it comes to estimating the size of the project the
function point analysis is used on account of
its advantages. Thus, it becomes
necessary for the project manager to determine SLOC measure from
its function
point measurement.
Jones through his experience determined the equivalence
between SLOC and function point. SLOC
function point equivalence varies across
different programming languages so it would take about 320
lines of assembly
code to implement one function point. In C language to express one SLOC
several
instructions of assembly language are needed.
Rule 2: Project during
Estimation
Function point raised to the power 0.4 predicts the approximate
development time in calendar
months.
E.g. if the size of a project is estimated by
325 function points i.e. approximately 40,000 SLOC then the
completion time for
the project would be approximately 17 months.
Rule 3: Rate of Requirement
Creep
User requirements creep in at an average rate of 2% per month from the
design through coding
phases.
Requirement creep is the increase in the
requirements of the user and these keep on increasing for a
variety of reasons as
the project progresses.
Requirement creeps is not expected to increase during
project testing and installation stages. The rule
states that creep takes between
the requirement phases till the testing phase and therefore only that
part of the
project should be considered.
Rule 4: Defect Removal Efficiency
Each software
review, inspection or test step will find and remove 30% of the bugs that are
present.
Defect removal steps at various stages of the project development
ensure that the final product is
reliable.
Rule 5: Project Manpower Estimation
The
size of the software in function points divided by 150 predicts the approximate
number of
personnel required for developing the application.
Rule 6: Software
Development Effort Estimate
The approximate number of staff months required
to develop software is given by the software
development time multiplied by the
number of personnel required.
Function points divided by 500 predicts the
approximate number of personnel required for regular
maintenance activities.
1. Discuss the common problems faced during effort estimation

One of the
most efficient parts of IT project management is the estimation of effort. The
IT industry is very volatile
and dynamic with fluctuations in software and
hardware happening every now and then.
 The largest expenditure in IT
projects is time. If the team is not technically ready to implement the
technology they are naturally going to require more time.
 Hence, while
estimating the effort the project manager has to take into account the
learning curve to
implement and manage the new technology.
 Therefore,
the project manager should select his team as per the technical
requirements of the project.
Team members should be familiar with the
software and hardware components of the project.
 This will ensure that
less time is lost in learning the new technology. However, the effort of
imparting
training to the team should be included in the estimate.
2. Explain briefly Albrecht/IFPUG function points and solve the following
The
five major components of Albrecht Function Point Analysis are:
1. EI
The number of external inputs. These are elementary processes in which
derived data passes across
the boundary from outside to inside. In an
example library database system, enter an existing patron's
library card
number.
2. EO
The number of external outputs. These are elementary processes in
which derived data passes
across the boundary from inside to outside. In an
example library database system, display a list of
books checked out a
patron.
3. EQ
The number of external queries. These are elementary processes with
both input and output
components that result in data retrieval from one or
more internal logical files and external interface
files. In an example library
database system, determine what books are currently checked out to a
patron.
4. ILF
The number of internal log files. These are user identifiable groups of
logically related data that
resides entirely within the application boundary
that are maintained through external inputs. In an
example library database
system, the file of books in the library.
5. ELF
The number of external log files. These are user identifiable groups of
logically related data that
resides entirely within the application boundary
that are used for reference purposes only, and
which reside entirely outside
the system. In an example library database system, the file that
contains
transactions in the library's billing system.
Function point metrics provide a
standardization method for measuring the various functions of a software
application.
It measures the functionality from the user’s point of view, that
is, on the basis of what the user requests and
receives in return. Function
point analysis is a standard method for measuring software development
from the
user’s point of view.
Unit 3
1. With the help of example explain forward pass and backward pass to
calculate activity duration in network diagram
Forward Pass - forward pass is performed on a network schedule to calculate;

a.
The earliest time and each activity in the network can start and finish.
b. The
minimum overall duration of the project.
-Early Finish (EF) = Early Start (ES) +
Duration
-Early Start (ES) = Max Early Finish (EF) of related predecessor activity.
Backward Pass - The purpose of performing a backward
pass on a network is to calculate the latest
time that each activity in the network
can start and finish and still maintain the minimum overall
duration of the project
is calculated by the forward pass.
-Late Start (LS) = Late Finish - Duration
-Late
Finish = Minimum Late Start (LS) of related successor activity.
1. Activity A: this is the starting activity hence Early State (ES) = 0.
Early Finish
(EF) = Early Start + duration = 0 + 8 = 8
2. Activity B: here Early Start (ES) = 8 which is the Early Finish of Activity A.
Early Finish (EF) = Early Start + duration = 8 + 12 = 20
3. Activity C: here Early Start (ES) = 20 which is the
Early Finish of Activity B.
Early Finish (EF) = Early Start + duration = 20 + 14 = 34
Similarly the Forward Pass for other Activities can be calculated and have been
depicted in the figure
above. Also, Activity F has two predecessor activities,
namely activity C and G, while calculating
forward pass of activity F we will have
to consider higher duration of predecessor activity.
1. Feasibility Assessment
Is the project possible within require timescales and
resource constraints? It is not until we have
constructed a detailed plan that
we can forecast a completion date with any reasonable knowledge
of its
achievability.
2. Resource Allocation
What are the most effective ways of allocating
resources to the project and when should they be
available? The project plan
allows us to investigate the relationship between timescales and resource
availability.
3. Detailed Costing
How much will the project cost and when is that
expenditure likely to take place? After producing an
activity plan and
allocating specific resources, we can obtain more detailed estimates of costs
and
their timing.
4. Motivation
Providing targets and being seen to monitor achievement against
targets is an effective way of
motivating staff, particularly where they have
been involved in setting those targets in the first place.
5. Co-ordination
When do the staff in different departments need to be
available to work on a particular project and
when do staff need to be
transferred between projects?
The project plan, particularly with large
projects involving more than a single project team, provides
an effective
vehicle for communication and co-ordination among teams.
Define the term risk and discuss the ways to deal with them.
An uncertain event
or condition that, if it occurs, has a positive or negative effect on the project
objectives.
The systematic process of identifying, analyzing and responding to project risk. It

includes maximizing the
probability and consequences of positive events and
minimizing the probability and consequences of adverse
events.
The Risk Management Framework specifies accepted best practice for
the discipline of risk management. It is
implementation independent – it defines
key risk management activities, but does not specify how to perform
those
activities.
In particular, the framework helps provide a foundation for a
comprehensive risk management methodology basis
for evaluating and
improving a program’s risk management practice.
The main phases of RISK
MANAGEMENT FRAMEWORK are:
1. Phase I: Prepare for Risk Management

 The first phase, prepare for Risk
Management, of the framework lays the groundwork for the other two
phases. In this phase, preparation activities for risk management are
performed.
 This phase determines who is sponsoring the risk
management, plan for conducting risk management, and the
resources
required to effectively conduct risk management.
2. Phase II: Perform Risk Management Activities
 The second phase, Perform
Risk Management activities, specifies the activities that are to be used for
managing risk. This phase is performed continually till the overall risks to the
key objectives of the project
are eliminated
 In this phase, activities of
management are performed as planned. First and foremost the phase
identifies
the risks that could affect the achievements of the key program
objectives.
 This phase also specifies to ensure that each risk is
maintained within tolerable limits over the entire
duration of the project. This
phase also determines whether the mitigation plan is having the desired
effect.
3. Phase III: Sustain an d Improve Risk Management
 The third phase, Sustain
and Improve Risk Management, is performed on a periodic basis to ensure
that
the risk management practice remains effective over the entire course
of the project.
 In this phase, activities are performed to sustain and
improve risk management effort over the entire
duration of the project. This
phase specifies the risk management assets and work products that need to
be under configuration, lessons learnt while preparing for risk management
and conducting risk
management and how the entire risk management
exercise can be improved.
Explain the nature of resources and their scheduling

Once all the resources
required for the completion of the project have been identified and the
requirement list
is prepared it is time to map that on the activity plan to assess the distribution of
resources required over the
duration of the project.
This can be done by representing the activity as a bar chart and use this to
produce a resource histogram for each
resource.
The output of the process of resource identification is the resource histogram.

Resource Allocation identifies what resources are needed to complete activities
and critical path calculates when
the activities can be performed.

Combining these two sets of data allows the
demand for each type of resource to be aggregated over time. This
information is
typically represented as a resource histogram.
The diagram below illustrates a
number of activities on a Gantt Chart. The numbers represent the amount of a
specific required each day. The numbers are summed and shown graphically at
the bottom of the diagram as a
resource histogram.
Resource Smoothing
-In smaller or simpler projects, resource smoothing can be
done by simply analysing the project
network to find out the demand for
resources.
-During this analysis it is assumed that all the activities will start on
their respective earliest start
time. We will then schedule the resource as per
requirement and then observe the overlaps and the
period when the demand for
the resource is the highest.
-In case the resource is limited and there is an
overlap than the activities will have to be
rescheduled. Alternative schedules will
have to be prepared as per the slack of each activity.
-Also if the duration of a
project is directly proportional to the amount of resource applied then the
length
of the project is a function of the number of workers assigned to the project.
Thus, the
project length would be shorter when more number of workers are
assigned.
Criteria for prioritizing activities for resource allocation:
-The criteria
for scheduling are the slack that the activities have and resources are allocated
to the
activities as per the slack that they have. For this activities have to be
arranged according to the float
they have starting from the activity having the
minimum float to the one that has the highest float.
-Also, if two activities have
the same float then the one with the smallest duration should be
scheduled first.
The objective behind scheduling the activity with the smallest duration is that
the
waiting time for the other activity is reduced. Now, if there are two activities
having identical float
and duration then the activity requiring more resources
should be scheduled first.
Discuss the factors to be taken into account while allocating individuals to task
-
While allocating human assets to software project activities the project manager
has to be specific
about two things namely,
A) Nature of Software Development.
B) Skills and experience that will influence the time taken and the quality of the
project.
-The project manager has to also consider the availability of the person
i.e. if the person has any work
commitments towards his department.
-Remember, a project is an undertaking of a non-
routine, non-repetitive nature and hence people with
required skills are drawn
from various departments of the organization and hence it is necessary to
check
their availability with them or the department in which they work on a regular
basis. Thus, it is
essential that the project manager confirms the availability of all
team members when required for
the project before finalizing the project
schedule.
-The project manager has to allocate people with experience to
activities on the critical path.
-The critical path is the longest path in the project
and hence it is essential to pay the utmost attention
to its completion and hence
the allocation experienced people. Also, the allocation of experienced
people
could reduce project uncertainties.
-The junior staff or the people with little
experience should be allocated to non-critical activities and
their skills should be
honed to undertake critical activities in the future.
-Building a project team is an
art and the project manager has to ensure that he has the right person
for the
right job and that they are compatible with the project requirements.
Unit 4
write a short note on Contract
- contracts on the basis of payment to suppliers
- fixed price contract
- the stages in Contract Placement
ixed Price Contract

-This is the simplest type of all contracts. The terms are quite
straight forward and easy to
understand.
-To put in simple, the service provider
agrees to provide a defined service for a specific period of
time and the client
agrees to pay a fixed amount of money for the service.
-This contract type may
define various milestones for the deliverables as well as KPIs (Key
Performance
Indicators). In addition, the contractor may have an acceptance criteria defined
for the
milestones and the final delivery.
-The main advantages of this type of
contract is that the contractor knows the total project cost
before the project
commences.
Advantage-
Known customer expenditure: If there are few
subsequent changes to the original requirements, then
the customer will have a
known outlay.
Supplier motivation: The supplier has a motivation to manage the
delivery of the system in a cost-
effective manner.
Disadvantage-
Higher price to
allow contingency: The suppliers absorbs risk for any errors in the original
estimate of
product size. To reduce the impact of this risk, the supplier will add a
margin when calculating the
price to be quoted in a tender.
Difficulties in
modifying requirements: The need to change the scope of the requirements
sometimes
becomes apparent as the system is developed - this can cause
friction between the supplier and
customer.
Upward pressure on the cost of
changes: When competing against other potential suppliers will try
and quote as
low a price as possible. If, once the contract is signed, further requirements are
put
forward, the supplier is in a strong position to demand a high price for these
changes.
Threat to system quality: The need to meet a fixed price can mean that
the quality of the software
suffers.
A contract is a legally binding document that
recognizes and governs the rights and duties of the parties to the
agreement. A
contract is legally enforceable because it meets the requirements and approval
of the law. A
contract typically involves the exchange of goods, service, money, or promise of

any of those.
Contact Placement has taken on a bigger role in day-to-day tasks
as businesses work towards increasing
productivity without increasing their
employee numbers. As the amount of contracts in business transactions
grow,
it’s imperative that contracts save time, not consume more of it.
Stage 1.
Contract Preparation – Identify Your Needs, Establish Goals, Set Expectations,
and Define Risk
 Contracts should seek to define and mitigate risk in a
relationship, looking ahead to any potential
scenarios that could occur over the
lifetime of the document and accounting for them in the contract.
 For
example, the terms of agreement within a contract should address what happens
if the client files for
bankruptcy, goes out of business, or sells the company,
along with any other contingencies that may arise.
 One goal of this document
should be to make sure the business is financially protected despite the
scenario, and will be paid once the tasks outlined in an agreement are complete.
A contract ensures that
even if a business relationship is strong, each side is
going to obtain exactly what is expressed in the
contract.
Stage 2. Author the
Contract
 When authoring the terms of the contract, it’s also important to pay
attention to specific wording. Any
ambiguity leaves contracts up for
interpretation, even down to a comma.
 State and country laws will also need
to be taken into consideration, especially if the two parties are in
different
locations.
Stage 3. Negotiate the Contract
 No matter how much research, planning, and preparation goes into the first
draft of a contract,
negotiation almost always follows. Negotiation should begin
with transparency and trust.
 Anticipating and researching the other party’s needs before the conversation
simplifies the process and
creates a strong foundation for a lasting relationship.
 As redlining begins, it’s easiest to use a contract management platform so
both parties can view the
working document to make changes and collaborate in
real time.
 Email and offline documents can be confusing and cause costly mistakes, but
a single source of truth for
conversations and contracts will result in quicker
negotiations and a contract that provides visibility for
both sides.
Stage 4. Get Approval before Finalizing the Contract

 After negotiations are
complete and both parties agree, next comes approval. In larger companies that
need manager approval or have audit procedures, all the requirements for
approval will need to be met
before finalizing the deal.
 For example, if a company has specific procurement policies, they will need to
be met prior to gaining
approval for the contract.
 In a contract placement
platform, this is as simple as setting up an approval workflow so that whoever
needs to approve the contract receives a notification and can view, edit, and
comment on the contract in
real time.
Stage 5. Execute the Contract
 The
signing should be the simplest part of a contract: both parties agree, the wording
is exact, and the
next step is simply making it official.
 However, many
businesses make agreements across the country or even the globe, and getting
signatures isn’t as straightforward as meeting in person.
 Especially if
deadlines are tight or time zones are incompatible, overnight mail or even email
may not be
the best way to get signatures faster.
 A legally binding online
signature (e-signature) can solve all these problems, allowing you to move faster,
accelerating signatures and revenue.
Stage 6. Keep up with Amendments and
Revisions
 Contracts are rarely stagnant. Revisions and amendments are a
common part of the lifecycle of a contract.
Tracking changes and the effects for
each party can be confusing; however, this is another reason to
implement a
reliable process, such as a contract lifecycle management platform, to easily
record edits and
add amendments.
 It’s important to stay ahead of the changes
and make sure both parties are fully aware and in agreement
on any revisions.
Stage 7. Manage after the signature - Obligations, Auditing and Renewals

Performing regular audits will ensure obligations are met and value is realized.
Alerts should be set for
deadlines and renewals. Missed renewals mean lost
opportunities to continue a relationship, and most
importantly for a company,
lost revenue.
 Being aware and making contact well before the renewal time
shows reliability and care for the
relationship, and will continue to build trust and
loyalty.
 Contract placement can be a time-consuming task, but if properly
managed, can be one of the most
lucrative areas for building business
relationships and generating revenue. A contract lifecycle
management platform
simplifies contract placement processes, providing the ability to manage and
avoid
risk and compliance issues through templates and approval workflows,
streamline negotiations with
online redlining, deliver more revenue and faster
with online signatures, and more easily manage
documents after their signed
helping organizations grab opportunities that may otherwise have been
missed.
Advantage-
Known customer expenditure: If there are few subsequent changes
to the original requirements, then
the customer will have a known outlay.
Supplier
motivation: The supplier has a motivation to manage the delivery of the system in
a cost-
effective manner.
Disadvantage-
Higher price to allow contingency: The
suppliers absorbs risk for any errors in the original estimate of
product size. To
reduce the impact of this risk, the supplier will add a margin when calculating the
price to be quoted in a tender.
Difficulties in modifying requirements: The need to
change the scope of the requirements sometimes
becomes apparent as the
system is developed - this can cause friction between the supplier and
customer.
Upward pressure on the cost of changes: When competing against other
potential suppliers will try
and quote as low a price as possible. If, once the
contract is signed, further requirements are put
forward, the supplier is in a
strong position to demand a high price for these changes.
Threat to system
quality: The need to meet a fixed price can mean that the quality of the software
suffers
Explain review process model with the help of diagram

oftware Review is
systematic inspection of a software by one or more individuals who work
together to find and resolve errors and defects in the software during the early
stages of Software
Development Life Cycle (SDLC). Software review is an
essential part of Software Development Life
Cycle (SDLC) that helps software
engineers in validating the quality, functionality and other vital
features and
components of the software. It is a whole process that includes testing the
software
product and it makes sure that it meets the requirements stated by the
client. Usually performed
manually, software review is used to verify various
documents like requirements, system designs,
codes, test plans and test cases.
Objectives of Software Review:
The objective of software review is:
To improve
the productivity of the development team.
To make the testing process time and
cost effective.
To make the final software with fewer defects.
To eliminate the
inadequacies.

Types
of Software Reviews:
There are mainly 3 types of software reviews:
Software
Peer Review:
Peer review is the process of assessing the technical content and
quality of the product and it is
usually conducted by the author of the work
product along with some other developers. Peer review
is performed in order to
examine or resolve the defects in the software, whose quality is also
checked by
other members of the team. Peer Review has following types:
(i) Code Review:
Computer source code is examined in a systematic way.
(ii) Pair Programming:
It
is a code review where two developers develop code together at the same
platform.
(iii) Walkthrough:
Members of the development team is guided bu
author and other interested parties and the
participants ask questions and make
comments about defects.
(iv) Technical Review:
A team of highly qualified
individuals examines the software product for its client’s use and identifies
technical defects from specifications and standards.
(v) Inspection:
In inspection
the reviewers follow a well-defined process to find defects.
Software
Management Review:
Software Management Review evaluates the work status.
In this section decisions regarding
downstream activities are taken.
Software Audit Review:
Software Audit Review is a type
of external review in which one or more critics, who are not a part of
the
development team, organize an independent inspection of the software product
and its
processes to assess their compliance with stated specifications and
standards. This is done by
managerial level people.
Explain the change control process.

-IT Project Management is like a well-
rehearsed play going awry at the last moment. No matter thenumber of hours of
practicing and rehearsing, there are bound to be some last minute glitches
whichcan put the entire project on tender hooks.
-Project managers have to get
back to the drawing board and start redesigning the process again. Theymay
have either discovered a better way of getting job down or some changes
requested bymanagement or user in the project deliverables may have prompted
the change in plans.
-Whatever be the reason the project manager has to decide
whether the change in the project isfeasible and the system to put in place to
review, approve or decline the request for change.
-Although, incorporating
changes in IT project management is not an easy task they are subject
tochanges due to the dynamic nature of the industry.
-Changes may be made
necessary due to the introduction of new software, security issues, or
newrequests from stakeholders.
-On his part the project manager has to elevate
the time, cost, risk, and any other repercussions thateach change requests
brings along with it. In case the change request it needs to be
documented,tracked and implemented.
-However in the real world these are not
how things work. Changes are forced onto the project andthe project manager is
forced to alter the project scope.
Change control is a methodology used to
manage any change requests that impact the baseline of your project.
It’s a way
to capture that change from the point where it’s been identified through every
step of the project
cycle. That includes evaluating the request and then approving, rejected or
deferring it.
The purpose of this process is to make sure that you’re not changing things in
the project that don’t need to be
changed. The last thing you want to do is
disrupt the project for no good reason, wasting valuable time and
resources. Any
changed that is approved is then documented. The change control process is
part of the larger
change management plan.
A control process sets delegation
limits and guidelines for decision making. It may include forms and templates to
be completed. It also outlines the sequential procedures to be followed in
respect to project change, which are
typically to:
 identify the proposed
change.
 assess its potential impact on a project— on factors such as scope,
cost, quality, risk and schedules. The
extent of rigour applied to this assessment
will depend on the nature of the project itself and key
stakeholders.
 approve
or reject it. Approving it may be beyond the delegation of the Project Manager. If
so, it may be
referred to the project sponsor or the project Steering Committee,
with recommendations based on the
assessment.
 advise the party who
requested the change of the outcome, with reasons.
 implement the change, if
approved, and adjust planning documents to reflect its impact.
 follow up to
check that implementation has occurred and been done properly.
It is important
that the project change control process is managed expeditiously so that it, in
itself, does not
become a delay factor in the delivery of the project.
Explain Motivation
Vroom's expectancy theory separates effort, performance
and outcomes, while Maslow and
Herzberg focus on the relationship between
internal needs and the resulting effort expended to fulfil
them.
Vroom's
expectancy theory assumes that behaviour results from conscious choices
among
alternatives whose purpose it is to maximise pleasure and to minimise
pain.
Vroom realised that an employee's performance is based on individual factors

such as personality,
skills, knowledge, experience and abilities.
He stated that effort, performance and motivation are linked in a person's

motivation.
He uses the variables Expectancy, Instrumentality and Valence to
account for this.
According to Vroom Motivation is a product of valence, expectancy and

instrumentality. It can be
put in an equation as follows −
Motivation = Valence ×
Expectancy × Instrumentality
Expectancy
Expectancy is the idea that increasing
the amount of effort will increase performance (if I work
harder then I will
perform better).
This is affected by:

Having the right resources available (e.g. raw materials, time)
Having the right skills to do the job
Having the necessary support to get the job
done (e.g. supervisor support, or correct information o
the job)
Instrumentality
Instrumentality is the idea that if you perform better, then the outcome will be
achieved (If perform
well, there I will achieve the desired outcome).
This is
affected by:
A clear understanding of the relationship between performance and
outcomes – e.g. the rules of th
reward 'game'
Trust in the people who will take
the decisions on who gets what outcome
Transparency of the process that
decides who gets what outcome
Valence
Valence is the perceived value the
employee puts on the outcome. For the valence to be positive,
the person must
prefer attaining the outcome than not attaining it. (If someone is mainly
motivated
by money, he or she might not value offers of additional time off).
The
three elements are important behind choosing one element over another
because they are
clearly defined:
Effort-performance expectancy (E-->P expectancy) and performance-outcome

expectancy (P-->O
expectancy).
E-->P expectancy: our assessment of the
probability that our efforts will lead to the required
performance level.
P-->O
expectancy: our assessment of the probability that our successful performance
will lead to
certain outcomes.
Vroom's expectancy theory works on perceptions,
so even if a motivation tactic works with most
people in the organisation, it
doesn't mean that it will work for everybody.
The job characteristics model,
designed by Hackman and Oldham, is based on the idea that the task itself is key
to employee motivation. Specifically, a boring and monotonous job stifles

motivation to perform well, whereas a
challenging job enhances motivation.
Variety, autonomy and decision authority are three ways of adding
challenge to a
job.
Hackman and Oldham’s job characteristics theory proposes that high
motivation is related to experiencing three
psychological states whilst working:
i.
Meaningfulness of work
 That labor has meaning to you, something that you
can relate to, and does not occur just as a set of
movements to be repeated. This is fundamental to intrinsic motivation, i.e. that

work is motivating
in an of itself (as opposed to motivating only as a means to an
end).
 The work must be experienced as meaningful (his/her contribution
significantly affects the overall
effectiveness of the organization). This is derived
from:
 Skill Variety: Using an appropriate variety of your skills and talents: too
many might be
overwhelming, too few, boring.
 Task Identity: Being able to
identify with the work at hand as more whole and complete, and
hence enabling
more pride to be taken in the outcome of that work (e.g. if you just add one
nut
to one bolt in the same spot every time a washing machine goes past it is much
less
motivating than being the person responsible for the drum attachment and
associated work
area (even as part of a group).
 Task Significance: Being able
to identify the task as contributing to something wider, to
society or a group over
and beyond the self.
For example, the theory suggests that I will be more
motivated if I am contributing to the
whole firm’s bonus this year, looking after
someone or making something that will benefit
someone else.
Conversely I will
be less motivated if I am only making a faceless owner wealthier, or am
making
some pointless item (e.g. corporate give-away gifts).
ii. Responsibility
 That
you have been given the opportunity to be a success or failure at your job
because sufficient
freedom of action has given you. This would include the ability
to make changes and incorporate the
learning you gain whilst doing the job.

Responsibility is derived from autonomy, as in the job provides substantial
freedom, independence
and discretion to the individual in scheduling the work
and in determining the procedures to be used
in carrying it out).
iii. Knowledge of
Outcomes
 This is important for two reasons. Firstly, to provide the person
knowledge on how successful their
work has been, which in turn enables them to
learn from mistakes.
 The second is to connect them emotionally to the
customer of their outputs, thus giving further
purpose to the work (e.g. I may
only work on a production line, but I know that the food rations I
produce are
used to help people in disaster areas, saving many lives).
 This comes from
feedback. It implies an employee awareness of how effective he/she is
converting
his/her effort into performance.
 This can be anything from production figures through to customer satisfaction

scores. The point is
that the feedback offers information that once you know, you
can use to do things differently if you
wish. Feedback can come from other
people or the job itself.
Knowing these critical job characteristics, the theory
goes, it is then possible to derive the key components of the
design of a job and
redesign it:
I. Varying work to enable skill variety.
II. Assigning work to groups to increase the wholeness of the product produced
and give a group to
enhance significance.
III. Delegate tasks to their lowest
possible level to create autonomy and hence responsibility.
IV. Connect people to
the outcomes of their work and the customers that receive them so as to provide
feedback for learning.
Taylor's viewpoint is reflected in the use of pieces-rates in manufacturing

industries and sales bonuses
amongst sales forces. A problem that project
leaders must be aware of is that piece-rates often cause
difficulties if a new
system is going to change work practices. If new technology is going to improve
productivity, the question of adjusting piece-rates downwards to reflect this will
be a sensitive issue.
Usually, radical changes in work practices have to be
preceded by a move from piece-rates to dayrates.
Even
when
work
practices
are
stable
and
output
can
be
easily
related
to
reward,
people
paid
by
the
amount they produce will not automatically maximize their output in order to
maximize their
income. The amount of output will often by constrained by 'group
norms', informal, even unspoken,
agreements among colleagues about the
amount to be produced. Rewards have to be related in a
simple way to the work
produced.
'This support department does well because we're a team, not
because we're all individuals. I think
it's the only way the support team can work
successfully.'
In this kind of environment, a reward system that makes excessive
distinctions between co-workers
can be damaging to morale and eventually to
productivity
Unit 5
What do you mean by team structure? Explain different types of team
structures
A team is a small number of people with complementary skills who are
committed to a common purpose, set
performance goals and approach for which
they hold themselves mutually accountable.
The team can also be defined as a
group of individuals which shares a common purpose and develops common
understanding of this purpose, common agreement on it and total commitment
to it, galvanized into a single
functional unit fully oriented and focused on the
tasks towards the agreed upon purpose.
As against traditional organizational
structures wherein they had different departments for each business
function,
today the day-to-day activities of a firm revolve around teams.
Whether it’s a sales and marketing team or research and development team,
teams are flexible and can build
products, negotiate prices and strike deals,
coordinate projects and provide services etc. There are four important
kinds of
teams that one would commonly find:
1. Problem – Solving Teams:

 This kind of team basically comprises of a few
members, ideally from 5 to 12, belonging to a particular
department coming
together on a weekly basis to discuss and solve problems of their
department
functioning.
 Members give their individual suggestions for process improvement and

after enough deliberation,
present their advice to the higher management for
further implementation.
 For example, Merrill Lynch, in the earlier days had
created a problem-solving team to figure out a way to
reduce the time taken
to open a new cash management account.
2. Self – Managed Teams:
 While problem-solving teams were effective in
recommending solutions, they didn’t have the power to
implement them.

Self-managed teams were built to address this challenge and apart from
discussing issues, they were
responsible for implementing the solutions and
taking responsibilities for their outcomes.
 From making operational
decisions to interacting with customers, self-managed teams are highly
effective
provided the members are motivated and driven to bring about
positive change.
3. Cross – Functional Teams:
 When employees from different business functions but belonging to a

similar hierarchical level come
together to achieve a common task, the team
is called a cross-functional team. The members bring their
individual
expertise from their respective work area and exchange information for a
common cause.
 Whether it is finding solution to a development fault or
coordinating complex projects, cross-functional
teams are very effective if
managed well.
 For example, the Boeing Company created a cross-functional team of

employees from various
departments like production, quality, and design
engineering, tooling and information systems to
automate shims on the C-17
program.
 Since the members belonged to diverse backgrounds, they were
able to give different perspectives to
arrive at the best solution. The team’s
suggestions helped reduce the cycle time and cost, as well as
greatly
improved the quality of the program.
 While cross-functional teams are
highly effective, they need good management skills to build trust and
teamwork amongst the members and manage the diverse nature of the
team.
4. Virtual Teams:
 In today’s world of internet and mobile technologies, it’s easier to manage

physically dispersed
members with the concept of building virtual teams.
Members collaborate online, participate in videoconferences
and
discuss
in real-
time
to
realize
a
common
objective.
 While virtual teams are easily manageable, the members sometime lack the
motivation to find solutions
or fail to trust each other due to absence of any
direct interaction.
 These challenges must be addressed by monitoring the efforts of the

members and recognizing their
individual contributions.
Virtual Team: A virtual
team is group of people to participate in common projects by making
collaborative efforts to achieve shared goals and objectives. These peoples
performed tasks and jobs
in a virtual work environment created and maintained
through IT and software technologies.
Advantage of forming a virtual team:
Cost savings - The
biggest advantage of virtual team enjoyed by an organization is the associated
cost
savings. The organization can do away with huge expenses on real estate,
office spaces, utilities bills
such as gas, electricity, water etc. and executives’
travel.
Leverage Global Talent - Virtual Teams allows organizations to look for
talent beyond their country of
origin. This brings together the experts and
specialists from across the globe to work together on the
project.
Increased
Productivity & Higher Profits - Members of virtual teams tend to have higher
focus on the
task at hand. As a practice virtual team supports flatter organization
structure. The members do not
have to deal with unnecessary bureaucracy
which slows down the decision making. This enhances the
productivity which
shows as higher profits.
Reduced Time to Market - Since the members span the
time zones, there could be different team
working on the same project 24*7, so
when one member sleeps there will be another one somewhere
else who would
start work where the former had left. This shortens the product development
time.
Newer Opportunities - If we see at larger societal level, virtual teams have
created newer
opportunities for people who are less mobile and hesitant to
relocate due to either family requirement
or physical challenge. Now any task
that does not require the physical presence of a person and which
can be
supported by communication technology throws an opportunity for many
deserving
candidates.
Discuss the main reasons for project closure
-Project is closed when it has
reached its stated objectives i.e. it has been successfully implemented
and been
handed over to its user. A successful project is simply developed to its customer.
-A project may be closed when it is transferred to another organizational division
to take the work
forward. Such a decision may be taken if the management feels
that the current project team is not a
position to reach the project objectives.
-Another reason for project closure or rather premature
project closure is when the project manager
reaches the conclusion that the
project is unfeasible and that the objectives are out of reach, resulting
in a
prematurely closed down project.
-A project on perfect course may face closure
on changed requirements of the user naming the project
redundant and forcing
to call of the project.
-Crises within the organization or customer may force the
closure of a project.
-Sudden an unanticipated changes in technology may force
the closure of a project.
-Budgetary issues may force the closure of a project.
-
Absence of key project personnel may force project closure.
-The planning of
project closure should be top priority and should be planned for in the inceptive
stages of a project as it’s elevated the chances of a successful completion.
-The
importance accorded to the closure stage of the project can be gauged when
organization employ
a specific manager, who possess an appropriate set of skills
and knowledge of project closure, to
overlook this phase of the project.
Explain five basic stages of Team development. Also state the different types of
people needed to form a balanced team
Developing teams is not an
instantaneous process; it takes time and commitment on the part of the project
manager to develop one. A project team is a consideration of people, never may
before. Also, as projects are
temporary, teams too are viewed as a temporary
arrangement and therefore there may be a lack of effort and
willingness amongst
team members to develop relationships.
The goal of team development is not to
develop long lasting relationship but to develop a team that can effectively
complete the project. Therefore, the bonus to develop the team lies with the
project manager.
The four stages of development all teams move through over
time: forming, storming, norming, and performing.
I. Forming
 This is where
team members first meet. It’s important for team leaders to facilitate the
introductions and
highlight each person’s skills and background. Team members
are also given project details and the
opportunity to organize their
responsibilities.
 Carefully planning each phase of a project helps team
members understand their role within the team
and what’s expected of them.
During your first project team meeting, start by explaining specifically what
each
person will be working on.
 Next, explain the project so everyone is clear on
their contribution and expected outcomes. If the goal of
the project is to increase
customer acquisition, you can explain that month-over-month growth has stalled
and your strategy to solve this is to:
 Find out what’s caused growth to plateau
 Come up with a plan to fix the
problem
 Put the plan into action
 At this point, explain how each team
member is expected to help. For example, let the designers know
that the user
interface will be reviewed to see whether there’s an opportunity to make
improvements.
 Finally, share the project roadmap so the team can see the
starting point, the proposed check-in points,
and the end goal. This gives them
insight into the bigger goal but also breaks down the timeline into
smaller
increments.
II. Storming
 At this stage, team members openly share ideas and
use this as an opportunity to stand out and be
accepted by their peers. Team
leaders help teams in this stage by having a plan in place to manage
competition
among team members, make communication easier, and make sure projects stay
on track.
 Disagreements are unavoidable on teams, especially when each
person on the team has a different
perspective on how to approach the issues
the team encounters. When you all work in the same location,
it can be easier to
hash out problems quickly.
 Instead of letting team members battle it out in
private messages select the best solution, be ready to
invite them into a chat
room to offer advice or ask some key questions. Very few team members will
have your perspective on the entire project (or the full scope of your team’s
segment of the project), so
don’t be afraid to jump in.
 When you do find a
good solution or process to help resolve difficult situations, make sure you
document
those immediately. The team can consult this record when future
problems arise and make adaptations
as needed. Your teams will soon learn that
conflict is not to be feared, and that they have the tools to
find a productive
compromise.
III. Norming
 By now, teams have figured out how to work together. There’s no
more internal competition, and
responsibilities and goals are clear.
 Each
person works more efficiently because he or she has learned how to share their
ideas and listen to
feedback while working toward a common goal.
 With
remote teams, it’s easy to run on assumptions until you’re almost up against a
deadline — and
then you discover that you didn’t get the outcome you needed.
Help your team check in with each other
by holding daily standup meetings or
mid-week progress reports to see if everyone is on track and has
the materials
they need.
 It’s easy for everyone — including you — to get in a tunnel and
focus on their own lists of tasks. Make
sure everyone steps back each day or
week to take a look at the larger picture.
IV. Performing
 In the performing
stage, teams are in sync and work more efficiently together than at any previous
stage.
Teams that have been working closely for some time have resolved enough
issues to understand what
success looks like for them. For example, success can
be anything from higher customer acquisition to a
positive shift in the metrics
they’re tracking.
 To get to this point, consistency is key. If you’ve asked team
members to update progress documents
weekly, check to make sure it’s being
done.
 Set reminders for yourself to check in with team members, or send
calendar events so that making
updates is always top of mind and getting done.
The main goal here is to keep the momentum going so
that the project wraps up
on time.
 Keep reminding the team to check in with each other regularly in
person or via instant chat, but stay out
of their way. They will waste time and
lose their focus if they have to answer frequent, unscheduled
questions about
what they’re working on.
 Encourage team members to develop a schedule
filled with large blocks of time that are free from
interruptions like meetings or
check-ins. In this world of constant notifications, it’s easy for people to get
derailed and forget which goals are really important. This is especially important
for creative and
development teams.
V. Adjourning
 Teams complete their project and debrief on what went well and
what could be improved for future
projects. Afterwards, team members move on
to new projects. This is the time for your team to finally
step back to see what
they’ve accomplished. Two things happen at this point:
 Teams review the last few weeks or months to celebrate their successes.

Teams take an honest look at what didn’t go well and pinpoint where there’s
room for
improvement.
 At the end of the project, set up an online meeting
where team members come together to discuss the
entire project, from the
successes to the frustrations.
 Ask them to prepare examples beforehand
outlining what worked and what didn’t, and then give each
person five minutes to
share their thoughts. Document the comments so that it’s easy to see which
trends emerge and what changes need to be made going forward.
 When
looking back to find opportunities for improvement, set up a brainstorming
session with your
team. Get your team members to prep ideas to share at the
meeting.
 For example, ask team members these types of questions to uncover
the good and the bad in each
project:
 What would you change about the team
and project introduction process?
 What additional documentation do we need
for issue resolution?
 What kind of support can team leaders offer?
 What
tasks took the most time?
 If you were to do a similar project again, what team members would you add
or remove as a
way to improve the team’s efficiency and expertise?
 Which tools worked best? Which hindered progress?

Working with a team of
people can be exhilarating—and challenging. Aside from the chemistry of
personalities
and work styles that affect a group dynamic, there’s also the
territorial play. Popular theories say a high-
performing team is comprised of
both distinctly defined roles and a well-rounded collection of personality
archetypes. Here’s a short guide to 7 personality types that complete a
successful team:
1. The Leader: This person is responsible for mediating conflicts, facilitating
communications
between team members, and keeping everyone on course.
The leader will schedule and guide the
course of meetings, but that doesn’t
mean being the only speaker, or leading all the meetings. A
good leader
knows how to delegate and let go of the reins.
2. The Team Player: Team players are identified by their enthusiasm to work
together for a
common good. They’re usually eager to help, willing to
compromise and diplomatic. They might
not the biggest initiators in the
world, but you can rely on team players to follow-through on tasks
and to
willingly settle conflicts with their calming demeanor (they’re sort of like the
glue of the
group).
3. The Researcher: The researcher types—who show up in sales, IT, support,

marketing, content,
etc.—are always asking questions and then finding their
own answers. If you need more
information to complete your project, it’s
important to have a strong researcher who can get it
for you. Researchers
ask the overlooked questions that can avert a future impediment. This
natural private eye knows the quickest way to the best resources and is the
person everyone goes
to with the most puzzling questions.
4. The Expert: This is the person that possesses intimate knowledge in a field
that your project
encompasses. So, if you’re on the marketing team within a
group that is working on new mobile
software, you need a developer to go to
who will explain the necessary technical details and
offerings—and make
sure you’re accurately representing the product in your messaging.
5. The Planner: If you have a natural planner on your team, trust that their skills
will deliver your
project in the estimated period of time. Natural planners love
lists, charts, and calendars. They’re
punctual, able to see the curve in the
road (and incoming curve balls) and often have strategies
for improving a
process or increasing team efficiency.
6. The Creative: Every team benefits from a creative thinker in the group—
someone who can
deliver fresh ideas and solutions that let the team’s work
stand out from the crowd. Creative types
have a tendency to get caught up
in their world of imagination, problem-solving, and
conceptualizing. To spot a
creative, look for the original thinker, the person willing to turn the
status quo
on its head and come up with a new approach to a long-standing goal.
7. The Communicator: Communicators are often thought of as the salespeople,

marketers, writers,
and leaders. Those are communication jobs. We’re talking
about the natural communicators—
not just the talkative ones (that’s often
part of it), but individuals who are naturally inclined to
reach out to others
and share information with the entire team. Your communicator might be the
person with the longest list of contacts and knows someone for just about
anything you need
Define the term quality. Explain McCall's quality model. Quality: As software is
not a tangible product, software quality is not easily definable. Software has
many quality characteristics. However, quality management resolves around
defects. Hence,
delivered defect density i.e. the number of defects per unit size
in the delivered software is the
industry accepted definition of quality.
McCall's
Quality Model:
Also called as General Electronics Model. It mainly has 3 major
representations for defining and
identifying quality.
(A)Product Revision
(1)Maintainability: Effort required to locate and fix a fault in the program within its
operating
environment.
(2)Flexibility: The ease of making changes required as
dictated by business by changes in the operating
environment.
(3)Testability:
The ease of testing program to ensure that it is error-free and meets its
specification,
i.e., validating the software requirements.
(B)Product Transition
(1)Portability: The effort required to transfer a program from one environment to
another.
(2)Re-usability: The ease of reusing software in a different context.
(3)Interoperability: The effort required to couple the system to another system.
(C)Product Operations:
(1)Correctness: The extent to which a functionality
matches its specification.
(2)Reliability: The system's ability not to fail/the extent
to which the system fails.
(3)Efficiency: Further categorized into execution
efficiency & storage efficiency & generally means the
usage of system resources.
(4)Integrity: The protection of program from unauthorized access.
(5)Usability:
The ease of using software.
Software quality is a nuanced concept that requires a framework that addresses

functional, structural and the
process of the software delivery. Measurement of
each aspect is a key tool for understanding whether we are
delivering a quality
product and whether our efforts to improve quality are having the intended
impact.
However, measurement can be costly. To balancing the effort required to
measure quality versus the benefit, you
first need to understand the reasons for
measuring quality. Five of reasons quality is important to measure
include:
I. Safety: Poor quality in software can be hazardous to human life and safety.
Quality problems can impact
the functionality of the software products.
II. Cost:
Quality issues cost money to fix. Whether you believe that a defect is 100x more
costly to fix late
in the development cycle or not, doing work over because it is
defective does not deliver more value than
doing it right once.
III. Customer
Satisfaction (Internal): Poor quality leads stakeholders to look for someone else
to do your job
or perhaps shipping your job and all your friend’s jobs somewhere
else. Recognize that the stakeholders
experience as the software is being
developed, tested and implemented is just as critical as the raw
number of
defects.
IV. Customer Satisfaction (External): Software products that don’t work, are hard
to use (when they don’t
need to be), or are buggy don’t tend not to last long in
the marketplace. Remember that in today’s social
media driven world every
complaint that gets online has a ripple effect. Our goal should be to avoid
problems that can be avoided.
V. Future Value: Avoiding quality problems
increases the amount of time available for the next project or
the next set of
features. Increasing quality also improves team morale, improved team morale is
directly
correlated with increased productivity (which will increase customer
satisfaction and reduce cost).
ISO 9126 is an international standard for the evaluation of software. The

standard is divided into four parts which
addresses, respectively, the following
subjects: quality model; external metrics; internal metrics; and quality in
use
metrics.
ISO9126–1 represents the latest (and ongoing) research into
characterizing software for the purposes of software
quality control, software
quality assurance and Software Process Improvement (SPI).
The other parts of
ISO9126, concerning metrics or measurements for these characteristics, are
essential for SQC,
SQA and SPI but the main concern of this article is the
definition of the basic ISO 9126 Quality Model.
The ISO 9126–1 software quality
model identifies 6 main quality characteristics, namely:
 Functionality:
Functionality is the essential purpose of any product or service. For certain items
this is
relatively easy to define, for example a ship’s anchor has the function of
holding a ship at a given location.
The more functions a product has, e.g. an ATM
machine, then the more complicated it becomes to define
its functionality. For
software a list of functions can be specified, i.e. a sales order processing
systems
should be able to record customer information so that it can be used to
reference a sales order. A sales
order system should also provide the following
functions:
 Record sales order product, price and quantity.

 Calculate total price.

Calculate appropriate sales tax.
 Calculate date available to ship, based on
inventory.
 Generate purchase orders when stock falls below a given threshold.
The list goes on and on but the main point to note is that functionality is
expressed as a totality of essential
functions that the software product provides.
A function of the sales order process could be to record the sales order but we
could implement a hard
copy filing cabinet for the actual orders and only use
software for calculating the price, tax and ship date.
In this way the functionality
of the software is limited to those calculation functions.
The relationship
between software functionality within an overall business process is outside the
scope of
ISO9126 and it is only the software functionality, or essential purpose of
the software component, that is
of interest for ISO9126.
 Reliability: Once a
software system is functioning, as specified, and delivered the reliability
characteristic
defines the capability of the system to maintain its service
provision under defined conditions for defined
periods of time. One aspect of
this characteristic is fault tolerance that is the ability of a system to
withstand
component failure. For example, if the network goes down for 20 seconds then
comes back the
system should be able to recover and continue functioning.

Usability: Usability only exists with regard to functionality and refers to the ease
of use for a given
function. For example, a function of an ATM machine is to
dispense cash as requested. Placing common
amounts on the screen for selection, i.e. $20.00, $40.00, $100.00 etc, does not
impact the function of the
ATM but addresses the Usability of the function. The
ability to learn how to use a system (learnability) is
also a major sub-
characteristic of usability.
 Efficiency: This characteristic is concerned with the
system resources used when providing the required
functionality. The amount of
disk space, memory, network etc. provides a good indication of this
characteristic. As with a number of these characteristics, there are overlaps. For
example, the usability of
a system is influenced by the system’s Performance, in
that if a system takes 3 hours to respond the
system would not be easy to use
although the essential issue is a performance or efficiency characteristic.

Maintainability: The ability to identify and fix a fault within a software component
is what the
maintainability characteristic addresses. In other software quality
models this characteristic is referenced
as supportability. Maintainability is
impacted by code readability or complexity as well as modularization.
 Portability: This characteristic refers to how well the software can adopt to
changes in its environment
or with its requirements. The sub characteristics of
this characteristic include adaptability. Object oriented
design and
implementation practices can contribute to the extent to which this
characteristic is present
in a given system.
State and explain different levels of Capability Maturity Model (CMM). Rather
than just checking that a system is in place to defect faults, a customer might
wish to check
that a supplier is using software development methods & tools
that are likely to produce good quality
software. A customer will feel more
confident, for instance, if they know that the supplier is using
structured
methods. This attempts to place organizations producing software at one of five
level of
process maturity to indicate the sophistication and quality of their
software production practices.
There in all five levels in the model.
Level 1: Initial
The
procedures followed tend to be haphazard. Some projects will be successful, but
this tends to be
because of the skills of particular individuals including project
managers. There is no level 0 as so any
organization would be at this level by
default.
Level 2: Repeatable
Organizations at this level will have basic project
management procedures in place. However, the way
an individual task is carried
out will depend largely on the person doing it.
Level 3: Defined
The organization
has defined the way in which each task in the software development life cycle is
to
be done.
Level 4: Managed
The product and process involved in software
development are subject to measurement and control.
Level 5: Maturity
Improvement in procedures are designed and implemented using the data
gathered from the
measurement process.
Capability Maturity Model (CMM) is a
methodology used to develop, refine maturity of an organizations software
development process. It is developed by SIE in mid1980. It is a process
improvement approach. It Deals with the
what processes should be implemented
& not so much with the how processes should be implemented. A
maturity model
is a structured collection of elements that describe characteristics of effective
processes.
 Place to start
 Benefit of a community’s prior experience

Common language and a shared vision
 Framework for prioritizing action
Place
to start
 The organization usually does not provide a stable environment.
Success in these organizations
depends on the competence and heroics of the people in the organization and
not on the use of
proven processes.
 The first phase of process is very initial
and important as it is the basic root of the capability models.
It needs to be well
cleared and error free so that the further process will not suffer any kind of loss
or
damage.
 This level of process has a basic and consistent project management process
to track the overall cost,
plan the schedule, and functionality. This phase can
allow some iterations in starting, but after when
the process starts to build at the
3
rd
or 4
th
phase it can’t allow any changes to be made in the 1
phase
itself.

All the activities should be planned in the first process itself, which can allow
other processes to
perform their allotted tasks efficiently and smoothly without
any kind of disturbance. This phase is
more valuable as compared to others
because, in this process it indicates half of the idea of the
capability model which
is to be made.
give a brief explanation of the main activities involved in Software Testing.

Testing is the process of evaluating a system or its component(s) with the intent
to find whether it satisfies the
specified requirements or not. In simple words,
testing is executing a system in order to identify any gaps, errors,
or missing
requirements in contrary to the actual requirements.
It depends on the process
and the associated stakeholders of the project(s). In the IT industry, large
companies
have a team with responsibilities to evaluate the developed software
in context of the given requirements.
Moreover, developers also conduct testing
which is called Unit Testing.
An early start to testing reduces the cost and time to
rework and produce error-free software that is delivered to
st
the client. However, in Software Development Life Cycle (SDLC),

testing can be started from the Requirements
Gathering phase and continued till the deployment of the software.
Quality Assurance: QA includes activities that ensure the

implementation of processes, procedures and
standards in context to verification of developed software and

intended requirements. Focuses on processes and
procedures rather than conducting actual testing on the system.
Quality Control: It includes activities that ensure the verification

of a developed software with respect to
documented (or not in some cases) requirements. Focuses on actual

testing by executing the software with an
aim to identify bug/defect through implementation of procedures and

process.
Testing: It includes activities that ensure the identification of

bugs/error/defects in a software. Focuses on actual
testing.
Audit: It is a systematic process to determine how the actual testing process is

conducted within an organization
or a team. Generally, it is an independent
examination of processes involved during the testing of a software.
Inspection: It
is a formal technique that involves formal or informal technical reviews of any
artifact by identifying
any error or gap. Inspection is a formal evaluation technique in which software

requirements, designs, or codes
are examined in detail by a person or a group
other than the author to detect faults, violations of development
standards, and
other problems.
Debugging: It involves identifying, isolating, and fixing the
problems/bugs. Developers who code the software
conduct debugging upon
encountering an error in the code. Debugging is a part of White Box Testing or
Unit
Testing. Debugging can be performed in the development phase while
conducting Unit Testing or in phases while
fixing the reported bugs.
Types of
Testing
 Manual Testing: includes testing a software manually, i.e., without
using any automated tool or any
script.
 Automation Testing: is used to re-run
the test scenarios that were performed manually, quickly, and
repeatedly. The
tester writes scripts and uses another software to test the product.
Methods of Testing
 Black-Box Testing: The technique of testing without
having any knowledge of the interior workings of the
application is called black-
box testing. In Black-Box Testing, tester will interact with the system's user
interface by providing inputs and examining outputs without knowing how and
where the inputs are
worked upon.
 White-Box Testing: It is the detailed
investigation of internal logic and structure of the code. In order to
perform
white-box testing on an application, a tester needs to know the internal workings
of the code.
 Grey-Box Testing: It is a technique to test the application with having a limited

knowledge of the internal
workings of an application. Grey box testers don't rely
on the source code; instead they rely on interface
definition and functional
specifications.
Testing Levels:
 Functional Testing
 Unit Testing
 Integration
Testing
 System Testing
 Regression Testing
 Acceptance Testing
 Alpha
Testing
 Beta Testing
 Non-Functional Testing
 Usability Testing
 Security
Testing
 Portability Testing
Explain the metrics correlated with Software reliability.
1. Product metrics: function point metric is a method of measuring the

functionality of software
development based upon a count of inputs,
outputs, master files, inquires, and interfaces. The method
can be used to
estimate the size of a software system as soon as these functions can be
identified. It
is a measure of the functional complexity of the program. It
measures the functionality delivered to
the user and is independent of the
programming language. It is used primarily for business systems.
2. Project management metrics: Good management can result in better
products and a relationship
exists between the development process and
the ability to complete projects on time and within the
desired quality
objectives. Cost increase when developers use inadequate processes.
Higher reliability
can be achieved by using better development process, risk
management process, configuration
management process, etc.
3. Process metrics: The quality of a product is a direct function of the process,
metrics can be used to
estimate, monitor and improve the reliability and
quality of software.
4. Fault and failure metrics: The goal of collecting the fault and failures metrics
is to be able to
determine when the software is approaching failure-free
execution. Test strategy is highly relative to
the effectiveness of fault
metrics. Usually, failure metrics are based upon customer information
regarding failures found after release of the software. The failure data
collected is therefore used to
calculate failure density, Mean Time between
Failures (MTBF) or other parameters to measure to
predict software
reliability.
The reliability growth group of models measures and predicts the improvement
of reliability
programs through the testing process. The growth model represents
the reliability or failure rate of a
system as a function of time or the number of
test cases.
Models included in this group are as following below.

Coutinho Model –
Coutinho
adapted the Duane growth model to represent the software testing process.
Coutinho
plotted the cumulative number of deficiencies discovered and the
number of correction actions
made vs the cumulative testing weeks on log-log
paper. Let N(t) denote the cumulative number of
failures and let t be the total
testing time. The failure rate, \lambda (t), the model can be expressed
as
N (t)
λ(t) =
t
−β1
= β0t
where \beta_0: and: \beta_1 are the model parameters. The least squares method
can be used to
estimate the parameters of this model.
Wall and Ferguson Model –
Wall and Ferguson proposed
a model similar to the Weibull growth model for predicting the failure
rate of
software during testing. The cumulative number of failures at time t, m(t), can be
expressed as
β
m(t) = a0[b(t)]
where \alpha_0: and: \alpha_1 are the unknown parameters. The function b(t) can
be obtained as
the number of test cases or total testing time.
Similarly, the failure
rate function at time t is given by
\lambda (t)= {m^' (t)} = {a_0\beta b^' (t){[b(t)]^{\beta -1}}}
Wall and Ferguson tested this model using several software failure data and
observed that failure
data correlate well with the model.

SPM Superbank

Uploaded by

Copyright:

Available Formats

SPM Superbank

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SPM Superbank

Uploaded by

Copyright:

Available Formats

SPM Superbank

responsibilities, management styles, and resources.

 He calls it the W5HH principle, after a series of questions that lead to a

 What will be done?

3. Write a short note on Portfolio management.

(3) Project Scope Definition Process

(5) Project Scope Change Control

There is a direct relationship between project scope, budget and schedule. An

principles. It is a framework for developing and sustaining complex products.

 Research and identify viable markets, technologies, and product capabilities;

 But, if the mantra of scrum is to always seek to improve, then the

3. Write a note on COCOMO II Model

One of the main advantages of COCOMO II is to provide estimates of time

RCPX-Product Reliability and Complexity

1. write a note on Caper Jones estimating rules of thumb

1. Discuss the common problems faced during effort estimation

user’s point of view.

Forward Pass - forward pass is performed on a network schedule to calculate;

The systematic process of identifying, analyzing and responding to project risk. It

1. Phase I: Prepare for Risk Management

Explain the nature of resources and their scheduling

The output of the process of resource identification is the resource histogram.

the activities can be performed.

ixed Price Contract

contract typically involves the exchange of goods, service, money, or promise of

Stage 4. Get Approval before Finalizing the Contract

Explain review process model with the help of diagram

Explain the change control process.

Vroom realised that an employee's performance is based on individual factors

He stated that effort, performance and motivation are linked in a person's

According to Vroom Motivation is a product of valence, expectancy and

This is affected by:

Effort-performance expectancy (E-->P expectancy) and performance-outcome

to employee motivation. Specifically, a boring and monotonous job stifles

movements to be repeated. This is fundamental to intrinsic motivation, i.e. that

 This can be anything from production figures through to customer satisfaction

Taylor's viewpoint is reflected in the use of pieces-rates in manufacturing

1. Problem – Solving Teams:

 Members give their individual suggestions for process improvement and

 When employees from different business functions but belonging to a

 For example, the Boeing Company created a cross-functional team of

 In today’s world of internet and mobile technologies, it’s easier to manage

 These challenges must be addressed by monitoring the efforts of the

 Which tools worked best? Which hindered progress?

3. The Researcher: The researcher types—who show up in sales, IT, support,

7. The Communicator: Communicators are often thought of as the salespeople,

Software quality is a nuanced concept that requires a framework that addresses

ISO 9126 is an international standard for the evaluation of software. The

 Record sales order product, price and quantity.

give a brief explanation of the main activities involved in Software Testing.

the client. However, in Software Development Life Cycle (SDLC),

Gathering phase and continued till the deployment of the software.

Quality Assurance: QA includes activities that ensure the

standards in context to verification of developed software and

procedures rather than conducting actual testing on the system.

Quality Control: It includes activities that ensure the verification

documented (or not in some cases) requirements. Focuses on actual

aim to identify bug/defect through implementation of procedures and

Testing: It includes activities that ensure the identification of

Audit: It is a systematic process to determine how the actual testing process is