Software Project Management Process summary

Project management is closely related to the quality, efficiency, and final results of software development, this article describes the software project risk assessment, cost budget, customer communication, needs analysis, development management, finished product delivery and other processes.
In today's domestic projects, the management form is very messy, and there is a lack of emphasis on management. As a result, many projects are eventually bent down due to the loss of management.
Many practical talents only focus on the development process, and lack of understanding of other processes (including myself), leading to a lack of systematic and phased management of projects.
I am a typical developer who only pays attention to development. I have learned the importance of management many times. Therefore, this article summarizes project management, there are many shortcomings. Please comment!

File Download: project management process .docx

1. Risk Assessment
2. Cost budget
3. Customer communication process
4. Requirement Analysis
5. Object-Oriented Programming (omitted)
6. Development Management
7. Product Delivery

I. Risk assessment

Software Project risks refer to the cost budget, development progress, technical difficulty, economic feasibility, and security management issues involved throughout the project cycle, and the impact of these problems on the project. The project risk is inversely proportional to its feasibility. 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 include product scale risks, demand risks, correlation risks, management risks, and security risks:

1. Product scale risks

Project risks are directly proportional to the product scale. Generally, the larger the product scale, the more prominent the problem. In particular, the estimation of product scale, the amount of Software Reused, the amount of demand changes, and other factors are closely related to product risks:

(1) Estimation of product scale

(2) Product Scale Estimation Trust

(3) deviation between product scale and Average Scale of previous products

(4) number of product users

(5) Number of Reusable Software

(6) How many changes are required?

2. Demand risks

Many projects are faced with some uncertainties when determining their needs. When these uncertainties are tolerated in the early stages of the project and cannot be resolved during the project's progress, these problems will pose a great threat to the project's success. If you do not control the risk factors related to the demand, it is very likely that the wrong product will be generated or the expected product will be poorly constructed. Each scenario may be fatal to the product. these risk factors include:

(1) lack of a clear understanding of the Product

(2) Lack of recognition of product requirements

(3) insufficient customer participation during Requirement Analysis

(4) No priority requirements

(5) New markets due to uncertain needs

(6) changing demands

(7) Lack of effective demand change management process

(8) lack of relevant analysis on demand changes

3. Correlation risk

Many risks are caused by the correlation of the project's external environment or factors. Controlling external relevance risks can mitigate the need for a strategy to include a probability plan so that necessary components can be acquired from a second resource or collaborative work resource and potential problems can be identified, factors related to the external environment include:

(1) customer supply items or information

(2) Interaction member or interaction group dependency

(3) Relationship between internal and external Switches

(4) availability of experienced personnel

(5) Project reusability

4. Technical Risks

The rapid development of software technology and the lack of experienced employees mean that the project team may be affected by technical skills. In the early stages, identifying risks and taking appropriate preventive actions are critical to solving risks, such as training, hiring consultants, and recruiting appropriate talents for the project team. There are mainly the following risk factors for technology:

(1) lack of training

(2) insufficient understanding of methods, tools and technologies

(3) insufficient experience in the application field

(4) unfamiliar with new technologies and development methods

5. Manage Risks

Although management issues constrain the success of many projects, do not be surprised because the risk management plan does not include all management activities. In most projects, project managers are often people who write project risk management plans. They have inherent defects-they cannot check their own errors. Therefore, project success becomes more difficult. If you do not face up to these thorny problems, they are likely to affect the project itself at a certain stage of the project. When we define the project tracking process and clarify the project roles and responsibilities, we can deal with these risk factors:

(1) Insufficient plans and task Definitions

(2) do not know the actual project status

(3) Unclear project owners and decision makers

(4) unrealistic commitments

(5) Insufficient communication with employees

6. Security Risks

Software products are creative products, and their core technologies are very important to keep confidential. However, for a long time, we have a relatively weak security awareness in the software field. We focus mainly on the technology in the development of software products, while ignoring the protection of patents. The flow of technical personnel in the software industry is a common phenomenon. With the loss and change of technical personnel, the leakage of products and new technologies can easily lead to the theft of our software products, the project fails. In addition, there is no clear industry specification for the identification of intellectual property rights in software, which is also a potential risk for our software projects.

7. Risk Avoidance Methods

(1) The demand is highly consistent with the real expectations of the customer. This document is written to facilitate the formation of user requirements, so as to avoid the loss caused by omissions being gradually amplified in the subsequent stages of the software system.

(2) establish a supervision system. any major decision during project development must involve customers. In this project, project supervision is implemented by the quality supervision group in project development.

(3) demand changes must be put forward by a unified owner and approved by the user's requirements. demand changes should be put forward on a regular basis rather than at any time, and the developer should make a detailed record, let the customer know the actual situation of demand changes.

(4) the complexity of the control system, the system structure is too simple, there will be a significant discount on the proportion of users to use, or even lead to a short software life. On the contrary, the software structure is too flexible and universal, which will inevitably lead to an increase in the difficulty of software implementation, the complexity of the system will increase, and this will bring risks in the implementation and testing phase. Proper control of system complexity helps reduce development risks.

(5) from the software engineering perspective, the software maintenance cost accounts for about 55% of the total cost ~ 70%. The higher the system, the higher the cost. Contempt for system maintainability is the biggest risk of large-scale software systems. During the long operation period of the software, the business rules will certainly continue to develop. The scientific solution to this problem is to constantly upgrade the software system version and gradually expand the system while ensuring maintainability.

(6) set up an emergency plan. Each development plan should have at least one emergency plan to deal with emergencies and unknown risks.

Back to directory

Ii. cost budget

1. Cost Budgeting Method

(1) Top-Down budgeting

The top-down pre-planning method is mainly based on the management experience of upper-and middle-level project managers to estimate the sub-project costs that constitute the overall project cost, and pass the results of these judgments and estimates to the management personnel at the lower layer. On this basis, the management personnel at the lower layer estimate the sub-tasks and sub-project costs of the project, then they continue to pass their cost estimates to the next layer until they are passed to the lowest layer.

In this way, when the upper-level management personnel estimate the cost to the lower-level based on their experience, the lower-level personnel may think that the upper-level estimation is not enough to complete the corresponding task. At this time, the lower-level personnel may not express their true views, but may not discuss them rationally with the upper-level management personnel to come up with a more reasonable budget allocation plan. In reality, they often have to wait for the upper-level managers to discover and correct the problems themselves, which often brings many problems to the project.

Top-down is more suitable for the early stage of project startup, with a 30% ~ In the range of 70%.

Scrum uses a top-down cost budgeting method that does not immediately and accurately determine the cost, but maximizes the capacity for changes to customers' requirements for future products.

(2) Bottom-up budgeting

The bottom-up method requires the use of WBS (Work Breakdown Structure, Work Breakdown Structure) to carefully examine the time and budget of all Work tasks of the project. Initially, the budget is for resources (team members' working hours and hardware configuration, the total project budget is formed by adding appropriate indirect costs (such as training costs, management costs, and non-renewal fees) and the profit target to be achieved by the Project Manager. The bottom-up budgeting method requires that all the tasks involved be fully considered. It is more suitable for the initial and middle stages of the project. It can be used to assess the cost of the project, which is 5%-different from the actual cost ~ In the range of 10%.

Note: WBS

WBSIt is a project decomposition oriented to the submitted results. From the list of submitted results, you can determine the activities to be executed for each submitted results. Scrum further refines WBS and splits an iteration into one or more work packages, then, the Work Package is divided into small development tasks (generally, the development cycle of a development task is less than 15 working hours ).

2. Determine project expenditure

The overall cost budget is the development cost calculated based on the following multiple cost budgets:

(1) Zero-base budget

In the initial stage of the cost budget, we should use the zero-base calculation principle, instead of using a rough calculation method similar to: the total cost of the previous year plus 20%.

(2) hardware and software costs and item costs

Item costs refer to the costs of servers (RAID clusters of RAM hard disk cpu nic cards), maintenance costs, server room rent, optical fiber communication costs, and software costs.

When calculating the cost, consider the length of Hard Disk assembly, the quality required by technicians, whether product suppliers can provide quality assurance, and whether additional management personnel are required for management.

(3) software license cost

(4) outsourcing costs

When using sub-projects such as videos, text messages, mobile telecommunication services, and portals, you can consider outsourcing to reduce development costs.

(5) Human resource costs

Calculate the average cost of human resources by estimating the average efficiency with the highest and lowest efficiency.

(6) maintenance costs

Back to directory

3. Customer communication process

From the perspective of customer communication, software projects can be divided into four different stages: requirement identification, solution customization, project implementation, and project end. Each stage has different communication priorities.

1. Demand identification stage

(1) text Communication

In the early stage of requirement identification, comprehensive and multi-angle analysis should be conducted through questionnaires, prototype presentations, interface presentations, logic processing presentations, and quasi-document templates, and unclear information should be provided to customers at any time, we look forward to your answers. In addition, the document record is used to create a document for analysis, and the customer is required to review the requirement analysis book so as to achieve a high degree of consistency between the analysis and the customer's real expectations.

(2) Business Logic Communication

When conducting business communication, you should understand the customer's industry language to promote the business analysis process and bridge the gap between application requirements and development. The communication process advocates sketch or visual informationization, and provides the most suitable operation interface for enterprise users at different levels. To think about problems from multiple perspectives, we must focus on the needs, especially the innovation and renewal needs of the customer's leadership.

(3) standardized management of demand changes

Demand changes can be understood in software development projects, but must be managed in a standardized manner to avoid the risk of endless demand changes. Demand changes must be put forward by a unified owner and approved by the user requirement review leader. Demand changes should be made on a regular basis rather than at any time. Developers should make detailed text records so that customers can understand the actual situation of demand changes and the cost paid by developers.

2. Solution customization stage

In this phase, the main task of the project is to work with the customer to develop a clear demand for the previous period, resources of both Parties, project start stage, implementation time agreement, project cost restrictions, etc. operable project plan, starting from this phase, we strive for customers to fully participate in project management and take into account the specific plans and risk avoidance of project implementation in the mutual interests of both parties.

3. Project implementation stage

At this stage, the software project team should work with the customer to lead the implementation of the project. At the same time, the project team should assess customer satisfaction in real time and improve customer satisfaction through continuous improvement. Customers should also be asked to participate in necessary training and check the project products if necessary. Before a change to a customer's needs occurs, the customer should take the initiative to communicate with the customer, so that the customer can fully understand each link of the project and the impact of the change, so as to reduce the demand change. In the event of a customer requirement change, we should work with the customer to resolve the cost, progress, and quality changes caused by the change.

4. End Stage

In this phase, the project results are handed over and the system is delivered to maintenance personnel to help customers achieve business objectives and settle various payments. After completing these tasks, you should evaluate the project, review the results of the project, and summarize the project experience.

5. Precautions for presales personnel

When a product project is used as a development result, the sales personnel should note that the sales promotion of the product should not be over-committed. If the commitment is excessive, it will bring difficulties to the subsequent project implementation. Once the commitment is not fulfilled, it will also reduce customer satisfaction and affect future cooperation. If there is an additional commitment, it must be recorded in text form, so that the implementation project manager can be informed and communicated to the project team members.

Note: In software projects, you must specify the following four Customer roles:

A.To make it clear that departments and users are used in the end, they need to understand their existing work methods, to let them know the target framework of the project, and to know what difficulties the project has to solve, but it is definitely not all of them, in this way, the project scope can be better controlled.

B.If you want to clarify the demand, he or she must be able to represent the end customer group. This type of customers who propose product requirements must have certain technical, business capabilities and authority, be able to truly represent the willingness and ideas of the end customer team, and have an IT Foundation, IT can describe problems and requirements in IT languages to facilitate communication and collaboration between the two parties and avoid ambiguity.

C.To clarify the middle-level leaders who need to confirm their needs, they must grasp the direction. A Software Development Project is a customer leader who solves the actual production or management problems and specifically implements the construction of the Leadership System. The customer leader who confirms the requirements should understand the key points and directions of system construction by senior leaders, it is necessary to familiarize yourself with the specific business and production management practices. If such customer leaders hold and make decisions, the smooth development of enterprise software development projects will play an extraordinary role.

D.Determine who will give comments on the finished product and who will accept the product. The project acceptance stage is the final stage of the project. If the acceptance personnel do not understand the needs and objectives of the initial stage of the project, they will have a negative impact on the acceptance from the attitude and actual use of the product, it is very unfavorable for enterprises that provide products to close their projects. According to the practice summary, the project acceptance should be conducted by the requirement creator and the validator, which can promote the smooth completion of the project and avoid delays.

Back to directory

IV,
Requirement Analysis

1. Requirement Analysis Process

The requirement process consists of requirement development and requirement management:

(1)
Requirement development is the management of the early stage of development. The communication process with the room can be divided into four stages: requirement acquisition, requirement analysis, requirement writing, and requirement verification.

(2)
Requirement management: activities that control and maintain requirements agreements during software project development. Including change control, version control, requirement tracking, and requirement status tracking.

2.
Requirement level

There are four levels of requirements: business requirements, user requirements, functional requirements, and non-functional requirements.

3. Key points in the demand development stage

(1)
Extract Business Objects

A business object refers to the real objects used by the system. For example, a Supply Chain Management (SCM) business object mainly includes multiple levels of wholesalers, retailers, shipping providers, and customers.

(2)
Extract Business Flow

In the process of understanding the business logic, we should list the respective functions of the developed software module, refine each workflow, and analyze the business logic in depth.

(3)
Performance Requirements

In the early stage of analysis, you should pay attention to the technical performance indicators of the software you have developed, such as storage capacity limit, running time limit, and security and confidentiality.

(4)
Environment requirements

Environment requirements refer to the requirements of the environment where the software platform is running, such as hardware: models, external devices, and data communication interfaces; Software: system software, this includes the operating system, network software, and database management system. Usage: What are the technical requirements of the user department and the operator.

(5)
Reliability Requirements

The probability that the developed software will fail after it is put into operation should be put forward according to the actual operating environment. High reliability requirements should be put forward for important software or software that may cause serious consequences if the operation fails.

(6)
Security and confidentiality requirements

In demand analysis, appropriate provisions should be made in this respect, and special designs should be made for the developed software to ensure its security and confidentiality performance during operation.

(7)
User Interface requirements

Specify the requirements for arrival for the user interface in detail.

(8)
Resource usage requirements

Various resources required by the developed software at runtime and during development.

(9)
Software Cost consumption and development progress requirements

After the software project is established, the software development progress and the cost of each step are required in accordance with the provisions of the contract as the basis for development management.

(10) development target requirements

Estimate the possible goals of the system in advance, which makes it easier to supplement and modify the system.

4.
Requirement Analysis task

The main task of requirement analysis is to use the logic model of the current system to export the logic model of the target system. The process is as follows:

(1)
Determine the comprehensive requirements for the system (functional, performance, operation, and expansion requirements)

(2)
Create Product Requirement document (PRD)

(3)
Analyze the data requirements of the system (conceptual model, data dictionary, and standardization)

(4)
Export the detailed logical model of the target system (data flow diagram, data dictionary, and main function description)

(5)
Develop a prototype system

(6)
Prepare Software Requirement Specification (SRS) from PRD Extraction)

Note: SRS format

1.Introduction 2 System Overview (project background, system objectives, and core business processes) 3. Glossary
4. System Structure (Architecture diagram and function diagram)

5.Main functions and business logic (Key Points) 6. interface requirements (internal and external interfaces) 7. Overall Network Design (topology network, host, and networking)

8.Running Environment (Linux, Windows, IIS,
WebLogic, Tomcat, OLAP, OLTP, JDK 8.0,. NET Framework
4.0)

 

Back to directory

V,
Object-Oriented Programming (omitted)

1.
Design principles

(1) SRP single responsibility chain

Each class should be responsible for only one thing.

(2) OCP Kaifeng closure Principle

Software entities (classes, modules, functions, etc.) should be extensible, but cannot be modified.

(3) LSP replacement principle

Subclass must be able to replace their base type.

(4) DIP Dependency inversion principle

High-level modules should not depend on low-level modules. Both of them should depend on interfaces and abstract classes. Abstraction should not depend on details, but on objects.

(5) ISP interface isolation principle

Instead of forcing the customer to rely on unused interfaces, the fat interfaces should be separated.

2.
Implement UML modeling

(1) Business Object Extraction

(2) Use Case Modeling Based on SRS and CRC

(3) Business sequence diagram

(4) create a class chart and establish the association between Objects Based on the condition chart.

(5) Draw activity diagrams, implement collaboration diagrams, and State Diagrams

 

Back to directory

Vi. Development Management

1.
Create a project plan

(1)
Design overall architecture

Appropriate and mature framework structures are adopted to address system implementation needs.

(2)
Control scalability

Expansion will increase the complexity of the system and extend the development time. low expansion will directly affect the system's secondary development and maintenance. The scalability of the control system can improve the development efficiency and reduce the difficulty of system maintenance.

(3)
Build infrastructure

Reasonably allocate the time and cost required for the deployment of software and hardware infrastructure (for example, ordering and installation of servers, fiber optic access, and ordering of software platforms ).

(4)
Divide development tasks

Use WBS (Work Breakdown
Structure. Each project can be divided into multiple different stages, and each stage can be divided into multiple Work Packages (
Package), the Work Package is the smallest deliverable in The WBS, and finally the Work Package is divided into multiple development task lists.

(5)
Deployment and development progress

A project should be divided into multiple development stages by schedule. The development cycle of each stage is generally 30 ~ Within 60 working days. During this phase, a consultation meeting should be held with the customer to formulate the product roadmap, invite the customer to actively participate in the development process, and provide feedback. Then, the development tasks in this period are divided into multiple iteration cycles according to the development difficulty, dependency, importance, and other multi-party conditions.

In the agile software development principle of Scrum, each iteration task should be further divided into multiple development task lists, and then the development task is assigned to the team members for their respective responsibilities, the development time should be controlled within 15 working hours. If the development time exceeds 15 working hours, you should consider refining the development task again. It is recommended that the development task should be selected by the team members rather than by force allocation.

(5)
TEST project results

Each work package should be deployed and tested simultaneously to improve the quality of the project. The work package for error Bugs should be recorded by the tester in text format to show the developer where the error is located, so that the developer can modify it in time.

2.
Manage development teams

(1) build a team

Establish a team based on the work tasks and project time, and allocate personnel according to the team's responsibilities. Generally, the number of teams should be limited to 8 ~ Between 12 persons. When the number of teams exceeds 15, you should consider splitting the team into two independent teams to take charge of different development tasks.

(2) allocate development tasks

Within each iteration cycle (generally 15 ~ 30 working days), each work package should be further divided into multiple development tasks, and the development tasks should be assigned to the team members for their respective responsibilities. The development time should be controlled within 15 working hours. If the development time of a development task exceeds 15 working hours, you should consider refining the task again. Development tasks should be assigned to each member in a free-of-choice manner.

(3) supervise the development progress

Hold a meeting in the early stage of the iteration to let the team members know the development progress and process, and assign development tasks in their own choice. You can use tools such as Microsoft Project to record the progress of the development process. After each work package completes development, you should test the function and record the test results in text.

A 15-minute standing meeting is held every day to ask the team members to explain the development tasks completed yesterday, the tasks to be done on the same day, and problems encountered during the development. A routine meeting is held every weekend to explain the overall process.

A sprint meeting was held at the end of the iteration to summarize the progress of the project, hand in the completed tasks, review the problems encountered in the iteration cycle, and prepare for the next iteration.

(4) System Test

Test each completed work package in a timely manner to ensure system quality and performance. Record the test results in text, link the test results with the performance salary income, and calculate the Performance income of the team members based on real data.

(5) solve problems encountered during development

In the early stage of training for developers, tasks can be allocated according to the working ability to guide the development of team members. When a problem occurs, the problem should be raised immediately during the Standing Meeting on the day and solved within 15 working hours to prevent further expansion of the problem.

3.
Supervise Product Quality

(1) quality requires planning, design, rather than review. At the initial stage of product establishment, you must negotiate with the QA Department to determine the appropriate quality policies and standards in the form of formal documents.

(2) Use TDD (test-driven development) mode during development to improve the development quality. Testers should record bugs in text mode and work with developers to demonstrate outstanding defects to developers to improve the modification efficiency.

(3) A product effect demonstration is conducted at the end of each iteration to collect feedback from customers, users, and senior leaders. Hold a review meeting within the team to analyze the test results, understand the product performance, and plan the improvements required for the next iteration.

4.
Modify a project plan

(1) In the product needs identification stage, product functions and development processes should be recorded in the form of documents. When the development plan needs to be modified, it should be discussed with the customer, let the customer know the impact of plan Modification on the project progress.

(2) The change of the project plan should be proposed by the Unified owner and approved by the leader who reviews user requirements. Demand changes should be made on a regular basis rather than at any time.

(3) A detailed text record should be prepared for planned changes, so that the customer can understand the actual situation of the changes and the cost paid by the developer.

 

Back to directory

VII,
Product Delivery

1.
Post-project review

After the project development is completed, it is 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. At this time, all eyes will be directed to the project management personnel. You may find that a large amount of trivial work will be completed within several hours. At this moment, the project manager needs to stay awake and calm, and treat the final work as a micro-project. Carefully review the project, analyze the project results, the efficiency of the project team, and the value of deliverables. The review results can be summarized as part of the project management experience.

2.
Quality Review

Before project delivery, the project should be handed over to the relevant QA department for quality review, and typical users should be invited to feel the quality of the product.

3.
Project final delivery

Under normal circumstances, a project delivery agreement will be concluded in the early stage of the project. The project delivery methods can be divided into informal acceptance and formal acceptance. Generally, informal acceptance is performed first after the project is completed, so that the customer can understand the quality of the project and provide feedback, finally, after the customer confirms the product quality, the formal product acceptance will be conducted in the form of a written agreement.

4.
Project Final Report

At the end of the project, the final report of the project should be prepared, which can be considered as a record of the project, but the report does not need to include all aspects of the project. The general final report should include the following:

(1) initial project view when a project is initially introduced

(2) evaluation of the project's value and supporting information

(3) Scope of the project

(4) project development process and WBS

(5) project meeting records

(6) Report on project Changes and reasons for changes

(7) project-related communication process documents

(8) Project Review Report and customer acceptance report

(9) project member performance report

(10) final results of the project

Back to directory

Welcome to the QQ group: 162338858. Blog forum discussion group:. NET Advanced Programming

Author: wind dust prodigal son

Http://www.cnblogs.com/leslies2/archive/2012/06/29/2569765.html

Original Works. Indicate the author and source when reprinting.