We can look at quality in software engineering from different perspectives: process, team, and product.
The quality of the process is advocated by those who see the development process as a kind of industrial process. Their main claim is that the quality of the software artefact can be inferred from the quality of process used to build it. On the other hand, people that look at software development as an inherently human activity, closer to art or craft (see Software as Art and Engineering) tend to emphasize the need to have quality in the human resources: it has been reported that the productivity of programmers varies significantly. Therefore, while the former see the development of software as a repetitive activity, where perfection is on the machine, the latter believe that software development is a knowledge-based activity and quality is in the worker. In the Project Management and Software Process I will analyze the impact of these two different perspectives in several software engineering approaches.
However, whether the software artefact quality results from the quality of the process or from the quality of the team, it has a set of desirable qualities: the qualities of the product. Their names are well-known, performance, availability, maintainability, usability, etc, though their meaning, depending on the source, may slightly change. For instance, some authors include reliability as part of availability, whereas other consider them as different qualities. The software engineer should be aware of the possible variations and confirm whether all the participants in a discussion are using the same language, (see Software Development as a Formalisation Process).
The best way to think about the qualities of a software artefact is from the perspective of their stakeholders. The stakeholders of a software artefact are diverse: users, customers, developers, etc. Users look at the artefact as a (running) entity that provides services, and are interested in qualities like performance and availability. For customers, the artefact is a mean to achieve business goals, and consider the cost of the artefact as one of its qualities. Developers look at the artefact from the point of view of its code, and are concerned about how difficult it is to develop and maintain it. The developers perspective focus on the language aspect of the artefact and they want the artefact descriptions to be readable and easy to change. Size complexity, see Complexity in Software Engineering, is of special concern to developers.
Very often qualities are in conflict and even change along time. For instance, consider a home banking application. Two relevant qualities are security and usability. However, more security may result in less usability. A tactic to increase the security of a system is to hide it behind a firewall, but then it will not be usable from a home banking perspective. Therefore, the business stakeholder is interested in balancing the security with the usability of the system. She realizes that there is a business opportunity in home banking, but she is afraid that the clients may be not interested to use the system, so she decides that usability should be emphasized over security: users will only need to know a password to login into the system. The business stakeholder is aware the bank is going to lose some money, due to attacks on security, but she believes the new service will increase the number of clients and reduce costs in the back office. However, when the service become successful, and clients use it daily, the business stakeholder decides to reduce usability and increase security. The new version of home banking application will require users to carry a mobile phone to receive a temporary password in order to login in.
A software artefact implements a compromise between the different qualities wanted by stakeholders and, since they can change during the system lifetime, the software artefact, naturally, has to evolve.
An excellent reference on Software Quality is the Software Architecture in Practice book by Len Bass, Paul Clements and Rick Kazman.