I. Risk assessment
Software project risk refers to the cost budget, development progress, technical difficulty, economic feasibility, safety management and other issues involved in the whole project cycle, as well as the impact of these issues on the project. The risk of the project is inversely proportional to the feasibility, and the higher the feasibility, the lower the risk. The feasibility of software projects can be divided into four aspects: economic feasibility, business feasibility, technical feasibility and legal feasibility. Software project risks are divided into six aspects: product scale risk, demand risk, correlation risk, management risk and security risk;
1.？ Product scale risk
The risk of the project is directly proportional to the scale of the product. The larger the general product scale, the more prominent the problem. In particular, the method of estimating product scale, the number of reusable software, the number of demand changes and other factors are closely related to product risk:
( 1) ? Method of estimating product scale
(2) ? Reliability of product size estimation
(3) ? Deviation of product scale from previous average product scale
(4) ? Number of users of the product
(5) ? How many reuse softwares are there?
(6) ? How much has the product demand changed?
2.？ Demand risk
Many projects face some uncertainties when determining requirements. When these uncertainties are tolerated in the early stage of the project and cannot be solved in the progress of the project, these problems will pose a great threat to the success of the project. If the risk factors related to demand are not controlled, the wrong products may be produced or the expected products may be damaged. Each situation may be fatal to the product, and these risk factors are:
( 1) ? Lack of clear understanding of products
(2) ? Lack of understanding of product requirements
(3) ? Insufficient customer participation in the process of demand analysis
(4) ? There is no priority demand
(5) ? Due to uncertain demand, new markets have emerged.
(6) ? Demand change
(7) ? Lack of effective requirement change management process
(8) ? Lack of relevant analysis of demand changes, etc.
3.？ Related risks
Many risks are caused by the external environment of the project or the correlation of factors. In order to control the risk of external correlation, the mitigation strategy should include a possibility plan, so as to obtain the necessary components from the second resource or collaborative work resources and detect potential problems. Factors related to the external environment are:
( 1) ? Customer-supplied items or information
(2) ? Dependencies of interaction members or interaction groups
(3) ? Relationship between internal or external subcontractors
(4) ? Availability of experienced personnel
(5) ? Project reusability
4.？ technical risk
The rapid development of software technology and the lack of experienced staff mean that the project team may affect the success of the project because of their skills. In the early stage, identifying risks and taking appropriate preventive measures are the key to solving problems in risk areas, such as training, hiring consultants and recruiting suitable talents for project teams. Regarding technology, there are mainly the following risk factors:
( 1) ? Lack of training
(2) ? Insufficient understanding of methods, tools and technologies.
(3) ? Lack of experience in application field
(4) ? Not familiar with the application of new technologies and development methods.
5.？ Managing risk
Although management problems limit the success of many projects, don't be surprised that all management activities are not included in the risk management plan. In most projects, the project manager is usually the person who writes the project risk management plan. They have a congenital deficiency-they can't check their mistakes. Therefore, the success of the project becomes more difficult. If we don't face up to these thorny problems, they are likely to affect the project itself at some stage. When we define the project tracking process and clarify the project roles and responsibilities, we can deal with these risk factors:
( 1) ? Inadequate definition of plans and tasks.
(2) ? Don't know the actual project status
(3) ? Project owners and decision makers are confused.
(4) ? Unrealistic promises
(5) ? Unable to fully communicate with employees.
6.？ dangerous person
The software product itself is a creative product, so it is very important to keep the secret of the core technology of the product. However, for a long time, our safety awareness in software is relatively weak, and the development of software products mainly focuses on the technology itself, ignoring the protection of patents. The flow of technicians in the software industry is a very common phenomenon. With the loss and change of technicians, it is likely to lead to the leakage of products and new technologies, which will lead to the theft of our software products by other companies and the failure of the project. Moreover, there is no clear industry standard for the identification of software intellectual property rights, which is also the potential risk of our software project.
7.？ Ways to avoid risks
( 1) ? The guidance of developers can ensure the integrity of requirements and make the requirements highly consistent with the real expectations of customers. Then, it is convenient to form an important written document "user requirements" to avoid the loss caused by omission being gradually amplified in the subsequent stage of the software system.
(2) ? To establish a supervision system, any major decision of project development must involve customers. In this project, the project supervision is carried out by the quality supervision team in the project development.
(3) ? Requirements changes shall be proposed by the unified person in charge and approved by the user requirements audit team leader. Requirements changes should be put forward regularly rather than at any time, and developers should make detailed records to let customers know the actual situation of requirements changes.
(4) ? The complexity of the control system and the simple structure of the system will obviously discount the proportion of users and even cause the software life to be too short. On the other hand, if the software structure is too flexible and universal, it will inevitably increase the difficulty of software implementation and the complexity of the system, thus bringing risks in the implementation and testing stages. Proper control of the complexity of the system is conducive to reducing the development risk.
(5) ? From the perspective of software engineering, the cost of software maintenance accounts for about 55%~70% of the total cost. The bigger the system, the higher the cost. Ignoring the maintainability of the system is the biggest risk of large-scale software systems. During the long operation period of software, business rules will certainly develop continuously. The scientific method to solve this problem is to constantly upgrade the software system and gradually expand the system on the premise of ensuring maintainability.
(6) ? Formulate emergency plans, and each development plan must at least formulate an emergency plan to deal with unexpected situations and unknown risks.
Second, the cost budget
1.？ Cost budget model
( 1) ? Top-down budgeting method
The top-down pre-method mainly estimates the sub-project costs that constitute the overall cost of the project according to the management experience of the middle and upper level project managers, and transmits the results of these judgments and estimates to the lower level managers. On this basis, the managers at this level estimate the subtasks and subprojects that make up the project, and then continue to pass their cost estimates to the next level until they reach the lowest level.
Using this budget method, when the upper managers' cost estimation based on experience is decomposed to the lower levels, there may be cases where the lower levels think that the upper level estimation is not enough to complete the corresponding tasks. At this time, the lower-level personnel may not express their true views, or they may not rationally discuss with the upper management, so as to get a more reasonable budget allocation plan. In practice, they can only silently wait for top managers to find problems and correct them, which often brings many problems to the project.
Top-down is more suitable for the initial stage of the project, and the difference with the real cost is between 30% and 70%.
Scrum adopts the top-down cost budget method, which will not accurately determine the cost immediately, but will accommodate the changes of customers' requirements for future products to the greatest extent.
(2) ? Bottom-up budgeting method
The bottom-up method requires the use of WBS (Work Breakdown Structure) to carefully check the time and budget of all work tasks of the project. The initial budget is for resources (team members' working hours, hardware configuration), and the project manager adds appropriate indirect expenses (such as training expenses, management expenses, unforeseen expenses, etc.). ) and the profit target to be achieved by the project, forming the total project budget. Bottom-up budgeting method requires comprehensive consideration of all involved tasks, which is more suitable for the initial and middle stages of the project. It can estimate the cost of the project in the preparation stage, and the difference between it and the real cost is between 5% and 10%.
Note: WBS
WBS is the decomposition of submitted projects. From the submission list, we can determine the activities that each submission needs to perform. Scrum will further refine WBS, break down an iteration into one or more work packages, and then break down the work packages into small development tasks (the development cycle of general development tasks is within 15 working hours).
2.？ Determine project expenditure
The total cost budget is the development cost comprehensively calculated by combining the following cost budget methods:
( 1) ? Zero radix budget
At the beginning of the cost budget, the zero-based calculation principle should be adopted, and the project cost cannot be roughly calculated as the total cost of the previous year plus 20%.
(2) ? Software and hardware costs, project costs
Project cost refers to costs similar to: server (RAM hard disk CPU NIC card RAID cluster) cost, maintenance cost, computer room rent, optical fiber communication cost, software cost, etc.
When calculating the cost, we need to consider many factors, such as the time required to assemble the hard disk, the quality of technicians, whether the product supplier can guarantee the quality, and whether additional management personnel are needed in management.
(3) ? Software license cost
(4) ? Outsourcing cost
When using sub-projects such as video, SMS, mobile telecommunication service, portal, etc. Outsourcing can be considered to reduce the development cost.
(5) ? Human resource cost
When calculating the cost of human resources, we should calculate the average cost of human resources by estimating the average efficiency of the highest and lowest work efficiency.
(6) ? Maintenance cost
Third, the process of customer communication
From the perspective of customer communication, software projects can be divided into four different stages: requirement identification, scheme customization, project implementation and project ending, and each stage has different communication focuses.
1.？ Requirement identification stage
( 1) ? Text communication
In the early stage of requirements identification, it is necessary to conduct all-round and multi-angle analysis through questionnaire survey, prototype display, interface display, logical processing display and standardized document template. , and feedback the ambiguity to the customer at any time, expecting the customer to answer. And establish a demand analysis book in the form of written records, and ask customers to review the demand analysis book, so as to achieve the result that the demand analysis is highly consistent with the real expectations of customers.
(2) ? Business logic communication
In business communication, we should understand the customer's industry language, so as to promote the process of business analysis and cross the gap between application requirements and development. The communication process advocates sketching or visual informationization to provide the most suitable operation interface for enterprise users at different levels. Think from multiple angles and grasp the key needs, especially the innovative and practical needs that customer leaders pay attention to.
(3) ? Standardized management of demand change
Requirements change is understandable in software development projects, but it must be managed in a standardized way to avoid the risk of endless requirements change. Requirements changes must be proposed by the unified person in charge and approved by the user requirements audit team leader. Requirements changes should be put forward regularly, not at any time. Developers should make detailed written records to let customers know the actual situation of demand change and the cost paid by developers.
2.？ Scheme customization stage
The main task of the project at this stage is to work out an operational project plan with the customer according to the clear needs in the early stage, the resources of both parties, the initial stage of the project, the implementation time agreement and the project cost limitation. From this stage, customers will fully participate in the project management, and consider the specific project implementation plan and risk avoidance from the interests of both parties.
3.？ Project implementation stage
At this stage, the software project team should lead the implementation of the project together with the customer. At the same time, the project team should evaluate customer satisfaction in real time and improve customer satisfaction through continuous improvement. Customers should also be required to attend necessary training and check the project products when necessary. Before the customer's demand changes, we should actively communicate with the customer, so that the customer can fully understand every link of the project and the impact of the change, and reduce the demand change. If customer needs change, we should work with customers to solve the changes in cost, schedule and quality caused by the changes.
4.？ End stage
At this stage, the project results are mainly handed over, and the system is delivered to maintenance personnel to help customers achieve business goals and settle various payments. After completing these tasks, we should evaluate the project, review the project results and summarize the project experience.
5.？ Precautions for pre-sales personnel
When a product-oriented project is regarded as a development achievement, the relevant sales staff should pay attention to: the promotion of products should not be over-committed. If there are too many commitments, it will bring difficulties to the implementation of subsequent projects; Once the promise is not fulfilled, it will also reduce customer satisfaction and affect future cooperation. If there are any additional commitments, they must be recorded in text form so that the implementation project manager can know and convey them to the project team members.
Note: In a software project, you need to define the following four customer roles.
A.？ It is necessary to clarify the end-user departments and users, understand their existing working methods, let them know the target framework of the project, and know what difficulties the project needs to solve, but certainly not all, so as to better control the scope of the project.
B.？ In order to identify the initiator of the demand, he or they should be able to represent the final customer base. This kind of customers who put forward product requirements should have certain technical and business capabilities and authority, can truly represent the wishes and ideas of the final customer team, and preferably have an IT foundation, and can describe problems and requirements in IT language, so as to facilitate communication and cooperation between the two parties and avoid ambiguity.
C.？ To be a middle-level leader who needs to confirm, we must grasp the direction. Software development project is to solve practical production or management problems, and also to lead the concrete realization of system construction. As a customer leader who needs to be confirmed, he should not only understand the key points and direction of system construction of senior leaders, but also be familiar with specific business and production management practices. If so, it will play an extraordinary role in the smooth progress of enterprise software development projects.
D.？ It should be clear who will comment on the finished product and who will accept it. The project acceptance link is the closing link of the project. If the people who accept the project don't understand the initial demand target of the project, it will have a negative impact on the acceptance from the attitude and the actual use effect of the product, which is very unfavorable for the enterprises that provide the product to close the project. According to the practice summary, the demander and the confirmer should do a good job in the acceptance of the project, which can promote the smooth completion of the project and avoid delays.
Fourth, demand analysis.
1. The process of demand analysis
The demand process includes two parts: demand development and demand management:
( 1) ? Demand development is the process of management and communication with guest rooms in the early stage of development, which is divided into four stages: demand acquisition, demand analysis, demand writing and demand verification.
(2) ? Requirements management: it is the activity of controlling and maintaining requirements agreement in the process of software project development. Include change control, version control, requirement tracking and requirement status tracking.
2.？ Demand level
The demand hierarchy includes four aspects: business demand, user demand, functional demand and non-functional demand.
3. Key points in the requirements development stage
( 1) ? Extract business objects
Business objects refer to the real objects used by the system. For example, the business objects of supply chain management (SCM) mainly include: manufacturers, wholesalers, retailers, suppliers and customers.
(2) ? Extract business process
In the process of understanding business logic, it is necessary to list the respective functions of the developed software modules, refine each workflow, and deeply analyze business logic.
(3) ? performance requirement
In the early stage of analysis, customers should pay attention to the technical performance indicators of the developed software, such as storage capacity limit, running time limit, security and confidentiality.
(4) ? Environmental demand
Environmental requirements refer to the requirements of the environment in which the software platform runs, such as hardware: model, external equipment and data communication interface; Software: system software, including operating system, network software and database management system; Purpose: From the system and technical level of the operator, what conditions should the user department have.
(5) ? Reliability requirements
The failure probability of the developed software should be based on the actual operating environment requirements after it is put into operation. For important software, or software whose failure will cause serious consequences, higher reliability requirements should be put forward.
(6) ? Security and confidentiality requirements
When analyzing the requirements, we should make appropriate provisions in this respect and design the developed software specially to ensure its security and confidentiality in operation.
(7) ? User interface requirements
Specify the arrival requirements of the user interface in detail.
(8) ? Resource use demand
All kinds of resources needed by the developed software at runtime and development.
(9) ? Software cost consumption and development schedule requirements
After the software project is established, the progress requirements of software development and the cost of each step are put forward according to the contract as the basis of development management.
(10) development goal requirements
Predict the possible goals of the system in advance, which makes it easier to make necessary supplements and modifications to the system.
4.？ The task of demand analysis
The main task of requirement analysis is to export the logical model of the target system with the help of the logical model of the current system. The process is as follows:
( 1) ? Determine the comprehensive requirements of the system (function, performance, operation and expansion requirements)
(2) ? Make product requirement document (PRD)
(3) ? Analyze the data requirements of the system (conceptual model, data dictionary, standardization)
(4) ? Export the detailed logical model of the target system (data flow diagram, data dictionary, main function description)
(5) ? Develop prototype system
(6) ? Extract and compile software requirement specifications from PRD.
Note: SRS format
1. Introduction? 2 system overview (project background, system objectives, core business processes) 3. Term description? 4. System structure (architecture diagram, function diagram)
5. Main functions and business logic (key points) 6. Interface requirements (internal and external interfaces) 7. Overall network design (topology network, host, network)
8. Operating environment (Linux, Windows, IIS, WebLogic, Tomcat, OLAP, OLTP, JDK 8.0,. NET Framework 4.0, etc. )
Five, object-oriented programming (omitted)
1.？ design principle
( 1) ? SRP single responsibility chain
Each class should only be responsible for doing one thing.
(2) ? Principle of OCP unsealing and closing
Software entities (classes, modules, functions, etc.). ) should be extensible, but not modifiable.
(3) ? LSP replacement principle
Subclasses must be able to replace their basic types.
(4) ? Dip correlation inversion principle
High-level modules should not depend on low-level modules, but both should depend on interfaces and abstract classes. Abstraction should not depend on details, and details should depend on objects.
(5) ? ISP interface isolation principle
We should separate fat interfaces instead of forcing customers to rely on unused interfaces.
2.？ Realizing UML modeling
( 1) ? Extraction of business objects
(2) ? Use case modeling based on SRS and CRC.
(3) ? Implement business sequence diagram
(4) ? Establish a class diagram and establish the association between objects according to the use case diagram.
(5) ? Draw activity diagram, realize cooperation diagram and state diagram.
Development management of intransitive verbs
1.？ Establish a project plan
( 1) ? Design the overall architecture
According to the implementation needs of the system, an appropriate and mature frame structure is adopted.
(2) ? Control scalability
Excessive expansion will increase the complexity of the system and prolong the development time; Low expansibility will directly affect the secondary development and maintenance of the system. Controlling the expansibility of the system can improve the development efficiency and reduce the difficulty of system maintenance.
(3) ? Establish infrastructure
Reasonably allocate the time and cost required for deploying infrastructure such as software and hardware (for example, ordering and installing servers, optical fiber access, ordering software platforms).
(4) ? Divide development tasks
Use WBS (Work Breakdown Structure) to classify and divide deliverables. Each project can be divided into several different stages, and each stage can be divided into several work packages, which are the smallest deliverables in WBS. Finally, several development task lists are separated from the work package.
(5) ? Deployment and development progress
A project should be divided into several development stages according to the progress, and the development cycle of each stage is generally within 30~60 working days. At this stage, we should hold a consultation meeting with customers, make a product roadmap, and invite customers to actively participate and give feedback during the development process. Then, according to the development difficulty, dependence, importance and other conditions, the development tasks in this period are divided into multiple iterative cycles.
In the principle of Scrum agile software development, each iterative task should be further subdivided into multiple development task lists, and the redevelopment task should be assigned to team members, and the development time should be controlled within 15 working hours. If the development time exceeds 15 working hours, we should consider refining the development task again. Development task suggestions should be selected by the team members themselves, rather than forced allocation.
(5) ? Test project results
Each work package should deploy testing work synchronously to improve the quality of the project. The work package with bugs should be recorded by the tester in words, and the errors should be shown to the developer so that the developer can modify it in time.
2.？ Manage the development team
( 1) ? Build a team
Establish a team according to the preconditions of work tasks and project time, and assign personnel according to team responsibilities. Generally, the number of team members should be controlled between 8 and 12. When the number of teams exceeds 15, we should consider splitting the team into two independent teams, which are responsible for different development tasks.
(2) ? Assign development tasks
In each iteration period (usually 15~30 working days), each work package should be further subdivided into multiple development tasks, and the redevelopment tasks should be assigned to team members, and the development time should be controlled within 15 working hours. If the development time of the development task exceeds 15 working hours, it is necessary to consider refining the task again. Development tasks should be assigned to each team member in a freely chosen way.
(3) ? Supervise the development progress
Hold a meeting in the early stage of iteration to let team members know the development progress and process, and assign development tasks in a self-selected way. In the meantime, you can use tools such as Microsoft Project to record the progress of the development process. After the development of each work package is completed, the function test should be carried out, and the test results should be recorded in words.
Hold a 15-minute standing meeting every day, so that team members can explain the development tasks completed yesterday, the tasks to be done that day and the problems encountered in the development process. And hold a regular meeting every weekend to explain the overall process.
At the end of the iteration, hold a sprint meeting to summarize the project progress, complete the task, review the problems encountered during the iteration and prepare for the next iteration.
(4) ? system test
Test each completed work package in time to ensure the quality and performance of the system. Record the test results in words, and link the test results with performance salary income, and calculate the performance income of team members with real data.
(5) ? Solve the problems encountered in development
Conduct pre-training for developers, assign tasks according to work ability and guide the development of team members. Problems should be raised at the executive meeting of the day immediately, and the problems should be solved within 15 working hours to prevent the problems from further expanding.
3.？ Supervise product quality
( 1) ? Quality needs planning and design, not evaluation. In the initial stage of product establishment, it is necessary to negotiate with the Quality Assurance (QA) department to determine the appropriate quality policies and standards in the form of formal documents.
(2) ? In the development process, TDD (Test Driven Development) mode is adopted to improve the development quality. Testers should record bugs in text form and demonstrate outstanding defects to developers together with developers to improve the efficiency of modification.
(3) ? At the end of each iteration, do a product demonstration and collect feedback from customers, users and senior leaders. Hold a review meeting within the team, analyze the test results, understand the product performance, and make plans for the improvement needed for the next iteration.
4.？ Modify the project plan
( 1) ? In the product identification stage, the product function and development process should be recorded in the form of documents. When the development plan needs to be revised, it should be discussed with the customer to let the customer know the influence of the plan revision on the project progress.
(2) ? The modification of the project plan shall be put forward by the unified person in charge and approved by the leader of the user requirements audit team. Requirements changes should be put forward regularly, not at any time.
(3) ? Detailed written records should be made for planned changes, so that customers can understand the actual situation of demand changes and the costs paid by developers.
Seven. Product delivery
1.？ Post-audit of the project
After the project development is finally completed, it can be regarded as a burden for developers to put down their work, but it is often a critical moment for project managers. Early risk assessment, cost budget, demand analysis and software design are all aimed at guiding the project to this moment, when all eyes will be on the project management personnel. You may find that a lot of trivial work will be finished in a few hours. At this moment, the project manager needs to stay awake and calm, and regard the final work as a micro-project. Carefully review the project in the later stage, and analyze the project results, the efficiency of the project team and the value of deliverable products, so that the audit results can be regarded as part of the summary of project management experience.
2.？ Quality evaluation
Before the project is delivered, the project should be submitted to the relevant "Quality Assurance" (QA) department for quality review, and typical users should be invited to feel the quality of the product.
3.？ Final delivery of the project
In general, the project delivery agreement will be concluded in the early stage of the project, and the project delivery methods are divided into informal acceptance and formal acceptance. After the general project is completed, informal acceptance will be conducted first, so that customers can experience the quality of the project and give feedback. Finally, the formal product acceptance will be carried out in the form of written agreement after the customer confirms the product quality.
4.？ Final report of the project
At the end of the project, the final report of the project should be made, which can be regarded as the record of the project, but the report does not have to include all aspects of the project. The general final report should include the following aspects:
( 1) ? The initial project view when the project is first introduced.
(2) ? Value evaluation and supporting information of the project
(3) ? scope of project
(4) ? Project development process and WBS
(5) ? Minutes of project meeting
(6) ? Project change report and reasons for change.
(7) ? Communication process documents related to the project
(8) ? Project audit report and customer acceptance report
(9) ? Performance report of project members
(10) The final result of the project