Shulou(Shulou.com)06/03 Report--

Making a development plan for a software project is perhaps the most unreliable thing, and project delays have become commonplace due to changes in requirements, the level of developers, and unpredictable situations such as personnel changes. Nowadays, project managers often make progress plans based on experience, which is indeed very important, and it is also an indispensable basic condition for project schedule estimation, but planning based on experience alone will give rise to the following problems:

1, the understanding of the project is different, each project manager's development experience and project experience are different, you have your planning method, I have my planning method, when different people plan for the same project, there may be great differences between the personnel arrangement and the project completion date. So if there is a replacement midway, then the software schedule is not clear.

2. Omitting the requirements that must be completed, if the project manager plans the project based on experience every time, then when the scale of the project becomes very large, some details of the requirements are bound to be omitted. These fatal details are often known in the later stage of design or development, which may seriously lead to the refactoring of the entire software architecture.

3. Without a set of models, there will be a lack of basis and traceability for project managers to plan based on experience alone, although most of the estimation of the time of each task depends on the experience of managers and the commitment of developers. However, the sequence of tasks, the dependency between tasks, and the impact of the number of personnel on project development efficiency need a set of methods to describe clearly. On the other hand, traceability is reflected in the level of why I have to arrange this.

In order to solve some of the above problems, we need to introduce a model (which can be understood as an idea) to improve our schedule estimation work. Here, I take a simple B2C system as the background, describe some of the main modules, and discuss with you how to plan for the development of a web software project.

The first thing, of course, is to be clear about what we need to do, that is, to determine the requirements. Our requirements and use cases are as follows:

User operation

Registration: users register as members of the website.

Login: users log on to the website, after logging in, they can buy products and view relevant user information.

Join the shopping cart: users can pay for the purchase together after adding the product to the shopping cart.

Purchase (generate order, pay): pay and generate order.

View / modify user profile: view / modify user profile through the user profile page.

Check the shopping cart: look at what you are going to buy.

Check the order: look at what you have already bought.

User use case

Administrator operation

Product

Operating products (operation refers to adding, deleting and changing operations): add, modify and delete products provided to users for purchase.

Manufacturer to which the product belongs: add, modify or delete the manufacturer to which the product belongs.

Manipulate product attributes: add, modify and delete product attributes.

Operation of product categories: add, modify, delete product categories.

Fittings

Operation and delivery methods: add, modify and delete the delivery methods provided, such as SF or UPS.

Operating countries and regions: add, modify, delete countries / regions, the website country region is different, the tax is also different.

Operation language: add, modify and delete the languages supported by the website, such as Chinese and English display.

Operation tax: set the category of tax, different products can attach different taxes and fees.

Operating system settings, such as setting store name, etc.: global settings for the website.

Operating currency: sets the currency paid by the user.

User

Operation user: add, delete, modify user information.

Operation user group: add, delete, and modify the user group to which the user belongs. Users of different user groups enjoy different discounts when purchasing goods.

Report form

Operation order report: add, delete, modify, query user orders.

Administrator use case

Through the use case, we can extract the business object:

1 user

2 user groups

3 products

3.1 Product classification

3.2 manufacturer

3.3 Product Properties

4 order

5 Accessories

5.1 countries

5.2 language

5.3 Logistics

5.4 tax

5.5 currency

5.6 method of payment

After identifying the business objects, we need to know the specific responsibilities of each object and the basic execution process of the use case, which can be achieved with an activity diagram.

The activity diagram shows the basic flow of the core use case purchase, from which we can see that in order to complete the purchase use case, we must first establish "product object", "logistics object", "payment method object", "transaction object", "order object". Because the shopping cart object is an optional step, it can be created separately.

Logistics object, transaction object and payment object are relatively independent objects and have no dependence. In order to establish product object, shopping cart object and order object, there are prerequisites. Let's analyze these objects in turn. The analysis is based on our use case diagram. We can use tables to express our analysis results:

The relationship between objects can be seen from the table above. So, in the development process, we will start with simple objects, that is, objects without dependencies, and then design complex objects. Simple objects can be designed in parallel or in turn, depending on the specific person. According to the business object table, we can deduce the critical path map of publication. As shown in the following figure:

Click here to view the picture

The above figure initially shows the development steps. Ideally, independent objects can be developed synchronously, and dependent objects can be developed after the development of the front object is completed. The dotted arrow in the figure indicates implicit dependency, which means that there is no actual task doing during this period, but only expresses a dependency, indicating that the task before the arrow must be completed before performing the task behind the arrow. However, we also found from the figure that the start time and completion time have not been planned, and the duration of each task has not been calculated. So let's start to estimate the development time for each task.

For the estimation of task time, there is a method called function point estimation. Here is a detailed description of this estimation method, please see the following two formulas:

Unadjusted function points = A1 x Inp+ a2 x Out + a3 x Inq + a4 x Maf + a5 x Inf

Technical complexity factor (TCF) = the comprehensive influence degree of software technical factors on software scale (DI) x 0.01 + 0.65

DI = Σ Fi

one

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.