1

Chapter- 5
A.Software Project Management
01. Software Project Management:
• Software Project Management is to be done in scientific way.
• It involves the knowledge, techniques and tools necessary to manage
the software development.
• It starts before any activity starts.
• The Software Project Management includes basic function such as
scoping, planning, estimating, scheduling, organizing, directing,
coordinating, controlling and closing.
02. Management Spectrum
• The management spectrum describes the management/hierarchy of
people associated with a software project.
• How to make a software project successful.
• Effective Software Project Management focuses on the four P’s:
➢ People
➢ Product
➢ Process
➢ Project
• The order is not arbitrary.
03. The People:
• People factor is very much important in the process of software
development.
• There are following areas for software people like, recruiting,
performance management, training, compensation, career
development, workgroup development, and team/culture development.
• Organizations achieve high levels of maturity in the people management
area.

Downloaded By: www.ravibaba18.blogspot.com

 2

04. Stakeholders
1. Senior managers who define the business issues that often have
significant influence on the project.
2. Project (technical) managers who must plan, motivate, organize,
and control the practitioners who do software work.
3. Practitioners who deliver the technical skills that are necessary to
engineer a product or application.
4. Customers who specify the requirements for the software to be
engineered
5. End-users who interact with the software once it is released for
production use.
05. Project Manager:
The following characteristics defines an effective project manager
• Problem solving: An effective software manager can diagnose the
technical and organizational issues and systematically structure a
solution or motivate other practitioners to apply the solution.
• Managerial Identity: A good manager must take charge of the
project and must have confidence to assume control when
necessary.
• Achievement: To optimize the productivity of a project team, a
manager must reward initiative and accomplishment of the
practitioners.
• Influence and Team Building: An effective project manager must
be able to read people, to understand verbal and non verbal
signals and react to the needs of the people sending these signals.
The manager must remain under control in high stress situation.
06. Software Teams:
How to lead?

Downloaded By: www.ravibaba18.blogspot.com

 3

07. Product
1. Before a project can be planned, the product objectives and scope
should be identified.
2. Objectives identify the overall goals for the product without considering
how these goals will be achieved.
3. Scope identifies the primary data, functions and behaviors that
categorize the product.
4. 4.It identifies cost, risk and realistic break downs of project task.
08. Process
➢ The process model is the plan to be selected depending on following
factors
▪ Customers and developers.
▪ Characteristics of product itself.
▪ Project environment of software team.
➢ Regardless of the size and type of project, there are small number of
framework activities that are applicable to all of them.
➢ There are also umbrella activities like SQA, that occur throughout the
system.
09. Project
1. We conduct planned and controlled software projects for one primary
reason-it is the only known way to manage complexity.
2. A software project manager, who build the product must avoid a set of
common warning signs, understand the critical success factors that lead
to good project management.
3. And develop a common sense approach for planning, monitoring and
controlling the project.
10. Project Scheduling:
➢ In project management, a schedule consist of a list of project terminal
elements, with intended start date and finish date.
➢ The s/w project scheduling distributes estimated efforts across the
planned project period by allocating the effort to particular s/w
engineering tasks.
➢ There are many tasks in a s/w project. The project manager defines all
the task and generates the schedule.
➢ Initially a macroscopic schedule is developed, identifying all major
process framework activities and then the detailed schedule of specific
tasks are identified and scheduled.

Downloaded By: www.ravibaba18.blogspot.com

 4

11. Factors that delay Project Schedule

➢ Although there are many reasons why software is fail, most can be
traced to one or more of the following root causes:
➢ An unrealistic deadline established by someone outside the software
team and forced on managers and practitioners.
➢ Changing customer requirements that are not reflected in schedule
changes.
➢ An honest underestimate of the amount of effort and/or the number of
resources that will be required to do the job.
➢ Predictable and/or unpredictable risks that were not considered when
project commenced.
➢ Technical difficulties that could not have been foreseen in advance.
➢ Human difficulties that could not have been foreseen in advance.
➢ Miscommunication among project staff that results in delays.
➢ A failure by project management to recognize that the project is falling
behind schedule and a lack of action to correct the problem.
12. Principles of Project Scheduling:
➢ Compartmentalization: The project must be compartmentalized into a
number of manageable activities and tasks.
➢ Interdependency: The interdependency of each compartmentalized
activity or task must be determined.
➢ Time allocation: Each task to be scheduled must be allocated some
number of work units (e.g., person‐days of effort).
➢ Effort validation: the project manager must ensure that no more than
the allocated number of people have been scheduled at any given time.
➢ Defined responsibilities: Every task should be assigned to a specific team
member
➢ Defined outcomes: Every task should have a defined outcome.
➢ Vii. Defined milestones: Every task or group of tasks should be
associated with a project milestone.
➢ viii. A milestone is accomplished when one or more work products has
been reviewed for quality and has been approved.

Downloaded By: www.ravibaba18.blogspot.com

 5

13. Project schedule can be tracked by using different scheduling

tools and techniques. Program Evaluation Review Technique
(PERT)
i. PERT, is used in projects that have unpredictable tasks and activities
such as in research and development projects.
ii. It utilizes three estimates of the time to complete the project: the
most probable, the most promising, and the most unfavorable. iii. It
is a probabilistic tool.
iii. iV) It uses several estimates to determine the time completion of the
project and controls activities so that it will be completed faster and
at a lower cost.
14. Critical Path Method (CPM):
➢ CPM is a technique that is used in projects that have predictable
activities and tasks such as in construction projects.
➢ It allows project planners to decide which aspect of the project to
reduce or increase when a trade-off is needed.
➢ It is a deterministic tool and provides an estimate on the cost and
the amount of time to spend in order to complete the project.
➢ It allows planners to control both the time and cost of the project.
15. Difference PERT Vs CPM
• The Program Evaluation and Review Technique (PERT) is suitable for
projects that have unpredictable activities while the Critical Path
Method (CPM) is suitable for projects that have predictable activities.
• CPM uses a single estimate for the time that a project can be completed
while PERT uses three estimates for the time that it can be completed.
• CPM is a deterministic project management tool while PERT is a
probabilistic project management tool.
• CPM allows project management planners to determine which aspect of
the project to sacrifice when a trade-off is needed in order to complete
the project while PERT does not.

Downloaded By: www.ravibaba18.blogspot.com

 6

16. Time-Line Charts or Gantt chart:

• A time-line chart can be developed for the entire project or separate
charts can be developed for each project function or for each individual
working on the project.
• All project tasks (for concept scoping) are listed in the left-hand column.
• The horizontal bars indicate the duration of each task.
• When multiple bars occur at the same time on the calendar, task
concurrency is implied.
• The diamonds indicate milestones.

17. Timeline Charts:

Ta We We We We Wee

Tas
Tas
Tas
Tas
Tas
Tas
Tas
Tas
Tas
Tas
Tas
Tas

Downloaded By: www.ravibaba18.blogspot.com

 7

18. Concept of Task Network:

• A task network, also called an activity network, is a graphic
representation of the task flow for a project.
• It is the mechanism through which task sequence and dependencies are
input to an automated project scheduling tool.
• In its simplest form, the task network depicts major software
engineering tasks.
• The concurrent nature of software engineering activities leads to a
number of important scheduling requirements.
• In addition, the project manager should be aware of those tasks that lie
on the critical path.
• That is, tasks that must be completed on schedule if the project as a
whole is to be completed on schedule.

Downloaded By: www.ravibaba18.blogspot.com

 8

19. Ways of Project Tracking:

• Tracking: - can be accomplished in different ways:
• Conducting periodic project status meetings in which each team
member reports progress and problems.
• Evaluating the results of all reviews conducted throughout the software
engineering process.
• Determining whether formal project milestones have been
accomplished by the scheduled date.
• Comparing actual start-date to planned start-date for each project task.
• Meeting informally with practitioners to obtain their subjective
assessment of progress to date and problems on the horizon.

Project
What can Risks
go
What is the
wrong?
What th damage
will
likelihood?
e be?

Downloaded By: www.ravibaba18.blogspot.com

 9

20. Risk Management:

• Software risk :A software risk is anything which can cause a delay in
software or stops the progress of a system or even terminates the
software project.
• Risk is an expectation of loss, a potential problem that may or may not
occur in the future.
• It is generally caused due to lack of information, control or time.
• A possibility of suffering from loss.
• Loss can be anything, increase in production cost, development of poor
quality software, not being able to complete the project on time.
21. Concept of Proactive and Reactive risk strategies
• Reactive:
1. Majority of the software teams and managers rely on this
approach i.e., nothing is done about risks until something actually
goes wrong.
2. Here when something goes wrong the team files into action and
attempts to correct the problem.
3. Here disaster management or risk management is the choice of
management technique.
• Proactive:
1. Here the primary objective is to avoid risk and to have a contingency
plan in place to handle unavoidable risk in controlled and effective
manner.
2. Here the proactive strategy start in the early of project development.
3. Possibilities and types of risks are identified, they are checked and
arranged as per their priority and impact and prioritized according to
their importance.
4. Then after ranking the risk the main plan of the project team is to
avoid the risk.
22. Types of Software Risks:
• There are two basic types of risks:
1. Generic Risk : Generic Risk is the general purpose possible threat
to every software product.
2. Product Specific Risk: Product Specific risk can be find out only by
those with a clear understanding of the technology going to be
used for that project.

Downloaded By: www.ravibaba18.blogspot.com

 10

• Different Categories of Risks: -

1. Technical Risk: - Threaten the quality and timeliness of the
software to be produced. If technical risk becomes real,
implementation may become difficult or impossible.
2. Business Risk: - Threaten the viability of the software to be built.
Business risk often jeopardizes the product or the project.
3. Market Risk:- Building product that no one wants
4. Strategic Risk: - Building a product that no longer fits into the
business strategy
5. Management Risk: - Building a product that the sale force doesn‘t
understand.
6. Budget Risk: - Losing budgetary or personnel commitment
23. Risk Assessment:
1. Risk assessment involves the evaluation of the risk. We take a
triplet into consideration for understanding risk assessment in
detail.
2. In the triple ri stands for risk, li stands for likelihood that is
probability of the risk, and xi represents impact of the risk.
3. In initial stages of project planning a risk is stated generally. As
the time passes, it is important to divide that risks into sub types
and try to refine it.
24. Risk Management Paradigm:

Downloaded By: www.ravibaba18.blogspot.com

 11

25. Risk identification:

• Risk identification can be defined as systematic attempt to specify or
find out threats to the project plan. Project plan includes estimation,
resource distribution etc.
• With the help of finding well known and predictable risks, the project
manager or leader can take first step to deal with or avoid them.
• These risks need to be controlled or avoided as per its form.
26. Risk Analysis:
• After identification of the risk, risk analysis has to be done.
• The process of risk analysis is analyzing the potential risks with its types
and details.
• The time and efforts needed for risks analysis are huge.
• Analysis starts with what risks are there, their probability and
consequences with their impact on the project.
Risk refinement : In initial stages of project planning a risk is stated generally.
As the time passes it is important to divide that risks into its sub types and try
to refine it.
The way to refine risk is to represent the risk in condition – transition –
consequence i.e. CTC format. The risk can be stated as follows.
<Condition>(Possibly)<Consequence>

27. Risk Prioritization:

• For the purpose of deciding the priority of the risk, process called as risk
prioritization is used.
• When first four columns of the risk table are filled with the risk related
data, the table needs to be sorted by probability and by impact.
• The risk with high probability and high impact risks are located at the top
of the table.
• The risks with low probability go to the bottom of the table after sorting.
• This is called as first order prioritization of the risks.
• The project manager analyses the sorted risk table and defines the
cutoff line.
• It is a horizontal line at some point in the table. The risk above this line
will be given more attention. The risks below the line will be again
reviewed and evaluated.

Downloaded By: www.ravibaba18.blogspot.com

 12

• After this, again second order prioritization of the risk below cut off line
is done.

Downloaded By: www.ravibaba18.blogspot.com

 13

28. RMMM strategy:

• To assist the project team in developing a strategy for dealing with risk.
• An effective strategy must consider three issues:
• risk avoidance, risk monitoring, and risk management and contingency planning.
• If a software team adopts a proactive approach to risk avoidance is always the best
strategy.
• This is achieved by developing a plan for risk mitigation.
29. Risk Mitigation:
• To mitigate this risk, you would develop a strategy for reducing turnover.
• Among the possible steps to be taken are:
➢ Meet with current staff to determine causes for turnover (e.g., poor working
conditions, low pay, competitive job market).
➢ Mitigate those causes that are under your control before the project starts.
➢ Once the project commences, assume turnover will occur and develop techniques
to ensure continuity when people leave.
➢ Organize project teams so that information about each development activity is
widely dispersed.
• Define work product standards and establish mechanisms to be sure that all models
and documents are developed in a timely manner.
• Conduct peer reviews of all work (so that more than one person is ―up to speed).
• Assign a backup staff member for every critical technologist
30. Risk Monitoring:
• As the project proceeds, risk-monitoring activities commence.
• The project manager monitors factors that may provide an indication of whether the
risk is becoming more or less likely.
• In the case of high staff turnover, the general attitude of team members based on
project pressures, the degree to which the team has jelled, interpersonal relationships
among team members, potential problems with compensation and benefits, and the
availability of jobs within the company and outside it are all monitored.

31. Risk Management:

• In addition to monitoring these factors, a project manager should monitor the
effectiveness of risk mitigation steps. Risk management and contingency planning
assumes that mitigation efforts have failed and that the risk has become a reality.
• It is important to note that risk mitigation, monitoring, and management (RMMM)
steps incur additional project cost. For example, spending the time to back-up every
Downloaded By: www.ravibaba18.blogspot.com
 14

critical technologist costs money. Part of risk management, therefore, is to evaluate

when the benefits accrued by the RMMM steps are outweighed by the costs
associated with implementing them.
32. Software Configuration Management (SCM):
• Software Configuration Management (SCM) is also known as change management.
• Changes can occur at any point of a time and that too because of any reason
throughout the life cycle.
• Sources of change can be:-
• Change in a product requirement and business rule because of new business or
market conditions.
• Modification in data,functionality,services etc.
• Reorganization or business growth
• Redefinition of product because of budgetary and scheduling constraints.
33. Elements of software configuration management system:
• Four important elements that should exist when a configuration management system
is developed:
• Component elements -a set of tools coupled within a file management system (e.g., a
database) that enables access to and management of each software configuration
item.
• Process elements -a collection of actions and tasks that define an effective approach
to change management (and related activities) for all constituencies involved in the
management, engineering, and use of computer software.
• Construction elements -a set of tools that automate the construction of software by
ensuring that the proper set of validated components (i.e., the correct version) have
been assembled.
• Human elements-a set of tools and process features (encompassing other CM
elements) used by the software team to implement effective SCM.
34. Need of SCM:
1. Identify change or changes.
2. Keep control on change.
3. For ensuring that change is properly implemented.
4. Make report of changes and present it to the people who have interest in that.
35. Benefits of SCM:
1. Changes can be made with ease throughout software development process.
2. Changes are systematically recorded.
3. Changes are available whenever required for review.
4. Different version of software project can be created and process can be continued
for long time.

Downloaded By: www.ravibaba18.blogspot.com

 15

5. Repository is available in the form of database.

6. Every object's detail can be stored with its attributes.
7. 7.Changes can be traced in forward and backward direction.
8. Customer requirements are fulfilled by accepting changes.9. It is one of the
activities of software quality assurance that supports validation as well as
verification.
9. Avoids lot of confusion because of change in software project.
36. Software Configuration Management Activities/Process:
1. Identification of change:
• To control and manage configuration items, each must be named and managed
using an objectoriented approach
• Basic objects are created by software engineers during analysis, design, coding, or
testing
• Aggregate objects are collections of basic objects and other aggregate objects
• An entity-relationship (E-R) diagram can be used to show the interrelationships
among the objects
2. Version Control:
• Combines procedures and tools to manage the different versions of configuration
objects created during the software process
• An entity is composed of objects at the same revision level
• A variant is a different set of objects at the same revision level and coexists with
other variants
• A new version is defined when major changes have been made to one or more
objects
3. Change Control:
• Change request is submitted and evaluated to assess technical merit and impact
on the other configuration objects and budget
• Change report contains the results of the evaluation
• Change control authority (CCA) makes the final decision on the status and priority
of the change based on the change report.
4. Software Configuration Audit:
• A software configuration audit complements the formal technical review by
assessing a configuration object for characteristics that are generally not
considered during review. The audit asks and answers the questions such as:
• Has the change specified in the ECO been made? Have any additional
modifications been incorporated?
• Has a formal technical review been conducted to assess technical correctness?
37. Status Reporting:
Downloaded By: www.ravibaba18.blogspot.com
 16

Configuration status reporting (sometimes called status accounting) is an SCM task that
answers the following questions:
1. What happened?
2. Who did it?
3. When did it happen?
4. What else will be affected?
38. SCM Repository Functions:
• Data integrity: It ensure consistency among related objects.
• Information sharing: Sharing information among multiple developers, multiple tools,
manages and controls multiuser access to data.
• Tool integration: Establishes data model that can accessed by many software
engineering tools, controls access to data.
• Data integration: Provides data base functions that allow various SCM task to be
performed on one or more Software Configuration Items(information as part of
project) .
• Methodology enforcement: Defines an entity relationship model stored in repository
for software engineering.
• Document standardization: It is a standard approach for creation of software
engineering documents.
39. SCM Tool Features:
• Versioning - control changes to all work products before and after release to
customer.
• Dependency tracking and change management - tracking relationships among
multiple versions of work products to enable efficient changes (link management)
• Requirements tracing – depends on link management, provides the ability to track all
work products that result from a specific requirements specification (forward tracing)
and to identify which requirement generated by any given work product (backward
tracing)
• Configuration management – works closely with link management and versioning
facilities to keep track of a series of configurations representing project milestones or
production releases
• Audit trails - establishes additional information about when, where, why, and by
whom changes were .

Downloaded By: www.ravibaba18.blogspot.com

 17

B. Software Quality Management

40. Basic Quality Concepts
1. Quality(Q)
2. Quality control (QC)
3. Quality assurance (QA)
4. Cost of quality

41. Quality
We define quality as a characteristic or attributes of something. eg. programs include
complexity, number of functions, line of code etc.
Two kinds of quality are:
• Quality of design: characteristic that designers specify for an item. It
encompasses requirements, specifications and design of the system.
• Quality of conformance: the degree to which the design specifications are
followed during manufacturing.
• If implementation follows the design, resulting system meets its requirements
and performance goals, conformance quality will be high.
• User satisfaction= compliant product+ good quality+ delivery within budget and
schedule.
42. Quality control:
• Quality control involves series of inspections, reviews, tests used throughout the
process.
• It includes a feedback loop to the process.
• A key concept of quality control is that all work product have defined,
specifications are compared and feedback loop is essential to minimize the
defects produced.
43. Quality assurance:
• Quality assurance assess the effectiveness and completeness of quality control
activities.

Downloaded By: www.ravibaba18.blogspot.com

 18

• The goal of Quality assurance is to provide management with the data necessary
about product quality, gaining confidence that product quality is meeting its
goal.
• If not its managements responsibility to address the problem and apply the
necessary resources to resolve quality issues.

44. Cost of quality:

It is divided into:
Prevention cost- includes quality planning, formal technical reviews, test equipment
and testing.
Appraisal cost- includes process inspection, equipment calibration, maintenance.
Failure cost-
• Internal failure cost- when we detect a defect in our product prior to shipment. It
includes rework, repair etc.
• External failure cost- Defects found after the product has been shipped to the
customer. It includes resolution, replacement, help line support and warranty
work.
45. Software Quality Assurance-SQA:
• Software quality assurance is composed of a variety of tasks associated with two
different aspects the software engineers who do technical work and an SQA
group that has responsibility for QA planning, oversight, record keeping, analysis,
and reporting.
• Software engineers address quality (and perform quality assurance and quality
control activities) by applying solid technical methods and measures, conducting
formal technical reviews, and performing well-planned software testing.
46. Activities of SQA:
1) Prepare an SQA plan for a project:
The plan is developed during project planning and is reviewed by all interested parties.
• The plan identifies
> evaluations to be performed
> audits and reviews to be performed
> standards that are applicable to the project

Downloaded By: www.ravibaba18.blogspot.com

 19

> procedures for error reporting and tracking

> documents to be produced by the SQA group
> amount of feedback provided to the software project team.
2) Participate in the development of the project’s software process description:
The software team selects a process for the work to be performed.
The SQA group reviews the process description for compliance with organizational
policy, internal
software standards, externally imposed standards (e.g., ISO-9001), and other parts of
the software project plan.
3) Review software engineering activities to verify compliance with the defined
software process.
• The SQA group identifies, documents, and tracks deviations from the process and
verifies that corrections have been made.
4) Audits are designed for s/w work products to verify compliance with those defined
as a part of process.
• Verify that corrections have been made and periodically reports the results of its
work to the project manager.
5)Ensure that deviations in software work and work products are documented and
handled according to a documented procedure. Deviations may be encountered in
the project plan, process description, applicable standards, or technical work
products.
6)Records any noncompliance and reports to senior management. Noncompliance
items are tracked until they are resolved.
47. Concept of Statistical SQA:
Statistical SQA reflects growing trend throughout industry to become more
quantitative about quality.
1. Information about s/w defects is collected and categorized.
2. Tracking fundamental causes of defects. (design error, violation of standard,
poor communication, inaccurate documentation)
3. use of pareto principle. (80% of defects can be traced to 20%of all possible
causes)
4. Once the causes have been identified, move to correct the problem that have
caused the defects.

Downloaded By: www.ravibaba18.blogspot.com

 20

48. Quality Evaluation Standards:

01. Six Sigma for s/w engineering.
02. ISO:9000 for software
01. Six sigma for software:
• Six Sigma is the most widely used strategy for statistical quality assurance in
industry today. Originally popularized by Motorola in the 1980s.
• The Six Sigma strategy - is a rigorous and disciplined methodology that uses data
and statistical analysis to measure and improve a company's operational
performance by identifying and eliminating defects in manufacturing and service-
related processes.
• The term Six Sigma is derived from six standard deviations instances (defects) per
million occurrences implying an extremely highquality standard.

49. DMAIC and DMADV:

Six sigma methodology defines three core steps:
These core and additional steps are sometimes referred to as the DMAIC (Define,
Measure, Analyze, Improve, and Control) method.
• Define customer requirements and deliverables and project goals via well-defined
methods of customer communication.
• Measure the existing process and its output to determine current quality
performance (collect defect metrics).
• Analyze defect metrics and determine the vital few causes.
• If an existing s/w process is in place, but improvement is required, six sigma
suggest two additional steps:-
• Improve the process by eliminating the root causes of defects.
• Control the process to ensure that future work does not reintroduce the causes of
defects.
• If an organization is developing a software process (rather than improving an
existing process), the steps are as follows:-
• Design the process to avoid the root causes of defects and to meet customer
requirement.

Downloaded By: www.ravibaba18.blogspot.com

 21

• Verify that the process model will avoid defects and meet customer requirement.
• The variation is sometimes called as DMADV (Define, Measure, Analyze, Design
and Verify method.)
50. ISO 9000 for software:
• International set of standards for quality management.
• Quality standards and procedures must be documented in an organizational
quality manual
• An external body is often used to certify that the quality manual conforms to ISO
9000 standards

Downloaded By: www.ravibaba18.blogspot.com

 22

51. ISO principles/standards with benefits:

1. Customer focus
2. Leadership
3. Involvement of People.
4. Process approach5. System approach 6. Continual improvement.
5. Factual approach to decision making
6. Mutually beneficial supplier relationships.
52. CMMI
• Definition- Capability Maturity Model Integration (CMMI) is a process
improvement approach that helps organizations improves their performance.
• CMMI (Capability Maturity Model Integration) is a proven industry framework
to improve product quality and development efficiency for both hardware and
software. Objectives of CMMI:
Specific Objectives:
> Establish Estimates
Downloaded By: www.ravibaba18.blogspot.com
 23

> Develop a Project Plan

> Obtain Commitment to the Plan
Generic Objectives:
> Achieve Specific Goals
> Institutionalize a Managed Process
>Institutionalize a Defined Process
> Institutionalize a Quantitatively Managed
Process
>Institutionalize an Optimizing Process
53. CMMI maturity levels:
Level 1: Initial.: The software process is characterized as adhoc and occasionally
even chaotic. Few processes are defined, and success depends on individual effort.
Level 2: Repeatable.: Basic project management processes are established to track
cost, schedule, and functionality. The necessary process discipline is in place to
repeat earlier successes on projects with similar applications.
Level 3: Defined.: The software process for both management and engineering
activities is documented, standardized, and integrated into an organization wide
software process. All projects use a documented and approved version of the
organization's process for developing and supporting software. This level includes all
characteristics defined for level2
Level 4: Managed.: Detailed measures of the software process and product quality
are collected. Both the software process and products are quantitatively understood
and controlled using detailed measures. This level includes all characteristics defined
for level3
Level 5: Optimizing.: Continuous process improvement is enabled by quantitative
feedback from the process and from testing innovative ideas and technologies. This
level includes all characteristics defined for level 4.

Downloaded By: www.ravibaba18.blogspot.com

 24

Downloaded By: www.ravibaba18.blogspot.com

 25

54. McCall’s Quality factors:

The factors that affect S/W quality can be categorized in two broad
groups:
• Factors that can be directly measured (defects uncovered during
testing)
• Factors that can be measured only indirectly (Usability and
maintainability)
• The S/W quality factors shown above focus on three important
aspects of a S/W product:
1. Its operational characteristics
2. Its ability to undergo change
3. Its adaptability to new environments

Downloaded By: www.ravibaba18.blogspot.com

 26

55. The various factors of quality are:

(1) The extent to which a program satisfies its specs and fulfills the
customers mission objectives.
(2) Reliability: The extent to which a program can be expected to perform
its intended function with required precision.
(3) Efficiency: The amount of computing resources and code required to
perform is function.
(4) Integrity: The extent to which access to S/W or data by unauthorized
persons can be controlled.
(5) Usability: The effort required to learn, operate, prepare input for, and
interpret output of a program.
(6) Maintainability: The effort required to locate and fix errors in a
program.
(7) Flexibility: The effort required to modify an operational program.
(8) Testability: The effort required to test a program to ensure that it
performs its intended function.
(9) Portability: The effort required to transfer the program from one
hardware and/or software system environment to another.
(10) Re usability: The extent to which a program can be reused in
other applications- related to the packaging and scope f the functions
that the program performs.
(11) Interoperability: The effort required to couple one system to
another.

Downloaded By: www.ravibaba18.blogspot.com