How can we measure the delivery quality of a project ???

Yesterday, I held a meeting with the Department to discuss the complete and standardized delivery process of the project. All participants involved in the project summarized the process for discussion and discussion:

1. inception: We rank and score the project impact of the customer's stakeholders and their stakeholders. The results are very interesting: the customer's leadership and the satisfaction level of our leadership are ranked first, and the end users are ranked last, the Project Manager, key users, customer managers, service managers, and security managers are in the middle. Isn't it normal ??

2. core question: how to measure the delivery quality of a project? There is no final outcome for everyone to argue about this issue. Different roles have different perspectives. for leadership, there may be only one indicator: Are leaders satisfied? However, this is entirely emotional, and there are many factors that affect the judgment. For example, if the customer relationship is good or the customer relationship is good, and the satisfaction and satisfaction are completely at will, from a rational or technical point of view, how can we give a project a more objective evaluation or a more accurate quantitative evaluation? (Cost issues can be ruled out, which should not be considered for project quality issues );

1) Stability: The official explanation indicates the software error rate and performance degradation trend in a running period and under certain Edge Conditions. However, the definition of stability is also vague. Currently, it can only be measured by running time. If the project is not down or inaccessible, can it be considered that the stability is 100%? But is System Access slow ?? To what extent is slow enough to be acceptable, and to what extent is unacceptable?

In addition, if some people are normal and some others are abnormal, how can this problem be solved ?? If only a few people cannot access the database normally, there may be many factors affecting the database, such as local networks, or users' computers.

2) Availability: the official explanation refers to the degree to which the product is effective, easy to learn, efficient, memorable, error-free, and satisfactory for users, that is, whether the user can use the product to complete their tasks, what is the efficiency and subjective feelings? In fact, the product quality from the user's perspective is the core of product competitiveness. This is also a subjective factor. Some people think that it is easy to use. Some people think that it is difficult to use it. Everyone's operation habits are different. We are not something like apple. Everyone said yes, how can we quantitatively evaluate availability ?? It is estimated that there is only a satisfaction survey, but the satisfaction survey itself is not a rigorous thing;

3) maintainability: the official explanation: maintainability refers to the difficulty of understanding, correcting, modifying, and improving the software. This is also the same problem. Of course, we all understand this truth during development, but it is a good maintainability if we do not complete all the documents and add all the code annotations? There are many changes to the software understanding, such as your architecture design, your database design, and your code quality (the quality of code is another topic to be discussed ), there is no standard for measuring these things. In the same architecture, you may think it is good. If you change it to another person, you may not feel it is good, and the customer does not have the ability to check the code, therefore, this indicator lies in how the deliverable fooled;

4) Scalability: in short, scalability is about how to handle larger businesses. Likewise, the truth is clear, but how can we measure it? If you think too much about scalability, there is another problem of over-design. If you are using your own project, you may think a lot with your own efforts. If you are using Party B's project, do you have to consider this long term in the design without affecting the normal delivery of the project? In addition, there are many ways to achieve scalability, such as distributed deployment, cluster, and database separation. However, this is theoretically feasible for the moment. To do this, we must consider the implementation cost and complexity. All in all, what is high scalability and low? It is another thing that cannot be evaluated;

5) Security: Very important indicators, but you can look at your own projects. Several projects have very considerate security considerations, including physical security, Account Security, functional security, and database security, these are not exactly one or two statements. There is a book "white hats talk about web Security" That explains a lot, but if you really want to do that, do you want to let yourself die?

6) bug: this is not an indicator, but it is the most intuitive embodiment and quantifiable. We can count the number of bugs, but there are two problems. First, how to classify bugs? Second, how can we determine the quality of the system based on the number of bugs? The first problem is that the classification of bugs must be classified. If we cannot treat all bugs equally, we must have a classification standard. What is this standard? To give an extreme example, I used to make a financial system and wrote a mistake. From a procedural point of view, a very small bug caused tens of thousands of bank statements to be voided by the customer, all finance staff work overtime for two days. Therefore, we should objectively judge the severity of a bug by the impact on the user, but most of the time it is also done by humans. Well, now let's assume that the number of Bugs has come out, it is also classified, so how is it acceptable? This is related to the amount of code and complexity of the system itself. A 10 thousand-line code and a 0.1 million-line code are also three bugs, and the criteria for judging them must be different;

7) There are other judgment indicators: for example, there are 100 requirements in the demand document and 80 in practice. Strictly speaking, the quality of delivery should not be counted, the delivery quality should be related to the implemented functions. This is more about the delivery capability and is the indicator of project management;

For a project of Party A and Party B, the company can say that it is a good project after receiving the project money. If it does not receive the money, it is not a good project. Aside from human factors, it is purely technical, it is really difficult to measure the quality of a system. Currently, subjective judgment is better than quantitative analysis, and a system is still not doing well, it may be more about the ability of one or two key personnel and the implementation of overall project management standards;

Here, we will discuss it. Each company has a different situation, because we have to deliver and operate on our own, so from our own perspective, we will certainly pay attention to the maintainability issue. If it is a project of both parties, it is estimated that few will think so much.