We have been working very hard since 2009 to facilitate in your learning Read More. We can't keep up without your support. Donate Now.


+ Link For Assignments, GDBs & Online Quizzes Solution


+ Link For Past Papers, Solved MCQs, Short Notes & More

“Only Quality control metrics for effective project management is sufficient to accommodate the need for efficient software development”. Justify this statement, either in favor or against with solid and precise reason.

+ http://bit.ly/vucodes (Link for Assignments, GDBs & Online Quizzes Solution)

+ http://bit.ly/papersvu (Link for Past Papers, Solved MCQs, Short Notes & More)

+ Click Here to Search (Looking For something at vustudents.ning.com?)

+ Click Here To Join (Our facebook study Group)

Views: 577

Replies to This Discussion

plz discuss here

no discussion yet ?????? 

I don't think that only quality control metrics are sufficient for efficient software development.

First of all we have to plan the overall strategy to develop a software, experienced team members, then during the development phase we'll see what is the cost effect of improving the quality, how much time it will take to implement a level of quality.

koe hai kya to discuss the about GDB

 Awais Arslan

you are right


Metrics are analyzed and they provide a dashboard to the management on the overall health of the process, project and product. Generally, the validation of the metrics is a continuous process spanning multiple projects. The kind of metrics employed generally account for whether the quality requirements have been achieved or are likely to be achieved during the software development process. As a quality assurance process, a metric is needed to be revalidated every time it is used.In general, for most software quality assurance systems the common software metrics that are checked for improvement are the Source lines of code, cyclical complexity of the code, Function point analysis, bugs per line of code, code coverage, number of classes and interfaces, cohesion and coupling between the modules etc. so i think Quality control metrics are effective for project management or sufficient to accommodate the need for efficient software development.

If you're responsible for managing operations, the following scenario won't be new to you: You have a meeting with the executive team tomorrow and you are running around to get information on metrics for your presentation. The next day, you're expected to report on the overall performance of your plant to several department heads.

manufacturing metricsCorporate executives are often inundated with data, making it difficult to pull out relevant insights. While most metrics on the executive dashboard are finance-related, executives in manufacturing organizations need visibility into operational metrics to gain more control over their business. They are looking to understand the impact operational performance has on their organization's goals.

The impact quality has on a company’s success is often well understood. However, companies have traditionally struggled to establish metrics that can easily represent the effectiveness of quality in the organization. The following metrics will help you provide an accurate picture to present to the executive team. It is important to understand that depending on the type of industry, geography, company size, etc., there might be additional metrics that you want to add to this list.

Metric 1: Cost of Quality

The definition of this metric is very similar to the way it sounds. It measures the cost incurred by an organization to manufacture a quality product. Further narrowing things down, these costs come from two main categories: cost of good quality and cost of poor quality. A detailed description of the metric and insights on how to measure it are available in our previous posts: Cost of Quality Definition and  Enterprise Quality Management Software - Part 2 Cost of Quality, and Cost of Poor Quality Definition.

Metric 2: Overall Equipment Effectiveness (OEE)

Quality impacts many different parts of the business, so it is critical to establish a comprehensive metric that provides visibility into the most important areas of operations. The answer to this lies within calculating the OEE formula:

OEE = Availability x Efficiency x Quality

First, overall equipment effectiveness measures how often an asset is available when it should be producing product for a customer. Second, when an asset is producing product for a customer, OEE measures how close the asset is producing to its theoretical maximum. And third, for those products that are produced, OEE measures the percentage that are produced within quality specifications.

Metric 3: Percentage of Products in Compliance

This is a critical metric in regulated industries such as medical devices, pharmaceutical, biotechnology, and food & beverages. Even in industries such as automotive and A&D, this metric plays a crucial role. It measures the percentage of products that are in compliance with government regulations and internal guidelines. It is often challenging for companies to keep employees up to date with the changing compliance landscape.

Additionally, compliance areas such as REACH, RoHS, WEEE impact companies differently based on the industry, which adds to the complexity of selling in a global market. This metric measures how effective your organization is in being compliant with local, national, or global policies that impact your business.  

Metric 4: On time and Complete Shipments

Managing the quality of the product should not be at the expense of delaying final delivery from the plant floor. Even though on time and complete shipments as a metric sounds fairly easy to understand, there are many different ways companies measure this metric. LNS Research defines this metric as percentage of products delivered on time and complete with no errors or re-promise dates.

Metric 5: New Products Introduction (NPI)

NPI as a metric is defined as a percentage of new products introduced in the market that hit time, volume, and quality targets. New products are often introduced in the market and are a source of competitive advantage in industries such as automotive and consumer electronics. Profit growth depends not only on how successful your organization is at introducing new products into the market, but also how effective your organization is at hitting NPI targets.

Much attention has been devoted to questions associated with the measurement of
quality. How do we determine the extent to which a software product contains this
vague attribute called quality? When is the quality of a software product high and
when is it low?
One of the more recent developments in quality assurance (not only for software)
is the realization that quality is not a binary attribute that either exists or does not
exist. Kaposi and Myers (1990), in a paper on measurement-based quality
assurance, have stated their belief that 'the quality assurance of products and
processes of software engineering must be based on measurement 7. The earlier
the measurement of quality begins, the earlier problems will be located. Cohen et
al. (1986), in addressing the cost of removing errors during the early phases of
software development, proclaim the existence of the famous exponential law8.

The quality of two products can be compared, and it is perfectly acceptable to
claim that the quality of one product is greater than the quality of another. It is
also acceptable to measure quality and deduce the extent of expected faults based
on the measured result.
The set of measurable values associated with the quality of a product is referred to
as the product's quality metrics. Software quality metrics can be used to determine
the extent to which a software product meets its requirements. The use of quality
metrics increases the objectivity of the evaluation of product quality. Human
evaluation of quality is subjective, and is therefore a possible source of
disagreement, particularly between customer and developer.
A number of methods for establishing software quality metrics are currently being
developed, though no generally accepted standard has yet emerged. For example,
an initial draft of IEEE Std-1061 (1990) includes a detailed discussion of software
quality metrics in general, including a suggested methodology for applying
metrics, and many examples and guidelines. Quality metrics, once defined, do
indeed increase objectivity, but the definition itself is not necessarily objective
and greatly depends upon the needs of the organization that produces the
The basic approach for applying software quality metrics requires:
• The identification of all required software quality attributes. This is usually
derived from the software requirements specification.
• Determinations of measurable values to be associated with each quality
attribute. A description of the method by which each measurable value will be
• A procedure for documenting the results of measuring the quality of the
software product.
A set of many values can be used to determine the overall quality of a software
product. However, a single measure can be created to represent the overall quality
of the software product. This requires:
• A weighted method for combining the measured quality attributes into a
single measure of quality for the product.
Some examples of software metrics are:
Reliability: The percentage of time that the system is successfully operational
(e.g. 23 out of 24 hours produces: 100 x (23/24) percent)
Recoverability: The amount of time it takes for the system to recover after failure
(e.g. 1hour to reload from backups and 30 minutes to reinitialize the system)
Software Project Management (CS615)
© Copyright Virtual University of Pakistan
User-friendliness: The amount of training time needed for a new user
The measurement of software quality should not be performed only at the end of a
project. The degree of quality should be measured at regular intervals during
development. Thus, any major reduction in the overall measure of quality should
act as a warning for the project manager that collective action is required. High
quality at the end of the project is achieved by assuring high quality throughout
the development of the project.
10.9 Some general guidelines
The basic software quality assurance activities cover the review and approval of
the development methodology, the software and documentation, and the
supervision and approval of testing. Other SQA activities, such as the supervision
of reviews, the selection and approval of development tools, or the administration
of configuration control, depend on the way SQA is adapted to a specific project.
The size of the project is usually the determining factor. The following guidelines
discuss some of the parameters to be considered for different types of project
when planning SQA.
• In small projects, many SQA activities can be performed by the project
manager. This includes the organization and supervision of reviews and
audits, the evaluation and selection of development tools, and the selection
and application of standards.
• Test procedures and testing are always best when conducted by a separate
independent team (discussed later). The decision on whether supervision of
testing activities can be assigned to SQA depends on many factors, including
the independence of the SQA team, the size of the project and the 'complexity
of the project.
• When testing is performed by an independent test team, SQAS involvement
will be minimal. In most other cases it will be the responsibility of the SQA
team to plan and supervise the testing of the system.
• As a general guideline, it is usually undesirable for SQA to be performed by a
member of the development team. However, small projects often cannot
justify the cost of a dedicated SQA engineer. This problem can be solved by
having a single SQA engineer responsible for two or three small projects (with
each project funding its share of the SQA services).
One additional guideline is based on the conclusions of Wesselius and Ververs
(1990) for the application of effective quality control:

• The ability to control software quality is directly linked to the quality of the
software requirements specification. Quality control requires the unambiguous
specification of as many of the required characteristics of the software product
as possible.

Guys this's the solution of CS615 GDB, I wish you Best of Luck


thanks asif muhammad

thank uuuu


Looking For Something? Search Here

Today Top Members 


This is a member-supported website. Your contribution is greatly appreciated!

© 2020   Created by +M.Tariq Malik.   Powered by

Promote Us  |  Report an Issue  |  Privacy Policy  |  Terms of Service