Software project management method

Note: Warton (I have not published an article here for a year. I posted an article translated half a year ago to prove that I am still here :). Is about the project management method. The translation is not good. If you have any questions, let me learn. If you like it, I will take the time to translate some books in this area ...) Methods of Project ManagementBy Vox Guo translation Warton (unknown source)

This article is not called methodology but methods, because it concentrates on the specific ways used in the software development procedure. it focuses more on practical applications than on academic analysis. but as you all known, these conclusions are based on the past project experience and my personal feeling.So it is not confusing if there are some errors.Any further discussions and suggestions, therefore, are welcome.This article is not named methodology, but method, because it focuses on some specific methods used in the software development process. Compared with theoretical analysis, this article focuses on application software development practices. But as you know, these conclusions are based on past engineering experience and my personal feelings. All, please do not be fooled by my articles, if there are some errors here. Therefore, any further discussions and suggestions are welcome.1.OverviewFor the software development procedure, the mostPivotalFactor is controllable. A disordered project directly causes high cost, prolonged developing period and finally low-quality software product. Of course that is not the result that we wowould like to see.1. An overview of the software development process, the most critical element is manageability. A messy project directly leads to high costs, delayed development periods, and low quality software products. Of course, this is not the result we want to see. In my opinion, when a project finishes, we need not only a stack of software, but also little maintenance (means high quality) andBridle-wiseTeam and a heritable developing procedure. inheriting means accumulation and continuity. that is why then great companies can rapidly issue new products to keep ve from the competitive market. it is just like the words from a famous scientist, "I have gained so much success. because I am standing on the shoulder of giant. "In my opinion, when a project ends, we need more than just a bunch of software, but less maintenance costs (meaning high quality) and well-trained teams and inherited development processes. Inheritance means accumulation and continuity. That's why so many companies are able to release their new products quickly to survive the competition in the market. As the famous scientist (note by Newton translator) said, "I succeeded because I stood on the shoulders of giants ". For those developing little-sized companies, it is not worthy to manage software project entirely according to procedure of CMM (Capability Maturity Model for software ), because the cost is so high that these companies will lose their flexibility. software Developing, however, shoshould conform to some basic rules for software quality management. it is helpful for the quality of final product. for small development It is not worthwhile for the company to manage software projects based entirely on the CMM (Capability Maturity Model for Software Capability Maturity Model. Because the cost is too large, the company will lose their toughness. For software quality management, software development should follow certain basic rules no matter how. This will be very helpful for the later product quality. If I am asked to describe the project management using only one sentence, I 'd like to say it is controllable procedure. what I mean is that the quality and schedule shocould be controllable whichever Software Phase you are in. if I want to describe project management in one sentence, it is a manageable and controllable process. In fact, no matter at that stage of software development, the quality and progress should be controllable. 2. Tips for Software Developing
Herein I list some tips for software developing. as the background and habits are different, these tips probably are not available to every person. but if these tips will bring you some further thoughts, I think they are valuable.2. some tips for software development are listed here. These tips may not work for anyone because of their different backgrounds and habits. However, if these tips give you some in-depth thinking, I think they are valuable.2.1 software estimation
TheWorking-ouT for any plan is based on the Software size. In case we grasp the Software size and architectureCognitionFor software project, we can originally arrange the manpower resources and schedule. this arrangement must not be accurate. as the software developing procedure goes along and the understanding deepens, however, software estimation will become more and more accurate and also the plan arrangement will press close to practical case.

2. 1 software budget any plan formulation (Working-ouT) is based on the Software size. Once we grasp the understanding of the Software size and architecture of the project, we can preliminarily arrange human data and progress. This arrangement does not need to be accurate. When the software development process advances and the understanding deepens, the software budget will become increasingly accurate and the plan will be .... In the initiation phase of software project, we shoshould carry out the first software evaluation. the software project can be divided into some correspondingly independent functional modules (Note: The modules are different from those modules defined in HLD phase ). functional points of every module shoshould be nailed down. according to these functional points, we can evaluate the size of the module THR Ough our software common sense (Note: some methods are provided by software engineering ). meanwhile we can also realize which module is most difficult and which module is most significant. once we have these data, our rudimentary manpower resources and schedule are not far from us. at the same time, we can keep our eyes on those difficult and significant modules on which more resources are used. in the soft In the initial phase of the software project, we should implement the first software evaluation. Software projects can be divided into functional modules with relatively independent functions (Note: The modules here are different from those defined in the HLD phase ). In the meantime, we can also recognize which module is the most difficult and which is the most important. Once we have the data, our basic HR data and progress are far from us. At the same time, we can keep our eyes on these difficulties and major modules, that is, the resources invested heavily. At the end of every software development phase,Such as SRS and LLD, We shoshould re-Estimate our software size and adjust our project plan. in fact it is a review procedure to the project plan. the advantages of this review are to make good use of our project resources and find the existing problems in the project. only through these continuous updates, can the project plan really direct our developing activities. otherwise it will become a piece of useless white Pa Per with the project going on. then you will feel that the schedule is always controlled in your hand. of course, it is a very pleasant feeling. at the end of each software development phase, just like SRS and LLD, We can reevaluate the scale of the software and adjust our project plans. In fact, this is a review process of the project plan. The advantage of this review is to better use project resources and discover existing project problems. Through these continuous updates, the Project Plan can really guide our development behavior. Otherwise, as the project goes on, it will become a piece of useless white paper. Therefore, you will feel that the progress is always under your control. Of course, this is a very pleasant feeling.2.2 discussion and review
Software development is a team project. so we think that team spirit is very important, even it is a key to the success of the project. usually there is not so much time left to software project because of market competition. every project manager, therefore, shocould pursue doing a thing well in one time. discussion and review are good ways to reach that goal.2.2 discussing and reviewing software development is a team project, so we think team spirit is very important, and even a key to the success of key projects. Generally, due to market competition, we do not have enough time to leave for software projects. Therefore, a project manager should track what is being done at any time. Discussion and review are a very good path to the goal. A good project must have a good developing procedure. It is document that reflects this good developing procedure. How can we finish top-quality documents in limited time? I think there are three significant factors. first of all, before you begin to write, discussion among related team members is required. this discussion between des not only technical problems, but also some details such as document style. once these problems are solved by the Team, the following work is only documental work which is a piece of cake. secondly, in the process of writing document, if y Ou find new problems that you can't understand or you think the previous design is wrong, please don't hesitate to put forward these problems to discuss with your colleagues. through this continuous discussion, we can converge the wisdoms of all the team members to assure there are few errors left in the final document. with the project going on, our understanding will deepen. then we maybe find S Ome ignored sectors which will influence our design. so the third factor to get top-quality documents, I think, is the review and upgrade of the finished document whenever we have new findings. A good project must have a good development process. It is a document that reflects the development process. How can we complete high-quality documents within a limited time? I think there are three major factors. First, it is necessary to discuss with relevant team members before you start writing. This discussion includes not only technical issues, but also detailed issues such as document style. Once these problems are solved by the Team, the next document is just a piece of cake. Second, if you discover new problems that you cannot understand or understand the previous design, do not hesitate to discuss these issues with your colleagues. Through this continuous discussion, we can gather the wisdom of all team members to ensure fewer errors in the final document. As the project progresses, our understanding is deepened. So we may find some ignored parts that will affect our design. So whenever we get new discoveries to get high-quality documents, I think the third factor is necessary to review and update documents that have ended. Undoubtedly, for a limited-Period Project, discussion and review mean abundant cost of time and it is not easy to arrange in most cases, especially in case of work occurring synchronously. the key to resolve the problem is elaborate partition for time and manpower. giving an example, if we have some privileges ents to review next week, it is reasonable to finish arrangement in this weekend. this arrangem Ent events des attendees, time, sites and duration of every review. only through this careful arrangement, can we avoid conflict of review. usually before the formal review, we leave time to team members to prejudge the review content. in the review meeting, in order to save time, the only aim is finding problems, not solving problems. further discussion shocould be held after the review meeting. mean While we shoshould adopt some steps to trace the problems found on the review meeting to avoid missing. no problem. For a project with a limited time period, discussion and review mean that you spend a lot of time, and in some cases it is not easy to arrange, especially when the work changes at the same time. The key way to solve this problem is to carefully divide time and manpower. For example, if we have some documents to review next week, we should take it for granted to complete the arrangement this weekend. This arrangement includes the participants, time, location, and duration of the review. Only through this careful arrangement can we avoid review conflicts. Before the formal review, we should set aside time for the project team members to predict and judge the review content. At the review meeting, the only purpose of saving time is to discover problems rather than solve them. In-depth discussions should be held after the review meeting. In the meantime, we should take measures to track the problems found at the review meeting to avoid missing issues. It is worth using plenty of time on discussion and reviews, because extends personal errors are exposed in discussion and reviews. at the end of our project, we find that the value of discussion and reviews is incredible. additionally, through this continuous communication and cooperation, we know each other better and the specified tiveness of the team has been strengthened. it is valuable to spend a lot of time discussing and reviewing, because many people may make a mistake. And exposed during review. At the end of the project, we found discussion and review incredible. In addition, through this continuous communication and cooperation, we know more about each other and our team's effectiveness is also reinforced.2.3 Venture ManagementVenture occurs everywhere. in the process of software developing, we will meet into difficulties and we will indeed try our best to overcome them. on the other hand, we still need to forecast the ventures we will encounter in the future and take action to decrease the influence of those potential ventures. this is the concept of venture management.2.3Risk ManagementRisks are everywhere. In the software development stage, we will encounter many difficulties and we should really try to overcome them. On the other hand, we still need to anticipate potential risks in the future and take actions to reduce the impact of such potential risks on the project. This is the concept of risk management. For a software project, the most serous venture is manpower. Most projects are divided into different functional modules managed by individual engineer. Can you imagine some engineer leave the company suddenly? To avoid catastrophic sequent, manpower backup plan shoshould be initiated in the beginning phase of software project. The most serious risk for a software project is human resources problems. Most projects are separated by functional modules managed by separate engineers. Can you imagine the impact of an engineer's sudden departure on the company? At the beginning of a software project, a human resources backup plan should be initiated to avoid the swelling of a disaster. How can we process Manpower backup plan in case of lacking engineers, which is occurring in your companies? Although we have no way to make some engineers backup the other engineers, it is possible that some engineers are partly in charge of other modules. at least they must understand the basic principle of other modules. this thought can be realized in the process of discussion and review if we make management reasonably. if one engineer is selected as a candidate to a module, He shocould take part in Ll the discussion and review related to this module. that is to say he is relative to this module. when a project manager lays a course, therefore, he shocould consider this relationship. as long as we stick to this method, that engineer or more engineers will be familiar with that module which is not in the scope of his or their charge essential. as a result, even if this venture becomes reality, The project can have ve more smoothly. If there are no engineers, how should we deal with the HR reserve plan? This is happening in many companies. Although we have no way to reserve some engineers, it is also possible for some engineers to partially control other modules. At least, they will be able to understand the basic principles of other modules. If we manage it appropriately, this idea can be implemented during discussion and review. If an engineer is selected as a module candidate, he should participate in all discussions and reviews on this module. That is to say, it has something to do with this module. Therefore, a project manager should consider this association when assigning a process. As long as we stick to this method, the engineer or more engineers will be familiar with the module that is not in their charge. As a result, even if this risk becomes practical, the project can be more stable. There are other ventures beside manpower, such as lab equipment, tool software and test environment. all these ventures shocould be recorded and traced. meanwhile the project shocould have a plan to reduce the effect of the ventures. while one venture disappears, the record related to this venture shocould be closed. at the end of every developing phase, Project Manager shocould call a meeting to discuss W HICH venture we will probably meet in the next phase. it is just like a saying, "although it does not rain, we shoshould get the umbrella ready. in addition to manpower, there are many other risks, such as lab equipment, tool software, and testing environment. Therefore, these risks should be recorded and tracked. In the meantime, the project should have a plan to reduce the impact of such risks. When a risk passes, the risk record should be closed. At the end of each development process, the project manager should hold a meeting to discuss which risks may occur in the next stage. That is to say, "We should prepare umbrellas even if it is not raining ".3. EpilogueThere are using factors determining the success of a software project. after all person with ability is the most important resource in a company. for most companies, we think that controllable and regular developing procedure is also an essential condition. efficiency from the combination of person with ability and fine developing procedure will be incredible. there are many factors that determine the success of the software project. After all, people who are competent in a company are the most important resources. For most companies, standardized software processes are also a basic condition that can be manipulated. The combination of talents and the effectiveness of the development process will be incredible.