[Product Development Experience Summary] the tip of the iceberg behind software products

Building a formal software product is never a simple task. In addition to the technical factors involved in the product, there are more non-technical factors. This article only describes the tools and functions provided by a team of a small company in the process from idea to implementation of a software product. Due to our limited experience, the description may be missing. please correct me more. However, we have realized how difficult it is to develop an available product. In other words, it is much easier to say that others are much easier to practice and implement than they are. Therefore, I feel more and more that I should learn how to respect what others seem dummies. Just like someone is criticizing this product and that product. If this product is made by yourself, you will not necessarily say so. Of course, I also hope to share your thoughts and suggestions.

First, let's take a look at the approximate interactive content involved in the use of our products (~ D ).

A installation package Interface

Function Selection of installation package: Support for vs2005/2008/2010 & installation successful

B interface after installation

Folder after installation

C usage

You can use a template to quickly create a host or plug-in & manifest editor during development.

Remote control tools for development, debugging, and deployment

D. Help and User Guide

API manual & User Guide

After having a rough impression on the above product, let's take a look at some things involved in the design and implementation of this product.

1 idea

A meaningful product is born to solve certain problems, otherwise there will be no value. The value is measured relative to the problem to be solved. If a software product is not used to solve the problem, there is basically no meaning. Therefore, valuable ideas generally come from various problems you encounter. If one of your ideas can solve many people's problems, this product is of great value.

Of course, it is not that easy to come up with a good idea. You can practice it without having a high value idea. In fact, a valuable idea is only preliminary, because it must be feasible. Every valuable idea is accompanied by more or less other problems. After all the questions are taken into consideration, we may be able to make a rational decision. However, this decision is not that easy, and I have been exploring it all the time.

2 Concept Design

With the idea of a software product, we began to figure out how to implement it. At the beginning, we didn't have a clear understanding of the product, such as what features the product provides to solve user problems, and how to use the features. At this time, the consciousness is vague.

In the conceptual design phase, I generally use a combination of "whiteboard + whiteboard pen + touch HD with camera functions. Use a whiteboard pen to do some quick design of brainstorming on the whiteboard, and then take photos with touch HD and save them. After saving it, you can print it and paste it on the whiteboard for some details until the mind has a preliminary impression on the simulation of software products.

Concept Design legend

3. Functional specifications

The concept design is only a few preliminary pictures, and the thinking span will be larger. Therefore, a standardized and easy-to-understand function description is required, that is, the Function Specification document. This document further refines the concept design. We can design it based on the actual situation. In general, the function documentation describes important Use Cases of the system. I have to mention that the best way to design a complex system is to look down on the entire application system in a high-level manner, then, based on the large factors such as the machines, components, characters, and running environment, the system is divided into different small systems to obtain more details.

Function Specification

4. User Scenario Description

In addition, for products such as sdks, it is best to design user scenarios involved in each public API. The user scenario is a simulation of the user's use after the product is released, so as to optimize the API design. The purpose of API design is to ensure that 50% ~ The 70% feature allows users to easily use applications, and the remaining features can be advanced features.

User Scenario Description

5. Schedule

At the same time as the outline design and functional specification design, I will start to schedule the entire project. Currently, project is directly used. The schedule also starts from top to bottom, starts from the big one, and then subdivided the task, and preliminarily estimated the approximate time based on each capability. Then, different people will audit and update the progress again. You need to know that the progress cannot be accurate. Generally, we need to move up to 20 points or even higher in the overall estimation time.

Schedule legend

6. Design Specifications

Design is an important part of the product implementation process. From the agile perspective, to save manpower and time, we only needAlgorithmImportant functions and important classes are designed in detail. Of course, I also believe that our team will be competent for simple functions. The benefit of leaving design specification documents is that maintenance, testing, and training are much easier. In our product development, I usually define the interface classes designed by the system, describe important algorithms, and hand them over to others for development and implementation. Therefore, I strongly recommend the class chart tool that comes with.

Design Specifications

7. Implementation

In this step, I think the implementation should be relatively simple. Only a unified development specification should be formed for the team. We use the design and development principles in framework design guideline for standardized development.

Fds ppt, highly recommended

8. Quality Assurance System

At the beginning of product construction, we considered quality assurance. At work, the company uses clearcase, cruisecontrol, ant, JUnit, and a bug management tool. We certainly cannot afford or use a heavyweight configuration management tool like clearcase. Therefore, I chose subversion (visualsvn server)/totoisesvn/ankhsvn + cruisecontrol. Net/Nant/msbuild + bugtracker. NET + xunit + Wix.

The reason why subversion is selected is: (1) free; (2) Branch/tag is provided. The second factor is the most important factor. A product cannot avoid continuous updates or releases of different versions. Therefore, we use branch/tag to support such product line engineering. Our product line management method is to have a trunk which has the most comprehensive functions and is continuously updated, unless it is in the merge stage. Once trunk reaches the fast and stable status and has reached the goal of product release, we will create several branch and tag for it. Trunk can continue to bugfixing and new feature updates, But Branch'sCodeWe must be very careful. We cannot add new features, do not go through code audits, and send notifications for code updates. This is a necessary guarantee to ensure the most stable release of products. Of course, there are many methods for product line management. I am not necessarily rational about this method, but I still think it is feasible.

Cruisecontrol. Net/Nant/msbuild: on the one hand, it is used to automatically build after the code is updated, on the other hand, it can also perform dailybuild to generate an installation package. The installation package is developed using Wix. through integration with Nant, every time the installation package is built, the code is automatically obtained, compiled, and obfuscated from the code base, and finally generated. Cc. NET is very powerful. After the code is updated, if the build fails, an email notification will be sent. Similarly, it can automatically execute the xunit unit test. If the test fails, an email notification will also be sent. This avoids code errors and regression as much as possible. Regression-rollback, which is a very serious bug. Generally, we define it as the highest level. Because uiosp is a middleware product, modifying its code may affect other products or itself. Therefore, automatic testing is also required.

QAS involves some batch processing files: start/stop/build the installation package and so on & visualsvnserver code management

Cc. Net & subversion integrated with Nant/msbuild/xunit bugtracker. net

Extension of bugtracker. Net: Code Audit

9 third-party components

In general, when developing software products, if some functions have been implemented by others, we will choose to reuse them. This involves third-party libraries. When using a third-party component, the license declaration is generally ignored. There are several common license, such as Apach, GPL, MS-PL. In China, you may ignore and use these things as you like. However, I suggest you develop software products with a little attention and try to avoid some problems.

10 help document

If a software product can be directly used without relying on help documents, the user experience of this product is generally very friendly, or many users have already recognized the Interactive Mode of the product. In most cases, we need to provide help documents, especially sdks. Developers are generally lazy and do not have to read documents. Therefore, writing documents must be ingenious. Of course, to be chic requires a price. It can only be improved step by step depending on the situation. We provide users with a user guide and API documentation on the product documentation. In writing the user guide, we will first use a simple example, a 3-minute quick start, and then gradually refine and deepen it. The API documentation will describe important classes as clearly as possible, and a example will be attached to each important class or API. We used the sandcastle and sandcastlebuilder tools when writing API instructions.

Help Project & API comments

11 Conclusion
A product involves too many details and is enough to write a lot of books. Here is just the tip of the iceberg. What is more important for a product to reflect its value is how it can be recognized by the market. This involves more non-technical issues. There are both high-level and underlying strategies. It is accepted that dealing with people is the most difficult. Once you are responsible for market expansion, you need business vision, business skills, communication skills, and reading skills ......, Too many! It is difficult to succeed without a team with meticulous division of labor! There must be many mistakes in this article. I hope you can give me more advice and give me some comments. Please share your thoughts with me. Of course, you should be a little bit light.

PS: by the way, we are currently recruiting people in Xi'an, for more information, see . NET software development engineer "recruitment information, or directly send a resume to the uishell@uishell.com. We know that it is not easy to do the Program . Therefore, we will try our best to make everyone happy, understand everyone, and protect everyone's rights and interests as much as possible.