Software Project Management Process Summary

First, the intention of the customer two, the customer booking List III, risk assessment

Software project risk refers to the cost budget, development progress, technical difficulty, economic feasibility, safety management and other problems involved in the whole project cycle, and the impact of these problems on the project. The risk of the project is inversely proportional to its feasibility, the higher the feasibility, the lower the risk. The feasibility of software project is divided into four aspects, such as economic feasibility, business feasibility, technical feasibility and legal feasibility. The risk of software project is divided into six aspects: product scale risk, demand risk, correlation risk, management risk, security risk, etc.

1. Product scale Risk

The risk of the project is proportional to the scale of the product, the larger the general product size, the more prominent the problem. In particular, the method of estimating product size, the number of reuse software, the number of changes in demand and other factors related to product risk:

(1) Methods for estimating product size

(2) Trust degree of product size estimation

(3) Deviation of product size from the average of previous product size

(4) Number of users of the product

(5) How much of the reuse software

(6) How much the product needs change

2. Demand risk

Many projects face some uncertainty when it comes to identifying requirements. When these uncertainties are tolerated early in the project and are not addressed in the course of the project's progress, these problems pose a significant threat to the success of the project. Without controlling the risk factors associated with demand, it is possible to produce the wrong product or poorly build the intended product. Each case can be fatal to the product, and these risk factors are:

(1) Lack of a clear understanding of the product

(2) Lack of recognition for product demand

(3) Customer participation is not enough in the process of doing demand analysis

(4) No priority required

(5) The new market is caused by uncertain demand

(6) Changing demand

(7) Lack of effective demand change management process

(8) Lack of correlation analysis for changes in demand

3. Related risks

Many risks arise from the relevance of the external environment or factors of the project. To control the external correlation risk, the mitigation strategy should include the possibility plan to obtain the necessary components from the second or collaborative work resources, and to perceive potential problems, factors related to the external environment:

(1) Customer supply items or information

(2) Interaction member or interaction group dependency

(3) Relationship of internal or external subcontractors

(4) Availability of experienced personnel

(5) Reuse of the project

4. Technical risk

The rapid development of software technology and the lack of experienced staff means that the project team may be able to influence the success of the project for technical reasons. In the early days, identifying risks and taking appropriate precautions are key to addressing risk areas such as training, hiring consultants, and recruiting the right people for the project team. There are the following risk factors for technology:

(1) Lack of training

(2) Lack of understanding of methodologies, tools and techniques

(3) Lack of experience in the field of application

(4) Unfamiliar with the application of new technologies and development methods

5. Managing Risk

Although management issues constrain the success of many projects, do not be surprised that the risk management plan does not include all management activities. In most projects, project managers are often the ones who write project risk management plans that have congenital deficiencies-and cannot check their mistakes. Thus, the success of the project becomes more difficult. Without addressing these thorny issues, they are likely to affect the project itself at some stage of the project. These risk factors can be addressed when we define the project tracking process and clarify the role and responsibilities of the project:

(1) Inadequate planning and task definition

(2) Do not understand the actual project status

(3) The project owner and the decision-maker are not clear

(4) Unrealistic promises

(5) Inability to communicate fully with employees

6. Security Risks

The SOFTWARE product itself belongs to the creative product, the core technology of the product itself is very important to keep secret. But all along, we in the software this aspect of security awareness is relatively weak, the development of software products mainly focus on technology itself, and neglect the protection of patents. The flow of technical personnel in the software industry is very common phenomenon, with the loss of technical personnel, changes, can lead to the disclosure of products and new technologies, resulting in our software products stolen by its company, resulting in project failure. In addition, there is not a clear industry specification for the identification of intellectual property in software, which is the potential risk of our software project.

7. Ways to avoid risk

(1) The development of the guidance to ensure the integrity of the demand, so that the demand and customer's true expectations of high consistency. And then in writing to facilitate the formation of the "user needs" this important document, to avoid the loss caused by omission in the software system in the subsequent stages of the gradual amplification.

(2) The establishment of a supervisory system, any larger decision in the project development must have the customer participation, in the project supervision by the project development in the quality Supervision team to implement.

(3) Demand changes need to be unified by the responsible person, and to the user needs of the audit leadership approval, the need for change should be regular and not at any time, and developers should do a detailed record, so that customers understand the actual situation of changes in demand. (This point in the general company can, but in a similar ZZGA administrative units must be required to a project in the different functional modules (which is essentially subsystem module) responsible for communication and final decision to the project counterpart in charge of the record, to be well-reasoned)

(4) The complexity of the control system, too simple system structure, the user to use the proportion will have a significant discount, or even lead to software life is too short. On the contrary, the software structure is too flexible and universal, it will inevitably lead to the difficulty of software implementation increases, the complexity of the system will rise, which would bring risks in the implementation and testing phase. Proper control of the complexity of the system helps reduce the risk of development.

(5) from the software engineering point of view, the software maintenance costs accounted for about the total cost of 55%~70%, the larger the system, the higher the cost. The contempt for system maintainability is the biggest risk for large software systems (this is where the company's top leaders are ignoring or not attracting attention at present, our company lacks in this regard). During the long period of software operation, the business rules are sure to evolve, and the scientific solution to this problem is to continuously upgrade the software system and gradually expand the system under the premise of ensuring maintainability.

(6) To set up contingency plans, each development plan should at least set up a contingency plan to deal with the unexpected situation and the risk of not knowing. (At present, the ZZGA evaluation project is because I originally this consciousness guidance can avoid the end of last year evaluation to exchange or unit evaluation can not use the rumor in time to stop, gave us a vivid lesson. ）

Second, the cost of the budget 1. Cost budgeting approach

(1) Top-down budgeting methods

The top-down approach is based on the management experience of upper and middle-level project managers, estimates the cost of sub-projects that comprise the overall cost of the project, and transmits the results of these judgments to the lower management staff. Based on this, the managers of this layer estimate the cost of the sub-tasks and sub-projects that comprise the project, and then continue to pass their cost estimates down one level until they are passed to the lowest level.

Using this budget approach, when the upper management staff based their experience on the cost estimates are broken down to the lower level, it may appear that the lower level estimates are insufficient to complete the corresponding task. At this point, the lower-level people do not necessarily express their true views, not necessarily with the upper management of the rational discussion, so as to obtain a more reasonable budget allocation plan. In practice, they often have to wait for the top managers to send their own

and correct the problem, which often leads to many problems for the project. (This is the source of the current Zzga project)

Top-down is more suitable for project start-up, and the actual cost difference between 30% ~ 70%.

Scrum uses a top-down approach to cost budgeting, which does not immediately and accurately determine costs, but rather to maximize the customer's future product requirements

The resulting change.

(2) Bottom-up budgeting approach

The bottom-up approach requires a careful review of the time and budget of all work tasks in the project using the WBS (work breakdown Structure, working breakdown structure). Initially, the budget is for resources (team members work time, hardware configuration), and the project manager on top of the appropriate indirect costs (such as training costs, management costs, unforeseen costs, etc.) and the project to achieve the profit goal of the project to form a total budget. The bottom-up budgeting approach requires full consideration of all the tasks involved, and is more applicable to the initial and mid-term of the project, which can be prepared to estimate the cost of the project, which differs from the actual cost between 5% and 10%. (Here is a little need to emphasize that after the project contract is set down, you can not blindly request according to the contract to investigate the demand, because as long as there is this idea and error awareness, will be in the demand research process, can not let customers sparing, speak freely, the result is we are tired of it. Because modifying a system is more cost-efficient than developing a system, and requires more programmers. So my advice is that demand research and development process all require close cooperation with customers, sparing, the key is to achieve their hearts want. In this way, we can restore the customer's real needs to the maximum. The specific needs of which are both inside and outside the contract can be verified afterwards. And should not be in the pre-contract in hand, to the customer caused adverse effects, the final customer needs in any case is to achieve otherwise acceptance is empty paper. Function can be added after the contract amount is the company's business management matters, the main function of the development team is to guide the customer demand, to meet the reasonable needs of customers. )

Annotations: WBS

WBS is the decomposition of the project to a deliverable, from the list of deliverables to determine the activities that each submission needs to perform. Scrum further refines the WBS and decomposes each iteration into a smaller work package.

2. Determining project expenditures

2.1, the Marketing department expenditure (the company's overall publicity, some project promotion information)

2.2. Expenditure of the Business Department

2.3. Cost of Development Department

The overall cost budget is a combination of the following multiple cost budgeting methods to form the overall cost of development:

(1) 0 base budget

In the early stages of the cost budget, the 0 cardinality calculation principle should be used, rather than using a rough approach like the one-year total cost plus 20% to calculate project costs.

(2) Hardware and software cost, item cost

Item cost is similar to: the cost of server (RAM hard disk CPU NIC card raid cluster) cost, maintenance cost, room rent, fiber communication cost, software cost and so on.

When calculating the cost, it is necessary to consider how long it takes to assemble the hard disk, the quality the technician needs, whether the supplier can provide quality assurance, and if the management requires additional management personnel.

(3) Software license cost

(4) Outsourcing costs

When using similar: Video, SMS, mobile telecommunications services, portals and other sub-projects, or more mature subsystems on the market can be considered in the form of outsourcing to reduce development costs.

(5) Human resources cost

The average cost of human resources should be calculated using the method of estimating the average efficiency at the highest and lowest efficiency in the calculation of human resources costs.

(6) Maintenance costs.

(7) Development of incentive costs. (More pay, distribution according to work, not the current company in accordance with the assessment of the allocation, to be reasonable, we are convinced. ）

Third, the process of customer communication

From the direction of customer communication, the software project can be divided into: Demand identification, program customization, project implementation, Project end and other 4 different stages, each stage has different communication priorities.

1. Requirements Identification phase

(1) Text communication

In the pre-demand identification, should be through questionnaires, prototype display, interface display, logical processing display, quasi-document template and other ways to carry out a full range of multi-angle analysis, at any time will be unclear feedback to customers, to look forward to customer answers. and to establish a textual record of the need for analysis of the book, and require customers to review requirements analysis book, in order to achieve the need to analyze the customer's real expectations of a highly consistent results.

(2) Business logic Communication

When conducting business communications, you should understand the customer's industry language to facilitate the process of business analysis, across the gap between application requirements and development. The communication process advocates a sketch or visual information-based approach to provide the most suitable interface for business users at different levels. To think in a multi-angle way, we should seize the focus of demand, especially the innovative and practical needs of the customer's leadership.

(3) Standardized management of requirements change

Requirements change is understandable in software development projects, but it is necessary to standardize the management of requirements changes to avoid the risk of endless changes in demand. Changes in requirements must be made by a unified owner and approved by the audit leader of the user's needs. Demand changes should be made on a regular basis rather than at any time, and developers should make detailed textual records to let the customer know the actual situation of the change in demand and the cost of the developer.

2. Program Customization phase

The main task of this phase of project is to work with the customer to develop an operational project plan based on the pre-defined requirements, the resources of the two sides, the phase of project initiation, the time agreement of the implementation, the project cost limit, etc., starting from this stage to obtain the full participation of the client in the project management. and to consider the specific plan and risk avoidance of the project implementation in the common interests of both parties.

3. Project implementation phase

At this stage, the software project team should co-lead the implementation of the project with the customer. At the same time, the project team should assess customer satisfaction in real time and improve customer satisfaction through continuous improvement, as well as requiring customers to attend the necessary training and inspect the project product as necessary. Before the customer needs to change, should take the initiative to communicate with customers, so that customers fully understand each aspect of the project, as well as the impact of changes, reduce demand changes. In the event of changes in customer requirements, the cost, schedule, and quality changes caused by the change should be resolved together with the customer. (for administrative agencies or units must be considered separately, the customer may have signed a contract, can not be arbitrarily modified, so the project team timely report to the company's leadership, the company's leadership decision whether to advance the cost of development in the follow-up project additional recovery. Or reject the customer's needs and explain why)

4. End Stage

This stage mainly carries on the handover to the project result, and delivers the system to the maintenance personnel, helps the customer to achieve the business goal, settles the various funds. After completing these tasks, the project evaluation should be carried out to review the results of the project and summarize the project experience.

5. Pre-Sales personnel precautions

In product-based projects as a result of development, the relevant sales staff should be aware of: product marketing should not be overly committed. If too much commitment, will bring difficulties to follow-up project implementation, once the commitment is not fulfilled, will also reduce customer satisfaction, affect future cooperation. If there is an additional commitment, be sure to record it in textual form so that the implementation project manager is aware and communicated to the project team members.

Note: In a software project, the following four types of customer roles need to be identified

1. To identify the end-use departments and users, to understand their existing way of working, to let them know the project's target framework, know the project to solve their difficulties, but not all the difficulties, so that the project can be better control of the scope.
   1. To clarify the needs of the proposed person, he or they want to be able to represent the end customer group. This kind of customer who put forward the product demand must have certain technical, business ability and authority, can truly represent the intention and idea of the end customer team, preferably has it foundation, can use it language to describe the problem and the demand, in order to facilitate the communication between the two sides, cooperation, avoid ambiguity.
   2. To clear the need to confirm the middle-level leadership, he must grasp the direction. Software development project is to solve the actual production or management problems, but also the specific implementation of leadership system construction, to do the needs of customer leadership, to understand the high-level leadership of the system construction points and direction, but also familiar with the specific business and production management practice. If this is the customer leadership to grasp and decision-making, the enterprise software development projects of the smooth progress of the extraordinary role.
   3. Be clear about who will make comments on the finished product and who will accept it. The project acceptance link, is the project close link, if the acceptance person to the project initial demand goal not to understand, will from the attitude and the product actual use effect to the acceptance to have the negative influence, to provides the product the enterprise closes the project very unfavorable. According to the practice summary, the request of the person and the confirmation person to do the project acceptance work, can promote the successful completion of the project, avoid delay.

Iv. Demand Analysis 1. The process of demand analysis

The requirements process consists of 2 parts: demand development and requirements management.

(1) Demand development is the management of the pre-development, and room communication process, can be divided into 4 stages: Demand acquisition, demand analysis, writing requirements

and requirements validation.

(2) Demand management: Is the software project development process Control and maintain requirements agreed activities. Includes: Change control, version control, demand tracking, demand status tracking.

2. Level of demand

The level of requirements include: business requirements, user requirements, functional requirements, non-functional requirements, such as 4 aspects. The requirements of the research staff is relatively high, at least a multi-project experience of senior programmers, ax.

3. The focus of the demand development phase

(1) Extracting business objects

Business object refers to the real object used by the system, such as a supply chain management (supply Chain Management, SCM) business objects mainly include: production wholesalers, retailers, delivery providers, customers at multiple levels.

(2) Extracting business process

In the process of understanding the business logic, we should enumerate the respective functions of the software modules developed, and refine each work flow to analyze the business logic in depth.

(3) Performance requirements

In the early analysis, we should pay attention to the technical performance index of the software developed by customers, such as storage capacity limit, running time limit, security secrecy and so on.

(4) Environmental requirements

Environmental requirements refers to the requirements of the environment in which the software platform is run, such as hardware: model, external equipment, data communication interface, software aspects: System software, including operating system, network software, database management system, use aspects: the use of departments in the system, operators on the technical level should have what kind of conditions.

(5) Reliability Requirements

The probability of failure of the developed software after it is put into operation should be demanded according to the actual operating environment. For the important software, or the operation of the failure will cause serious consequences of the software, should put forward high reliability requirements.

(6) Security and confidentiality requirements

The need for analysis should be appropriately defined in this regard, the development of the software to give special design, so that in operation, its security and confidentiality aspects of the performance of the necessary guarantees.

(7) User interface requirements

Provide the user interface with detailed requirements for arrival.

(8) Resource use requirements

The various resources that are needed to develop the software at run time and development time.

(9) Software cost consumption and development progress requirements

After the establishment of the software project, according to the contract, the progress of software development and the cost of each step of the requirements, as the basis for development and management.

(10) Development target requirements

It is easier to make the necessary additions and modifications to the system by pre-estimating the possible goals that the system will achieve in the future.

4. Task of demand analysis

The main task of demand analysis is to derive the logical model of the target system by means of the logical model of the current system, the flow is as follows:

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

(2) Create Product requirements document (PRD)

(3) Data requirements of the analysis system (conceptual model, data dictionary, normalization)

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

(5) Development of prototype system

(6) Extracting and compiling software Requirement specification (SRS) from PRD

Remarks: SRS format

1. Introduction 2 System Overview (project background, system objectives, core business processes) 3. Terminology Description 4. System structure (frame composition, function diagram)

5. main function and business logic (emphasis) 6. Interface requirements (internal, external interface,) 7. Network overall design (topology network, host, group network)

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

V. Object-oriented Programming (abbreviated) 1. Design principles

(1) SRP single responsibility chain

Each class should be responsible for only one thing.

(2) The closure principle of the OCP Kaifeng

The entities of the software (classes, modules, functions, etc.) should be extensible, but not modifiable.

(3) LSP Replacement principle

Subclasses must be able to replace their base types.

(4) Dip dependency Inversion principle

High-level modules should not be dependent on lower-layer modules, both of which should be dependent on interfaces and abstract classes. Abstractions should not be dependent on details, and details should be dependent on the object.

(5) ISP Interface Isolation principle

Customers should not be forced to rely on unused interfaces, but should separate the fat interfaces.

2. Implementing UML Modeling

(1) Extraction of business objects

(2) based on SRS, CRC and other implementation of the model

(3) Realization of business sequence diagram

(4) Create a class diagram to establish an association between objects based on the use case diagram

(5) Draw activity diagram, implement collaboration diagram, State diagram

VI. Development and Management 1. Establish a project plan

(1) Design the overall structure

For the implementation of the system needs to take appropriate and mature framework structure.

(2) Control of scalability

Expansion through the large, will increase the complexity of the system, extend the development time, the expansion through the low, will directly affect the system of two development and maintenance. The scalability of the control system can improve the development efficiency and reduce the difficulty of system maintenance.

(3) Building infrastructure

Allocate the time and cost needed to deploy infrastructure such as software and hardware (e.g. ordering and installation of servers, fibre access, software platform ordering).

(4) Division of development Tasks

Use WBS (Work breakdown Structure, working breakdown structure) to classify and divide deliverables. Each project can be divided into several different stages, each of which can be divided into multiple work packages (work packages), which are the smallest deliverables in the WBS, and finally the multiple development task lists are decomposed from the work pack.

(5) Deployment development Progress

A project should be divided into multiple development phases, with the development cycle of each phase typically within 30~60 business days. In this phase, we should hold consultation meetings with customers, develop product roadmap, invite customers to 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, dependence, importance and other multi-criteria.

In Scrum Agile software development principles, each iteration task should be subdivided into multiple development task lists, development tasks should be controlled within 15 working hours, and if development time exceeds 15 working hours, consideration should be given to refining the development tasks again. Development task recommendations should be chosen by the team members themselves, rather than forced allocations.

(5) test project results

Each work package should deploy test work synchronously and improve the quality of the project. The work package for the error bug should be recorded by the tester as text, showing the developer the error and allowing the developer to make changes in a timely manner.

2. Managing the development team

(1) forming a team

According to the work task and the project time precondition establishment team, according to the team responsibility assigns the personnel, the general team number should control in the 8~12 person. When the number of teams exceeds 15, consider splitting the team into 2 separate teams responsible for different development tasks.

(2) Assigning development tasks

In each iteration cycle (typically 15~30 business days), each work package should be further subdivided into multiple development tasks, the development time of the development task should be controlled within 15 working hours, if the development task development time exceeds 15 working hours, should consider the task refinement. The development task should be assigned to each member in a freely selectable manner.

(3) Supervise the development progress (currently ZZGA project team can not do, why?? There are many reasons, but the main reason is the overdraft limited programmer's energy and fuzzy programmer and maintenance personnel differences, short-term number up, but in the system is buried in the time bomb, resulting in system development efficiency can not be improved, and to the customer impression is very poor, customers have begun to question our development strength. ）

Hold a meeting in the early stages of the iteration to let the team members know the progress and process of the development, and assign the development tasks in a self-selected way. You can use tools such as Microsoft Project to document the progress of the development process, test the sexual function after each work package has been developed, and document the test results in a textual manner.

Hold a 15-minute stand-up meeting each day to let the team members account for the development tasks that were completed yesterday, the tasks that will be done on the day, and the problems encountered during the development process. A regular meeting is held every weekend to account for the overall process.

Hold a sprint meeting at the end of the iteration to summarize the progress of the project, submit the completed tasks, review the problems encountered during the iteration, and prepare for the next iteration.

(4) System testing (more pathetic is this, as a professional software companies do not know the importance of QA, so that developers both as athletes and referee, this misunderstanding let users directly feel that our program has not been tested on-line, but also let our version management overshadowed. The customer has again drawn a question mark on our development strength. ）

Perform timely testing of each completed work package to ensure system quality and performance. The test results are recorded in text, and the test results are linked to performance payroll income, and the performance income of the group is calculated with real data.

(5) Solve the problems encountered in the development

The development of the early training, can be appropriate according to the ability to assign tasks, to guide the development of team members. When problems are encountered, they should be presented immediately at the standing meeting of the day, and the problems encountered during the 15 working hours will be resolved to prevent further expansion.

3. Monitor product quality

(1) Quality needs to be planned, designed and not reviewed. At the beginning of the product establishment, the quality Assurance (QA) department must be consulted to determine the appropriate quality policies and standards in a formal document manner.

(2) using TDD (test-driven development) mode in the development process to improve the quality of development. Testers should document bugs in textual form and work with developers to present outstanding flaws to developers to improve the efficiency of their modifications.

(3) A demonstration of product effects at the end of each iteration, collecting feedback from customers, users, and senior leaders. Conduct review meetings within the team, analyze test results, understand product performance, and plan for the improvements that need to be made for the next iteration.

4. Modify the project plan

(1) In the product needs identification phase, the product function and development process should be documented, and when the development plan needs to be modified, it should be discussed with the customer to let the customer understand the impact of the plan modification on the project progress.

(2) The modification of the project plan should be made by the unified responsible person and approved by the audit leader of the user's requirement. Demand changes should be made on a regular basis rather than at any time.

(3) The planned changes should be made in a detailed textual record, so that customers understand the actual situation of the change in demand and the cost of the developer to pay the price.

Seven, product delivery 1. Post-audit of the project

When project development is finalized, it can be a burden for developers to put down their work, but this is often a critical time for project managers. Early risk assessment, cost budgeting, demand analysis, software design are to guide the project to this moment, at this time all eyes will be invested in project management personnel. You may find that a lot of trivial work will be done in a matter of hours, and the project manager needs to be sober and calm at the moment, treating the final work as a mini-project. Review the project in detail, analyze the results of the project, the efficiency of the project team, and the value of the deliverables, which can be used as part of the project management experience summary.

2. Quality Review

Before the project is delivered, the project should be assigned to the relevant quality assurance (QA) Department for Quality Review and invite typical users to feel the quality of the product.

3. Final delivery of the project

Under normal circumstances in the early stages of the project will be a project delivery agreement, the project delivery methods are divided into informal acceptance and formal acceptance of the two. Generally after the completion of the project will be the first informal acceptance, so that customers appreciate the quality of the project and provide feedback, and finally in the customer affirmation of product quality and then in the form of a written agreement on the formal product acceptance.

4. Final report of the project

At the end of the project, a final report on the project should be developed, which can be considered a record of the project, but the report does not have to contain all aspects of the project. The general final report should include the following:

(1) Initial project view when the project was first introduced

(2) Evaluation of the value of the project and supporting information

(3) Scope of the project

(4) Project development process and WBS

(5) Meeting minutes of the project

(6) The report of the project change and the reasons for the change

(7) Communication process documents related to the project

(8) Project audit report and customer acceptance report

(9) Performance report of Project members

(10) Final results of the project

Software Project Management Process Summary