1. Software quality

With the increasing scale of software development, the quality of software attracts more and more attention. As regards software quality, the IEEE729 — 1983 standard has the following definitions:

  1. The characteristics and overall ability of software products to meet given requirements;
  2. The degree to which the software has the desired combination of properties;
  3. The degree to which customers or users believe the software meets their overall expectations;
  4. The degree to which software combination features meet users’ expected needs in use;

From this definition we can see that quality is not absolute, it is always related to a given requirement. Therefore, the evaluation of software quality is always derived by comparing the actual condition of the product with the characteristics and quality criteria of software quality derived from the given requirements.

However, software quality presented here is a vague concept and difficult to measure. Therefore, the purpose of software quality management is to establish a quantitative understanding of the software product quality of the project and to achieve specific quality objectives.

Project quality management includes the process needed to ensure that the project can meet the requirements originally stipulated, that is, “all the activities that determine the quality policy, objectives and responsibilities in the overall management function, and implement them in the quality system through means such as quality planning, quality assurance, quality control and quality improvement”.

Software quality management focuses on determining the quality objectives of software products, making plans to achieve these objectives, and monitoring and adjusting software plans, software work products, activities and quality objectives to meet the needs and expectations of customers and end users for high-quality products.

Software quality management consists of three parts:

  1. Quality planning – Determine which quality standards are relevant to the project and determine how these quality standards should be met;
  2. Quality assurance – regularly assess the overall project performance and establish confidence that the project can meet relevant quality standards;
  3. Quality control – Monitor the overall results of the project, determine whether they meet relevant quality standards, and identify ways to eliminate nonconforming performance.

1.1 Software Quality Plan

Prior to formal software development, a software quality plan needs to be developed that describes how the project management team will implement its quality policy. In ISO9000 terms, it should describe the project quality system, i.e., “the organizational structure, responsibilities, procedures, processes and resources used to implement quality management”.

At present, there are many international quality standards, ANSI/IEEESTOL730-1984, 983-1986 standards are more commonly used. The quality plan identifies which quality standards are applicable to the project and determines how to meet the requirements of these standards. The following activities should be completed during the software quality planning phase:

  1. Plan the software quality activities of the project;
  2. Define measurable goals and priorities for software product quality;
  3. Determine that the realization process of software product quality goal is quantifiable and manageable;
  4. Provide appropriate resources and funding to manage the quality of software products;
  5. Training the personnel who implement and support software quality management as required in the implementation and support process;
  6. Training the software development team and other software project-related personnel in software quality management;
  7. Develop and maintain a software quality plan for the project according to documented procedures;
  8. The software quality management activities of the project should be based on the software quality plan of the project.
  9. Determine, monitor, and update the quality objectives of software products throughout the software life cycle;

1.2 Software Quality assurance

Quality assurance refers to the planned system activities carried out within the quality system to build confidence that the project meets the requirements of relevant quality standards. Quality assurance should be carried out throughout the project, measuring and analyzing the quality of software products on an event-driven basis, and comparing the analysis results with established quality standards to provide a basis for quality improvement. In the case of software outsourcing, it is necessary to reasonably divide the quantitative quality objectives of software products and assign them to the contractors who deliver software products.

1.3 Software quality control

Quality control refers to monitoring the specific results of a project, determining whether it conforms to relevant quality standards, and determining how to eliminate the root causes of nonconforming results. Software quality control is not only a software testing problem, review, debugging and testing are important means to ensure software quality. Quality control refers to monitoring the specific results of a project, determining whether it conforms to relevant quality standards, and determining how to eliminate the root causes of nonconforming results. Quality control should be carried out throughout the project. Project results include both product results (such as deliverables) and project management results (such as cost and schedule performance).

Quality control is usually carried out by the Quality Control department or a similarly named department within the organization. Software quality control includes the following activities:

  1. Testing software products and applying the test results to the status of software quality management activities;
  2. Senior management regularly participates in the review of software quality management activities;
  3. The software project leader participates in the review of software quality management activities regularly;
  4. The software quality assurance review group is responsible for reviewing software quality management activities and work products and filling in relevant reports;

(1) Software review

Software review is not conducted after software development is completed, but at all stages of software development. Because errors may occur in each stage of software development, if these errors are not found and corrected in time, they will continue to expand, and may eventually lead to the failure of the development.

First of all, the review objectives shall include the following parts:

  1. Detect any form of functional, logical or implementation error in the software;
  2. Verify software requirements through review;
  3. Ensure that the software is represented according to predefined standards;
  4. The acquired software is developed in a uniform form;
  5. Make projects easier to manage.

Secondly, the review process should include: holding a review meeting. At the end of the meeting, one of the following decisions must be made: ① Accept the product without modification; ② Because the mistake is serious, refuse to accept; ③ Temporarily accept the product. Review report and record;

Questions are recorded, and a review question sheet is generated at the end of the review session,

In addition, a brief review report must be completed. Basic review criteria should also be followed, such as:

  1. Allocate resources and time schedule for each formal technical review;
  2. Reviewing products, not designers, should not put designers under any pressure;
  3. The meeting should not deviate from the subject, but establish an agenda and maintain it;
  4. The purpose of the review committee is not to solve problems, but to identify problems and limit arguments and refutations;
  5. Establish a review list for each product to be reviewed to help reviewers think;

(2) Test

Software testing is not only an important part of software development but also an important part of software quality assurance. Testing is the dynamic execution of a system (or components of a system) with known inputs in a known environment.

Testing generally includes unit testing, module testing, integration testing and system testing. If the test results do not match the expected results, you have probably found a bug in the system, and the following basic documentation will be generated during the test. Test plan: determine test scope, methods, resources needed, etc. Test procedure: describe in detail the test steps and data (including test data and expected results) related to each test scenario. Test results: Document the results of each test run, and if the run goes wrong, a problem report should be generated, and any problems found must be resolved through debugging.

2 project risk management

Whether IT is system integration or software development, IT companies often face the implementation and management of various projects, and face many problems such as how to determine the investment value of the project, evaluate the size of the benefit, analyze the uncertain factors, decide the investment recovery time and so on. Moreover, an IT project, no matter its size, will inevitably bring changes to the implemented party (user) in management, business operation and other aspects, which makes IT project inevitably has the characteristics of high risk. Especially in recent years, the extensive implementation of IT projects, on the one hand, for many enterprises brought management, management innovation, and on the other hand, aborted, interrupted, failure of the project is not a minority. Therefore, how to effectively manage and control risks in project implementation has become a necessary condition for the success of project implementation.

In fact, project risk management not only runs through the whole project process, but also begins risk analysis before project events occur.

Risk management can be divided into three parts according to the time of risk control and project events: pre-control — risk management planning, in-process control — risk management methods, and post-control — risk management report.

2.1 Concept of project risk management

According to the definition of PMBOK2000, risk management refers to the systematic process of identifying, analyzing and taking countermeasures to project risks. It includes maximizing the probability and consequence that are favorable to the project objective and minimizing the probability and consequence that are unfavorable to the project objective. Project risk is divided into known risk, predictable risk and unpredictable risk according to whether there is certainty or not. According to the content of risk management can be divided into the following types.

(1) Internal technical risk: technological change and innovation is one of the important sources of project risk

Generally speaking, the adoption of new technology or technological innovation in a project is undoubtedly an important means to improve project performance, but this will also bring some problems, many new technologies are not proven or not fully mastered, which will affect the success of the project. In addition, when people out of the need of competition, they will improve the requirements of project product performance and quality, and unrealistic requirements are also the source of project risks.

(2) Internal non-technical risks

Strategic risks related to changes in the company’s business strategy, management risks related to the management level of the company’s management/project management personnel, and risks related to changes in scope; The quality risk of not fulfilling the task in accordance with the required technical performance and quality level; Schedule risk of not completing the task within the budgeted time frame; The cost risk of not completing a task within the budgeted cost range.

(3) External legal risks

Including changes in regulations or standards related to the project, such as licensing rights, patents, invalidation of contracts, litigation, etc.

(4) External non-legal risks

It mainly refers to the political and social impact of the project, the change of the economic environment, the change of the employment relationship in the organization, such as corporate merger and acquisition, government intervention, currency changes, inflation, taxation, natural disasters, etc. This kind of risk has a great influence on the project and the nature of the project.

2.2 Process of risk management

Risk management includes the process of identifying, analyzing and responding to project risks so as to maximize the impact of positive events and minimize the impact of negative events. The main process of project risk management includes:

  1. Risk management planning, determining how to direct and plan the risk management activities of the project;
  2. Project risk identification, identifying which risks may affect the project and documenting their characteristics;
  3. Qualitative risk analysis, complete qualitative analysis of risks and environment, and rank them according to their impact on project objectives;
  4. Qualitative risk analysis is a method to determine the significance of a specific risk and guide the relevant response;
  5. The temporal correlation of risk-related actions may increase the importance of risk;
  6. Quantitative risk analysis, to measure the possibility and consequences of risks and estimate their potential impact on project objectives;
  7. Risk response planning, creating processes and techniques to enhance opportunities and mitigate threats to project objectives;
  8. Risk monitoring and control to monitor existing risks, identify new risks, implement mitigation plans and assess their effectiveness throughout the project life cycle;

The processes described above interact not only with each other but also with processes in other knowledge domains. In general, each process occurs at least once in a project.

(1) Risk identification

Risk identification is to identify the risk events that may exist in the whole project process. Risk identification is performed at the beginning of the project, in the middle of each project phase, and before major scope change approval; in fact, it is a continuous process throughout the project life cycle. To identify risks, you should first understand what risks (risk events or risk sources) are likely to occur at various stages of software development. The risks that may occur at each stage of software development are listed below.

  1. Initial phase: unclear project objectives; Unclear project scope; Less user participation or communication with users; Not knowing enough about the business; Understanding of requirements; No feasibility study was conducted.
  2. Design phase: lack of experience in project team, such as lack of experienced system analyst; There is no change control plan, so that there is no basis for change, the change does not change, the change should not change, the resulting design is bound to fail or deviate from user needs; Hasty planning may bring progress risks; Missing item: a feature is not taken into account due to an oversight by the designer.
  3. Implementation stage: the development environment is not good; Implementation difficulties caused by design errors; Poor programmer development ability, or programmers are not familiar with development tools; Project scope changes (sudden addition or modification of features that require design rethinking); Project schedule change (request to complete tasks ahead of schedule, etc.); Personnel leave, software development work in a project has a certain continuity, need to transfer and handover, sometimes the impact of personnel leave on the project will be great; The lack of internal communication in the development team leads to deviations in the understanding of the system design by programmers; No backup plan is available. No practical test plan; The tester was inexperienced.
  4. Final stage: poor quality; Customer dissatisfaction; Equipment did not arrive on time; Funds cannot be recovered.

In the initial stage, most requirements analysis and a small part of design (most business modeling and requirements, and a small part of analysis and design) are carried out. The design stage mainly carries out most of the design, a small part of the coding (most of the analysis and design, part of the implementation and testing, starting to consider deployment); The implementation phase involves most of the coding and testing, but also a small part of the design (most of the implementation and testing, part of the deployment); The closing phase completes installation and maintenance (most deployments).

In addition to considering the project process, there are also risks in human resource management of software enterprises, such as recruitment failure, dissatisfaction of employees caused by new policies, and sudden resignation of technical backbone, etc. These events will affect the normal operation of the company, and even cause a fatal blow to the company. High-tech enterprises, in particular, are more dependent on people, so they need to identify risks in human resources.

The above is just a list of common risk events. Different projects may have different risk events, so we should identify the risk events that are really likely to happen in a specific project. It is generally based on the nature of the project, from the potential events and their consequences and the potential consequences and their causes to check the risk. Collect and sort out possible risks of the project and fully solicit opinions of all parties to form a risk list of the project, and describe these risk events, such as: possibility, scope of possible consequences, expected occurrence time, occurrence frequency, etc. There are many effective methods for risk identification, such as establishing risk item checklist, causal analysis chart, interviewing various project stakeholders, etc.

(2) Risk analysis

Once you have a risk list for the project, you can proceed to risk analysis. The purpose of risk analysis is to determine the impact of each risk on the project. Generally, it is to quantify the identified project risks. Three concepts should be paid attention to here.

  1. Risk gain and loss value: it refers to the possible impact on the project once the risk occurs, indicating the possible loss. If the size of the loss is not easy to estimate directly, the loss can be broken down into smaller pieces and reassessed. The risk gain and loss values can be expressed by relative values. It is recommended to convert the loss size into the time expression of the impact on the plan.
  2. Probability of risk: It is the percentage of the probability of a risk occurring. It is a subjective judgment.
  3. Value-at-risk: Also known as risk exposure or risk exposure, value-at-risk is an important parameter used to evaluate risk, “value-at-risk”, “risk probability” and “risk impact”. For example, if a risk probability of 25% occurs, the project plan will be extended by 4 weeks. Therefore, the risk value = 25% * 4 weeks =1 week.

Risk analysis is the risk impact analysis of the risk events identified above. Evaluate the scope of possible results of the project by estimating risks and their interactions, evaluate risks from the three aspects of cost, schedule and performance, and determine which risk events or sources can be avoided, which can be ignored (including bearable), and which measures should be taken.

(3) Risk response methods

After the risk analysis is completed, the risks existing in the project, their probability of occurrence and risk impact on the project have been identified, and the priority of the risks can be eliminated. Then, according to the nature of the risk and the project’s ability to bear the risk, the corresponding prevention plan, that is, risk response.

The formulation of risk response strategy mainly considers the following four factors: evadability, transferability, mitigation and acceptability. To some extent, the risk response strategy determines what kind of project development plan to adopt. Risks that should be “avoided” or “passed on” must be considered in project strategy and planning. Risk in a project can never be completely eliminated,

PMBOK2012 edition mentioned four coping methods:

  1. To evade. Risk aversion refers to changing a project plan to eliminate risks or conditions or to protect project objectives from impact. While a project can never eliminate all risk events, some specific risks can be avoided. Some risk events that arise early in the project can be resolved by clarifying requirements, obtaining information, improving communication, or gaining technical expertise. Identify the causes of risk events through analysis and eliminate these causes to avoid the occurrence of some specific risk events.

For example, how to avoid customer dissatisfaction? There are two cases of customer dissatisfaction. One is that there is no basis for judging customer satisfaction, that is, there is no mutually recognized customer acceptance standard, and the other is that the developer does not meet the acceptance standard, that is, it does not meet the needs of users. In either case, the developer has an inescapable responsibility that can be avoided by doing the following: involve the customer in the business modeling phase; In the demand stage, we should communicate with customers to understand their real needs. The model or DEMO system of the target system should be demonstrated to the customer and feedback should be obtained. If the feedback opinion differs greatly from the DEMO system, the modified DEMO system should be demonstrated to the customer again until both sides reach a consensus. There shall be acceptance plan and acceptance standard agreed by both parties; Perform change control and configuration management.

  1. Transfer. Transferring risk means trying to transfer the consequences of a risk, along with the responsibility for dealing with it, to a third party. Shifting risk actually shifts responsibility for risk management onto the other party, not out of it. This method basically requires the risk taker to be paid a risk fee. It includes utilization insurance, performance bond, guaranty and bond. Contracts can be used to shift responsibility for specific risks to another party. If the design of the project is stable, a fixed-sum contract can be used to shift the risk to the seller. Although cost reimbursement contracts leave more of the risk to the customer or sponsor, they can help reduce costs if changes occur mid-project.

  2. Reduce. Mitigate the impact on the project by reducing the probability of risk events occurring or the amount of gain or loss. Taking action in advance to reduce the probability of a risk occurring or its impact on the project is much more effective than trying to remedy the risk after it has occurred. The costs of risk mitigation should be well estimated and proportionate to the probability of risk occurrence and its consequences. Consideration of contingency reserves in the project budget is another way to reduce the impact of risk.

For example, risk identification revealed that the programmers on the project team were not familiar with the required development techniques. Familiar techniques can be used to mitigate the cost or schedule impact of a project. Training can also be done beforehand to mitigate the impact on the project.

  1. Accept it. Accept the consequences of your risks. Adopting this technique indicates that the project team has decided not to change the project plan to address a risk, or that they cannot find any other good solution. Proactive risk acceptance involves having a contingency plan in place in case a risk occurs. For example, to avoid the consequences of a natural disaster, a remote backup center was considered in a large software project. After determining the risk response strategy, the risk response plan can be prepared, which mainly includes the identified risks and their description, the probability of risk occurrence, the responsible person for risk response, risk response strategy and action plan, emergency plan, etc.

(4) Risk response plan

Develop response plans for risk events that require response measures, and implement response plans once risk events occur. Response plans are often applied to identified risks that occur during a project, and having a contingency plan in place in advance can significantly reduce the cost of taking action when risks occur. Risk triggers, such as missing intermediate milestones, should be defined and tracked. If the impact of the risk is significant, or if the chosen response is not effective, a contingency plan should be developed. This plan may include setting aside a contingency fund, developing alternative plans, or changing the scope of the project. The most common response to accepting risk is a contingency reserve, or reserve for short, which involves setting aside time, money, or resources for a known risk. The reserves set aside for accepted risks depend on the size of the impact calculated at the acceptable level of risk.

For example, in a software development project, a developer is likely to resign, which will have a certain impact on the project, so we should develop a response plan for this risk event. The process is as follows:

  1. Conduct investigation to determine the cause of flow;
  2. Include mitigation of these flow causes in the risk management plan prior to project commencement;
  3. At the beginning of the project, plan for implementation once personnel leave to ensure that the project can continue after personnel leave;
  4. Establish documentation standards and a mechanism to ensure timely documentation;
  5. Scrutinize all work so that more people can get their work done on schedule;
  6. Develop reserve personnel for each key technician.

Of course, this coping plan needs to cost a certain amount. After considering the risk cost, we should decide whether to adopt the above strategy.

(5) Risk monitoring

After formulating the risk response plan, the risk does not exist, and may increase or decline in the process of project advancement. Therefore, in the process of project implementation, it is necessary to monitor the development and change of risks at all times, and determine the new risks brought by the disappearance of some risks.

Risk monitoring includes two levels of work: one is to track the development and change of identified risks, including changes in the conditions and consequences of risk generation throughout the project cycle, and to measure the needs of risk mitigation plans. The second is to adjust the risk response plan in a timely manner according to the changes of risks, and identify and analyze the existing risks and the residual risks and new risks in a timely manner, and take appropriate response measures.

The risks that have occurred and solved should also be adjusted out of the risk monitoring list in time. One of the most effective risk monitoring tools is “Top 10 Risk List”, which is a simple and easy risk monitoring activity. It takes the top 10 risks of a project as control objects according to the size of “risk value” and closely monitors the top 10 risks of a project. After each risk check, a new “Top 10 risk list” is formed.