Project development experience (1)

1 Project Process

Based on the problems in our project, I have summarized some of my experiences and the problems and solutions I encountered in the project after I learned knowledge in the training middle school.

1.1 Sign contract

The contract of the Project is vague and the scope can be large or small. As a result, the project grows in the future, but the project cost remains unchanged. It seems that all contracts in China are basically promised at the time of making a ticket, and there is no detail. The problem was discovered after the contract was signed. However, the contract can indicate the level of requirement change, the amount of money, etc.;Signing a contract is also a very high skill. We recommend that you sign the system boundary, function scope, and solution together with the contract so that the new functions proposed by the customer can be put on hold for the moment.

1.2 Team building

Determine the project owner and project manager as soon as possible after project initiation. This person is critical and requires strong comprehensive capabilities, especially in terms of personality charm. We do our best to add the customer's personnel to our project team. This person is our unified contact with the customer in the future. The customer designates a person to communicate with the project team, it cannot be said by both Zhang and Wang. If their opinions are inconsistent, you will have to offend the leaders, the project team only recognizes one opinion and asks you to unify your internal team before talking to the project team. We do not want to be involved in conflicts and political struggles between the customer's internal business departments. Many project managers do not have the right to select their own team members, so try to exert your influence to find the people you want. The composition of members varies greatly depending on the project, and it is difficult to have specific requirements. However, there must be people who are proficient in customer business. In many small projects, this person is the project manager himself, industry experts (Industry ExpertIn this way, the two parties can understand each other only when talking to the customer. The project manager needs to understand the situation of each member and use the expertise of each employee. The software industry is a very special industry. Project Management and Personnel Management have their own special characteristics.

As a project manager, there are several things in his mind: What to do, how to do it, how to deliver it, the resources on hand, and the priority of each task. The so-called fast and good saving is a dream of mankind. These four aspects are mutually contradictory. They are a typical type that requires both the horse and the horse to run without grazing. In terms of priority, leaders from all parties usually give you the deadline, so the progress is the first. The province is the second place, the fundamental goal of an enterprise is to make profits. If revenue cannot increase, at least the cost should be controlled. Good is the third place. No way, no one wants to keep improving. However, without strong resource assurance, the quality had to be sacrificed first. In the end, there were many customer requirements. How to Reduce the expectations of the customer and bring them back to reality from the ideal is also the internal work of the Project Manager.

1.3 Demand Research

In the demand research and analysis phase, the project team does not have sufficient understanding of the customer's overall organizational structure, relevant personnel, their relationships, and responsibilities, so that the project team cannot obtain the complete requirements or ultimately the requirements confirmed by authoritative user representatives. Because the project manager and demand analyst's work problems and research work are not detailed enough, the degree of customer participation is not high, the relevant owner of the customer is not clear or the scope and demand of the responsibility is not strong, the proposed demand is random, and the pre-project validation of the demand is not positive enough; multiple user representatives talk about each other, and the proposal is not the present but at the same time, the software is expected to be delivered as soon as possible; our practice mainly focuses on the needs of leaders. Basically, leaders say what they mean. As a result, the developed functions are not actually needed by actual users, the demand changes at will in the later stage of the project, resulting in the spread of the project scope, delays in progress, and increased costs. At the same time, our understanding is the key to demand research. Many companies only think that this stage is important and requires a long time to invest, but in fact many companies cannot do this, I always want to enter the encoding phase soon. In addition, in order to catch up with the progress, we always want to save some work and write less documents, so that we cannot come up with customer requirements and the contrast between the later functional changes and the original functions.

The reason is that we do not fully understand the needs of all stakeholders and do not pay enough attention to the Demand Survey. There is no shortcut to software development, and there will be a higher cost of return after saving the work. The full requirement comes from all stakeholders of the project. The aspirations and objectives of different stakeholders are often far different. Therefore, it may be quite difficult to balance the desires of stakeholders of the project.

The purpose of a software development project is to fulfill the needs and aspirations of the stakeholders. If you do not have sufficient communication and impact on all stakeholders of the project, so that they can participate in the project as much as possible, the scope and specific requirements of the project may be incomplete and clear at the beginning of the project, it may also be because the stakeholders of a project put forward new requirements due to changes in understanding in the future, resulting in a longer construction period, an increase in costs, or even a complete failure of the project. Therefore, from the start of the project, the demand analyst and its project members should distinguish the stakeholders and organizations, influence them through communication and coordination, and drive their support for the project, investigate and clarify their needs and aspirations, and reduce their resistance to the project to ensure project success. The following are some effective measures

1 And get familiar with the entire stakeholders of the project as soon as possible.
In some projects, due to objective factors such as progress requirements, the demand analyst communicates with the technical departments of the construction unit in a large amount, and the investigation into the business management department and actual users is not in-depth enough, as a result, the demand for the software has to be adjusted after trial,"Start from scratch"The proportion of the parts is very high, which greatly exceeds the time required by the progress. Therefore, familiarizing yourself with the full picture of stakeholders is the first step in requirement investigation and the basis of requirement investigation. Among the stakeholders of custom development projects, the most important is the personnel organization and business relationship in the construction unit. It is best to use the organizational structure diagram to draw the organizational structure of the relevant units; establish the survey object address book to ensure timely communication during the survey and analysis. At the same time, pay attention to the Primary and Secondary relationships of project stakeholders, so that reasonable trade-offs can be made when there is a conflict between their needs.
Familiar with the Business Division of relevant departments within the construction organization and Their Relationships,Prepare necessary materials for Function Analysis,At the same time, you can be familiar with all types of users, and conduct extensive and effective communication and communication in a timely manner. In particular, it is necessary to conduct in-depth discussions with the customer's business and technical planners and actual users, collect necessary raw information, and ensure the integrity and correctness of the demand investigation.
The construction organization is only part of the stakeholders of the project (of course the main part). To better understand the full picture of the stakeholders of the project, the construction organization should also build a structure map of all stakeholders of the project on the basis of the organization diagram of the construction organization, in order to better and comprehensively carry out demand research and analysis.
2And describe various services in detail to facilitate confirmation by all customers
Investigate and describe the original system in full detail as much as possible (this is critical and you need to understand the shortcomings and advantages of the original system, as well as the user's operating habits in these systems) and the business processes that the user wants to have in the future, and document these business processes and discuss them with the customer to modify the incorrect or inaccurate descriptions, finally let the customer confirm. In my opinion, it is very important to understand the integrity and accuracy of the business processing process. Although data is queried, added, deleted, modified, and transferred, the specific business is divided into several steps, each step has its service name, and the same step may perform different operations on multiple datasets, only after investigation and understanding can we design software suitable for the user's business characteristics and habits of each process business node, making the developed software more popular. Of course, during software outline design, we should try to eliminate the constraints of the business process, that is, take the work of various business nodes in the process as independent objects, and fully consider the interfaces between them and other business objects, the process is implemented through mutual calls of business objects between processes. In this way, the system can be easily modified when the business process has limited changes.ProgramTo meet new requirements.
You can collect, sort, and analyze the following information for various businesses. The information comes from various stakeholders: standards observed, work manuals issued by the Organization, operational procedures, business-related superior notifications, service guidelines for relevant businesses, registration forms to be filled in during business processing, various related statistical reports, and pass introduction to similar systems collected through other channels,Technical materialsAnd so on.
3Visual demand research, guiding various customers to explore their needs
Many customers cannot provide complete, accurate, implicit, or potential demands because of their lack of computer knowledge. However, if these requirements cannot be met, user dissatisfaction may occur. Therefore, the demand research and analysis personnel should be good at thinking what the user thinks, and should not be afraid of a large number of user needs, not only need to determine specific needs, we should also be good at exploring hidden or potential needs with users in an enlightening way, and explore exciting demands beyond the customer's expectations based on various research and analysis technologies. This requires the demand research analyst to be familiar with the relevant business as soon as possible, so as to be able to stand on the user's standpoint to view the software requirements, think what the user thinks, and build a bridge between the business and the computer. The visual requirement survey method can be used to inspire users to explore potential needs in depth. Visual requirement research is to use charts and other tools to inspire users to clearly describe their needs and improve their needs.
Senior leaders can provide an overall system framework. Business managers can use business flowcharts to describe the business processes of the new and old systems. For technical personnel of customers, you can use a data flow diagram, an object diagram, orUMLVarious graphics in the system are described from various angles. for business management personnel, technical personnel in the customer, and users in various levels of processes, draw a user interface Diagram for demand mining, is a relatively effective way of communication.
The importance of the user interface is described here. The design of the user interface is the responsibility of software design. Of course, unless the customer has special requirements on the interface. However, if we discuss it with the customer before the demand Research (followed by the original system research and analysis and System Model), the effect of the demand research can be greatly improved. At this time, the customer does not have an image concept for the future system, or there is a vague pre-defined concept that needs to be expressed, verified, clarified, and perfected. From the experience of first-in-one interface with users in our subsequent projects, see ( The system should be developed in the real environment under the guidance of analysts during requirement analysis. Of course, development is only a functional simulation of the interface, and there is no underlying Code Implementation), Draw User Interface sketch to discuss with the customer, can greatly stimulate them to provide more accurate and comprehensive requirements, and these interfaces can also be used in later development. The original collection of information and business description showed that when the system model was exhausted, this method could achieve the effect of different villages. Therefore, the so-called requirement is"What does the system do when you press various related buttons (or enter various related commands )?"The so-called design is"How do you do this when you press a variety of related buttons (or enter a variety of related commands )?". The final purpose of the requirement is to completely and accurately describe the various interfaces or"Interface", And their relationship or relationship with the external environment, such as when a button in the interface is pressed, a new interface, a new button, or call other software hardware to complete some functions. From top to bottom, it is a good requirement to clearly describe these interfaces and the involved data.
4Collaborate with other project team members to continuously improve system requirements
After the requirement document is completed, it is not all that is done. Just throw it to the design personnel behind it. As other members of the project team within the project stakeholders, the effectiveness of the requirements also plays a certain role in verifying. Although the life cycle of a software project is divided into different stages according to various development models, the end of each stage is not simply to insert the results of the phase work to the members of the next stage. Especially for high-tech software development projects, the work of the previous stage is often accepted by members of the next stage through multiple communications, its effectiveness and rationality should also be tested by the work of the next stage. Through the test, it is sometimes necessary to adjust the work results of the previous stage, especially the demand. Therefore, personnel at different stages of the same stage should collaborate and cooperate with each other to complete software development tasks.

5And feature specification, which is the biggest mistake in our project, making our customer changes passive. The Feature Specification reflects all the features required by the customer. We also developed the features in accordance with the Feature Specification. Subsequent customer changes can be compared with the "Feature Specification". The specific change is implemented according to our change process. The functional specification, as the final outcome of product requirements, must be comprehensive: All requirements must be included. Developers and customers cannot make any assumptions. If any desired functional or non-functional requirement is not written into the software requirement specification, it cannot be part of the protocol and cannot appear in the product. Pay attention to the following points:

(1)Integrity

Each requirement must clearly describe the features to be implemented so that developers can obtain all the necessary information needed to design and implement these features. Do not omit any necessary requirement information. Missing requirements will be difficult to identify. Focusing on user tasks rather than system functions will help you avoid integrity. If a message is missing, use"To be confirmed"This vulnerability is identified as a standard identifier. All requirements must be addressed before development starts."To be confirmed".

(2)Correctness

Each requirement must accurately state the features to be developed. The reference for making a correct judgment is the source of the requirement, such as the user or high-level System Requirement Specification Description. It is incorrect if the software requirement conflicts with the corresponding system requirement. Only user representatives can determine the correctness of user requirements, which is the reason for the active participation of users. A requirement review without user participation will result in the following statement:"Those are meaningless. These are probably what they want."In fact, this is entirely speculation by the reviewers.

(3)Feasibility

Each requirement must be implemented within the capabilities and limits of known systems and environments. To avoid unfeasible requirements, it is best to obtain the requirements(Collection requirements)During the process, a software engineering team member is always working with the requirement analysis personnel or personnel considering the market, and is responsible for checking the technical feasibility.

(4)Essentials

Each requirement should record the standards that the customer really needs and that the final system needs to follow."Necessity"It can also be understood that each requirement is used to authorize you to write a document."Root Cause". Each requirement needs to be traced back to a customer's input, such as using an instance or another source.

(5)Division priority

Assign an implementation priority to each requirement, feature, or instance to indicate its weight in a specific product. If all requirements are considered equally important, the Project Manager will lose control during development or budget saving or scheduling.

(6)Non-Ambiguity

Readers of all requirements can only have a clear and unified explanation. Natural Language can easily lead to ambiguity, therefore, try to express each requirement in a concise and clear user language. Effective ways to avoid ambiguity include formal review of Requirement documents, writing test cases, developing prototypes, and designing specific solution scripts.

(7)Verifiable

Check whether each requirement can be verified by designing test cases or other verification methods, such as demonstration and detection, to determine whether the product is actually implemented as required. If the requirement cannot be verified, determining whether the implementation is correct becomes subjective judgment rather than objective analysis. A conflict between the two sides is not feasible or the demand for ambiguity is not verifiable.
(8)Consistency

Consistency means that it is not in conflict with other software requirements or high-level (system, business) requirements. The inconsistency between all requirements must be resolved before development. Only after some investigation and research can we know whether a certain requirement is correct.
(9)Modifiable
The document should be revised when necessary or to maintain the change history for each requirement. This requires that each requirement be identified independently and differentiated from other requirements, so that there is no ambiguity. Each requirement should appear only once in the document. This makes changes easy to maintain consistency. In addition, the use of directory tables, indexes, and mutual reference lists will make the Software Requirement Specification Description easier to modify.

(10)Trackability

Should be able to meet each software requirement with its roots and design elements,Source codeEstablish a link between test cases. This trackability requires that each requirement be written and identified separately in a structured and fine-grained manner, rather than a description of a large segment.

Project development experience (2)
Http://www.cnblogs.com/ghd258/archive/2007/06/04/771154.html
Overall experience in project development
Http://www.cnblogs.com/ghd258/archive/2007/02/12/648697.html