Unit 1: Introduction to Software Project Management
What is Software Engineering?
Software engineering is defined as a process of analyzing user requirements and
then designing, building, and testing software application which will satisfy those
requirements.
Why Software Engineering is Popular?
•
•
•
•
•
•
Large software – In our real life, it is quite more comfortable to build a wall
than a house or building. In the same manner, as the size of the software
becomes large, software engineering helps you to build software.
Scalability- If the software development process were based on scientific
and engineering concepts, it is easier to re-create new software to scale an
existing one.
Adaptability: Whenever the software process was based on scientific and
engineering, it is easy to re-create new software with the help of software
engineering.
Cost- Hardware industry has shown its skills and huge manufacturing has
lower the cost of the computer and electronic hardware.
Dynamic Nature- Always growing and adapting nature of the software. It
depends on the environment in which the user works.
Quality Management: Offers better method of software development to
provide quality software products.
Challenges of Software Engineering
Here are some critical challenges faced by software engineers:
•
•
•
•
In safety-critical areas such as space, aviation, nuclear power plants, etc. the
cost of software failure can be massive because lives are at risk.
Increased market demands for fast turnaround time.
Dealing with the increased complexity of software need for new
applications.
The diversity of software systems should be communicating with each other.
Software Products
Software Products are nothing but software systems delivered to the
customer with the documentation that describes how to install and use the
system. In certain cases, software products may be part of system products
where hardware, as well as software, is delivered to a customer. Software
products are produced with the help of the software process. The software
process is a way in which we produce software.
Types of software products:
Software products fall into two broad categories:
Generic products:
Generic products are stand-alone systems that are developed by a production
unit and sold on the open market to any customer who is able to buy them.
Customized Products:
Customized products are the systems that are commissioned by a particular
customer. Some contractor develops the software for that customer.
Attributes for Software Products
The characteristics of any software product include features which are displayed by
the product when it is installed and put in use.
They are not the services which are provided by the product. Instead, they have
related to the products dynamic behavior and the use made of the product.
Examples of these attributes are:
Efficiency, reliability, robustness, maintainability, etc.
However, the relative importance of these characteristics varies from one software
system to another.
Product Characteristics
Description
Maintainability
The software should evolve to meet the
changing demands of the clients.
Dependability
Dependability includes various characteristics
Dependable software should never cause any
physical or economic damage at the time of
system failure.
Efficiency
The software application should overuse
system resources like memory and processor
cycle.
Usability
The software application should have specific
UI and documentation
Software Engineering Problems
The Problem of scale: A fundamental problem of software engineering is the
problem of scale; development of a very large system requires a very different set
of methods compared to developing a small system. In other words, the methods
that are used for developing small systems generally do not scale up to large
systems. A different set of methods has to be used for developing large software.
Any large project involves the use of technology and project management.
Cost, schedule and quality: The cost of developing a system is the cost of the
resources used for the system, which, in the case of software, are the manpower,
hardware, software, and the other support resources. Generally, the manpower
component is predominant, as software development is largely labor-intensive and
the cost of the computing systems is now quite low.
The Problem of consistency: Though high quality, low cost and small cycle time
are the primary objectives of any project, for an organization there is another goal:
consistency. An organization involved in software development does not just want
low cost and high quality for a project, but it wants these consistently.
Software Project
A Software Project is the complete procedure of software development from
requirement gathering to testing and maintenance, carried out according to the
execution methodologies, in a specified period of time to achieve intended
software product.
SP Vs. other types of projects activities covered by SPM
• Many Techniques of general project management are applicable to software
project management,But fred Brooks pointed out that the products of
software projects have certain characteristics that make them different.
Some ways of categorizing software projects
1. Compulsory Vs Voluntary systems (projects):
• Compulsory systems are the systems which the staff of an
organization have to use if they want to do a task.
• Voluntary systems are the systems which are voluntarily used
by the users e.g., computer gaming, school project, etc.
2. Information Vs Embedded systems (projects):
• Information systems are used by staff to carry out office
processes and tasks e.g., stock control system.
• Embedded systems are used to control machines e.g. a system
controlling equipment in a building.
Embedded systems are also called real-time or industrial systems.
Information systems versus embedded systems
A distinction may be made between information systems and
embedded systems. Very crudely, the difference is that in the former
case the system interfaces with the organization, whereas in the latter
case the system interfaces with a machine! A stock control system
would be an information system that controls when the organization
reorders stock. An embedded, or process control, system might
control the air conditioning equipment in a building. Some systems
may have elements of both so that the stock control system might also
control an automated warehouse.
3. Objective-based Vs Product-based systems (projects):
• Project whose requirement is to meet certain objectives which
could be met in a number of ways, is objective-based project.
• Project whose requirement is to create a product, the details of
which have been specified by the client, is product-based
project.
Project management cycle
Phase 1: Project Initiation
This is the starting phase where the project manager must prove that the project has
value and is feasible. This includes creating a business case that justifies the need
for the project, and a feasibility study to prove it can be executed within a
reasonable time and cost.
Steps for the project initiation phase may include the following:
•
Undertaking a feasibility study: Identify the primary problem your
project will solve and whether your project will deliver a solution to
that problem
•
Identifying scope: Define the depth and breadth of the project
•
Identifying deliverables: Define the product or service to provide
•
Identifying project stakeholders: Figure out whom the project affects
and what their needs may be
•
Developing a business case: Use the above criteria to compare the
potential costs and benefits for the project to determine if it moves
forward
Phase 2: Project Planning
After the project has been approved, the project moves into the second project
management phase: project planning. The goal of this phase is the creation of the
project plan, which will be the guide for the next two phases. The project plan must
include every component associated with the execution of the project, including
the costs, risks, resources and timeline.
Project managers often lay out their project plan using a Gantt chart, which
provides a visual representation of the entire project. This provides a roadmap for
the work until the project reaches its conclusion.
Steps for the project planning phase may include the following:
•
Creating a project plan: Identify the project timeline, including the
phases of the project, the tasks to be performed, and possible
constraints
•
Creating workflow diagrams: Visualize your processes using
swimlanes to make sure team members clearly understand their role in
a project
•
Estimating budget and creating a financial plan: Use cost estimates to
determine how much to spend on the project to get the maximum
return on investment
•
Gathering resources: Build your functional team from internal and
external talent pools while making sure everyone has the necessary
tools (software, hardware, etc.) to complete their tasks
Phase 3: Project Execution
The third project management phase is project execution, which is when the tasks
and milestones outlined in the plan are tackled to produce the deliverable to the
client’s or stakeholder’s satisfaction.
Along the way, the project manager will reallocate resources as needed to keep the
team working. In addition, they will identify and mitigate risks, deal with problems
and incorporate any changes.
Steps for the project execution phase may include the following:
•
Creating tasks and organizing workflows: Assign granular aspects of
the projects to the appropriate team members, making sure team
members are not overworked
•
Briefing team members on tasks: Explain tasks to team members,
providing necessary guidance on how they should be completed, and
organizing process-related training if necessary
•
Communicating with team members, clients, and upper
management: Provide updates to project stakeholders at all levels
•
Monitoring quality of work: Ensure that team members are meeting
their time and quality goals for tasks
•
Managing budget: Monitor spending and keeping the project on track
in terms of assets and resources
Phase 4: Project Monitoring and Control
The fourth project management phase, project monitoring and control, takes place
concurrently with the execution phase of the project. It involves monitoring the
progress and performance of the project to ensure it stays on schedule and within
budget. Quality control procedures are applied to guarantee quality assurance.
The biggest issues in a project are typically related to three factors—time, cost and
scope, which collectively are referred to as the triple constraint. The main goal of
this phase is to set firm controls on the project to ensure those three factors don’t
go off track.
Phase 5: Project Closure
The fifth project management phase is project closure, in which the final
deliverables are presented to the client or stakeholder. Once approved, resources
are released, documentation is completed and everything is signed off on. At this
point the project manager and team can conduct a post-mortem to evaluate
the lessons learned from the project.
Steps for the project closure phase may include the following:
•
Analyzing project performance: Determine whether the project's goals
were met (tasks completed, on time and on budget) and the initial
problem solved using a prepared checklist.
•
Analyzing team performance: Evaluate how team members
performed, including whether they met their goals along with
timeliness and quality of work
•
Documenting project closure: Make sure that all aspects of the project
are completed with no loose ends remaining and providing reports to
key stakeholders
•
Conducting post-implementation reviews: Conduct a final analysis of
the project, taking into account lessons learned for similar projects in
the future
•
Accounting for used and unused budget: Allocate remaining resources
for future projects
SPM framework
A project management framework consists of the processes, tasks, and tools used
to take a project from start to finish. It encompasses all the key components
required for planning, managing, and governing projects. The project
management framework can be broken into three parts:
1.Project life cycle This is the cycle a project goes through from beginning to
end. It consists of five phases:
Initiation: This is where you define what the project actually is. You can
outline your objectives in a project charter and identify any potential risks.
Planning: In this phase, you list all the project tasks in a detailed roadmap.
Estimate how long each one will take, create deadlines, and add assignees.
Execution: Put the plan into action. Teams commence work on project tasks
and align their schedules to achieve key deliverables.
Monitoring and controlling: Project managers oversee progress by tracking
team performance, creating reports, and readjusting priorities if necessary.
Closure: The final phase incorporates the results achieved when all project
tasks are completed. A project manager will analyze these results and plan
the next steps.
2. Project control cycle The control cycle is the process of monitoring and
controlling the project.
3. Tools and templates Project plans, project management reports, and risk logs
are common tools and templates for managing projects. Project framework
examples There are many project management frameworks you can choose to
use. Here are six of the most common ones: PRINCE2: This framework is highly
structured with a heavy emphasis on upfront planning.
CCPM: Critical chain project management focuses primarily on resource
allocation across the project.
Lean: A lean framework focuses on minimizing wasted effort and resources.
Process improvement techniques are often incorporated into this framework.
XPM: Extreme project management was designed for complex projects that
occur in fast-changing environments. Emphasis is on stakeholder management as
plans and schedules are rapidly changing.
Scrum: This framework was also designed for industries undergoing rapid
change. Using this framework, projects are often broken down and planned in 24 week sprints.
Waterfall: This framework is one of the traditional approaches to project
management. Waterfall requires a project to be planned from beginning to end,
with no phase of a project beginning until the previous one has ended.
How to choose a project management framework One single framework does
not work for all projects, which is why so many of them have been created over
the years. When deciding which framework is best for your project, consider the
following: If your industry, technology, or product is fast-changing, an adaptable
framework such as XPM or Scrum is recommended. If the project deliverable is
not well defined and is intangible in nature (such as software), a sprint-based
approach (such as Scrum) may work best. If the project is well defined and
stable, planning it out in its entirety decreases risks. Therefore, PRINCE2 or
Waterfall should work best. Frameworks may be chosen based on what your
organization and stakeholders are familiar with. If your company has never
completed an XPM project before, introducing one may be difficult. The
priorities of your stakeholders will impact your framework. If waste is a critical
concern, a lean framework may be chosen. Frameworks are designed to be
flexible and adapt to a project’s needs. It may be that you will end up borrowing
pieces of separate frameworks as the circumstances of your project change.
Unit 2: Project Analysis
Project analysis is the process of examining the aspects of a project in details.
This is mainly to see to it that the project runs as expected and is also within the
predefined budget.
Strategic Assessment
Used to assess whether a project fits in the long-term goal of the organization
Usually carried out by senior management
Needs a strategic plan that clearly defines the objectives of the organization
Evaluates individual projects against the strategic plan or the overall business
objectives Programmed management
suitable for projects developed for use in the organization Portfolio
management
suitable for project developed for other companies by software houses
SA – Programmed Management
Individual projects as components of a programmed within the organization
Programmed as “a group of projects that are managed in a coordinated way to
gain benefits that would not be possible were the projects to be managed
independently
SA – Programmed Management Issues
Objectives
How does the project contribute to the long-term goal of the
organization?
Will the product increase the market share? By how much?
IS plan
Does the product fit into the overall IS plan?
How does the product relate to other existing systems?
Organization structure
How does the product affect the existing organizational structure? the
existing workflow? the overall business model?
MIS
What information does the product provide?
To whom is the information provided?
How does the product relate to other existing MISs?
Personnel
What are the staff implications?
What are the impacts on the overall policy on staff development?
Image
How does the product affect the image of the organization?
SA – Portfolio Management
suitable for product developed by a software company for an organization
may need to assess the product for the client organization
Programmed management issues apply
need to carry out strategic assessment for the providing software company
Long-term goal of the software company
The effects of the project on the portfolio of the company (synergies and
conflicts)
Any added-value to the overall portfolio of the company
Technical Assessment
Functionality against hardware and software
The strategic IS plan of the organization
any constraints imposed by the IS plan
Internal Rate of Return(IRR)
Capital budgeting is a function of management, which uses various techniques to
assist in decision making. Internal Rate of Return (IRR) is one such technique of
capital budgeting. It is the rate of return at which the net present value of a project
becomes zero. They call it ‘internal’ because it does not take any external factor
(like inflation) into consideration.
Formula and Calculation for IRR
The formula and calculation used to determine this figure is as follows.
How to Calculate IRR
1. Using the formula, one would set NPV equal to zero and solve for the
discount rate, which is the IRR.
2. The initial investment is always negative because it represents an outflow.
3. Each subsequent cash flow could be positive or negative, depending on the
estimates of what the project delivers or requires as a capital injection in the
future.
4. However, because of the nature of the formula, IRR cannot be easily
calculated analytically and must thus instead be calculated iteratively either
through trial-and-error or by using software programmed to calculate IRR
(e.g. using Excel)
What is the Benefit-Cost Ratio (BCR)?
The benefit-cost ratio (BCR) is a profitability indicator used in cost-benefit
analysis to determine the viability of cash flows generated from an asset or project.
The BCR compares the present value of all benefits generated from a project/asset
to the present value of all costs. A BCR exceeding one indicates that the
asset/project is expected to generate incremental value.
Formula for the Benefit-Cost Ratio
The formula for the benefit-cost ratio is outlined below:
Where:
•
•
•
•
CF = Cash flow
i = Discount rate
n = Number of periods
t = Period that the cash flow occurs
Although the formula above may appear complicated, the calculation is simply the
discounted cash inflows divided by the discounted cash outflows. The discount rate
used refers to the cost of capital, which can be the company’s required rate of
return, the hurdle rate, or the weighted average cost of capital.
Example of the Benefit-Cost Ratio
Cash flow projections for a project are provided below. The relevant discount
rate is 10%.
Question: What is the benefit-cost ratio of the project?
Answer:
The benefit-cost ratio would be calculated as $97,670.72 / $33,625.09 = 2.90.
Interpreting the Benefit-Cost Ratio
The higher the BCR, the more attractive the risk-return profile of the project/asset.
The value generated by the BCR indicates the dollar value generated per dollar
cost.
For example, the BCR of 2.90 in the preceding example can be interpreted as “For
each $1 of cost in the project, the expected dollar benefits generated is $2.90.” The
following shows the value range of the BCR and its general interpretation:
Advantages of the Benefit-Cost Ratio
Key advantages of the benefit-cost ratio include:
•
•
•
•
It is a useful starting point in determining a project’s feasibility and whether
it can generate incremental value.
If the inputs are known (cash flows, discount rate), the ratio is relatively easy
to calculate.
The ratio considers the time value of money through the discount rate.
The ratio indicates the value generated per dollar of costs.
Limitations of the Benefit-Cost Ratio
Key limitations of the benefit-cost ratio include:
•
•
The reliability of the BCR depends heavily on assumptions. Poor cash flow
forecasting or an incorrect discount rate would lead to a flawed ratio.
The ratio itself does not indicate the project’s size or provide a specific value
on what the asset/project will generate. For example, both projects below
show a BCR of 2, but present value cash flows are significantly different:
CASH FLOW
Introduction
In this method of comparison, the cash flows of each alternative will be
reduced to time zero by assuming an interest rate i. Then, depending on the type
of decision, the best alternative will be selected by comparing the present worth
amounts of the alternatives.
The sign of various amounts at different points in time in a cash flow diagram
is to be decided based on the type of the decision problem.
In a cost dominated cash flow diagram, the costs (outflows) will be assigned
with positive sign and the profit, revenue, salvage value (all inflows), etc. will be
assigned with negative sign.
In a revenue/profit-dominated cash flow diagram, the profit, revenue, salvage
value (all inflows to an organization) will be assigned with positive sign. The
costs (outflows) will be assigned with negative sign.
In case the decision is to select the alternative with the minimum cost, then the
alternative with the least present worth amount will be selected. On the other
hand, if the decision is to select the alternative with the maximum profit, then the
alternative with the maximum present worth will be selected.
BASES FOR COMPARISON OF ALTERNATIVES
In most of the practical decision environments, executives will be forced to
select the best alternative from a set of competing alternatives.
Let us assume that an organization has a huge sum of money for potential
investment and there are three different projects whose initial outlay and annual
revenues during their lives are known. The executive has to select the best
alternative among these three competing projects.
There are several bases for comparing the worthiness of the projects. These bases
are:
1. Present worth method
2. Future worth method
3. Annual equivalent method
4. Rate of return method
1.PRESENT WORTH METHOD
ü In this method of comparison, the cash flows of each alternative will be
reduced to time zero by assuming an interest rate i.
ü Then, depending on the type of decision, the best alternative will be
selected by comparing the present worth amounts of the alternatives.
In a cost dominated cash flow diagram, the costs (outflows) will be
assigned with positive sign and the profit, revenue, salvage value (all
inflows), etc. will be assigned with negative sign.
ü In a revenue/profit-dominated cash flow diagram, the profit, revenue,
salvage value (all inflows to an organization) will be assigned with
positive sign. The costs (outflows) will be assigned with negative sign.
a.Revenue-Dominated Cash Flow Diagram
A generalized revenue-dominated cash flow diagram to demonstrate the present
worth method of comparison is presented in Fig.
To find the present worth of the above cash flow diagram for a
given interest rate, the formula is
PW(i) = – P + R1[1/(1 + i)1] + R2[1/(1 + i)2] + ...
+ Rj [1/(1 + i) j] + Rn[1/(1 + i)n] + S[1/(1 + i)n]
b.Cost-Dominated Cash Flow Diagram
A generalized cost-dominated cash flow diagram to demonstrate the
present worth method of comparison is presented in Fig.
To compute the present worth amount of the above cash flow diagram for
a given interest rate i, we have the formula
PW(i) = P + C1[1/(1 + i)1] + C2[1/(1 + i)2] + ... + Cj[1/(1 + i) j]
+ Cn[1/(1 + i)n] – S[1/(1 + i)n]
EXAMPLE
Alpha Industry is planning to expand its production operation. It has identified three
different technologies for meeting the goal. The initial outlay and annual revenues
with respect to each of the technologies are summarized in Table 1. Suggest the best
technology which is to be implemented based on the present worth method of
comparison assuming 20% interest rate, compounded annually.
Solution
In all the technologies, the initial outlay is assigned a negative sign
and the annual revenues are assigned a positive sign.
TECHNOLOGY 1
Initial outlay, P = Rs. 12,00,000
Annual revenue, A = Rs. 4,00,000
Interest rate, i = 20%, compounded annually
Life of this technology, n = 10 years
The cash flow diagram of this technology is as shown in Fig. 4.3.
Fig. Cash flow diagram for technology 1.
The present worth expression for this technology is
PW(20%)1 = –12,00,000 + 4,00,000 (P/A, 20%, 10)
= –12,00,000 + 4,00,000 (4.1925)
= –12,00,000 + 16,77,000
= Rs. 4,77,000
TECHNOLOGY 2
Initial outlay, P = Rs. 20,00,000
Annual revenue, A = Rs. 6,00,000
Interest rate, i = 20%, compounded annually
Life of this technology, n = 10 years
The cash flow diagram of this technology is shown in Fig. 4.4.
Fig. Cash flow diagram for technology 2.
The present worth expression for this technology is
PW(20%)2 = – 20,00,000
= – 20,00,000
=
+ 6,00,000 (P/A, 20%, 10)
+ 6,00,000 (4.1925)
– 20,00,000 + 25,15,500
=
Rs. 5,15,500
TECHNOLOGY 3
Initial outlay, P = Rs. 18,00,000
Annual revenue, A = Rs. 5,00,000
Interest rate, i = 20%, compounded annually
Life of this technology, n = 10 years
The cash flow diagram of this technology is shown in Fig. 4.5.
Fig. Cash flow diagram for technology 3.
The present worth expression for this technology is
PW(20%)3 = –18,00,000
= –18,00,000
+ 5,00,000 (P/A, 20%, 10)
+ 5,00,000 (4.1925)
=
–18,00,000 + 20,96,250
=
Rs. 2,96,250
From the above calculations, it is clear that the present worth of technology 2 is the
highest among all the technologies. Therefore, technology 2 is suggested for
implementation to expand the production.
2. FUTURE WORTH METHOD
ü In the future worth method of comparison of alternatives, the future worth of
various alternatives will be computed.
ü Then, the alternative with the maximum future worth of net revenue or with
the minimum future worth of net cost will be selected as the best alternative
for implementation.
i.Revenue-Dominated Cash Flow Diagram
A generalized revenue-dominated cash flow diagram to demonstrate the future worth
method of comparison is presented in Fig.
In Fig. P represents an initial investment, Rj the net-revenue at the end of the jth
year, and S the salvage value at the end of the nth year.
The formula for the future worth of the above cash flow diagram for a given
interest rate, i is
FW(i) = –P(1 + i)n + R1(1 + i)n–1 + R2(1 + i)n–2 + ...
+ R j(1 + i)n–j + ... + Rn + S
In the above formula, the expenditure is assigned with negative sign and the
revenues are assigned with positive sign.
ii.Cost-Dominated Cash Flow Diagram
A
generalized
costdominated cash flow diagram
to demonstrate the future worth method
of comparison is given in Fig.
In Fig. 5.2, P represents an initial investment, Cj the net cost of
operation and maintenance at the end of the j th year, and S the
salvage value at the end of the nth year.
The formula for the future worth of the above cash flow diagram
for a given interest rate, i is
FW(i) = P(1 + i)n + C1(1 + i )n–1 + C2(1 + i)n–2 + ... + Cj(1 + i)n–j + ... + Cn – S
EXAMPLE
Consider the following two mutually exclusive alternatives:
At i = 18%, select the best alternative based on future worth method of
comparison.
Solution Alternative A
Initial investment, P = Rs. 50,00,000
Annual equivalent revenue, A = Rs. 20,00,000
Interest rate, i = 18%, compounded annually
Life of alternative A = 4 years
The cash flow diagram of alternative A is shown in Fig.
The future worth amount of alternative B is computed as
FWA(18%) = –50,00,000(F/P, 18%, 4) + 20,00,000(F/A, 18%, 4)
= –50,00,000(1.939) + 20,00,000(5.215)
= Rs. 7,35,000
Alternative B
Initial investment, P = Rs. 45,00,000
Annual equivalent revenue, A = Rs. 18,00,000
Interest rate, i = 18%, compounded annually
Life of alternative B = 4 years
The cash flow diagram of alternative B is illustrated in Fig..
The future worth amount of alternative B is computed as
FWB(18%) = – 45,00,000(F/P, 18%, 4) + 18,00,000 (F/A, 18%, 4)
= – 45,00,000(1.939) + 18,00,000(5.215)
= Rs. 6,61,500
3.ANNUAL EQUIVALENT METHOD
ü In the annual equivalent method of comparison, first the annual equivalent
cost or the revenue of each alternative will be computed.
ü Then the alternative with the maximum annual equivalent revenue in the
case of revenue-based comparison or with the minimum annual equivalent
cost in the case of cost- based comparison will be selected as the best
alternative.
i.Revenue-Dominated Cash Flow Diagram
A generalized revenue-dominated cash flow diagram to demonstrate the annual
equivalent method of comparison is presented in Fig.
Fig. Revenue-dominated cash flow diagram.
In Fig. P represents an initial investment, Rj the net revenue at the end
of the j th year, and S the salvage value at the end of the nth year.
The first step is to find the net present worth of the cash flow diagram
using the following expression for a given interest rate, i:
PW(i) = –P + R1/(1 + i)1 + R2/(1 + i)2 + ...
+ Rj/(1 + i) j + ... + Rn/(1 + i)n + S/(1 + i)n
In the above formula, the expenditure is assigned with a negative sign and the
revenues are assigned with a positive sign.
ii.Cost-Dominated Cash Flow Diagram
A generalized cost-dominated cash flow diagram to demonstrate the annual
equivalent method of comparison is illustrated in Fig.
In Fig, P represents an initial investment, Cj the net cost of operation and
maintenance at the end of the jth year, and S the salvage value at the end of
the nth year.
The first step is to find the net present worth of the cash flow diagram using
the following relation for a given interest rate, i.
PW(i) = P + C1/(1 + i)1 + C2/(1 + i)2 + ...
+ Cj/(1 + i) j + ... + Cn/(1 + i)n – S/(1 + i)n
EXAMPLE
A company provides a car to its chief executive. The owner of the
company is concerned about the increasing cost of petrol. The cost per
litre of petrol for the first year of operation is Rs. 21. He feels that the cost
of petrol will be increasing by Re.1 every year. His experience with his
company car indicates that it averages 9 km per litre of petrol. The
executive expects to drive an average of 20,000 km each year for the next
four years. What is the annual equivalent cost of fuel over this period of
time?. If he is offered similar service with the same quality on rental basis
at Rs. 60,000 per year, should the owner continue to provide company car
for his executive or alternatively provide a rental car to his executive?
Assume i = 18%. If the rental car is preferred, then the company car will
find some other use within the company.
Solution
Average number of km run/year = 20,000 km
Number of km/litre of petrol = 9 km
Therefore,
Petrol consumption/year = 20,000/9 = 2222.2 litre
Cost/litre of petrol for the 1st year = Rs. 21
Cost/litre of petrol for the 2nd year = Rs. 21.00 + Re. 1.00
= Rs. 22.00
Cost/litre of petrol for the 3rd year = Rs. 22.00 + Re. 1.00 = Rs. 23.00
Cost/litre of petrol for the 4th year = Rs. 23.00 + Re. 1.00 = Rs. 24.00
Fuel expenditure for 1st year = 2222.2 21 = Rs. 46,666.20
Fuel expenditure for 2nd year = 2222.2 22 = Rs. 48,888.40
Fuel expenditure for 3rd year = 2222.2 23 = Rs. 51,110.60
Fuel expenditure for 4th year = 2222.2 24 = Rs. 53,332.80
The annual equal increment of the above expenditures is Rs. 2,222.20
(G). The cash flow diagram for this situation is depicted in Fig.
Fig. Uniform gradient series cash flow diagram.
In Fig., A1 = Rs. 46,666.20 and G = Rs. 2,222.20
A = A1 + G(A/G, 18%, 4)
= 46,666.20 + 2222.2(1.2947)
= Rs. 49,543.28
The proposal of using the company car by spending for petrol by the company will
cost an annual equivalent amount of Rs. 49,543.28 for four years. This amount is
less than the annual rental value of Rs. 60,000. Therefore, the company should
continue to provide its own car to its executive.
4.RATE OF RETURN METHOD
ü The rate of return of a cash flow pattern is the interest rate at which the
present worth of that cash flow pattern reduces to zero.
ü In this method of comparison, the rate of return for each alternative is
computed. Then the alternative which has the highest rate of return is
selected as the best alternative.
ü A generalized cash flow diagram to demonstrate the rate of return method of
comparison is presented in Fig
In the above cash flow diagram, P represents an initial investment, Rj the
net revenue at the end of the jth year, and S the salvage value at the end of
the nth year.
The first step is to find the net present worth of the cash flow diagram using
the following expression at a given interest rate, i.
PW(i) = – P + R1/(1 + i)1 + R2/(1 + i)2 + ...
+ Rj/(1 + i) j + ... + Rn/(1 + i)n + S/(1 + i)n
EXAMPLE
A person is planning a new business. The initial outlay and cash flow pattern for the
new business are as listed below. The expected life of the business is five years. Find
the rate of return for the new business.
Solution
Initial investment = Rs. 1,00,000 Annual equal revenue = Rs. 30,000
Life = 5 years
The cash flow diagram for this situation is illustrated in Fig.
Fig. Cash flow diagram.
The present worth function for the business is
PW(i) = –1,00,000 + 30,000(P/A, i, 5)
When i = 10%,
PW(10%) = –1,00,000 + 30,000(P/A, 10%, 5)
= –1,00,000 + 30,000(3.7908)
=
Rs. 13,724.
When i = 15%,
PW(15%) = –1,00,000 + 30,000(P/A, 15%, 5)
= –1,00,000 + 30,000(3.3522)
= Rs. 566.
When i = 18%,
PW(18%) = –1,00,000 + 30,000(P/A, 18%, 5)
= –1,00,000 + 30,000(3.1272)
= Rs. – 6,184
i= 15% + 0.252% = 15.252%
Therefore, the rate of return for the new business is 15.252%.
Unit 3: Activity Planning and Scheduling
Activity planning begins with outlining the structure of work breakdown.
The goal of activity planning is pinpointing activities required to achieve
deliverables. This sequence is known as activity planning in project management.
Every project cycle through a process known as progressive elaboration.
OBJECTIVES OF ACTIVITY PLANNING
• The objective of software project planning is to provide a framework that
enables the manager to make reasonable estimates of resources, cost, and
schedule.
1.GANTT CHART
The bar chart (Gantt chart) is used for the representation of a project in which the
activities are represented by horizontal segments, of which the length is
proportional to the time necessary to conclude the task in question.
The bar chart is an effective tool for the management of work in a project.
Shortening the project duration
If we wish to shorten the overall duration of a project, we would normally consider
attempting to reduce activity durations. In many cases this can be done by applying
more resources to the task - working overtime or procuring additional staff, for
example. The critical path indicates where we must look to save time -if we are
trying to bring forward the end date of the project, there is clearly no point in
attempting to shorten non-critical activities. Referring to Figure 6.20 it can be seen
that we could complete the project in week 12 by reducing the duration of activity
F by one week (to 9 weeks).
What would the end date for the project be if activity F were shortened to 7 weeks?
Why?
As we reduce activity times along the critical path, we must continually check for
any new critical path emerging and redirect our attention where necessary.
There will come a point when we can no longer safely, or cost-effectively,
reduce critical activity durations in an attempt to bring forward the project end
date. Further savings, if needed, must be sought in a consideration of our work
methods and by questioning the logical sequencing of activities. Generally, time
savings are to be found by increasing the amount of parallelism in the network and
the removal of bottlenecks (subject always, of course, to resource and quality
constraints).
Identifying critical activities
The critical path identifies those activities which are critical to the end date of the
project: however, activities that are not on the critical path may become critical. As
the project proceeds, activities will invariably use up some of their float and this
will require a periodic recalculation of the network. As soon as the activities along
a particular path use up their total float then that path will become a critical path
and a number of hitherto non-critical activities will suddenly become critical.
It is therefore common practice to identify 'near-critical' paths - those whose
lengths arc within, say. 10-20% of the duration of the critical path or those with a
total float of less than say. Often of the project's uncompleted duration.
The importance of identifying critical and near-critical activities is that it is they
that are most likely to be the cause of delays in completing the project. We shall
see. in the next three chapters, that identifying these activities is an important step
in risk analysis, resource allocation and project monitoring.
Unit 4: Risk Management
Risk Management
Risk management is the process of identifying, assessing and controlling threats to
an organization's capital and earnings. These threats, or risks, could stem from a
wide variety of sources, including financial uncertainty, legal liabilities, strategic
management errors, accidents and natural disasters. IT security threats and datarelated risks, and the risk management strategies to alleviate them, have become a
top priority for digitized companies. As a result, a risk management plan
increasingly includes companies' processes for identifying and controlling threats
to its digital assets, including proprietary corporate data, a customer's personally
identifiable information (PII) and intellectual property.
Importance
•
Creates a safe and secure work environment for all staff and customers.
•
Increases the stability of business operations while also decreasing legal
liability.
•
Provides protection from events that are detrimental to both the company
and the environment.
•
Protects all involved people and assets from potential harm.
•
Helps establish the organization's insurance needs in order to save on
unnecessary premiums.
Risk management strategies and processes
All risk management plans follow the same steps that combine to make up the
overall risk management process:
•
Establish context. Understand the circumstances in which the rest of the
process will take place. The criteria that will be used to evaluate risk
should also be established and the structure of the analysis should be
defined.
•
Risk identification. The company identifies and defines potential risks
that may negatively influence a specific company process or project.
•
Risk analysis. Once specific types of risk are identified, the company
then determines the odds of them occurring, as well as their
consequences. The goal of risk analysis is to further understand each
specific instance of risk, and how it could influence the company's
projects and objectives.
•
Risk assessment and evaluation. The risk is then further evaluated after
determining the risk's overall likelihood of occurrence combined with its
overall consequence. The company can then make decisions on whether
the risk is acceptable and whether the company is willing to take it on
based on its risk appetite.
•
Risk mitigation. During this step, companies assess their highest-ranked
risks and develop a plan to alleviate them using specific risk controls.
These plans include risk mitigation processes, risk prevention tactics and
contingency plans in the event the risk comes to fruition.
•
Risk monitoring. Part of the mitigation plan includes following up on
both the risks and the overall plan to continuously monitor and track new
and existing risks. The overall risk management process should also be
reviewed and updated accordingly.
•
Communicate and consult. Internal and external shareholders should be
included in communication and consultation at each appropriate step of
the risk management process and in regards to the process as a whole.
Risk management approaches
After the company's specific risks are identified and the risk management process
has been implemented, there are several different strategies companies can take in
regard to different types of risk:
•
Risk avoidance. While the complete elimination of all risk is rarely
possible, a risk avoidance strategy is designed to deflect as many threats
as possible in order to avoid the costly and disruptive consequences of a
damaging event.
•
Risk reduction. Companies are sometimes able to reduce the amount of
damage certain risks can have on company processes. This is achieved by
adjusting certain aspects of an overall project plan or company process,
or by reducing its scope.
•
Risk sharing. Sometimes, the consequences of a risk are shared, or
distributed among several of the project's participants or business
departments. The risk could also be shared with a third party, such as a
vendor or business partner.
•
Risk retaining. Sometimes, companies decide a risk is worth it from a
business standpoint, and decide to keep the risk and deal with any
potential fallout. Companies will often retain a certain level of risk if a
project's anticipated profit is greater than the costs of its potential risk.
Limitations:
•
A false sense of stability. Value-at-risk measures focus on the past
instead of the future. Therefore, the longer things go smoothly, the better
the situation looks. Unfortunately, this makes a downturn more likely.
•
The illusion of control. Risk models can give organizations the false
belief that they can quantify and regulate every potential risk. This may
cause an organization to neglect the possibility of novel or unexpected
risks. Furthermore, there is no historical data for new products, so there's
no experience to base models on.
•
Failure to see the big picture. It's difficult to see and understand the
complete picture of cumulative risk.
•
Risk management is immature. An organization's risk management
policies are underdeveloped and lack the history to make accurate
evaluations.
Risk management examples
One example of risk management could be a business identifying the various risks
associated with opening a new location. They can mitigate risks by choosing
locations with a lot of foot traffic and low competition from similar businesses in
the area.
Another example could be an outdoor amusement park that acknowledges their
business is completely weather-dependent. In order to alleviate the risk of a large
financial hit whenever there is a bad season, the park might choose to consistently
spend low and build up cash reserves.
Yet another example could be an investor buying stock in an exciting new
company with high valuation even though they know the stock could significantly
drop. In this situation, risk acceptance is displayed as the investor buys despite the
threat, feeling the potential of the large reward outweighs the risk.
Nature of Project Risks
• Planning assumptions
• Estimation errors
• Eventualities
Planning assumptions
At every stage during planning, assumptions are made which, if not valid, may put
the plan at risk. Our activity network, for example, is likely to be built on the
assumption of using a particular design methodology - which may be subsequently
changed. We generally assume that, following coding, a module will be tested and
then integrated with others - we might not plan for module testing showing up the
need for changes in the original design but, in the event, it might happen.
At each stage in the planning process, it is important to list explicitly all of the
assumptions that have been made and identify what effects they might have on the
plan if they are inappropriate.
Estimation errors
Some tasks are harder to estimate than others because of the lack of experience of
similar tasks or because of the nature of a task. Producing a set of user manuals is
reasonably straightforward and, given that we have carried out similar tasks
previously, we should be able to estimate with some degree of accuracy how long
it will take and how much it will cost. On the other hand, the time required for
program testing and debugging, might be difficult to predict with a similar degree
of accuracy - even if we have written similar programs in the past.
Estimation can be improved by analyzing historic data for similar activities.
Keeping records comparing our original estimates with the final methods of
estimation, outcome will reveal the type of tasks that are difficult to estimate
correctly.
-- Keep historic data of your estimation and the actual performance
– Compare your estimation and the actual value
– Classify the tasks that are easy or difficult to give accurate estimation.
Eventualities
Some eventualities might never be foreseen and we can only resign ourselves to
the fact that unimaginable things do, sometimes, happen. They are, however, very
rare. The majority of unexpected events can, in fact, be identified - the
requirements specification might be altered after some of the modules have been
coded, the senior programmer might take maternity leave, the required hardware
might not be delivered on time. Such events do happen from time to time and,
although the likelihood of any one of them happening during a particular project
may be relatively low, they must be considered and planned for.
• Unexpected and unimaginable events
• Common unexpected events
– Hardware cannot be delivered on time
– Requirement’s specification needs to be rewritten
– Staffing problem
Managing Risk
• Step 1: Risk Identification
– Generate a list of possible risks through brainstorming,
problem identification and risk profiling.
• Macro risks first, then specific events
• Step 2: Risk Assessment
– Scenario analysis for event probability and impact
– Risk assessment matrix
– Failure Mode and Effects Analysis (FMEA)
– Probability analysis
• Decision trees, NPV, and PERT
– Semiquantitative scenario analysis
Risk Identification
Risk identification is the process of identifying and assessing threats to an
organization, its operations, and its workforce. For example, risk identification
may include assessing IT security threats such as malware and ransomware,
accidents, natural disasters, and other potentially harmful events that could disrupt
business operations. Companies that develop robust risk management plans are
likely to find they’re able to minimize the impact of threats, when and if they
should occur.
Risk Identification Process Steps:
There are five core steps within the risk identification and management
process. These steps include risk identification, risk analysis, risk evaluation, risk
treatment, and risk monitoring.
Risk Identification: The purpose of risk identification is to reveal what,
where, when, why, and how something could affect a company’s ability to operate.
For example, a business located in central California might include “the possibility
of wildfire” as an event that could disrupt business operations.
Risk Analysis: This step involves establishing the probability that a risk
event might occur and the potential outcome of each event. Using the California
wildfire example, safety managers might assess how much rainfall has occurred in
the past 12 months and the extent of damage the company could face should a fire
occur.
Risk Evaluation: Risk evaluation compares the magnitude of each risk and
ranks them according to prominence and consequence. For example, the effects of
a possible wildfire may be weighed against the effects of a possible mudslide.
Whichever event is determined to have a higher probability of happening and
causing damage, it would rank higher.
Risk Treatment: Risk treatment is also referred to as Risk Response
Planning. In this step, risk mitigation strategies, preventative care, and contingency
plans are created based on the assessed value of each risk. Using the wildfire
example, risk managers may choose to house additional network servers offsite, so
business operations could still resume if an onsite server is damaged. The risk
manager may also develop evacuation plans for employees.
Risk Monitoring: Risk management is a non-stop process that adapts and
changes over time. Repeating and continually monitoring the processes can help
assure maximum coverage of known and unknown risks.
What Is Risk Analysis?
Risk Analysis is a process that helps you to identify and manage potential
problems that could undermine key business initiatives or projects. However, it can
also be applied to other projects outside of business, such as organizing events or
even buying a home!
To carry out a Risk Analysis, you must first identify the possible threats that you
face, then estimate their likely impacts if they were to happen, and finally estimate
the likelihood that these threats will materialize.
Risk Analysis can be complex, as you'll need to draw on detailed information such
as project plans, financial data, security protocols, marketing forecasts, and other
relevant information. However, it's an essential planning tool, and one that could
save time, money, and reputations.
When to Use Risk Analysis
Risk analysis is useful in many situations:
•
When you're planning projects, to help you to anticipate and neutralize
possible problems.
•
When you're deciding whether or not to move forward with a project.
•
When you're improving safety and managing potential risks in the
workplace.
•
When you're preparing for events such as equipment or technology
failure, theft, staff sickness, or natural disasters.
•
When you're planning for changes in your environment, such as new
competitors coming into the market, or changes to government policy.
Main techniques include:
– Decision tree analysis
– simulation
Decision Trees and Expected Monetary Value (EMV)
• A decision tree is a diagramming method used to help you select the best
course of action in situations in which future outcomes are uncertain
• EMV is a type of decision tree where you calculate the expected monetary
value of a decision based on its risk event probability and monetary value.
Simulation
• Simulation uses a representation or model of a system to analyze the
expected behavior or performance of the system
• Monte Carlo analysis simulates a model’s outcome many times to provide
a statistical distribution of the calculated results
• To use a Monte Carlo simulation, you must have three estimates (most
likely, pessimistic, and optimistic) plus an estimate of the likelihood of the
estimate being between the optimistic and most likely values.
Unit 5: Resource Allocation
Identifying resource requirements:
•
•
•
•
The first step in producing a resource allocation plan is to list the resource
that will be required along with the expected level of demands.
This will normally be done by considering with each activity in turn and
identifying the resources required.
It is likely that there will also be resources required that are not activity
specific but are part of the project infrastructure.
Resource requirement list must be comprehensive.
Resource allocation
Resource allocation is the process of assigning and managing assets in a manner
that supports an organization's strategic goals.
Resource allocation includes managing tangible assets such as hardware to make
the best use of softer assets such as human capital. Resource allocation involves
balancing competing needs and priorities and determining the most effective
course of action in order to maximize the effective use of limited resources and
gain the best return on investment.
In practicing resource allocation, organizations must first establish their desired
end goal, such as increased revenue, improved productivity or better brand
recognition.
The Importance of Resource Allocation
The most important aspect of resource allocation is that you’re going to have
everything where you need it and when you need it. After all, if you need the
company accountant to help you with specific financials for your project but she’s
working on another task elsewhere you’re not properly allocating your resources.
If you need a meeting room to host a big discussion but they’re all booked then
you also haven’t properly allocated your resources. That’s why it’s so important to
get these things done as early as possible.
6 Aspects That Negatively Impact Your Resource Allocation
What if you can’t get everything working just right? What if there are struggles in
the process of allocating your resources? Well, the truth is that several different
things could make resource allocation more difficult. So, let’s take a little closer
look at what some of those things are that you should be looking at.
1. Timeline Changes
One of the first things that often changes when it comes to any project is the
timeline. You might end up with a project manager or program manager who
decides they need to project done sooner (like yesterday). Or you might have a
client that is suddenly in a big rush to get things done. Or maybe one of the pieces
of the puzzle took longer than expected and now everyone else needs to work
faster to get their part done. And of course, their part started later, which means
they may not have the same availability that they did initially (which takes us to
another point further down).
2. Scope Changes
The scope of the project is another aspect that can change the resources being
allocated. If the scope of the project being requested changes it is entirely possible
that the people required to work on it will also change. New tasks and new needs
are going to make it essential for additional tools to be used as well. This can
change what you originally requested as the resources for your project and might
throw off the entire project if those resources are not immediately available.
3. Resource Availability Changes
If you don’t have the right resources to get the job done you’re also going to have
some problems getting everything allocated. Maybe the people you need for this
project just aren’t available at the time you need them. If that’s the case you’ll
either need to find new people or you’re going to need to rearrange the timeline of
the project itself. This can make it difficult for project managers or program
managers to get the job done or to ensure that someone else can get the job done.
4. Task Dependencies
If there is one part of the project that needs to get done before the next part of the
project can get done that means there’s a dependency. But what if part A of the
project takes a week longer than it was planned? Now you need part B to be done
later. And that might not be possible with the original team that you put together.
Because what if the team that’s responsible for part B has another project that now
needs to be done? Maybe they booked you into the only week they had available
but now that you’re behind they just can’t make it work? Now you have to figure
out a way to work around their other schedule or to change the team you have
planned.
5. Overall Urgency
You have to understand what the most urgent aspects are. Do you need to get this
task done immediately? It’s often the case that a project that comes in first will get
pushed off to the side in favor of an entirely different project that needs to be
completed. If that’s the case you may need to reallocate some of your people so
they can work on the newer project or your project might lose people because your
manager believes the other project is more important and allocates your team to
that area instead.
6. Teamwork
Your entire team needs to be able to work together. It’s not just about making sure
that your team can work together in small groups. The entire team, everyone who
is responsible for the project, needs to be able to work together and to get the
project done together. This isn’t always easy, especially when you’re bringing
together people who may not work together frequently. If that’s the case you want
to make sure that you’re doing some team building and that you’re figuring out
ways to make sure everyone can get along.
Resource Smoothing
Resource smoothing is one of the project management tools used in the resource
optimization techniques. It is defined as a technique that adjusts the activities of
a schedule model so that all requirements for the resources do not go beyond the
resource limits already pre-defined during the planning.
There are only a few reusable resources that are limitless thus the time schedules
have to be imposed and adjusted to manage the limited availability of the resources
in a given time. Resource smoothing is one of the tools used to reconcile the
limited resources and time but a different approach than resource leveling.
It is used when the time constraint takes important priority in project planning. The
objective of this project management tool is to complete the work or activity within
the required date and, at the same time, avoiding peaks and troughs or the resource
demand.
A smooth resource profile is usually achieved by delaying some tasks or works.
This will reduce the flexibility of the schedule when it comes to dealing with
delays but it is very cost effective in managing and using the resources.
Resource Leveling
Resource leveling is a technique in project management that overlooks resource
allocation and resolves possible conflict arising from over-allocation. When project
managers undertake a project, they need to plan their resources accordingly.
This will benefit the organization without having to face conflicts and not being
able to deliver on time. Resource leveling is considered one of the key elements to
resource management in the organization.
An organization starts to face problems if resources are not allocated properly i.e.,
some resource may be over-allocated whilst others will be under-allocated. Both
will bring about a financial risk to the organization.
Structure of Resource leveling
Many organizations have a structured hierarchy of resource leveling. A work-based
structure is as follows:
•
•
•
Stage
Phase
Task/Deliverable
All of the above-mentioned layers will determine the scope of the project and find
ways to organize tasks across the team. This will make it easier for the project team
to complete the tasks.
In addition, depending on the three parameters above, the level of the resources
required (seniority, experience, skills, etc.) may be different. Therefore, the
resource requirement for a project is always a variable, which is corresponding to
the above structure.
Resource leveling is aimed at increasing efficiency when undertaking projects by
utilizing the resources available at hand. Proper resource leveling will not result in
heavy expenditure.
The project manager needs to take into account several factors and identify critical
to non-critical dependencies to avoid any last-minute delays of the project
deliverables.
Differences between Resource Leveling and Resource Smoothing
Resource leveling
Resource Smoothing
It applies the resource constraints to the project and
may result in a change in project duration.
We apply resource smoothing after doing
resource-leveling.
Since we need to first accommodate the
resource constraints before we can optimize it.
Here we make use of slack, and will not result
in a change of project duration. Because the
total allocation of a certain resource remains
the same.
Resource Leveling is primarily driven by resource
constraints like you do not have more than 45
hours of the given resource for a week.
Resource smoothing is more to do with
desired limits like we do have 45 hours
available for a given resource but we wish that
we allocate 38 hours per week so we have
some breathing space.
The allocation limits identified in resource leveling
must be applied.
The desired limit identified in resource
smoothing may not be applied in some cases,
if we do not have slack. It is optimized within
the float boundaries
When Resource Leveling changes the project
dates, may also change the critical path, since
constraints drive it.
Resource smoothing will not change the
critical path; it tries to make the best use of
slack.
Unit 6: Monitoring and Control
Monitoring and Control
Monitoring and control processes continually track, review, adjust and report on
the project’s performance. It’s important to find out how a project’s performing
and whether it’s on time, as well as implement approved changes. This ensures the
project remains on track, on budget and on time.
Project control is a “project management function that involves comparing actual
performance with planned performance and taking appropriate corrective action (or
directing others to take this action) that will yield the desired outcome in the
project when significant differences exist.”
Essentially, project controls are a series of tools that help keep a project on
schedule. Combined with people skills and project experience, they deliver
information that enables accurate decision making. The project control process
mainly focuses on:
•
Measuring planned performance vs actual performance.
•
Ongoing assessment of the project’s performance to identify any preventive
or corrective actions needed.
•
Keeping accurate, timely information based on the project’s output and
associated documentation.
•
Providing information that supports status updates, forecasting and
measuring progress.
•
Delivering forecasts that update current costs and project schedule.
•
Monitoring the implementation of any approved changes or schedule
amendments.
Importance of project monitoring and control:
Monitoring and control keep projects on track. The right controls can play a major
part in completing projects on time. The data gathered also lets project managers
make informed decisions. They can take advantage of opportunities, make changes
and avoid crisis management issues.
Monitoring and control techniques:
There are a range of monitoring and control techniques that can be used by project
managers, including:
A Requirements Traceability Matrix (RTM). This map, or traces, the project’s
requirements to the deliverables. The matrix correlates the relationship between
two baseline documents. This makes the project’s tasks more visible. It also
prevents new tasks or requirements being added to the project without approval.
This makes the project’s tasks more visible. It also prevents new tasks or
requirements being added to the project without approval.
A control chart monitors the project’s quality. There are two basic forms of
control chart – a univariate control chart displays one project characteristic, while a
multivariate chart displays more than one.
Review and status meetings further analyses problems, finding out why
something happened. They can also highlight any issues that might happen later.
Put simply, monitoring and control ensures the seamless execution of tasks. This
improves productivity and efficiency.
Collecting the data
As a rule, managers will try to break down long activities into more controllable
tasks of one- or two-weeks duration. However, it will still be necessary to gather
information about partially completed activities and, in particular, forecasts of how
much work is left to be completed. It can be difficult to make such forecasts
accurately.
A software developer working on Amanda's project has written the first 250 lines
Exercise 9.1 of a Cobol program that is estimated to require 500 lines of code.
Explain why it would be unreasonable to assume that the programming task is 50%
complete. How might you make a reasonable estimate of how near completion it
might be?
Where there is a series of products, partial completion of activities is easier to
estimate. Counting the number of record specifications or screen layouts produced,
for example, can provide a reasonable measure of progress.
In some cases, intermediate products can be used as in-activity milestones. The
first successful compilation of a Cobol program, for example, might be considered
a milestone even though it is not the final product of the activity code and test.
Partial completion reporting
Many organizations use standard accounting systems with weekly time sheets to
charge staff time to individual jobs. The staff time booked to a project indicates the
work carried out and the charges to the project. It does not, however, tell
the project manager what has been produced or whether tasks are on schedule.
It is therefore common to adapt or enhance existing accounting data collection
systems to meet the needs of project control. Weekly time sheets, for example, are
frequently adapted by breaking jobs down to activity level and requiring
information about work done in addition to time spent. Figure 9.3 shows a typical
example of such a report form, in this case requesting information about likely
slippage of completion dates as well as estimates of completeness.
Asking for estimated completion times can be criticized on the grounds that
frequent invitations to reconsider completion dates deflects attention away from
the importance of the originally scheduled targets and can generate an ethos that it
is acceptable for completion dates to slip.
Weekly timesheets are a valuable source of information about resources used.
They are often used to provide information about what has been achieved.
However, requesting partial completion estimates where they cannot be obtained
from objective measures encourages the 99% complete syndrome -tasks are
reported as on time until 99% complete, and then stay at 99% complete until
finished.
Risk reporting
One popular way of overcoming the objections to partial completion reporting is to
avoid asking for estimated completion dates, but to ask instead for the team
members' estimates of the likelihood of meeting the planned target date.
One way of doing this is the traffic-light method. This consists of the following
steps:
• identify the key (first level) elements for assessment in a piece of work;
• break these key elements into constituent elements (second level);
• assess each of the second level elements on the scale green for 'on target', amber
for 'not on target but recoverable', and red for 'not on target and recoverable only
with difficulty';
• review all the second level assessments to arrive at first level assessments;
• review first and second level assessments to produce an overall assessment.
Visualizing Progress
Having collected data about project progress, a manager needs some way of
presenting that data to greatest effect. we look at some methods of presenting a
picture of the project and its future. Some of these methods (such as Gantt charts)
provide a static picture, a single snap-shot, whereas others (such as time-line
charts) try to show how the project has progressed and changed through time.
1.GANTT CHART
The bar chart (Gantt chart) is used for the representation of a project in which the
activities are represented by horizontal segments, of which the length is
proportional to the time necessary to conclude the task in question.
The bar chart is an effective tool for the management of work in a project.
2.BALL CHART
➢ Ball charts – way of showing or not targets have been met
or not.
➢ It is represented in the form of circles that indicate the start
and the end point completion of activities.
➢ Circles of the ball chart mostly contain only two dates the
original and the revised one.
➢ An activity is denoted by a red circle and green color
denotes that the activity is ahead of its schedule.
➢ Slippage in the project completion date but it is overcome
by the timeline charts.
SLIP CHART
➢ Slip chart – visual indication of activities that
are not progressing to schedule.
➢ An alternative view of Gantt chart by providing
a visual indication of those activities which are
not on schedule.
➢ The more bend in the greater the variation in
the project plan.
➢ If the slip line deviates more towards the non
achievement of project objectives then it has to
be reconsidered
➢ Additional slip lines can be included at regular
intervals.
3.THE TIMELINE
One disadvantage of the charts described so far is that they do not show clearly the
slippage of the project completion date through the life of the project. Knowing the
current state of a project helps in revising plans to bring it back on target, but
analyzing and understanding trends helps to avoid slippage in future projects.
The timeline chart is a method of recording and displaying the way in which
targets have changed throughout the duration of the project.
➢ The Timeline – recording and displaying the way in which
targets have changed.
➢ The chart represents the planned time along the horizontal
axis and the actual time along the vertical axis.
➢ A line down the horizontal axis represents the scheduled
activity completion dates and the slip in the line indicates a
delay in the respective activities.
➢ It is used to calculate the duration of execution of the
project.
Cost monitoring:
➢ It provides an indication of the effort.
➢ It provides a simple method of comparing actual and planned
expenditure.
➢ The more cost is incurred to complete the activities to keep the project
on schedule.
➢ The chart does a comparison between the actual and the planned
expenditure.
➢ Cost charts become much more useful to calculate the future costs.
Earned Value Analysis:
➢ The total value credited to a project at any point is known as the
earned value.
➢ The assigned value is the original budgeted cost value and termed as a
planned value or budgeted cost of work schedule.
➢ Common methods used in assigning an earned value are,
1) 0/100 technique
2) 50/50 technique
3) Milestone technique
➢ 0/100 technique is suitable for longer duration cost estimation.
➢ Earned value denotes the total value credited to a project at any point
and it is termed as budgeted cost of work performed(BCWP).
➢ Budgeted cost of work performed(BCWP).
➢ The baseline budget
➢ Monitoring earned value
➢ Schedule variance
➢ Cost variance
➢ Performance ratios.
5.1) Baseline Budgets
➢ To setup an earned value analysis, the first step is to create a baseline
budget.
➢ Common ways of measuring earned value in software development
process is persons –hours or work days.
➢ The 0/100 technique can be used to get the creditability of earned
value.
5.2) Monitoring Earned value
➢ The earned value analysis is to monitor the project progress.
➢ Monitoring process indicates the completion of tasks and includes the
activity start and milestone achievement of the project.
➢ The actual cost is calculated by the actual cost of each task and is also
called as actual cost of work performed.
➢ Types of variance are,
➢ Schedule variance – difference between the earned value and
the planned value indicates the degree of the completed work .
➢ Cost variance – difference between the earned value and the
actual cost of a completed work results in cost variance.
➢ Positive cost variance – project under control
➢ Negative cost variance – actual cost incurred is much
more than the planned one.
5.3) performance ratios
➢ Performance ratios defines two index values namely cost performance
index and schedule performance index.
➢ Formulas,
➢ CPI = Earned value/Actual costs
➢ SPI = Earned value/ Planned value
➢ Greater value – work is completed better than planned
➢ Lesser value – work is more costlier than planned.
Project Controls:
Project controls are processes for gathering and analyzing project data to keep
costs and schedules on track. The functions of project controls include initiating,
planning, monitoring and controlling, communicating, and closing out project costs
and schedule. Ultimately, project controls are iterative processes
for measuring project status, forecasting likely outcomes based on those
measurements and then improving project performance if those projected
outcomes are unacceptable.
Activities under the umbrella of project controls may include:
•
•
•
•
•
•
•
•
Aligning projects with portfolio/organization goals and objectives
Developing a work-breakdown structure (WBS)
Collaborating on initial project schedules
Developing a risk management plan
Project budgeting and forecasting
Monitoring project costs
Feedback and reporting
Optimizing project strategies to enable better outcomes in the future
While a project may deal with many parameters, such as quality, scope, etc., the
discipline of project controls focuses on the cost and schedule factors, continuously
monitoring for any risk to them.
Hierarchically, project controls nest under project management. A project
controller could be reporting to a project manager on a specific project or an
entire portfolio of projects. Project controls are integral to successful project
management, as it alerts project stakeholders to potential trouble areas and allows
them to course correct, if needed.
Benefits of Project Controls
In megaprojects, the various moving parts can make it difficult to stay aligned with
the initial plans. However, close monitoring, analysis, and regulation can keep this
in check. Projects of all sizes, not just large projects, experience significant
benefits when controls are properly executed.
The following are some of the key benefits of project controls:
•
•
•
•
•
•
•
•
•
Reduced project costs through ability to make timely decisions using KPIs
Increased project predictability for cost and completion date
Increased visibility into the financial health of the project at all stages
Ability to mitigate project scope creep
Meaningful benchmarking data for future projects via well-structured
projects
Increased margins when working in a fixed-price environment
Improved reputation for properly managing and controlling projects
Competitive advantage over organizations with less mature project
management capabilities
Increased job satisfaction for project team members
What is the Difference Between Project Controls and Project Management?
There are 3 key differences between Project Controls and Project Management:
1- Project Control is one of the Project Management subsets with the primary focus
of managing the project’s cost and schedule.
2- Project Manager is directing the work of the project team while the Project
Controller advises the team and the Project Manager of possible cost & schedule
issues/ recovery plans.
3- Project Controller generates the project’s cost/ schedule information while the
Project Manager consumes the information generated and makes decisions for the
project.
Unit 7: Managing Contracts and people
Learn the basics of contract management.
•
•
•
Contract management is when someone takes on the responsibility of
managing contracts for employees or vendors or other parties.
Contract managers need legal knowledge to accurately lead the contract
management process.
Not all companies have set contract managers, but major defense firms or
companies that frequently work with the government tend to use contract
managers.
What is contract management, and why is it important?
Contract management is the process of managing contract creation, execution, and
analysis to maximize operational and financial performance at an organization, all
while reducing financial risk. Organizations encounter an ever-increasing amount
of pressure to reduce costs and improve company performance. Contract
management proves to be a very time-consuming element of business, which
facilitates the need for an effective and automated contract management system.
Types Of Contracts In Software Project Management:
The types of contracts in software project management can include fixed price,
firm fixed price, fixed price incentive fee, fixed price with economic price
adjustments, purchase orders, cost reimbursable, cost plus fixed fee, cost plus
incentive fee, cost plus award fee, cost plus percentage of cost, time and materials,
and unit price contracts.3 min read
1. Fixed Price Contracts
2. Purchase Orders
3. Cost Reimbursable Contract
4. Unit Price Contract
5. Time and Materials Contract
The types of contracts in software project management can include fixed price,
firm fixed price, fixed price incentive fee, fixed price with economic price
adjustments, purchase orders, cost reimbursable, cost plus fixed fee, cost plus
incentive fee, cost plus award fee, cost plus percentage of cost, time and materials,
and unit price contracts.
Fixed Price Contracts
With fixed price contracts, also known as lump sum contracts, the buyer and
service provider agree on a fixed price for the services in question. This type of
contract is low-risk for the buyer, but high-risk for the seller since the time and
costs of the project could exceed the fixed price. For this reason, a fixed price
contract should include a detailed scope of work that clearly outlines what the
buyer can expect for the agreed-upon price. When the contract is signed, the seller
must complete the task or deliver the goods as agreed or risk being in breach of
contract. Types of fixed price contracts include the following:
•
•
•
•
Firm Fixed Price Contracts: This type of fixed price contract is typically
used in government and partial government projects where the scope is
defined in detail. This makes it easy to create a request for proposals and to
compare the bids you receive. The downside for this contract is that
deviating from the defined scope can be expensive.
Fixed Price Incentive Fee Contracts: With this type of fixed price
contract, the buyer also offers a performance-based incentive as an extra
payment to the seller. Performance can be measured for this purpose by
various metrics, including time, cost, or performance.
Fixed Price Award Fee Contracts: As with the fixed price incentive fee,
this type of contract offers a bonus for exceeding a specific
performance metric. For example, if the seller delivers the product early, he
or she could be eligible for a bonus equal to 10 percent of the total contract.
Fixed Price With Economic Price Adjustment: With this type of contract,
although the price is fixed, it can be readjusted with fluctuations in the
market.
Fixed price contracts are commonly used on a deliverables basis for outsourcing
and turnkey procurement.
Purchase Orders
A purchase order is a specific type of contract that is used only to purchase goods
and commodities.
Cost Reimbursable Contract
When the scope of a project is unclear or subject to change, you should consider a
cost reimbursable contract. This document, sometimes called cost disbursable, is
also useful when the risk of a specific project is high. The seller provides work for
a fixed time period or project, then increases the bill to create profit after finishing
the work.
The amount of profit in this type of contract is often based on performance metrics
detailed in the document itself. The downside of this type of contract lies with the
buyer, who carries the risk for this type of contract since he or she pays all costs.
The full cost of the contract won't be defined until the work is done. For this
reason, few businesses opt to use a cost reimbursable contract.
Types of cost reimbursable contracts include the following:
•
•
•
•
Cost Plus Percentage of Costs/Cost Plus Fee: With this variation, the
seller receives a defined percentage of the total cost of the project upon
completion. This is also an arrangement that mainly benefits the seller.
Cost Plus Fixed Fee: The seller receives costs incurred plus an additional
flat fee that is fixed in the contract. This amount is received when the
contract is fulfilled regardless of performance.
Cost Plus Incentive Fee: This is a performance-based fee paid on top of
actual costs. It is a flat amount rather than a percentage.
Cost Plus Award Fee: Similar to a cost plus incentive fee, this contract
provides an award on top of the costs incurred.
Unit Price Contract
This type of contract, also called an hourly rate contract, combines elements
of fixed price and cost contracts. A unit price contract pays a specified hourly rate
for every hour spent on the project. It is commonly used by freelancer workers.
Time and Materials Contract
This contract is used when labor is the main deliverable and typically provides the
seller an hourly rate.
If you need help with software project management contracts, you can post your
job on Up Counsel’s marketplace. Up Counsel accepts only the top 5 percent of
lawyers to its site. Lawyers on Up Counsel come from law schools such as Harvard
Law and Yale Law and average 14 years of legal experience, including work with
or on behalf of companies like Google, Menlo Ventures, and Airbnb.
Contract Lifecycle:
Stage 1: Contract Management Preparation—Identify Your Needs, Establish
Goals, Set Expectations, and Define Risk
Contracts are legally binding documents that should not be approached
lightly. Therefore, it’s important to be organized and prepared with the right
resources.
Properly identifying the needs, reasons, and ultimate goals that require a
contract makes any decisions down the line much easier.
Contract management should:
•Seek
to define and mitigate risk in a relationship
•Look ahead to scenarios that could occur over the lifetime of the document
•Account for these various outcomes 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.
Another example is a contract of pricing terms for customers. One goal of
this document is to financially protect the business in any scenario, and
ensure payment once the tasks outlined in an agreement are complete.
Good contract management ensures that even if a business relationship is
strong, each side obtains exactly what is in the contract.
Once we establish the reasons for creating a contract, it’s time to begin
drafting the contract.
Stage 2: Draft the Contract
Consulting with in-house counsel or an attorney is wise, especially if there
are any uncertainties. Better yet, use a pre-set template drafted by your legal
team to ensure all the information is up-to-date and all required clauses and
terms are automatically included.
When drafting or authoring the terms of the contract, it’s important to pay
attention to specific wording. Any ambiguity leaves contracts up for
interpretation, even down to a comma. State and country laws also need to be
taken into consideration. This is especially true if the two parties are in
different locations.
Stage 3: Get Approval Before Finalizing the Contract
In companies that need manager approval or have audit procedures, all
requirements for approval need to be met before finalizing the deal.
For example, a company needs to meet procurement policies prior to contract
approval. In a contract management platform, this is as simple as setting up
an approval workflow. Simply put, whoever needs to approve the
contract receives a notification and can view, edit, and comment on the
contract in real time.
Stage 4: Contract Negotiation
No matter how much research, planning, and preparation goes into the first
draft of a contract, negotiation almost always follows. Contract negotiation
should begin with transparency and trust. Anticipating and researching the
other party’s needs before the conversation simplifies the process. Further, it
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. A
single source of truth for conversations and contracts will result in quicker
negotiations and a contract that provides visibility for both sides.
Stage 5: Sign 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. More importantly, it accelerates signatures and
revenue.
Stage 6: Keep Up With Amendments and Revisions
Contracts are rarely stagnant. Revisions and amendments are a common part
of the contract lifecycle. Tracking changes and the effects for each party can
be confusing, unfortunately.
Moreover, 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. Additionally, make
sure both parties are fully aware and in agreement on any revisions.
Stage 7: Manage After the Signature—Audits, Renewals, and Obligations
Finally, contract lifecycle management doesn’t stop once there is a signed
contract. In particular, performing regular audits ensures all parties meet
obligations and realize value.
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. Additionally, this effort will
continue to build trust and loyalty.
Moving Forward in Contract Management
Contract management is a time-consuming task. Luckily, it has potential to
be one of the most lucrative areas for building business relationships and
generating revenue.
A contract lifecycle management platform simplifies contract management
processes by:
•Managing
and avoiding risk and compliance issues through templates and
approval workflows
•Streamlining contract negotiations with online redlining
•Delivering more revenue (and faster) with online eSignatures, and
•Tracking signed documents, helping organizations grab otherwise missed
opportunities
7 Essential Stages of Contract Management
Lifecycle. Process. Whatever you call it, effective contract management doesn’t
only involve developing agreements and getting them signed – it’s a series of
actions that guide you from the earliest stages of developing holistic processes for
handling each and every company agreement, through to the steps to seeing
contracts through to their conclusion.
Having a clear understanding of what happens at each stage is an important way to
ensure your contract management processes meet all of the requirements and
objectives to deliver optimal results.
Here are the seven essential stages of contract management.
1. Planning stage
Before you can implement a process, it’s important to develop a system that will
best suit your company’s needs and resources. To keep things streamlined and
organized, it’s also important to develop contract management processes that can
be implemented company-wide.
Your contract management strategy is a flexible roadmap consisting of processes
that account for all types of company agreements, from standard employment
contracts to the paperwork from highly specific and complex deals. The first step
to developing your strategy is to determine your needs, including answering the
following:
•
•
•
•
•
What types of contracts do you have to manage and in what volume?
Are there standard agreements you use again and again? What needs to be
included in these?
Who is responsible for each stage of contract management and what do they
need to perform their job?
What common problems have occurred in the past, or what issues might
arise during the management of a typical contract?
What resources are required to implement your contract strategy?
Understanding the remaining stages of contract management will help to inform
your processes.
2. Implementation stage
Once you have outlined your contract management processes, you will need to
implement your plan before you can start using it. This includes deploying contract
management software to help you to execute contract-related tasks, as well as
migrating your contracts to a centralized repository.
A crucial part of your implementation plan is onboarding – making sure everyone
involved understands your vision and objectives for contract management and is
comfortable with the tools they will be using.
3. Pre-contract stage
Now that you have your contract management foundation set up, you can begin to
implement it for new contracts. That means developing new contracts or
implementing boilerplate agreements for more standard situations. The key
challenge of this stage of contract management is developing a specific document
that will deliver what you need and reduce your risks.
For standard situations, this stage may be as simple as finding the right contract
type, entering the relevant information and perhaps making a few tweaks. More
unusual or complex contracting scenarios may require the development of a whole
new document. Developing a contract from scratch can be made easier by looking
at other agreements that might be applicable and adapting those terms. Don’t forget
to carry over any important requirements such as compliance obligations or
branding standards. Once you have agreed on the terms and developed your
contract, e-signatures can keep things moving.
4. Handover stage
It’s common – especially in larger companies – that the individuals involved in
executing a contract are not the same as those who negotiated it. Thus, in order to
ensure the contract is fulfilled as expected, it’s important to ensure a smooth
handover. Rather than assuming stakeholders have everything they need, it’s useful
to spend some time walking through all of the contract details and confirming
roles, responsibilities and milestones.
5. Contract stage
The contract stage is when all of the goals of your contracts come to life – if you
manage them properly. And much of the contract management work you’ve
performed thus far is setting you up to do just that.
But the contract stage doesn’t manage itself – it’s here where you must play close
attention to all of the terms laid out within your agreement and perform regular
monitoring to make sure everything is happening as it should. It’s useful to have
a plan for doing so, with a clear sense of key milestones and performance metrics
that will let you confirm everything is on track – or provide an early warning
system if any problems arise.
6. Pre-renewal stage
Nothing lives forever – not even your contracts. But there are several ways your
agreements may come to an end: one-off agreements may wind down to a natural
conclusion, you may renew an agreement, or choose to terminate it. Often there are
specific terms – and even possibly penalties or default actions, should you fail to
do anything – that can affect the outcome, which is why it’s important to start
thinking about the end of your contract in a proactive and timely manner. Now is
the time to evaluate how your contract performed and decide whether you want to
renew and/or make any changes. Make sure all stakeholders are aware of
termination and renewal dates and that you have enough time to consider all the
information before you get locked into any decisions.
7. Post-contract stage
Once a contract ends, there is still some housekeeping to do to ensure that
everything is wrapped up properly. This includes ensuring termination conditions
have been met, issuing or paying final invoices, and archiving your contract. It’s
also useful to perform a contract post-mortem, which can provide valuable
information and learnings that can improve the results of future contracts.
What is the role of each type of Contract in Project Management?
We know that every day, many projects and infrastructure works are undertaken
across the world. These projects can be of any type ranging from software,
construction, telecom, to scientific, and oil & gas. Every project has
stakeholders/clients and vendor/seller/supplier in common. In other words, every
project is initiated by an organization which should be supported by suppliers for
the various needs of the procurement. In project procurement management, these
two parties are generally termed as 'buyer' and the 'seller.' The agreement between
the two is called the “contract.”
Contracts are an essential part of procurement management. Since formal, it
creates a legal binding between the buyer and the seller. Contracts are necessary
for project management as they provide relief on either side. It is by managing the
risks involved in procurements. A contract is required to share and bear the
individual’s responsibilities in completion of the project. This is more so in larger
and complex projects. Good procurement practices help the corporates to increase
their profitability.
In this article, an attempt is made to throw more light on procurement as well as on
contract management. It is to get the professionals to understand and be conversant
with the contractual processes and their types.
The Project Manager:
Project Manager is the person who leads the team that is responsible for achieving
the project objectives. The performing organization assigns a Project Manager.
Based on the authority level, the project manager performs numerous roles. Many
organizations based on the project size and complexity, assign 'a contract project
manager.' A contract project manager's role is significantly different from the
Project Manager.
Contract Manager:
The Contract Project Manager (also referred to as Contract Manager) plays a very
critical role for an organization. He/she manages contracts throughout the projects
and their life cycle. On many occasions, they also play the role of a Liaoning
person between the companies, employees, vendors, customers. He/she creates the
contract’s repository and is solely responsible for maintaining all the contractual
records. The company uses these records for their projects, which finally become
part of Record Management.
Some of the key responsibilities include but not limited to:
•
•
•
•
•
Draft, develop, negotiate and execute the contract.
Create policies and procedures to the contract and ensure the effectiveness.
A Liaoning person and a contract facilitator.
Manage and close the contracts throughout the project duration.
Create a contract repository and update periodically.
Placement refers to the process of connecting the selected person and the
employer in order to establish an ongoing employment relationship.
In this step the employee is given the activities he/she needs to perform and is told
about his/her duties. Placement is usually followed by the orientation process.
Typical terms of a contract
In a textbook such as this, it is not possible to describe all the necessary content of
contracts for IT goods or services. It is possible, however to outline some of the
major areas of concern.
Definitions
The terminology used in the contract document may need to be defined, for
example, who is meant by the words 'client' and 'supplier'.
Form of agreement
For example, is it a contact of sale, a lease, or a licence? Also, can the subject of
the contract, such as a licence to use a software application, be transferred to
another party?
Goods and services to be supplied
Equipment and software to be supplied This includes an actual list of the individual
pieces of equipment to be delivered, complete with the specific model numbers.
Services to be provided This covers such things as:
• documentation;
• installation;
• conversion of existing files;
• maintenance agreements;
• transitional insurance arrangements.
Ownership of the software
Who has ownership of the software? There are two key issues here: firstly, whether
the customer can sell the software to others and, secondly, whether the supplier can
sell the software to others. Where off-the-shelf software is concerned, the supplier
often simply grants a license for you to use the software. Where the software is
being written specially for a customer, then that customer will normally wish to
ensure exclusive use of the software - they may object to software which they
hoped would give them a competitive edge being sold to their rivals. They could
do this by acquiring the copyright to the software outright or by specifying that
they should have exclusive use of the software. This would need to be written into
the contract. Where a core system has been customized by a supplier, then there is
less scope for the customer to insist on exclusive use.
Where software is written by an employee as part of a contract of employment, it is
assumed that the copyright belongs to the employer. Where the customer
organization has contracted an external supplier to write software, the contract
needs to make clear who is going to retain the copyright - it cannot, in this case, be
automatically assumed it is the customer. The customer might have decided to take
over responsibility for maintenance and further development once the software is
delivered and in this case will need access to the source code. In other cases, where
the customer does not have an adequate in-house maintenance function, the
supplier can retain the source code, and the customer will have to approach the
supplier for any further changes. There are many potential dangers with this, not
the least being that the supplier could go out of business. An escrow agreement can
be included in the contract so that up-to-date copies of the source code are
deposited with a third party. In the United Kingdom, the National Computing
Centre provide an escrow service.
Environment
Where physical equipment is to be installed, the demarcation line between the
supplier's and customer's responsibilities with regard to such matters as
accommodation and electrical supply needs to be specified. Where software is
being supplied, the compatibility of the software with the existing hardware and
operating system platforms would need to be confirmed.
Customer commitments
Even when work is carried out by external contractors, a development project still
needs the participation of the customer. The customer will have to provide
accommodation for the suppliers and perhaps other facilities such as telephone
lines.
Acceptance procedures
Good practice would be to accept a delivered system only after it has undergone
user acceptance tests. This part of the contract would specify such details as the
time that the customer will have to conduct the tests, deliverables upon which the
acceptance tests depend and the procedure for signing off the testing as completed.
Standards
This covers the standards with which the goods and services should comply. For
example, a customer can require the supplier to conform to the ISO 12207 standard
relating to the software life cycle and its documentation (or, more likely, a
customized sub-set of the standard). Within the European Union, government
customers with contracts for projects above a certain threshold value must, by law,
ensure that the work conforms to certain standards.
Some customers find that specially written or modified software is not thoroughly
tested by the supplier before delivery. Some suppliers seem to think that it is
cheaper to get the customer to do the testing for them!
Project and quality management
The arrangements for the management of the project must be agreed. Among these
would be frequency and nature of progress meetings and the progress information
to be supplied to the customer. The contract could require that appropriate ISO
9000-series standards be followed. The ISO 12207 standard provides for the
customer to have access to quality documentation generated internally by the
supplier, so that the customer can ensure that there is adherence to standards.
Timetable
This provides a schedule of when the key parts of the project should be completed.
This timetable will commit both the supplier and the customer. For example, the
supplier might be able to install the software on the agreed date only if the
customer makes the hardware platform available at that point.
Price and payment method
Obviously the price is very important! What also needs to be agreed is when the
payments are to be made. The supplier's desire to be able to meet costs as they are
incurred needs to be balanced by the customer's requirement to ensure that goods
and services are satisfactory before parting with their money.
Miscellaneous legal requirements
This is the legal small print. Contracts often have clauses that deal with such
matters the legal jurisdiction that will apply to the contract, what conditions would
apply to the sub-contracting of the work, liability for damage to third parties, and
liquidated damages. Liquidated damages are estimates of the financial losses that
the customer would suffer if the supplier were to fall short of their obligations. It is
worth noting that under English law, the penalties laid down in penalty clauses
must reflect the actual losses the customer would suffer and cannot be unrealistic
and merely punitive. Even this limitation will not be enough in some cases as far as
the supplier is concerned. As computer systems assume increasingly critical roles
in many organizations and in safety-critical systems can even be life-threatening in
the case of malfunction, the possible consequential damage could be very great.
Suppliers will not unnaturally try to limit this kind of liability. The courts (in
England and Wales) have tended to look critically at such attempts at limiting
liability, so that suppliers will, in the case of major contracts, take out insurance to
cover such liabilities.
If there is a dispute, resorting to litigation, while being lucrative to the lawyers
involved, is both time-consuming and expensive. An alternative is to agree that
disputes be settled by arbitration. This requires that any dispute be referred to an
expert third party whose decision as to the facts of the case is binding. Even this
procedure is seldom quick and inexpensive and another option is alternative
dispute resolution where a third party acts as a mediator who has only an advisory
capacity and attempts to broker an agreement between the two sides.
What is Contract Management?
Contract management is an intricate oversight process that follows contracts from
pre-award to completion, including execution, vendor selection, issue detection
and control, tracking and processing. When implemented properly, contract
management processes ensure that budgets and abilities are in alignment with
project objectives.
The Stages of Contract Management
Contract management is not solely about creating agreements and getting them
approved. It includes a series of stages that follow the process through to a
successful conclusion. Any missed steps can cause delays and mistakes down the
line. Here’s an outline of five fundamental areas of importance:
1. Create: The contract management system must have the ability to
incorporate standardized procedures with details specific to the goals of the
organization. First steps include identifying the type of contract and who
will be responsible for each task. The planning process should consider
company resources, objectives and team member strengths and weaknesses,
while developing an overview of potential challenges and risks.
2. Negotiate: The contract should be written in a manner that reflects the
organizational needs and values, helping to establish trust between the two
parties. Once the initial contract has been designed, negotiation is the
obvious next step. Line items can be discussed, changed or removed, as part
of the negotiation process.
3. Approve: Approval usually includes multiple sign-offs. Numerous
managers, departments and even contractors, may have to sign off on the
specifics before the final deal is made.
4. Finalize: The contract signing process between enterprises is the final step
before getting the project underway. Obtaining signatures from numerous
parties and entities quickly—even when distance is a factor—is crucial to
avoiding postponements to the process.
5. Manage: Once the project begins, changes can still occur. Revisions need to
be carefully managed and communicated to the appropriate parties.
Deadlines, audits, revenue, and expenditures need to be tracked, completed
and shared with the rest of the team.
An Acceptance Management Process is a method by which project deliverables
are reviewed, tested and accepted by the customer. The process entails completing
a number of review steps to ensure that the deliverable meets the customer's
expectations and satisfies the acceptance criteria outlined in the Project Charter.
When work is completed, customer needs to carry out acceptance testing.
Contract may put a time limit to acceptance testing – customer must
perform testing bf
time expired.
• Part or all payment to the supplier should depend on acceptance testing
Acceptance criteria are defined as “the list of requirements that must be
satisfied prior to the customer accepting delivery of the product”.
MANAGING PEOPLE AND ORGANIZING TEAMS
1 INTRODUCTION
OB = organizational behavior
There are 3 main concerns in OB; staff selection, staff
development, and staff motivation
The issues have impact at all stages of project planning and
execution, particularly in;
➢ Some objectives can address health and safety during the project (step 1:
Identify project scope and objectives)
➢ Although project leaders might have little control over organizational
structure, they need to be aware of its implications (step2: Identify project
infrastructure)
➢ The scope and nature of activities can be set in a way they will enhance
staff motivation (Step 3: Identify the products and activities)
➢ Many risks to project success relate to staffing (Step 4: Identify activity
risks)
➢ The qualities of individual members of staff should be taken into account
when allocating staff to activities (Step 5: Allocate resources)
2 Understanding behavior
Behaviors associated with complex and challenging mental health, dementia
or other neurological conditions include aggression, wandering, agitation. These
apparent changes in the personality of the person with the disease are a major source
of distress both to the person who is presenting the behaviors and to those who
experience them – the caregiver, the family members, and the service providers in
all sectors of the health-care system.
People differ from each other in their needs and values. Group effort eases
their task of achieving organizational goals effectively. Human relations can be
defined as motivating people in organizations to work as a team. Although human
relationships have existed from quite some time in the past, the study of human
relations has developed only recently. Social sciences like sociology, psychology,
anthropology, economics and political science have contributed to the development
of OB and human relations.
Goal of Human Relations
Create a win-win situation by:
satisfying employee needs
while achieving organizational objectives
Win-win situation:
occurs when the organization and the employees get what they want.
Levels of Behavior
Individual behavior – influences group behavior
Group Level Behavior-– consists of the things two or more people do and say
as they interact
Organizational Level Behavior
Organization – a group of people working to achieve an objective
Created to produce goods and services for the larger society
Organizational behavior – the collective behavior of an organization’s
individuals and groups.
3 ORGANIZATIONAL BEHAVIOURS: A BACKGROUND
OB was studied by Frederick Taylor in the late 19th and early
20th centuries
Taylor attempted to analyses the most productive way of doing
manual tasks
Taylor had 3 basic objectives:
to select the best people for the job
to instruct them in the best methods
to give incentives in the form of higher wages to the best
workers
Taylor’s view emphasizes on the financial basis of staff
motivation; however, the other issues of motivation should be
encouraged staff not just on such rewards.
Theory X and Theory Y by Donald McGregor draws attention
to the way that expectations influence behavior
Theory X holds that:
The average human has an innate dislike of work
There is a need therefore for coercion, direction and
control
People tend to avoid responsibility
Theory Y holds that:
Work is as natural as rest or play
External control and coercion are not the only ways of
bringing about effort directed towards and organization’s
ends
Commitment to objectives is a function of the rewards
associated with their achievement
The average human can learn to accept and further seek
responsibility
The capacity to exercise imagination and other creative
qualities is widely distributed
One way of judging whether a manager espouses Theory X or
Theory Y is to observe how staff react when the boss is absent:
If there is no discernible change then this is a Theory Y
environment;
If everyone visibly relaxes, it is a Theory X environment
Therefore,
A “reward” does not have to be a financial reward- it could be
something like a sense of achievement
Theory X and Theory Y illustrated how the state of mind of workers
influenced their productivity
SELECT THE RIGHT PERSON FOR THE JOB
Taylor stressed “the need for the right person for the job”.
Examples of question;
What sort of characteristics should they be looking for?
Is an experienced programmer better than a new graduate
with a first?
class mathematics degree?
Recruitment is often an organizational responsibility
There are 2 types of candidates that are distinguished by Meredith Belbin:
@Eligible candidate
@Suitable candidate
Eligible candidates have curriculum vitae (CV) which shows, for
example, the
‘right’ number of years in some previous post and the ‘right’ paper
qualifications.
Suitable candidates can actually do the job well
A mistake is to select an eligible candidate who is not in fact
suitable
Thus, Belbin suggests we should try to assess actual skills rather
than past experience and provide training to make good minor gaps in
expertise
And it also has the general approach for recruitment process
5 INSTRUCTIONS IN THE BEST METHODS
Create a job specification
Create a job holder profile
Obtain applicants
Examine CVs
Interviews (e.g., aptitude tests, personality tests and the
examination of samples of previous work)
Other procedures (e.g. medical examination)
What is the purpose of instruction?
The purpose of instruction is to help people learn. The goal of instructional
designers is to make learning easier, quicker, and more enjoyable. Some
people view training as a process of finding out who the brightest employees
are. But performance in a course is not very highly correlated with the basic
ability to be good on the job. We believe that an instructional designer's job is
to help everyone to learn and be successful.
Challenge: How to make good instruction?
The key to improving our instruction is to know what methods of instruction to
use when. It's helpful to think of different methods of instruction as different
tools for a carpenter. If you only have a hammer, then everything looks like a
nail to you. And you won't be able to make a very good piece of furniture. So,
what we need is a knowledge base about methods of instruction to
supplement the creative, "art" aspect of training. Such a knowledge base
would offer optimal methods for given situations.
What are the relevant kinds of learning?
Perhaps the most important aspect of the situation is the kind of learning that is to
be facilitated. Knowing about the kinds of learning helps us to do a better job of
teaching them. The most basic distinction is Benjamin Bloom's three domains:
Cognitive learning (thoughts), such as teaching someone to add fractions.
Affective learning (feelings, values), such as teaching someone to not want to
smoke.
Physical or motor learning (actions), such as teaching someone to touch type.
6 MOTIVATIONS
The Taylorist model:
Taylor’s viewpoint is reflected in the use of piece-rates in
manufacturing industries and sales bonuses amongst sales forces.
Piece-rates can cause difficulties if a new system will change
work practices.
If new technology improves productivity, adjusting piece-rates
to reflect this will be a sensitive issue.
“Piece-rates” are where workers are paid a fixed sum for each
item they produce.
“Day-rates” refer to payment for time worked
Rewards based on piece-rates need to relate directly to work
produced
So, this model emphasizes on the reward system
Maslow’s hierarchy needs:
1.Physicological needs
2.Saftey needs
3.Needs for Love and Belonging
4.Needs for Esteem
5.Needs for Self-Actualization
6.Needs to Know and understand
7.Aesthic needs
Herzberg’s two-factor theory:
Some things about a job can make you dissatisfied.
If the causes of this dissatisfaction are removed, this does not
necessarily make the job more exciting
There are two sets of factors about a job:
Hygiene or maintenance factors
Motivators
Hygiene or maintenance factors, which can make you
dissatisfied if they are not right, for example the level of pay or the
working conditions;
Motivators, which make you feel that the job is worthwhile, like
a sense of achievement or the challenge of the work itself
A model of motivation developed by Vroom and his colleagues.
It identifies three influences on motivation:
expectancy: the belief that working harder will lead to a better
performance
instrumentality: the belief that better performance will be
rewarded
perceived value: of the resulting reward
Motivation will be high when all three factors are high
A zero level for any one of the factors can remove motivation
7 HACKMAN JOB CHARACTERISTICS MODEL:
Managers should group together the elements of tasks to be carried
out so that they form meaningful and satisfying assignments.
Oldham and Hackman suggest that the satisfaction that a job gives
is based on 5 factors
The first three factors make the job ‘meaningful’ to the person who
is doing it
These three factors:
- skill variety: the number of different skills that the job holder has
the opportunity to exercise
- task identify: the degree to which your work and its results are
identifiable as belonging to you
task significance: the degree to which your job has an influence on
others
The other two factors are:
autonomy: the discretion you have about the way that you do the
job
-feedback: the information you get back about the results of your
works
Methods of improving motivation;
Set specific goals: these goals need to be demanding and yet
acceptable to staff. Involving staff in the setting of goals helps to gain
acceptance for them.
Provide feedback: Not only do goals have to be set but staff have to
have regular feedback about how they are progressing
Considering job design: Jobs can be altered to make them more
interesting and give staff more feeling of responsibility
Two measures are often used to enhance job design;
job enlargement-> The person doing the job carries out a wider
variety of activities. It is opposite of increasing specialization
job enrichment -> The job holder carries out tasks that are normally
done at a managerial or supervisory level
8. WORKING IN GROUPS:
A problem with major software projects is that they always involve
working in groups, and many people attracted to software development
find this difficult.
It is not easy for people from different backgrounds to work
together as a team so it is suggested that teams should go through five
basic stages of development.
9 BECOMING A TEAM:
It is suggested that teams go through 5 basic stages of development:
1.Forming: The members of the group get to know each other and try
to set up some ground rules about behavior
2.Storming: Conflicts arise as various members of the group try to
exert leadership and the group’s methods of operation are being
established
3.Norming: Conflicts are largely settled and a feeling of group identity
emerges.
4.Performing: The emphasis is now on the tasks at hand
5.Adjourning: The group disbands.
10 DECISION MAKING:
• Decision can be categorized as being:
structured: generally, relatively simple, routine decisions where rules
can be applied in a fairly straightforward way
Unstructured: more complex and often requiring a degree of
creativity
• Some mental obstacles in good decision making
➢ Faculty heuristics
➢ Escalation of commitment
➢ Information overload
• Group decision making
• Obstacles
Measure to reduce disadvantages in group decision making
*Another way to categorize decisions is by the amount if risk and uncertainty
that is involved*
➢ To make it more efficient and effective -> training members to
follow a set procedure
➢ Brainstorming techniques can help groups to create more ideas.
11 LEADERSHIP:
Leadership is based on the idea of authority or power.
Power may come either from the person’s position (position power),
from the person’s individual qualities (personal power) or may be a
mixture of the two
Types of Power: Position power
1.coercive power: the ability to force someone to do something
by threatening punishment
2.connection power: which is based on having access to those
who have power
3. legitimate power: which is based on a person’s title
conferring a special status
4. reward power: where the holder can give rewards to those
who carry out tasks to his or her satisfaction
Types of Power: Personal power
1.expert power: which comes from being the person who is able
to do a specialized task
2.information power: where the holder has exclusive access to
information
3. referent power: which is based on the personal attractiveness
of the leader
Leadership style:
There are 2 axes: directive vs. permissive and autocratic vs. democratic:
-directive autocrat: makes decisions alone, close supervision of
implementation
- permissive autocrat: makes decision alone, subordinates have
latitude in implementation
Directive democrat: makes decisions participatively, close
supervision of implementation
Permissive democrat: makes decisions participatively,
subordinates have latitude in implementation.
12 Organizational Structures
An organizational structure defines how activities such as task allocation,
coordination and supervision are directed towards the achievement of organizational
aims.[1] It can also be considered as the viewing glass or perspective through which
individuals see their organization and its environment.
Organized Structure gives members clear guidelines for how to proceed.
A clearly-established structure gives the group a means to maintain order and
resolve disagreements.
Organized Structure binds members together. It gives meaning and identity
to the people who join the group, as well as to the group itself.
Organized Structure in any organization is inevitable -- an organization, by
definition, implies a structure. Your group is going to have some structure
whether it chooses to or not. It might as well be the structure which best
matches up with what kind of organization you have, what kind of people are
in it, and what you see yourself doing.
It is important to deal with structure early in the organization's development.
Structural development can occur in proportion to other work the organization is
doing, so that it does not crowd out that work. And it can occur in parallel with, at
the same time as, your organization's growing accomplishments, so they take place
in tandem, side by side. This means that you should think about structure from the
beginning of your organization's life. As your group grows and changes, so should
you’re be thinking on the group's structure.
Elements of Structure:
Some kind of governance
Rules by which the organization operates
A distribution of work
13 HEALTH AND SAFETY:
Responsibility for safety must be clearly defined at all levels. Some points
that will need to be considered include:
➢ Top management must be committed to the safety policy
➢ The delegation of responsibilities for safety must be clear
➢ Those to whom responsibilities are delegated must understand the
responsibilities and agree to them
➢ Deployment of a safety officer and the support of experts in particular
technical areas
➢ Consultation on safety
➢ An adequate budgeting for safety costs
Unit 8: Software quality assurance and testing
Objectives and principles of software testing
Software Testing Definition -:
Software testing is a process of evaluation of functional and nonfunctional items to
identify difference between expected and actual result.
Software testing is a process of executing a source code or application with intent
to identifying and eliminating bugs from the source code or application.
According to IEEE “Software testing is a process of evaluating the system or
system component by manual or automated means to verify that it satisfy specified
user requirement or to identify difference between expected and actual result.”
According to Myers “Software testing is a process of executing a program or
system with the intent of finding errors.”
Objectives of software testing -:
– Ensures the quality of product
– Defect prevention and detection
– Verify and validate the user requirement
– Ready to integration and revise the component
– Focus on accurate and reliable result
– Work should be performed under predefined process and SRS
– Discuss on generating test cases test cases
– Provide information to take decision for next phase
– Gain confidence of work
– Evaluates the capabilities of a system and system performance
Principles of software testing -:
– It is ongoing process to achieve quality product
– Defect discovered, Analysis and correct
– Trying to meet user satisfaction
– Ensure product and system application
– Evaluation of user requirement
– Covers all test coverage
– Process for early testing to discover defect
Test Plan
A Test Plan is a detailed document that describes the test strategy, objectives,
schedule, estimation, deliverables, and resources required to perform testing for a
software product. Test Plan helps us determine the effort needed to validate the
quality of the application under test. The test plan serves as a blueprint to conduct
software testing activities as a defined process, which is minutely monitored and
controlled by the test manager.
What is the Importance of Test Plan?
•
•
•
Help people outside the test team such as developers, business managers,
customers understand the details of testing.
Test Plan guides our thinking. It is like a rule book, which needs to be
followed.
Important aspects like test estimation, test scope, Test
Strategy are documented in Test Plan, so it can be reviewed by
Management Team and re-used for other projects.
How to write a Test Plan
You already know that making a Test Plan is the most important task of Test
Management Process. Follow the seven steps below to create a test plan as per
IEEE 829
1.
2.
3.
4.
5.
6.
7.
8.
Analyze the product
Design the Test Strategy
Define the Test Objectives
Define Test Criteria
Resource Planning
Plan Test Environment
Schedule & Estimation
Determine Test Deliverables
Levels of Testing
There are mainly four Levels of Testing in software testing :
1. Unit Testing : checks if software components are fulfilling functionalities or
not.
2. Integration Testing : checks the data flow from one module to other
modules.
3. System Testing : evaluates both functional and non-functional needs for the
testing.
4. Acceptance Testing : checks the requirements of a specification or contract
are met as per its delivery.
Each of these testing levels has a specific purpose. These testing level provide
value to the software development lifecycle.
1) Unit testing:
A Unit is a smallest testable portion of system or application which can be
compiled, liked, loaded, and executed. This kind of testing helps to test each
module separately.
The aim is to test each part of the software by separating it. It checks that
component are fulfilling functionalities or not. This kind of testing is performed by
developers.
2) Integration testing:
Integration means combining. For Example, In this testing phase, different
software modules are combined and tested as a group to make sure that integrated
system is ready for system testing.
Integrating testing checks the data flow from one module to other modules. This
kind of testing is performed by testers.
3) System testing:
System testing is performed on a complete, integrated system. It allows checking
system's compliance as per the requirements. It tests the overall interaction of
components. It involves load, performance, reliability and security testing.
System testing most often the final test to verify that the system meets the
specification. It evaluates both functional and non-functional need for the testing.
4) Acceptance testing:
Acceptance testing is a test conducted to find if the requirements of a specification
or contract are met as per its delivery. Acceptance testing is basically done by the
user or customer. However, other stockholders can be involved in this process.
Other Types of Testing:
Regression Testing
Whenever a change in a software application is made, it is quite possible that other
areas within the application have been affected by this change. Regression testing
is performed to verify that a fixed bug hasn't resulted in another functionality or
business rule violation. The intent of regression testing is to ensure that a change,
such as a bug fix should not result in another fault being uncovered in the
application.
Alpha Testing
This test is the first stage of testing and will be performed amongst the teams
(developer and QA teams). Unit testing, integration testing and system testing when
combined together is known as alpha testing. During this phase, the following
aspects will be tested in the application −
•
Spelling Mistakes
•
Broken Links
•
Cloudy Directions
Beta Testing
This test is performed after alpha testing has been successfully performed. In beta
testing, a sample of the intended audience tests the application. Beta testing is also
known as pre-release testing. Beta test versions of software are ideally distributed
to a wide audience on the Web, partly to give the program a "real-world" test and
partly to provide a preview of the next release.
Test Strategy
A Test Strategy is a plan for defining an approach to the Software Testing Life
Cycle (STLC). It guides QA teams to define Test Coverage and testing scope. It
helps testers get a clear picture of the project at any instance. The possibility of
missing any test activity is very low when there is a proper test strategy in place.
What is Test Strategy Document?
Test Strategy Document is a well-described document in software testing which
clearly defines the exact software testing approach and testing objectives of the
software application. Test document is an important document for QA teams which
is derived from actual business requirements that guides the whole team about
software testing approach and objectives for each activity in the software testing
process.
How to prepare a good test strategy document
Every organization has their unique priority and set of rules for software designing,
so do not copy any organization blindly. Always ensure that their document is
compatible and adds value to your software development before following the
template.
Test Strategy in STLC:
Step#1: Scope
It defines parameters like
•
•
•
Who will review the document?
Who will approve this document?
Software Testing activities carried out with timelines
Step#2 Test Approach
It defines
•
•
•
•
•
Process of testing
Testing levels
Roles and responsibilities of each team member
Types of Testing ( Load testing, Security testing, Performace testing etc.)
Testing approach & automation tool if applicable
•
Adding new defects, re-testing, Defect triage, Regression Testing and test
sign off
Step#3 Test Environment
•
•
Define the number of requirement and setup required for each environment
Define backup of test data and restore strategy
Step#4 Testing Tools
•
•
Automation and Test management tools needed for test execution
Figure out a number of open-source as well as commercial tools required,
and determine how many users are supported on it and plan accordingly
Step#5 Release Control
•
Release management plan with appropriate version history that will make
sure test execution for all modification in that release
Step#6 Risk Analysis
•
•
List all risks that you can estimate
Give a clear plan to mitigate the risks also a contingency plan
Step#7 Review and Approvals
•
•
All these activities are reviewed and signed off by the business team, project
management, development team, etc.
Summary of review changes should be traced at the beginning of the
document along with an approved date, name, and comment
Difference Between Test Strategy and Test Plan
Test Plan
Test Strategy
•
A test plan for software project
can be defined as a document that
defines the scope, objective,
approach and emphasis on a
software testing effort
•
Test strategy is a set of
guidelines that explains test
design and determines how
testing needs to be done
•
Components of Test plan includeTest plan id, features to be tested,
test techniques, testing tasks,
features pass or fail criteria, test
deliverables, responsibilities, and
schedule, etc.
•
Components of Test strategy
includes- objectives and scope,
documentation formats, test
processes, team reporting
structure, client communication
strategy, etc.
•
Test plan is carried out by a
testing manager or lead that
describes how to test, when to
test, who will test and what to test
•
A test strategy is carried out by
the project manager. It says
what type of technique to
follow and which module to
test
•
Test plan narrates about the
specification
•
Test strategy narrates about the
general approaches
•
Test plan can change
•
Test strategy cannot be changed
•
Test planning is done to
determine possible issues and
dependencies in order to identify
the risks.
•
It is a long-term plan of action.
You can abstract information
that is not project specific and
put it into test approach
•
A test plan exists individually
•
In smaller project, test strategy
is often found as a section of a
test plan
•
It is defined at project level
•
It is set at organization level
and can be used by multiple
projects
Software Quality
Software quality product is defined in term of its fitness of purpose. That is, a
quality product does precisely what the users want it to do. For software products,
the fitness of use is generally explained in terms of satisfaction of the requirements
laid down in the SRS document. Although "fitness of purpose" is a satisfactory
interpretation of quality for many devices such as a car, a table fan, a grinding
machine, etc.for software products, "fitness of purpose" is not a wholly satisfactory
definition of quality.
Example: Consider a functionally correct software product. That is, it performs all
tasks as specified in the SRS document. But, has an almost unusable user interface.
Even though it may be functionally right, we cannot consider it to be a quality
product.
The modern view of a quality associated with a software product several
quality methods such as the following:
Portability: A software device is said to be portable, if it can be freely made to
work in various operating system environments, in multiple machines, with other
software products, etc.
Usability: A software product has better usability if various categories of users can
easily invoke the functions of the product.
Reusability: A software product has excellent reusability if different modules of
the product can quickly be reused to develop new products.
Correctness: A software product is correct if various requirements as specified in
the SRS document have been correctly implemented.
Maintainability: A software product is maintainable if bugs can be easily
corrected as and when they show up, new tasks can be easily added to the product,
and the functionalities of the product can be easily modified, etc.
Software Engineering Institute Capability Maturity Model (SEICMM)
The Capability Maturity Model (CMM) is a procedure used to develop and refine
an organization's software development process.
The model defines a five-level evolutionary stage of increasingly organized and
consistently more mature processes.
CMM was developed and is promoted by the Software Engineering Institute (SEI),
a research and development center promote by the U.S. Department of Defense
(DOD).
Capability Maturity Model is used as a benchmark to measure the maturity of an
organization's software process.
LEVELS OF SEICMM:
Level 1: Initial
Ad hoc activities characterize a software development organization at this level.
Very few or no processes are described and followed. Since software production
processes are not limited, different engineers follow their process and as a result,
development efforts become chaotic. Therefore, it is also called a chaotic level.
Level 2: Repeatable
At this level, the fundamental project management practices like tracking cost and
schedule are established. Size and cost estimation methods, like function point
analysis, COCOMO, etc. are used.
Level 3: Defined
At this level, the methods for both management and development activities are
defined and documented. There is a common organization-wide understanding of
operations, roles, and responsibilities. The ways through defined, the process and
product qualities are not measured. ISO 9000 goals at achieving this level.
Level 4: Managed
At this level, the focus is on software metrics. Two kinds of metrics are composed.
Product metrics measure the features of the product being developed, such as its
size, reliability, time complexity, understandability, etc.
Process metrics follow the effectiveness of the process being used, such as
average defect correction time, productivity, the average number of defects found
per hour inspection, the average number of failures detected during testing per
LOC, etc. The software process and product quality are measured, and quantitative
quality requirements for the product are met. Various tools like Pareto charts,
fishbone diagrams, etc. are used to measure the product and process quality. The
process metrics are used to analyze if a project performed satisfactorily. Thus, the
outcome of process measurements is used to calculate project performance rather
than improve the process.
Level 5: Optimizing
At this phase, process and product metrics are collected. Process and product
measurement data are evaluated for continuous process improvement.
Software Engineering | Software Quality Assurance(SQA)
Software Quality Assurance (SQA) is simply a way to assure quality in the
software. It is the set of activities which ensure processes, procedures as well as
standards suitable for the project and implemented correctly.
Software Quality Assurance is a process which works parallel to development of a
software. It focuses on improving the process of development of software so that
problems can be prevented before they become a major issue. Software Quality
Assurance is a kind of an Umbrella activity that is applied throughout the software
process.
Software Quality Assurance have:
1. A quality management approach
2. Formal technical reviews
3. Multi testing strategy
4. Effective software engineering technology
5. Measurement and reporting mechanism
Major Software Quality Assurance Activities:
1. SQA Management Plan:
Make a plan how you will carry out the sqa through out the project.
Think which set of software engineering activities are the best for
project.check level of sqa team skills.
2. Set The Check Points:
SQA team should set checkpoints. Evaluate the performance of the
project on the basis of collected data on different check points.
3. Multi testing Strategy:
Do not depend on single testing approach. When you have lot of testing
approaches available use them.
4. Measure Change Impact:
The changes for making the correction of an error sometimes re
introduces more errors keep the measure of impact of change on project.
Reset the new change to change check the compatibility of this fix with
whole project.
5. Manage Good Relations:
In the working environment managing the good relation with other teams
involved in the project development is mandatory. Bad relation of sqa
team with programmers team will impact directly and badly on project.
Don’t play politics.
Benefits of Software Quality Assurance (SQA):
1.
2.
3.
4.
5.
6.
7.
SQA produce high quality software.
High quality application saves time and cost.
SQA is beneficial for better reliability.
SQA is beneficial in the condition of no maintenance for long time.
High quality commercial software increase market share of company.
Improving the process of creating software.
Improves the quality of the software.
QA organization structure
Quality assurance principles require an organizational structure that links
responsibility for quality directly to the executive level of the company. Large
organizations fulfill this requirement by appointing a quality assurance manager
who reports to the CEO. The organizational structure also has to provide the QA
manager with direct organizational paths into every department. Small businesses
can meet these requirements by assigning the QA responsibilities to someone in
management, giving him the authority to manage QA matters throughout the
company and creating a QA reporting path to the executive level. Employees
continue to report to their department manager for disciplinary and non-QA
matters, but report to the person responsible for QA on quality questions.
Design
Quality assurance principles require the verification of all design work. In small
businesses, designers can check their own work, but they have to do it as a
separate process. On an organizational level, this means that the design
department doesn't need a special quality function. All designers are responsible
for the quality of their own work, under the supervision of the manager
responsible for quality. They sign drawings and design documentation as designer
and then check their work, initialing it when verified. They also keep track of
revisions. The manager in charge of quality can use his organizational access to
perform spot checks.
Sales and Marketing
Quality in sales and marketing means that sales and marketing material matches
the documented characteristics of the company's products and services. Typically,
sales personnel and marketing managers are responsible for the quality of the
materials they create. The manager in charge of quality can use his organizational
access to periodically review sales and marketing material. If he finds
discrepancies, he may try to resolve them directly with the person responsible
through his direct supervisory path in the organization. If he is not satisfied with
the results, he can use his organizational access to the executive level to report
the problem and suggest solutions.
Production
Production is a key company department for quality and normally requires its
own quality function. Quality in a product means that the product corresponds
with the needs and expectations of the customer. The two aspects of production
quality are the specification of the product and its production according to the
specification.
The responsibility for verifying that the specification matches customer needs and
expectations usually rests with the manager responsible for quality. He makes
sure production has the appropriate documentation. Within the production
department's organization, responsibility for quality lies with testing. The
production department assigns responsibility for quality to a member of the
testing group who then reports to the manager in charge of quality on quality
issues. The manager can use his organizational direct access to production to
identify and solve problems or report them to the executive level of the company.
Human Resources
In human resources, quality means that job descriptions are clear, the required
education and training is specified for each position and the personnel files
include proof of the required education and training for each employee. The
responsibility for quality lies with the department manager. The manager
responsible for quality works with the department manager through the
organizational link, giving him direct access to the department. Together, they
verify that employee files satisfy quality requirements.
Software Quality Assurance Plan
Abbreviated as SQAP, the software quality assurance plan comprises of the
procedures, techniques, and tools that are employed to make sure that a product or
service aligns with the requirements defined in the SRS(software requirement
specification).
The plan identifies the SQA responsibilities of a team, lists the areas that need to
be reviewed and audited. It also identifies the SQA work products.
The SQA plan document consists of the below sections:
1. Purpose section
2. Reference section
3. Software configuration management section
4. Problem reporting and corrective action section
5. Tools, technologies and methodologies section
6. Code control section
7. Records: Collection, maintenance and retention section
8. Testing methodology
Unit 9: Software Configuration Management
What is Software Configuration Management?
In Software Engineering, Software Configuration Management (SCM) is a
process to systematically manage, organize, and control the changes in the
documents, codes, and other entities during the Software Development Life Cycle.
The primary goal is to increase productivity with minimal mistakes. SCM is part of
cross-disciplinary field of configuration management and it can accurately
determine who made which revision.
Why do we need Configuration management?
The primary reasons for Implementing Technical Software Configuration
Management System:
•
•
•
•
•
•
There are multiple people working on software which is continually
updating
It may be a case where multiple version, branches, authors are involved in a
software config project, and the team is geographically distributed and
works concurrently
Changes in user requirement, policy, budget, schedule need to be
accommodated.
Software should able to run on various machines and Operating Systems
Helps to develop coordination among stakeholders
SCM process is also beneficial to control the costs involved in making
changes to a system
Tasks in SCM process
•
•
•
•
•
Configuration Identification
Baselines
Change Control
Configuration Status Accounting
Configuration Audits and Reviews
Configuration Identification:
Configuration identification is a method of determining the scope of the software
system. With the help of this step, you can manage or control something even if
you don't know what it is. It is a description that contains the CSCI type (Computer
Software Configuration Item), a project identifier and version information.
Activities during this process:
•
•
•
•
•
Identification of configuration Items like source code modules, test case, and
requirements specification.
Identification of each CSCI in the SCM repository, by using an objectoriented approach
The process starts with basic objects which are grouped into aggregate
objects. Details of what, why, when and by whom changes in the test are
made
Every object has its own features that identify its name that is explicit to all
other objects
List of resources required such as the document, the file, tools, etc.
Example:
Instead of naming a File login.php its should be named login_v1.2.php where v1.2
stands for the version number of the file
Instead of naming folder "Code" it should be named "Code_D" where D represents
code should be backed up daily.
Baseline:
A baseline is a formally accepted version of a software configuration item. It is
designated and fixed at a specific time while conducting the SCM process. It can
only be changed through formal change control procedures.
Activities during this process:
•
•
•
•
Facilitate construction of various versions of an application
Defining and determining mechanisms for managing various versions of
these work products
The functional baseline corresponds to the reviewed system requirements
Widely used baselines include functional, developmental, and product
baselines
In simple words, baseline means ready for release.
Change Control:
Change control is a procedural method which ensures quality and consistency
when changes are made in the configuration object. In this step, the change request
is submitted to software configuration manager.
Activities during this process:
•
•
•
Control ad-hoc change to build stable software development environment.
Changes are committed to the repository
The request will be checked based on the technical merit, possible side
effects and overall impact on other configuration objects.
It manages changes and making configuration items available during the
software lifecycle
Configuration Status Accounting:
Configuration status accounting tracks each release during the SCM process. This
stage involves tracking what each version has and the changes that lead to this
version.
Activities during this process:
•
•
•
•
•
•
Keeps a record of all the changes made to the previous baseline to reach a
new baseline
Identify all items to define the software configuration
Monitor status of change requests
Complete listing of all changes since the last baseline
Allows tracking of progress to next baseline
Allows to check previous releases/versions to be extracted for testing
Configuration Manager
Responsible for the execution of the Process (directly perform or delegate
responsibilities). Includes operating the defined and agreed process, ensuring it
interfaces with all other relevant processes, reviewing the effectiveness and
efficiency of the process, performing process audits and managing the process
improvement cycle.
Responsibilities
•
•
•
•
•
•
•
•
•
•
•
Responsible for the deployment of the process. Evaluates performance
metrics against the defined critical success factors and institutes actions to
correct shortcomings or further streamline the process as necessary
Responsible for the execution of the process controls, ensuring that staff
comply with process and data standards
Interfaces with other processes and/or business functions to ensure they are
able to leverage the benefits provided by the Configuration Management
process
Directs, prioritizes and schedules audits; ensures that any corrective action
identified in Process and/or Database audits are carried out
Directs and schedules the training of new CI owners and CI coordinators
Manages the evaluation of Configuration Management tools and recommend
those that best meet the organization's requirements
Ensures regular housekeeping of the Configuration Management System
data
Ensures appropriate security and access levels to the Configuration
Management System
Plans and manages a population of the Configuration Management System,
including discovery and other data import methods
Produces reports and Management information, including impact analysis
reports and Configuration status reports
Identifies opportunities and submits proposals for improvement with respect
to tools, staff, training, process, procedures and work instructions
Participant of SCM process:
Following are the key participants in SCM
1. Configuration Manager
•
•
•
Configuration Manager is the head who is Responsible for identifying
configuration items.
CM ensures team follows the SCM process
He/She needs to approve or reject change requests
2. Developer
•
•
The developer needs to change the code as per standard development
activities or change requests. He is responsible for maintaining configuration
of code.
The developer should check the changes and resolves conflicts
3. Auditor
•
•
The auditor is responsible for SCM audits and reviews.
Need to ensure the consistency and completeness of release.
4. Project Manager:
•
Ensure that the product is developed within a certain time frame
•
•
•
Monitors the progress of development and recognizes issues in the SCM
process
Generate reports about the status of the software system
Make sure that processes and policies are followed for creating, changing,
and testing
5. User
The end user should understand the key SCM terms to ensure he has the latest
version of the software