Summary of Project Management learning

Project Management Summary:

1. Risk Assessment
2. Cost budget
3, the process of customer communication
4. Demand Analysis
5. Object-oriented design (coding process)
6. Development Management
7. Delivery of finished products

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. But the software project risk divides into the product scale risk, needs the risk, the correlation risk, the management risk, the security risk and so on six aspects:

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

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 needs
(6) Changing demand
(7) Lack of effective demand change management process
(8) Lack of correlation analysis for changes in demand

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

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

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

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.

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.
(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. Contempt for system maintainability is the biggest risk for large software systems. 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.

Cost Budget Cost budgeting method

(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 find and correct their problems in silence, which often leads to many problems for the project.
Top-down is more suitable for project start-up, and the actual cost difference between 30% ~ 70%.
Scrum uses a top-down, cost-budgeting approach that does not immediately and accurately determine costs, but rather to maximize the changes that customers make to future product requirements.
(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%.
Annotations: WBS
The WBS is the decomposition of the project for the deliverables, and the list of deliverables can determine the activities that each submission needs to perform. Scrum further refines the WBS, decomposes one iteration into one or more work packages, and decomposes the work package into small development tasks (the development cycle for general development tasks is within 15 business hours).
2. Determining project expenditures
The overall cost budget is the development cost combined with the following multiple cost budgeting methods:
(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 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
Back to Catalog

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.

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.

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.

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.

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.

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
A. To clarify the end-use departments and users, to understand their existing working methods, to let them know the project's target framework, know the project to solve their difficulties, but it is not all the difficulties, so that the scope of the project can be better controlled.
B. 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.
C. To make clear the need to identify 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.
D. 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.
Back to Catalog

The process of requirement analysis for demand analysis

The requirements process consists of 2 parts: demand development and requirements management.
(1) Demand development is the management of 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.

Level of demand

The level of requirements include: business requirements, user requirements, functional requirements, non-functional requirements, such as 4 aspects.

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
In the demand analysis should be appropriate in this regard, the development of the software to give a 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.

Tasks for 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
Note: 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.)
Back to Catalog

Object-Oriented Programming (abbreviated) 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.

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
Back to Catalog

Development management set up 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
Reasonable allocation of the time and cost required 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, which are assigned to the team members, and development time should be within 15 business hours. If the development time exceeds 15 working hours, you should consider refining the development task 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.

Management 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
Within each iteration cycle (typically 15~30 business days), each work package should be further subdivided into multiple development tasks, and the development tasks assigned to the team members are responsible, and the development time should be within 15 business hours. If the development task is more than 15 working hours, you should consider refining the task again. The development task should be assigned to each member in a freely selectable manner.
(3) Monitor development progress
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 test
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.

Regulatory 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.
Back to Catalog

Post-audit of product delivery projects

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.

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.

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.

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

Summary of Project Management learning