Talk:Software quality

From Wikipedia, the free encyclopedia
Jump to: navigation, search

I just read the presentation that is cited as [4] in the article: "Industry data demonstrate that poor application structural quality in core business applications (such as Enterprise Resource Planning (ERP), Customer Relationship Management (CRM) or large transaction processing systems in financial services) results in cost and schedule overruns and creates waste in the form of rework (up to 45% of development time in some organizations [4])". This presentation does not support this claim and also does not included references to scientific papers that would support it. I think this sentence should be removed. Michel — Preceding unsigned comment added by (talk) 14:55, 15 October 2011 (UTC)

Removed reference[edit]

I removed this reference as it broke the references header and I could not discern what it meant to cite. If anyone has a clue or has this reference, please do re-insert it appropriately.

"O. Alshathry, H. Janicke, Optimizing Software Quality Assurance, Computer Software and Applications Conference Workshops (COMPSACW), 2010 IEEE 34th Annual, pp.87 - 92"

Sangrolu (talk) 19:31, 8 March 2011 (UTC)

Software Quality in 1-2 Sentences[edit]

This article could benefit tremendously from a concise definition of Software Quality (no easy task). Need help! Putting my first go at it. Please revise, and discuss. Dalvizu 02:07, 18 August 2007 (UTC)

I definitely agree with that: in my humble opinion, this article represents a partial perspective on quality. Although the CISQ standard looks fine (won't debate here about its relevance), it should be highlighted that many others have addressed this: garvin, kitchenham and pfleeger, among others. I'll try to give some common definitions for better objectivity, with references. Don't hesitate to argue on this. Boris Baldassari (Talk) 09:44, 5 February 2013 (UTC)

Conformance to requirements[edit]

It seems a little contradictory to talk of software quality being defined by conformance to requirements when one of the biggest problems of software development is the difficulty in specifying clear requirements.

Defining software quality this way also implies a concious planned development from formal specifications. It ignores organic software development methods such as agile or open source; most people would agree that Linux is a high-quality piece of code but what are the original requirements that Linus Torvalds was supposed to comply to? Does anyone know or care if those were met?

Software is, at least to some degree, an art. "Well written" code is entirely a human concept since the average computer doesn't seem to care. Now art, by its very nature, isn't about meeting pre-defined requirements; it is said that the merchant who commissioned the Mona Lisa refused it because it didn't look enough like his wife.

-- Shanky

Couldn't agree more. As a expert in the field, it seems to me that Software Quality is not accurately described solely conformance to standards. This article currently only represents a single (and somehwat dogmatic) point of view. Please, BOLDLY edit this article. I certainly intend to. Mmcdougall 18:49, 8 Jun 2005 (UTC)

I think software quality is defined not only by its technical aspects, but also by the user experience. Many software packages have great internals, but rather bad GUI. I added a section on usability (quality in the eye of the beholder). It needs a lot more work. Philippe 12:36, 4 May 2006 (UTC)

Agreed whole heartedly. There may be a lot of praise on Linux. But, most are from the technical people. It is a fact. This means it meets the technical users' expectation. However, it is also a fact that Linux is not very successful in taking up by non-technical users even it is free and available in so many forms (distributions). This also means that it does not meet the end users' expectation. Therefore, whether it is a quality product is actually depend on who is the user. (talk) 18:44, 2 April 2010 (UTC)

Quality Factors and the Human Factor[edit]

I think the word Quality points at a collecion of things. Herein is one of the aspects I think makes it subjective. We all seem to have our own personal collection of things we point at when we talk about Quality. Moreover, each project seems to have their own collective rendition of what Quality software means to them: what they find acceptable. So, any discussion of Quality ignoring this simple reality seems doomed to devolve in to sounding dogmatic and definitive. I never forget that software engineering is not just a technical task, but a human one as well (art?).

As for Usability and Reliability and GUI issues, I am inclined to agree with Bertrand Meyer how there are Internal and External Quality Factors. Internal pointing at those quality factors experienced by those who design, code and test and External pointing towards those experienced by any level of end user who sees and interacts with whatever interface the software presents (graphical or otherwise).

The best way to continue the discussion is by either clearer language about what a Quality Factor is and what it looks like in real code in a real project. Also within the human context of agreement as well.

Internal Quality Factor: Understandibility. What does it point to? Perhaps a list will help fill in the meaning:

1. Coding Standards (technical and style) --> Directly impacts the "quality" of the code text itself. Agreed upon coding and style standards makes the code text more understandable. 2. Design Patterns --> Another direct contributor to code "quality". The code is more understandable when predictable design patterns are used in the code text. 3. UML Tools --> These have a first step of having indirect impact on the understandibility of the code, but as they move towards actual production code text, they take on more impact. 4. Extreme or Agile methods --> It has been shown more than once, how the methods of agile and extreme programming improve the readibility of the code text (just one aspect of a larger affect).

External Quality Factory: Understandibility. I can see how quality factors cannot help but carry up fom the code text to the user interface itself. So, whenever I think about and deal with quality factors, I know that whatever I do in the code text is going to directly or indirectly impact the user interface at some point.

1. GUI Standards --> Such as those that Microsoft uses for GUI design standards. 1. UML Tools --> One of the aspects of UML is to bring standard style, agreement, consistency and such things to the GUI. I think this has a direct impact on the User Understandibility of the software.

When I think about the example notions above, what I see is how agreed upon standards for how to design, write and test software, I see how the word quality quickly moves from the essoteric and subjective to the very concrete and real. What remains always a gray area is what people agree to and find helpful in any situation.

More on Software Quality[edit]

Aren't there tools or techniques that provide some sort of measure of quality? The first that come to my mind is "code coverage", which is the combination of test cases and evaluation that shows that the test cases executes a high percentange of source code. The test case and source code combineed determine quality in its ability to weed out defects, particularly if the test case includes "unexpected" data sets.-- (talk) 02:23, 3 March 2011 (UTC)

Other measures of quality include evaluation of the documentation of the code, whether it be as simple as the number of comment lines per source line, or procedurally by other external methods (such as existance and review of user manuals, how-to-test documentation, independent code reviews, sustainability requirements, or other methods). Much has been written about this, but time-to-market seems to drive activities that result in shortcuts to quality. Fundamentally - quality takes time to create, but pays dividends in the long run. -- (talk) 02:23, 3 March 2011 (UTC)

Conformance to standards?[edit]

I think conformance to standards is necessary to improve software quality, especially what regards the Internet. Paulo Oliveira 11:55, 6 Jun 2005 (UTC)

I agree that quality is a vague term, but disappoint to hear that requirements conformance should not be used to measure software quality. A product could be technically brilliant, but failing to meet users expectation can never earn it the recognition of quality. For software development, requirements are the expression of users expectation. -- Francis Law 02:44, 12 February 2007 (UTC)
Requirements can be wrong or unattainable. Often during coding there are things that can't be done as requested or plain wrong. This leads to a requirement refinement. At the end requirements should be strong enough and the software should be capable of showing conformance. If a technically brilliant product doesn't meet the user expectation then either one (or both) is wrong.Javier Ortiz Bultrón 01:01, 20 July 2010 (UTC)
This argument is between Quality (in terms of actually meeting customer expectations, e.g. Validation - was the right product built? ) and quality of requirements (was it specified correctly, or Verification - was it built "right"). This is basic Systems Engineering discipline. The objective, of course, is to satisfy the customer needs (validation) which is sometimes subjective. Often challenging, which is why documentation, reviews, and good communications remain important in the management of complex systems. -- (talk) 02:35, 3 March 2011 (UTC)

Merge with Software reliability (done) Software assurance?[edit]

Someone added a suggestion to merge this article with Software reliability, but there doesn't seem to be any discussion of exactly why. I'm going to speculate that "quality" is somehow a more expansive topic than "reliability"—I don't have any argument with that. Just wanted to bring it up here. I haven't even read this page; it looks to sparse to even bother. What's with the fascination with lists of other pages in the software-related pages? (While I'm here, the Computer software page itself needs more help. Why try to define so many software sub-topics when the primary page is not very good? Brent 01:18, 18 October 2005 (UTC)

I agree with User:Conan's merge suggestion. Software testing is great, but Software reliability and Software quality are overlapping ideas with each other. Perhaps Software quality and reliability is better? FWIW, Computer software looks better now than SR and SQ. -- Perfecto Canada 21:03, 5 November 2005 (UTC)
I disagree. Reliability is only one aspect of quality, there is too much to say in only one article.--Thv 08:42, 7 November 2005 (UTC)
I agree with Thv that reliability is only one aspect of software quality. However, I think this article needs more effort to become more valuable. I would suggest to start with planning the flow of thought before filling in content and information. Then, associate it with other topic, such as Quality, Quality Standards, etc. -- Francis Law 13:10, 12 February 2007 (UTC)
I agree with former contributors that Reliability is one of the aspects. As for structuring the content of this page I would suggest to follow one of the "public domain" software quality reference models, ie. McCall [1977], Boehm [1978] and ISO 9126/1993. Furthermore I would advice to simply "define "Software Quality" as "Software meeting requirements" and would focus the discussion on structuring and defining these requirements, and the process of (automated) validation. --Rob Snelders (talk) 15:33, 19 February 2010 (UTC)
I agree that there is a distinction between Software Quality and Software Reliability. Reliability is only a subset of Quality. Quality is a combination of reliability, suitability, availability, maintainabilty, performance, cost effectiveness, and other factors. E.g. quality tends to cover all the "-illities" of a system. (Yes, I probably missed some, so please feel free to add...) -- (talk) 02:44, 3 March 2011 (UTC)
I disagree. Software Assurance is a big trend supported by the US DHS and DoD, which focus almost exclusively on security and vulnerabilities, which is a very restricted notion by definition. For example, poor efficiency (performance, ressources comsumption..etc ) or poor maintainability of an IT system, or of an embedded system, CANNOT be classified as “vulnerabilities”. This would have no sense. Security is a subset of software quality, and as such, it may make sense to integrate Software Assurance into Software Quality. An alternative would be to redefine the Software Assurance definition, to make it broader. In all cases, the structure of the resulting page would have to be very clear. DamienPo (talk) 20:08, 11 February 2013 (UTC)

I would like to add a vote to leave Software assurance as a separate page. As others note, Software Assurance is a more specific term; not as broadly used as Software Quality. As an example, I work for a major medical device manufacturer and we do not use the term Software Assurance, although we perform many activities that other organizations would specifically label Software Assurance. Our use of the term, Software Quality, however, is closely aligned with much of the content of the Software quality page, its references, and with industry use in general. Casualhacker (talk) 18:51, 8 May 2013 (UTC)

Application- vs. infrastructure software[edit]

It may be a good idea to discuss the topic from the above two perspectives. Just to kick off some topics:

  • Infrastructure software is designed to be stable eg. for the long run
  • Application software is usually dealing with constant changes in requirements, the design may not be so stable
  • High availabilty, scalability (technical features in general) usually implemented at the infrastructure level. Application development should not directly deal with them.
  • Meanwhile UI requirements against application softwares are generally higher then against infrastructure softwares...

Copy violation?[edit]

The recent additions to this article by appear to be directly copied from some workshop notes, and as such are probably copyright, besides being in an unencyclopaedic tone. Colonies Chris 15:37, 10 August 2006 (UTC)

Yeah, I agree. Right now it doesn't look like an encyclopaedic article at all. I'd suggest removing those edits entirely or heavily modifying them ASAP. Sarg 16:27, 18 August 2006 (UTC)
Restored most of section 3 from the history.

Not a Definition Problem[edit]

Ask youselves, quality with respect to what?

Quality is measured. You're (maybe) correct, stating that LINUX evolved from something without clear objectives. But by no means, this translates to saying that you measure LINUX quality against that. Got it?

I'll clarify. Keeping with the same example, Linux is good because Linux does this and does that. Fine. In saying so, you defined your quality scale and you claim Linux is good with respect to that. Period.

The best picture, of course, is to define the requirements in advance. This is one of the challenges of SW engineering.

Look carefully; you'll see that the definition, as "conformance to requirements", is correct. The same problem arises in other engineering areas involving complex products. So we shift the discussion from the definition, to the challenge of ensuring quality of the final product.

The definition is also in agreement with what was done when we wrote ISO/IEC 9126 and, lately, ISO/IEC 25000 (I was part of it). 16:13, 13 November 2006 (UTC)

Quality, what quality?[edit]

This discussion has been going on in business and University environments for the past 30 years so I don't expect to end soon.I think the present definition covers the technical aspects of software quality fairly well, and covers the software reliability quite well. However, there are other aspects of quality not covered at all, primarily the business side.

In 2000 ISO has gone back and redefined Software Quality as "...meeting or exceeding customer expectations...". This was due, in part, because of the dot-bombs making software with no customers or business value.

In engineering fields product always has to meet technical and business constraints, including cost, time to market, and return on investment. One question SQA asks is "Did we build the product right?", (verification), the other is "Did we build the right product?" (validation). If software was truely an engineering discipline, Universities would apply the same curriculum standards that apply to all other engineering fields and software engineers would know how to balance and meet all technical and business requirements and constraints. The top 3 tech companies are software companies, they do not give their product away for free, and seem to have done this quite well.

This discussion has been going on in business and University environments for the past 30 years so I don't expect to end soon.

Alhenry2006 20:07, 31 March 2007 (UTC)Al


This page has been flagged for cleanup for almost two years. Let's see if we can fix it. A quick glance makes me think it needs inline citations, as well as improvement in the prose. Comments from others? Arthurrh (talk) 23:22, 13 December 2007 (UTC)

This is a very difficult subject. It is an age old subject, but not very well developed in the software/IT industry. I am not an expert in the area, but willing to give it a go. However, I am not sure what should I do before editing it. Do I need to obtain consent from anybody or reaching an agreement before I start updating it? I think it needs a thorough thought and major restructure. Francis Law (talk) 01:14, 4 April 2010 (UTC)

What is quality?[edit]

I am not an expert in software quality. However, I have been using the following definition for my works.

Quality products are products that meet or exceed expected quality.

Software is a product that is developed to solve some problems. Therefore, it suits this definition. Some people may argue that quality could be defined differently, but I find this is what we really mean by "quality". However, this definition put every business in a spin quickly because:

  1. Expected quality is unlimited and ever changing;
  2. Expected quality is subjective and not measurable;
  3. Exceed expected quality means over production which is not acceptable to most business.

This explain why most people complain on quality of products including software while software companies struggle to achieve a reputation in quality. To be practical, the definition is adjusted into:

Quality products are products that meet agreed quality.

Again, this definition does not resolve issue #2 above. To resolve this issue, we have to turn ambiguous "quality" into something verifiable, i.e. requirements. To ensure quality of requirements, we could adopt Software Quality Model such as that described in ISO/IEC 9126.

Some people may argue software could be developed without requirements. I think this only an excuse. No matter what, software is developed to do something. That "something" is the requirements to the software being developed. Declaring no requirements is only an excuse to avoid managing requirements. This make the software being developed a failure already.

Francis Law (talk) 06:11, 4 January 2008 (UTC)

I'm by no means a quality expert, but it seems the page reads very dryly. Obviously, there exists the quality aspect of code to requirements, would the page benefit from lower level information, eg software quality metrics, links to any unit testing, code coverage pages?

Sorry if I'm out of line, new here :p

Minkythecat (talk) 16:58, 5 March 2008 (UTC)

The message may be dry but I think it touches the basic truth. Minky's message probably misses the main point of the message. I'm not talking about the importance of requirement or coding. I'm defining what is quality with respect to software product. Quality cannot be achieved by a single factor or a single element. It is the accumulated results of many factors.

Most discussion focus in areas people working with. However, it seldom try to view the quality from the user perspective. User is the ultimate judge on the quality of product. How often does a technically brilliant product fails to please users? Usually, developer complaint that users can't understand the beauty of the product. I'm no exception and I did that in the past. However, I start to realize the cause is most likely the product fails to meet users' expectation. Therefore, the technically brilliant product becomes a technically brilliant rubbish to the users.

This sounds very harsh. But, I truly believe in this.

Francis Law (talk) 09:38, 2 April 2010 (UTC)

Where is Software Reliability Modeling?[edit]

Some entry should discuss operational profiles, reliability allocation, the use of software reliability models (e.g., Shooman, Jelinski-Moranda, Goel-Okumoto, Musa, Moranda Geometric, Musa-Okumoto, various S-shaped models) to monitor testing, the use of this approach on each spiral in spiral development to support Statistical Process Control, etc. (talk) 11:34, 1 July 2008 (UTC)

Software security has no place in this article[edit]

The software security should not be included in this article: it is a completely separate topic. How does this:

Does the software protect itself and its data against unauthorized access and use? Does it allow its operator to enforce security policies? Are security mechanisms appropriate, adequate and correctly implemented? Can the software withstand attacks that can be anticipated in its intended environment? Is the software free of errors that would make it possible to circumvent its security mechanisms?

relate to software quality? I am currently writing an open source program for mathematical computations. As such, it has no security features whatsover. What does "unauthorised access" mean to a computational open source program? Please, move software security to a software security article, where it belongs. (talk) 12:56, 13 June 2009 (UTC)

You are mistaken. Security is an important quality factor of software. It is not a feature and it is not optional. You are right that many of the features listed will not be relevant to many programs. Not all questions you list are relevant to your program, but the last one is. Rp (talk) 12:29, 29 October 2009 (UTC)
Security is certainly an important factor that contributes to the overall quality. It is one of the sub-characteristics identified in the Software Quality Model ISO/IEC 9126. The model can help to achieve quality in product. However, a product may have considered all characteristics and sub-characteristics in the model. But, it can still be labelled as poor quality if it cannot meet it user's expectation. Therefore, the model should be a tool to help materialize the user's expectation into atomic and testable requirements. Francis Law (talk) 23:45, 3 April 2010 (UTC)

Who Wants to Help?[edit]

I am currently studying Software Engineering and am researching Measuring Software Quality. I will begin editing this page soon. I will review the comments posted in this discussion and try to act on them as best as possible. Dfletter (talk) 00:06, 13 February 2009 (UTC)

I have just flagged my interests to update this page before I notice your post. How's your update? I think this page requires a well thought out plot and a major restructure. Francis Law (talk) 02:08, 4 April 2010 (UTC)
software quality is indeed an age old subject! I am retired now but I started dealing with these issues something like 35 years ago. I even wrote guidelines for Fortran developers in those days. Anyhow this is not at all well developed for business systems on which so much relies and I am willing to contribute but I am not sure how to proceed. I would like to add a specific section describing what critical architecture issues and source code quality checks to ensure reliability, performance efficiency, and maintainability of IT business applications. Please adviseFrancois grassot (talk) 13:20, 18 August 2010 (UTC)

Proposal for contribution[edit]

Software Quality has been a subject of great interest and importance to me -- I would like to help contribute to the discussion and the content of the page. Mbarberony (talk) 00:03, 18 June 2011 (UTC).

I have been an IT practitioner for over 25 years now, mostly as a consultant (I was head of Technology Consulting - which included System Integration - for the Financial Service Industry at BearingPoint in North America) but in the past few years, I have been working for a major swiss bank first as interim CTO for their North American Wealth Management group and now as Head of Strategy for the Global CTO organization.

Software quality is of major importance to us and we are in the process of setting up a bank-wide Key Performance Indicator aiming at measuring, improving and monitoring the quality of our software portfolio and I would like to share the perspective I gained and that we are gaining from this and prior experience.

It seems to me that the article as of now has a wealth of information but some of it might be extraneous and confusing to the reader, so my first suggestion would be to restructure (refactor!) the content to make it more concise and helpful to anyone consulting this article.

In that context, I would suggest that the first thing to do is to reword the definition section to present a simple but not simplistic definition of the topic – with another section presenting alternative view: with respect to the formal definition and in keeping with the suggestions made by others in that page, I would submit that that software quality regroup two very complementary but rather distinct notions: functional quality and structural quality.

Unless someone has an alternative proposal, I’ll propose a more structured approach based on my recent work at the CISQ, a SEI and OMG joint effort, where I’ve had the chance to get exposed to the work performed by luminary industry experts in SW quality, universities’ research labs, as well as Caper Jones, CISQ Distinguished Advisor.


Could you please add a citation for where the CISQ criteria come from - is there a formal document somewhere? (I like the definition, but where does it come from? I couldn't find anything on the CISQ website). (talk) 09:41, 22 August 2011 (UTC)

I did insert the link to one of the key document published by CISQ: (see CISQ 2009 Executive Forums Report) — Preceding unsigned comment added by Mbarberony (talkcontribs) 20:59, 8 November 2011 (UTC)

Also, I added the CISQ document on which is the first first metric standard published by CISQ - It deals with Automated Function Points measurement. CISQ has also announced to its membership that definitions for metrics associated to for the four Quality Characteristics—Maintainability, Reliability, Security, and Performance Efficiency—will be released and submitted to OMG in Request for Comment form at its March 2012 Technical Meeting. — Preceding unsigned comment added by Mbarberony (talkcontribs) 20:44, 28 November 2011 (UTC)

Major Cleanup[edit]

  • As proposed in my last entry, I updated the introduction section a few weeks back and I just changed the overall definition and regroup some material in other section. I am working on a more systematic description of quality characteristics which I will be able to post very soon.
  • Added end of the edit today -- I will be working on adding links to the text particularly by leveraging the links in the previous version.

— Preceding unsigned comment added by Mbarberony (talkcontribs) 17:28, 21 July 2011 (UTC)

re-Major Cleanup for objectivity: article is too CISQ-oriented[edit]

After some thoughts, I believe this article mainly covers CISQ's definition of quality, which is a partial and incomplete point of view. The article is fine and quite well written, but I believe this should be moved to something more CISQ-specific, like a specific section in the CISQ wikipedia's main page. Here are my arguments:

  • Many others have had different (and quite more generic) views on quality. They should be cited as reference, instead of quoting only one vision on this hot subject of debate.
  • Many quality models have been published, for many different organisation types and domains. CISQ covers only a part of what is addressed in other quality models. This is unfair for them.
  • The attributes of quality are partial. They mainly cover the manufacturing view on quality (which is the most proeminent view in the industry, ok), but miss several aspects (e.g. transcendental view from Garvin, conformance to requirements from Feigenbaum, fitness for use from Juran, community in FLOSS models...).
  • Recent research in software quality models has highlighted many shortcomings in modern standards (ISO 9126, SQuaRE, or even CMM), and CISQ doesn't behave better than other models. In that sense, the article misses many aspects of quality models and once again constitutes a partial view on quality and quality models.

Boris Baldassari (Talk) 12:17, 5 February 2013 (UTC)

I propose the following plan for a major rewrite:

  1. Software quality: Definitions of Garvin, Kitchenham, Feigenbaum, Juran, Deming, Shewhart, Ishikawa, and others. (I can provide them all).
  2. Software Measurement
    1. Issues with software measurement: fenton, pfleeger,
    2. Methods for software measurement: Basili's GQM, Lessons learned from software measurement programs.
  3. Software quality models
    1. Early models: McCall, Boehm, Dromey
    2. Standards: ISO 9126, ISO SQuaRE,
    3. FLOSS quality models: OSMM Capgemini, OSMM Navia, QSOS, OpenBRR, QualiPSo, QualOSS, SQO-OSS

Boris Baldassari (Talk) 12:30, 5 February 2013 (UTC)

The CISQ is a neutral, non-profit consortium, backed by the OMG and the Software Engineering Institute, Carnegie Mellon University, which is a good and credible voice of the IT industry, which does not focus only on embedded system. It’s actually good to talk about software quality for business IT, and not only – as it is too often the case – for embedded system. The latest is sometime “life critical”, and as such very important, but IT is business critical. Nothing wrong with that I think. Also, it’s a consortium open to everyone, free of charge membership.

DamienPo (talk) 19:13, 11 February 2013 (UTC)

But referencing them directly rather than using WP:SECONDARY sources may not be ideal. --Walter Görlitz (talk) 19:31, 11 February 2013 (UTC)

DamienPo, you missed my point. CISQ is free, open, fine, and so on, ok. But it doesn't mean it defines quality. I mean, I've nothing against CISQ, really, and like what they are doing. But software quality (for IT and embedded/desktop/whatsoever software, btw) is a lot more than just what CISQ includes. An encyclopaedic article must talk about what has been said before, and what is said apart from, one single source. Having CISQ- or IT-related information seems fine to me, but having only it completely misses the objectivity and completeness requirements of wikipedia. What about the few arguments I've listed above? Boris Baldassari (Talk) 21:59, 13 February 2013 (UTC)

Reference to Software Engineering: A PRACTITIONER’S APPROACH[edit]

The reference mentions the author as Scott Pressman. The book bears the name of Roger S Pressman. Is this the same person? Also I have access to the 5th edition of the book (electronic), and I cannot find the definition near the specified page. Can someone verify the reference. Doesn't seem right that something as basic as the definition will not exist in the 5th edition. — Preceding unsigned comment added by (talk) 15:52, 13 December 2011 (UTC)