Ch2-Development and Quality Plan

Software Quality
Assurance
EMIT-606
Lecture 2:
Development and quality plans
Prof. Dr. RJ Qureshi

Development and quality
plans - Objectives
• Development plan and quality plan objectives

• The elements of the development plan
• Elements of the quality plan
• Development and quality plans for small and for internal
Agenda projects
• Software development risks and software risk
management
2
Prof. Dr. R. J. Qureshi, FCIT KAU
Planning is meant to prepare adequate foundations for successful and timely completion of the
project. The planning process includes:
1. Scheduling development activities and estimating the
required manpower resources and budget
2. Recruiting team members and allocating development
resources
3. Resolving development risks
4. Implementing required SQA activities
5. Providing management with data needed for project
control
1. Project products, specifying “deliverables”
2. Project interfaces
3. Project’s methodology and development tools
4. Software development standards and procedures
5. Map of the development process
6. Project milestones
7. Project staff organization and coordination with external participants
8. Required development facilities
9. Development risks and risk management actions
10. Control methods
11. Project cost estimates

 Project Introduction Document
 Feasibility Assessments
 Management Issues
What Constitutes a Project Introduction?
Prof. Dr. R. J. Qureshi, FCIT KAU 7

What Constitutes a Project Introduction?
• History
• Main problems of the current system
• Scope of the new system
• Context
• Main Inputs/Outputs
• Main Functions
• Functional Decomposition

What are the Main Types of Feasibilities?

Feasibility Assessments
• Economic
• Technical
• Operational
• Schedule

Economic Feasibility
• Estimating Project Benefits
• Estimating Project Costs

Estimating Project Benefits
• Tangible
• Intangible

Tangible
• Tangible benefits are those that are measure able in terms of monetary values.
• Cost reduction.
• Time in terms of cost
• Error reduction.
• Opening new market.
• Sales opportunities.
• Improvement of management planning and control.
• That how much cost will be reduced in terms of overtime, staff and resources
reduction.

Intangible Benefits
• Intangible benefits of a project are not measurable in terms of monetary
values.
• Efficiency.
• Performance.
• Quality.
• Employee’s morale.
• Company goodwill.

Estimating Project Costs
• LOC
• Function Point (FP)
• Back Firing
• Constructive Cost Model (COCOMO) I
• Constructive Cost Model (COCOMO) II
• New LOC Method
• Agile budgeting

What is Technical Feasibility?

TECHNICAL FEASIBILITY
• Technical feasibility is composed of estimating:
• Hardware cost (HW);
• SW cost.
• SW cost includes the purchasing of SW required to develop the project, such as
OS, server, front end and back end. HW cost includes the purchasing of HW
required to develop the project, such as number of system units, monitors,
keyboards, mousses and printers.

What is Operational Feasibility?

Operational Feasibility
• The operational cost includes all cost that is required to run the SW
system operationally at all sites of the organization. It includes the
computer terminals needed at each office, the cabling to establish
network, salary required hiring computer operators and backup cost.

What is Schedule Feasibility?

Schedule Feasibility
• Schedule feasibility is used to display total scheduled time vs. the
activities performed needed to complete the project. There are two
main types of charts are drawn to represent schedule feasibility.
• Gantt chart
• PERT chart

Schedule Feasibility
• Gantt chart displays the activities against the time as a horizontal bar
only whereas PERT chart also displays the interaction among the
activities.
• PERT chart abbreviation is Program Evaluation and Review Technique.
• Time overlapping activities can be seen using the Gantt chart where
as which activities can be done in parallel

Management Issues
• Who is going to finance the project?
• Who is/are suspected customer/s?
• Who is the champion of the project in the top management?
• How to manage risks regarding the project?

What is Costs-Benefits Analysis Sheet?
• Project manager prepares costs-benefits analysis sheet at the end of
proposal document showing the tangible benefits of the SW system
against the cost. The overall objective of costs-benefits analysis sheet
is to show to the stakeholders that benefits would recover the
investment cost.

The Main Criteria To Approve The Proposal Or PSD Or
Baseline Plan
• How much the new system will save costs?
• When and where cost will be saved?
• How much new system will improve the organizational processes and
information processing?
• How much better services are provided to customers?
• Will the system implement within affordable time?
• Is the organization having required resources?
• The benefits are long term or short term.
• Long-term benefits are covering the development cost or not.
Main benefits of the Baseline Plan
• To uncover main functional requirements.
• Track the project in the correct direction.
• To remove all misunderstandings and uncertainties regarding the
project.
• Users can makeup their mind before a detailed analysis is made.
• To maintain a feedback loop among the customer, analyst and the
developer.
• It is easy for an analyst to trace and manage the effects on the base
line plan whenever a change is made in the project scope or goals

Selection of Methodology?
• Select the most suitable model to be used for a particular project.

Selection of Methodology
• These are the criteria on the basis of which Project
Manager selects the appropriate model for a
particular project.
 Customer- Customer sometimes imposes the SW house to follow a specific
model for his project.
 Team size- Team size is very critical factor that forces the SW house to select
a specific model that suits to their team available for the project to be
developed.
 Technology- Technology in terms of development tool, platform and
technical capabilities to develop the project is also an important factor for
the selection of process model.
 Reuse of the existing components- Object Oriented or Component-Based
Development process model helps to reuse the existing components.
 Characteristics of the system.
Selection of Methodology
• Characteristics of the system-As followed
• Linear Sequential model is the best choice for a new project having
functionalities similar to previously completed projects.
• Rapid Application Development model is the appropriate choice for a
project having very tight deadlines.
• Evolutionary models are the best choice for the projects having
impossible deadlines.

What is Functional Specifications?

Functional Specifications
Summary of Requirements
Modeling of Requirements
Data Modeling

What is Design Specifications?

Design Specifications
Interface Designing
Data Modeling
Hierarchical Charts
Algorithm Designing

What is Implementation Plan

Implementation Plan
Code
Testing
Maintenance
Deployment

1. List of quality goals

2. Review activities

3. Software tests
4. Acceptance tests for software
externally developed
5. Configuration management plans: tools, procedures and data for
version releases
 List of quality goals
 The term “quality goals” refers to the developed software system’s
substantive quality requirements using validation and verification.
 Validation
 Verification
 Unit
 Integration
 System
 Acceptance
 Formal Technical Review (FTR)
 Post Mortem Analysis
 Walkthrough
 Formal Inspection
 Sprint Review
 Sprint Retrospective
FTR Meeting
FTR meeting is a review session in which the review leader presents
the contents of agenda to be reviewed.
One member of review session acts the role of recorder.
The review members highlight the issues on the basis of their
homework due to distribution of document and agenda well in
advance.
There are three main functioning of FTR meeting participants to
accept, reject or recommend modifications in the product to be
reviewed.
Objectives of FTR Meeting
The objectives of the formal technical review are as follows to:
• uncover errors in function, logic, or implementation for any representation of
the software;
• verify that the software under review meets its requirements;
• ensure that the software has been represented according to predefined
standards;
• achieve software that is developed in a uniform manner;
• make projects more manageable.
Post Mortem Analysis
A post-mortem analysis is a process in which you summarize what
went wrong (and should be fixed) in a project, as well as what went
well and should be repeated.
The analysis also produces action items and who is responsible for
each.
Crucial issues that held the project back.
Code Walkthrough
It is one of the group-oriented methods.
The set of people look at the code and ask questions to the author
of the code.
 If the author is unable to answer some questions then he tries to
identify the answers of those questions before the next walkthrough.
Completeness is limited to the area where questions are raised by

the team.
Formal Inspection
It is also called code inspection or Fagan (researcher name who
introduced this method) inspection.
Effectiveness of this method lies in the fact that:
 How much well planned and prepared the review is conducted?
 Enlisting multiple diverse views.
 Assigning specific roles to the participants.
 Going sequentially through the code in a structured manner.
Sprint Review
The sprint review is a meeting which the development team, the
scrum master, the product owner and the stakeholders will attend.
The team presents a demo on the product and will determine what
are finished and what aren't.
Sprint Retrospective
The sprint retrospective is a recurring meeting held at the end of a
sprint used to discuss what went well during the previous sprint
cycle and what can be improved for the next sprint.
The Agile sprint retrospective is an essential part of the Scrum
framework for developing, delivering, and managing complex
projects.
What is a Risk?

Risk Is
• Anything that can go wrong against the project to fail it.

What is Risk Management?

Risk Management
• Risk management is composed of:
• estimating all possible risks that can effect a project;
• preparing a plan to manage all estimated risks;
• monitoring the estimated risks;
• implementing the risk avoidance plan to manage them.

What are Main Categories of Project Risks?

Main Categories
• There are two main categories of risks.
• Predictable or Certain
• Non predictable or Uncertain

Predictable or Certain Risks
• Certain risks are sure risks that they will definitely happen such as
budget and schedule risks.

Non predictable or Uncertain Risks
• uncertain risks are those that may or may not happen such as any
incident in terms of accident or people may leave the project during
development including the project director or management may
change their policy in terms of stop financing the project. Stop
financing of a project means to finish the project.

What are Main Types of Project Risks?

Main Types of Project Risks
• Project
• Technical
• Business
• Social

Project Risks
• Threaten the project plan such as:
• Budget
• Schedule
• Resources
• Personnel (Staffing and organization)
• Changing Requirements
• Project Size
Technical Risks
• Threaten the quality of software such as:
• Potential design
• Implementation
• Interface verification
• Maintenance problems
• Specification ambiguity
• Obsolete technology
Business Risks
• Threaten the feasibility of software such as:
• Target market is not willing
• Meet the customer’s requirements
• Changing scope
• Losing the support of top management
• Stop funding
Project Risks
• Project risks include budget, schedule, people, resources and
customer requirements problems.
• Project may not exceed the estimated budget and schedule.
• People may not leave the project during completion. Resources may not lack
short.
• Customer Requirements verification and it may not change after observing
the working version.

Technical Risks
• Technical risks include the quality, identifying the potential design,
implementation, interfaces, verification & maintenance problems,
requirements ambiguity and obsolete technology.
• Identifying the potential design means selection of best solution may not be wrong.
• SW may not be implement-able after completion.
• SW verification problems could be approval of main functionalities and
understanding of vague customer requirements.
• The technology in terms of HW and SW selected to implement and develop the
project may not become obsolete.

Business Risks
• Business risks cover the market trend, scope of SW and management
support.
• The SW project will meet the customer requirements and market trend at the
completion or not.
• Will the scope of the SW meet the organizational mission statements or not?
• The SW may not lose the support of the top management.

Social
• Geographical distances and time zones
• Language issues
• Communication
• Coordination issues
• Decision making
• Cultural differences

Main Strategies to Manage Risks
• There are two main strategies to handle or manage the risks.
• Reactive
• Proactive

Reactive Strategy
• Reactive strategy is used when you take some action when some
incident or accident happens such as budget, schedule and people
risks.
• Budget and schedule risks are raised when initial actions are not being
taken when indications start appearing that project is going out of
tolerance level in terms of estimated budget and schedule.
• The extra budget and schedule is needed to complete the project.
• People risk is raised when some members of the project staff suddenly left
the project because they got better offer from any of your competitor and
you have no backup to fill their positions. It is also called fire-fighting mode.

Proactive Strategy
• Proactive strategy is the planned strategy to handle the risks.
• We estimate all possible risks and develop a plan to handle and
reduce them and try to reduce the loss if it not possible to avoid the
all risks 100%.
• Proactive strategy is also called intelligent strategy.

Risk Management Strategy for Project Risks
• Threaten the project plan such as:
• Budget
• Schedule
• Resources
• Personnel (Staffing and organization)
• Changing Requirements
• Project Size (increase size of SW )

Reactive Strategy to deal with Budget and Schedule Risks
• Request the customer to deliver core functionalities within the agreed
schedule and extra functionalities later on in terms of update.
• Offer six months or one year free maintenance to customer to manage
the risks.

Proactive Strategy to deal with Budget and Schedule Risks
• Measure the velocity of the project after each release using scheduling techniques
like Earned value analysis to take corrective actions by bridging the gap between the
planned budget or schedule and the actual budget or schedule.
• In case of agile development, you promised the customer to deliver release after
every two weeks as per the contract but you deliver first release after 3 weeks
instead of 2 weeks because of less knowledge value about the project. You should
deliver the second and third release in one and half weeks time to bridge the gap to
manage the risks.

Proactive Strategy to deal with Budget and Schedule Risks
• Multiple sites are twice as slow than a single site location.
• Offshore and outsourcing need more time, costly, bugs and failure like
India, Pakistan and Bangladesh

Reactive Strategy to deal with Leaving Team Members Risks
• Risk of Team member resigns
• Call him to find the cause of leaving like less salary, designation issue, humiliating boss, duty
timing and manage it
• Cross functional team can handle the role of leaving team member.
• Risk of Project Manager (PM) resigns.
• Promote the junior PM to senior PM and ask the senior PM to train the junior PM during the
three months notice period like the case of IT24 company in Pakistan in 2008 and even after the
three months the Ex PM Mr. Qaisar Abbas used to come for one to two hours daily about
couple of months even after joining the new company Mindshare Solutions and get paid for
this advisory till the Junior PM got comfortable with the project.
• NetSol Technologies has a senior architect of LeaseSoft product. He is working since 1996 and
one of the founders of LeaseSoft and got HSMP visa and resigned in 2008. The company offered
him to transfer to UK office to manage the risk.

Proactive Strategy to deal with Leaving Team Members Risks
• NetSol Technologies had a risk of continuous switching team members 15 years ago
because of low salaries.
• The NetSol technologies started a training institute and company continuously hires the best
training candidates. So hiring cycle is running in parallel to deal the leaving team members risks
• As soon as any member resigns, as a Project manager you try to avoid it using
reactive strategy but you start hiring process even you are able to manage the risk
by stopping the leaving candidate.
• Start hiring cycle even you have cross functional team.
• Record all meetings so the new team member can easily synchronize with the
existing team.

Reactive Strategy to deal with Large Team Size Risk
• There were 800 team members in Swedish Company and there was
productivity issue.
• Alistair Cockburn an agile coach asked them to have five teams of 10 to 20 members with clear
goals.
• Each team should have a leader. Team lead of Team A, B, C, D & E should strongly collaborate
each other.
• Team productivity increases after couple of months through effective communication and
coordination. The company no more needs 800 people.

Proactive Strategy to deal with Large Team Size Risk
• Divide the large teams into multiple small teams like Yahoo company.
• Eliminate the waste principle of Lean methodology to remove extra team members.
• Sprint Retrospective to continuously optimize the team.
• System with 350 team size due to architectural dependencies.
• Design a new architecture to remove the dependencies and teams becomes independent to each other.

Proactive Strategy to deal with Large Team Size Risk
• Semi-Automatic Ground Environment (SAGE System) completed in the early 1960s,
revolutionized USA air defense.
• The integrated radar and computer technology that was developed for SAGE also
contributed significantly to the development of civilian air traffic control systems.
• SAGE was developed using 100 team members resulting in over budget and late in
delivery.
• The project manager (PM) was after the smoke fade what would you like to change
if you develop SAGE again.
• “I will select 10 persons team size to rewrite it”

Reactive Strategy to deal with Infrastructural Resources Risk
• Use agile methodology to start payment cycle after each release in
couple of weeks.

Proactive Strategy to deal with Infrastructural Resources Risk
• Use incremental methodology to start the project with less resources
and you can improve the resources as payment cycle will start

Reactive Strategy to deal with Large Size SW Risk
• Code refactoring to optimize it.
• Remove extra features and introduce only minimum marketable features.

Proactive Strategy to deal with Large Size SW Risk
• Preventive maintenance.
• Code Restructuring

Reactive Strategy to deal with changing requirements Risk
• Ask the customer to increase the budget and schedule when he will
change the requirements that this is the new budget and schedule.
• Show him history of previous projects.
• Deliver the core functionalities within budget and schedule and
remaining features with extra time and budget

Proactive Strategy to deal with changing requirements Risk
• Use prototyping to have continuous feedback.
• Deliver often every demo or release.
• Face to face meetings.
• Strong collaboration with the customer.

Technical Risks
• Threaten the quality of software such as:
• Specification ambiguity
• Potential design
• Interface verification
• Implementation
• Maintenance problems
• Obsolete technology

Reactive Strategy to deal with Specification Ambiguity Risk

Reactive Strategy to deal with Specification Ambiguity Risk
• Bootstrapping Scrum and XP under Crisis A Story from the Trenches
https://ieeexplore.ieee.org/abstract/document/4599519
• Use Scrum as a methodology
• Introduce Product owner
• No direct interaction of stakeholders with the teams
• collaborate, deliver, reflect and improve

Proactive Strategy to deal with Specification Ambiguity Risk

Reactive Strategy to deal with Potential design and Interface
verification Risks

Reactive Strategy to deal with Potential design and Interface verification Risks
• Designers and programmers at a single location like Nokia Case Study.

• Start using incremental strategy
• Deploy in stages like Motorola and let the learning cycle improve with respect to the team and
customer.
• Stat delivering every demo or release
• Start daily inspection to deal with the potential design risk

Proactive Strategy to deal with Potential design and Interface
verification Risks

Proactive Strategy to deal with Potential design and Interface verification Risks
• Clear requirements (strong analysis)

• Collaborate, deliver, reflect and improve.
• Sprint Review
• Sprint Retrospective
• Post mortem analysis
• Formal Technical Review

Reactive Strategy to deal with Implementation and Maintenance Risks

• Bootstrapping Scrum and XP under Crisis A Story from the Trenches

https://ieeexplore.ieee.org/abstract/document/4599519
• Use Scrum as a methodology
• Introduce Product owner
• seating arrangement of all teams in a hall to improve strong collaboration
(communication and coordination)
• No direct interaction of stakeholders with the teams

• IT 24 half team in USA and half team in Pakistan

• Each team starts working on separate releases.
• CMMI Quality Standard
• Stop the quality standard like the case of Denmark base company
• “From CMMI and isolation to Scrum, Agile, Lean and collaboration”
• https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.477.4637&rep=rep1
&type=pdf

96
Proactive Strategy to deal with Implementation and Maintenance Risks

Proactive Strategy to deal with Implementation and Maintenance Risks
• Pair Programming
• TDD
• Continuous Integration
• Daily testing
• Coding standards
• Refactoring
• Deliver every demo or release

Reactive Strategy to deal with Obsolete technology Risk

Reactive Strategy to deal with Obsolete Technology Risk
• Outsourcing
• like the Descon Info. Sys. had to do in case of customer asked to change the
business logic from C# to Java Versata

Proactive Strategy to deal with Obsolete Technology Risk

Proactive Strategy to deal with Obsolete Technology Risk
• Descon Info. Sys. Started hired Java developers and started training of
Java Versata to have in house development
• Train your teams with the latest tools and technologies before the
customer asked you to switch

Business Risks
• Threaten the feasibility of software such as:
• Target market is not willing
• Stop funding
• Meet the customer’s requirements
• Changing scope
• Losing the support of top management

Reactive Strategy to deal with Target market is not willing and stop funding Risks

Reactive Strategy to deal with Target market is not willing and stop funding Risks
• Stop beating the dead horse like NetSol technologies freeze the System to
integrate with the Pakistani ATM network.

Proactive Strategy to deal with Target market is not willing and stop funding Risks

Proactive Strategy to deal with Target market is not willing and stop funding Risks
• Find a customer before developing a system
• Develop small scale projects to deliver in couple of months to attract
customers like 9/11 incident

Reactive Strategy to deal with Meet the customer’s requirements, Changing
scope, Losing the support of top management Risks

Reactive Strategy to deal with Meet the customer’s requirements, Changing scope, Losing the support of
top management Risks
• Stop the quality standard like the case of Denmark base company
• “From CMMI and isolation to Scrum, Agile, Lean and collaboration”
• https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.477.4637&rep=rep1&type=pdf
• Extensive Analysis and Design using the traditional methodology
• Like Indian company InfoSys failed in US Client who is dealing with the property estate business
company
• Request the customer to give extra time and change the system as per the new requirements, scope
and take approval from the top management
• like TriSoft had to do with the File Management System for the Government Dept. of Pakistan

Proactive Strategy to deal with Meet the customer’s requirements, Changing
scope, Losing the support of top management Risks

Proactive Strategy to deal with Meet the customer’s requirements, Changing scope, Losing
the support of top management Risks
• Deliver 1st increment in couple of weeks and complete SW in couple of months
• Deliver consistent releases
• Welcome to the new requirements at any stage of the project.
• Prefer Working SW over comprehensive doc.
• Like Descon Info. Sys. contacted with the customer to deliver one working version after
every two weeks and hired four teams and started delivering 4 releases instead of one
release
• Corio Inc. of US delivering one release after every week

Social Risk
• Threaten the collaboration of the team
• Geographical distances and time zones
• Language issues
• Cultural differences
• Communication
• Coordination issues
• Decision making

Reactive Strategy to deal with Geographical distances and time zones, Language issues,
Cultural differences, Communication and Coordination issues Risks

Reactive Strategy to deal with Geographical distances and time zones, Language issues, Cultural differences, Communication
and Coordination issues Risks
• Multisite to single site like Descon Info Sys
• Nokia company moves their programmers to one location at china

Proactive Strategy to deal with Geographical distances and time zones, Language issues,
Cultural differences, Communication and Coordination issues Risks

Proactive Strategy to deal with Geographical distances and time zones, Language issues, Cultural differences, Communication
• Australia multinational company is successfully implementing agile software development with
distributed teams for construction industry.
• It is spending $ 140 K per year to build trust, improve collaboration and synchronization among
distributed teams. The budget includes travelling, hoteling, food and recreations.
• The company has offices in England, France, Germany, Russia and Australia.
• The top management calls its teams at a neutral place in Europe once a year for one week or two weeks
break so they can stay together to improve their trust, coordination & communication, synchronize,
understand the psychology, bridge the social cultural differences, mental level and gel well to work as
one team even in a distributed environment.

Proactive Strategy to deal with Geographical distances and time zones, Language issues, Cultural differences, Communication
• A new software company calls its Project Managers for three months from India,
Pakistan, Bangladesh and Dubai to the US before starting its first project using
distributed teams.
• The CEO spends investment to train from Mike Cohn an agile coach and allow the
project managers to spend time so that there will be significant improvement in
collaboration, respect, trust, coordination & communication, synchronization,
understanding the psychology and mental level, bridging the social cultural
differences, and gel well to work as one team even in a distributed environment

Reactive Strategy to deal with Decision Making Risk

Reactive Strategy to deal with Decision Making Risk
• Microsoft purchased Nokia at the cost of $7.6 billion and wasted almost $
8 billion then get rid of it at the cost $ 3.5 billion .
• Switch distributed teams to collocated teams like Nokia.
• Start delivering in releases like Motorola and let the learning cycle to
happen.

Proactive Strategy to deal with Decision Making Risk

Proactive Strategy to deal with Decision Making Risk
• Pull Strategy
• Collaborative decision making
• Sprint Retrospective
• Sprint Review

Assessment Method to Measure Risks
• Risk Exposure method is used to measure or assess the risks for any
software project.
• The analyst measure the average probability of risk occurrence based on
the cost, schedule and support.
• The constant value for the risks is between 0.7 and 1.0.
• Risk exposure is calculated by multiplying the probability (P) of risk
occurrence and cost impact (C).
• Risk Exposure = P * C

Example 1
• Calculate the risk exposure for a project if 70% of the SW components will be reused from the 60 selected
components. The average code for each new component is 100 LOC at the cost of $ 14/LOC. The risk probability
is 80%.
• Risk Exposure = P * C
• cost to develop a component = Cost/LOC * LOC
Solution
123
Example 1
• Calculate the risk exposure for a project if 70% of the SW components will be reused from the 60 selected
components. The average code for each new component is 100 LOC at the cost of $ 14/LOC. The risk probability
is 80%.
• Risk Exposure = Probability * Cost Impact
Solution
SW components reused = 70%
Total components needed to develop = 60
SW components reused = 0.7 * 60 = 42
New SW components needed = 60 – 42 = 18
Cost/LOC = $ 14 / LOC
Average code of each new component = 100 LOC
cost to develop 18 components = 18 * 14 * 100 = $ 25200
Risk Exposure = 0.8 * 25200 = $ 20160
124
Solution
Risk Exposure = P * C
Probability = 80 %
SW components reused = 70 %
SW cost needs to develop each new component = $ 14 / LOC
Total cost needed to develop 18 components having 100 lines of code = 18
* 14 * 100 = $ 25200
Risk Exposure = 0.8 * 25200 = $ 20160
125
Example 2
• Calculate the risk exposure for a project if 70 % of the SW components will be
reused from the 80 selected components. The average code for each new
component is 150 LOC at the cost of $15/LOC. The risk probability is 75%.
126
Example 2
• Calculate the risk exposure for a project if 70 % of the SW components will be reused from the 80 selected
components. The average code for each new component is 150 LOC at the cost of $15/LOC. The risk
probability is 75%.
Solution
SW cost needs to develop each new component = $15 / LOC
Average code of each new component = 150 LOC
Total Cost to develop 24 components = 24* 15 * 150 = $ 54000
Risk Exposure = 0.75 * 54000 = $ 40500
127
Solution
Risk Exposure = P * C
Probability = 50 %
SW cost needs to develop each new component = $15 / LOC
Total cost needed to develop 18 components having 150 lines of code
Total Cost = 24* 15 * 150 = $ 54000
Risk Exposure = 0.75 * 54000 = $ 40500
128
New
project
Pre - Risk identification

project and assessment
Planning risk Planning and updating risk

management activities management activities
Ongoing
projects Implementing
risk management actions
Identifying and (risk resolution)
assessing new software
risks Monitoring software risk
management activities
Required results
achieved Evaluate Unsatisfactory results
monitoring
results

Ch2-Development and Quality Plan

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ch2-Development and Quality Plan

Uploaded by

Copyright:

Available Formats

Software Quality

Prof. Dr. RJ Qureshi

• Development plan and quality plan objectives

Prof. Dr. R. J. Qureshi, FCIT KAU 7

Prof. Dr. R. J. Qureshi, FCIT KAU 8

Prof. Dr. R. J. Qureshi, FCIT KAU 9

Prof. Dr. R. J. Qureshi, FCIT KAU 10

Prof. Dr. R. J. Qureshi, FCIT KAU 11

Prof. Dr. R. J. Qureshi, FCIT KAU 12

Prof. Dr. R. J. Qureshi, FCIT KAU 13

Prof. Dr. R. J. Qureshi, FCIT KAU 14

Prof. Dr. R. J. Qureshi, FCIT KAU 15

Prof. Dr. R. J. Qureshi, FCIT KAU 16

Prof. Dr. R. J. Qureshi, FCIT KAU 17

Prof. Dr. R. J. Qureshi, FCIT KAU 18

Prof. Dr. R. J. Qureshi, FCIT KAU 19

Prof. Dr. R. J. Qureshi, FCIT KAU 20

Prof. Dr. R. J. Qureshi, FCIT KAU 21

Prof. Dr. R. J. Qureshi, FCIT KAU 22

Prof. Dr. R. J. Qureshi, FCIT KAU 23

Prof. Dr. R. J. Qureshi, FCIT KAU 24

Prof. Dr. R. J. Qureshi, FCIT KAU 26

Prof. Dr. R. J. Qureshi, FCIT KAU 27

Prof. Dr. R. J. Qureshi, FCIT KAU 29

Prof. Dr. R. J. Qureshi, FCIT KAU 30

Prof. Dr. R. J. Qureshi, FCIT KAU 31

Prof. Dr. R. J. Qureshi, FCIT KAU 32

Prof. Dr. R. J. Qureshi, FCIT KAU 33

Prof. Dr. R. J. Qureshi, FCIT KAU 34

Prof. Dr. R. J. Qureshi, FCIT KAU 35

2. Review activities

Completeness is limited to the area where questions are raised by

Prof. Dr. R. J. Qureshi, FCIT KAU 51

Prof. Dr. R. J. Qureshi, FCIT KAU 52

Prof. Dr. R. J. Qureshi, FCIT KAU 53

Prof. Dr. R. J. Qureshi, FCIT KAU 54

Prof. Dr. R. J. Qureshi, FCIT KAU 55

Prof. Dr. R. J. Qureshi, FCIT KAU 56

Prof. Dr. R. J. Qureshi, FCIT KAU 57

Prof. Dr. R. J. Qureshi, FCIT KAU 58

Prof. Dr. R. J. Qureshi, FCIT KAU 59

Prof. Dr. R. J. Qureshi, FCIT KAU 60

Prof. Dr. R. J. Qureshi, FCIT KAU 64

Prof. Dr. R. J. Qureshi, FCIT KAU 65

Prof. Dr. R. J. Qureshi, FCIT KAU 66

Prof. Dr. R. J. Qureshi, FCIT KAU 67

Prof. Dr. R. J. Qureshi, FCIT KAU 68

Prof. Dr. R. J. Qureshi, FCIT KAU 69

Prof. Dr. R. J. Qureshi, FCIT KAU 70

Prof. Dr. R. J. Qureshi, FCIT KAU

Prof. Dr. R. J. Qureshi, FCIT KAU

Prof. Dr. R. J. Qureshi, FCIT KAU

Prof. Dr. R. J. Qureshi, FCIT KAU

Prof. Dr. R. J. Qureshi, FCIT KAU

Prof. Dr. R. J. Qureshi, FCIT KAU

Prof. Dr. R. J. Qureshi, FCIT KAU

Prof. Dr. R. J. Qureshi, FCIT KAU

Prof. Dr. R. J. Qureshi, FCIT KAU

Prof. Dr. R. J. Qureshi, FCIT KAU

Prof. Dr. R. J. Qureshi, FCIT KAU

Prof. Dr. R. J. Qureshi, FCIT KAU

Prof. Dr. R. J. Qureshi, FCIT KAU

Prof. Dr. R. J. Qureshi, FCIT KAU