Software process
1.1. Software Process Model Overview
The earliest software development did not have a significant process model, all work is natural. With the accumulation of people and the need for project size, people continue to summarize various software process models to guide people's software development. The process model includes the provisions of the software development process and the corresponding role definitions, and the product definition. Comparable Waterfall models and incremental models. Many process models are evolved from both. Now the iteration of iterations in the incremental model is almost used to all popular process models. Here you must focus on the waterfall model. Nowadays, the waterfall model has been out of time, should not be adopted. In fact, I feel that the waterfall model is very effective in the actual project and needs to be mastered. The advantage of the waterfall model is to meet the technology development of the idea and easy to master and apply. The process of process model is based on profound understanding, and a model, which will bring catastrophic consequences to the project. In the actual project, it should be a model of a (several) model to develop its own team model in conjunction with the actual situation of your team. The past project experience seems that the waterfall model is quite good, but it cannot be used simply. You should first use incremental iterative ideas to split the project into small systems that can gradually increment (once release). Each time it is released as an iteration, the scale and complexity of each iterative system is small enough to develop in a waterfall model.
1.2. Unified Process VS Agility Process
The most influential should be a unified process model (UP), in the UP model, the RUP model proposed by RUP model, and has perfect tool support. RUP is centered on the use case, using UML's nine graphics as an exchange language. RUP developed a detailed use of detailed examples at the beginning of the project and specified a very detailed plan. RUP focuses on documentates, most of the activities produces rich and complete documents. RUP divides system development into several iterations, each iteration includes demand, analysis, design, implementation, testing workflow. Each workflow has specified the specific activity content of the input product, outputting products, participation in role, and workflow. RUP is called a heavy-duty software process model that contains dozens of characters, thousands of documentates and closely combined with Rational's series of tools. Therefore, when we implement RUP, we generally have a deletion, and have selection.
Since the unified process is too cumbersome, the implementation cost is too high, and the change in demand is not agile, and therefore, agility process is increasingly popular. Agile process is a general name of a series of lightweight process models, which represents an XP (extreme programming) model. The main idea of agile process can be seen from the "Agile Software Development Declaration":
We are disclosing better software development methods by practicing and helping others. Through this work, we believe:
l Individuals and interactions over the process and tools
l The software that can work is better than the face-feared document.
l Customer cooperation is better than contract negotiations
l Response change is better than follow
Although the right item is also valuable, we think the left item has greater value.
Here, some practices and principles of agile development with the most complete and most representative XP:
1. Customers as a team member. This ensures that obtaining effective needs. Customers must work with the team. The customer must understand the demand of the project and have a speech on the demand of the project. If the client can't work together, you need to find a replacement, it needs to fully understand and express the customer's needs, such as the domain expert who can be responsible for customer needs, can be a business analyst returned by the demand research.
2. Use the user material as a material that records the demand. User material records and information points of user conversation. XP does not encourage premature analysis of user material and form a formatted demand specifications, because these work will become useless after the demand changes. 3. Short-term delivery. XP enhances customers by continuously submitting runoff products. XP delivers a work version every two weeks. Each iteration is selected according to the priority level and dependent order. XP also plans a longer period of user material to be implemented by publishing programs.
4. Textage programming. This is the development model of innovation in XP, two shared machines engaged in programming. At the same time, each pair is free combination and frequent changes. This will promote the mutual learning of team members and guarantee the quality of the encoding. It turns out that the relationship between programming does not reduce efficiency.
5. Test drive development. When writing classes, write this class to the test class. This mode of "Programming", the target is very clear, when the test class debug passes, the target class is written and tested, and the test class is still a good document, which describes how the class is used.
6. Work together. Members of the project work together in an open space. This is a guarantee for maintaining good communication.
7. Maintain the simplest design. It is easy to complicate. Avoid duplicate code, if all the code appears twice, you should immediately think of how to abstain to eliminate duplicate code.
8. The code is design. XP believes that the code is the best design document, and the code is easier to explain than other documents. In particular, in the test drive development mode, the test code is the most valuable design document. Other UML charts only serve as aid.
After a period of practice, it is more easier to implement in small and medium-sized projects like Weboa.net, more efficient than the unified process.
1.3. Software process for the Kind Weboa.net project
Each software process model should take into account: methodology, document specification, role division, my approach is defined in the project plan, and write a software process manual to make a detailed description.
1.3.1. Process method
At the beginning of this project, when the project plan is developed, it is referred to in the unified process, and some practices are added to the project. At the same time, CMMI provides a number of standards and recommendations for ensuring software, and I have referred to some of this aspects, such as risk management and project reporting mechanisms in determining part of the project development process. The process of the project is as follows:
The entire project reference UP is divided into preparation phase, defined stage, design phase, implementation phase, productization phase, and paying the task as a number of workflows. All workflows are divided into three collection, three lines parallel. The task of the project management set is to plan and supervise the work, mostly periodic tasks. The task of research and development is to refine the project. The support level contains tasks to ensure the smooth completion of the above two types of work. The following focuses on the research and development process of the project.
First of all, demand analysis, because it is productive project, demand does not come from a specific customer, so there is less demand research, and demand research phase will arrange demand collection. After the demand is collected, it is analyzed, and the demand will be sorted into a "demand description" and "use case specifications". Demand analysis, there is a general estimate of the needs of the needs, and the technical staff will be prepared for some key technologies. This is an effective practice of reducing risk and provides a basis for the establishment of future schedules. After the demand analysis is completed, a review is performed, and then the demand is divided into several subsystems to enter the iterative development of each subsystem. In each iteration, there are several workflows: UI design, architecture design, database design, business analysis (class design), unit test, integrated test, realization, each workflow is over, is output with a document And accepted the review. What we use is the principle of UI, the UI directly corresponds to demand, and the rest of the work is to make UI's functionality. This has a clear purpose, in fact, a modular level "test drive development", practice prove, is a good method. After the project is over half, because of the introduction of XP, the cycle of each iteration is shortened, which makes each iterative process, the length of the workflow is shortened until two or three days, so it no longer emphasizes the output document, but directly The running release is reviewed. Practice has proved that this is more effective and saving time, and the boss can continue to see the progress of the system. In addition, the unit testing and implementation are not distinguished. Role definition
According to the human resources characteristics of this project, the following roles are defined.
Role Work Description Project Manager Project Management, Progress Control, Software Process Guidance, Quality Review, Formulation System Analyst Coordinates Arrangement Demand Analysis, Architecture Design, Module Design UI Design Database Design Data Data Design Configuration Administrator Configuration Management The various work developers are responsible for the detailed design and implementation of the module and the unit test document administrators to organize documents, and manage documentation test managers.
It should be noted that the characters and people still have a big difference, and the practical experience tells us that the role should be defined, what is the responsibility of what role is undertake, and personnel can be based on the situation, and a multi-role. At this time, when a member plays a role, doing the role to do.
1.3.2. Document specification
This project produces the following documentation throughout the process, most of the documents are also iterative. It is to be explained that the document requires standards, including which documents need to be needed, who is completed, contain those content, what formats are used, but the document does not have to strictly refer to standards such as national standards. It is the best practice to formulate the standards for yourself.
l Project development plan. A new version is launched after weekly planning review.
l Project plan change report. And new project plans to cooperate, the cause of the plan
l Demand specifications. Parental description The function of the product is the basis for the assembly of the design.
l Use the example specifications. Carefully describe system behavior, is the most important demand material and development foundation
l Daily task book. Assign each person. (For large teams, you can be assigned to the group length)
l Project summary report. Divided into weekly reports, monthly reports. Statistical workload and work results and evaluate
l Architecture manual. Explain the architecture, catalog, naming regulations, and platform technology, as the basis for detailed design and implementation
l Number report. Summary after the end of the project
l Model: Database ER diagram, class structure diagram of the system, reflecting the design of the system. Export time is complete, let the future generations.
l Code: The code is designed, so there is no detailed design document. Combine the class structure diagram, read code, annotation, and its test code, you can clear the design of the system. l Integrated test feedback report. Includes test case description and bug description
l Demand change report. Describe the change of demand, the cause, the cause of the approval. Keep a list of demand changes through approval.
1.3.3. Tools and Platform
This project uses Microsoft
Windows2000 .NET Framework1.1 SQL Server2000
For the platform, use
MS Project 2000
As a project plan tool, use
Cvs
As a configuration management tool
Visor
As a
UML
Drawing tool, use
VS.NET 2002
As a development implementation tool.
