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

[this is a handout of modern software engineering]

A software team has gone through the stages of planning / design / development, and achieving the goal of code completion (Code Complete) seems to be the right thing to do. In fact, the final stage of the software life cycle is often the most test of the team, testing not only the team's project management level, resilience, but also the team's blood type. The originally planned software release time is coming up, but the software still has bug of one kind or another. What should we do?

Will a good software team release software with known defects?

I think similar to human blood type, the "software blood type" of software teams can be divided into four types:

Type A: they know that good software companies will release software with known defects

Type B: they don't believe that.

Type O: they don't know that, so their mouths are surprised to be shaped O

Type AB: they are type A for the software they develop and type B for the software developed by others.

Type B people will find it painful to develop software. It is important to note that all software companies want to be able to correct defects before releasing software, but what is the first meaning of "defect"? If it's just some irrelevant problems that users can get around, do we have to solve them right away? Second, what is "correction"? What if there are "defects" in the correction plan? People who do business software are worried about this, and only good software companies can find a balance, release software that can solve users' problems in time, and modify problems in the software in time-- note that the two "timely" are not necessarily at the same time. Software that does "big homework" (for example, to demonstrate and hand in homework) can ignore these two in time, hand in the papers, and everything will be all right.

When it comes to "quality", we do not mention "total quality management", because after "comprehensive", there will be a phenomenon of "waste of the road and benevolence and righteousness". Everyone talks about "total quality management", which often means that our quality management does not get to the point. And some mediocre people tend to hinder the normal work process on the grounds of "high quality". Those who repeatedly demand "high quality" are often due to the following circumstances:

A) lack of insight into users, industry and software development, and there is no specific definition of "high quality".

B) there is no specific way to make the software achieve the so-called "high quality".

C) afraid of real-world feedback, so if you don't release the software, you can put it off for a day.

You can look at these two examples and infer the blood types of these teams:

The jump ticket of the STG game was postponed for 7 days in order to perfect, but it was not released 7 days later. )

English learning software (said "released in the morning", but it hasn't arrived in the morning)

Some students will immediately cite examples of world-famous companies launching perfect software, such as Apple, the Duke of Doom forever and so on. . Excuse me: is the first version of iPhone perfect? It doesn't even have the ability to copy / paste.

So, from the Code Complete of the software to the final release, what steps do we have to go through, what tricks can we walk through this bloody process with greater consensus and less pain, and what kind of blood type and bloody team can we launch excellent software on time?

First of all, take a look at some common nouns:

Alpha: the first trial version of a major feature that has been integrated. Some small functions have not been implemented. In fact, many Alpha versions of software are only used internally. The version for external users will have a nice name, Technical Preview, and so on.

Beta: the function is basically complete, and the stability is higher than the Alpha version. Users can use it on a small scale in practical work, such as Beta1, Beta2, Beta3.

ZBB (Zero Bug Build): one day's version will get rid of all the bug recorded 48 hours ago.

RC (Release Candidate): release candidate versions, RC1, RC2... Until RTM, the version interval is short.

RTM (Release To Manufacturer): the final release. If a RC version is not a big problem, then the RC will become the final version, usually, the software company will give the final version and related documents and other materials to another team (Manufacturer) to package, carve floppy disks, CDs. In the age of AppStore/MarketPlace, we had corresponding RTM (Release To Market).

RTW (Release To Web): similar to RTM, for web applications, we don't have to rely on "Manufacturer/Market" to make software CDs or manage software distribution channels, but we rely on "Web" to release our final version. If the software product is a website service, the software system is usually managed by the website operation team (Operation Team). Such a release can also be called RTO (Release To Operation). The operation team and the R & D team work together to decide when the system will be online (Go Live).

Consultation team (Triage Team)

Representatives of various roles of the software team (pm/dev/test/UX, etc.) form a consultation team. Deal with every issue that affects product release. To make an analogy, just like the outpatient clinic or emergency room (Triage Room) of a hospital, if many patients pour in at once, but the manpower and equipment in the hospital are limited, the doctors and nurses on duty should arrange according to the patient's condition. Another similar but more urgent scene is that in the field hospital, between the two battles, medical personnel rushed to the battlefield where the smoke of gunpowder had not yet dissipated to search and rescue the wounded, some simply bandaged, some had to carry stretchers, and some were so seriously injured that they had to let it go. Everyone's blood type and courage have been demonstrated in these triage meetings. The following tricks are carried out under the leadership of the consultation team.

For each bug, the consultation team makes the following decisions:

-repair

-this is how the design is originally designed (as designed)

-No repair (won't fix)

-postpone / / if our software is really a solution to user problems and is valuable, then there must be a next version.

Trick: design change (Design Chang Request)

After the Alpha / Beta phase, the mountain removal team received a lot of feedback from users, some expected and some unexpected. As we all can see, the original design also has a lot of room for improvement. With user feedback, we can also get a more consistent opinion. In addition, people also have a lot of new ideas. For a moment, there were different opinions, and many people shouted-- DCR,DCR!

Rewriting or refactoring

Xiaofei: our so-and-so module really sucks. I think it has to be rewritten, and now there is a new technology called "I admire" (WPF) [or plug in any of the latest fashionable technology]. It can do cool effects, why not?

Erzhu: first we have to see how bad it was and whether it can complete the function now. How serious is the problem you are talking about? Is the function can not be realized? Or is there something wrong with the interface? Or can't be extended (for example, can't support more users)?

Dasuan: in addition, is it refactoring or rewriting?

Refactoring-optimize part of the code while keeping the original interface as much as possible.

Rewrite-re-implement the original function, at the same time, to distinguish whether to repeat all the original functions, or secretly add a lot of new features (Feature Sneak)?

Xiaofei: let's find a leader, Super General Manager, and take a look at my new features.

A Chao: aren't you repairing the bug of this module? Why did you start writing new features?

Xiaofei: yes, but do you think this new feature I added is cool, um... It's a little slow now, but it would be even better if the database made some corresponding changes, such as adding a buffer.

A Chao: did the user mention this function? What does this have to do with the vision of our project? After the database is modified, how to migrate the original user data to the new Schema?

Xiaofei: yes, but if users see it, they will like it.

A Chao: many programmers have the impulse to think that they can do more while making changes. There is a "thing" that they have always wanted to do, but no one has paid attention to it several times, so now if they have the opportunity, just "add it". Or there are a lot of ideas. To make an analogy, it was supposed to fix a sometimes leaky pipe on the top of the kitchen, but the repairman came, fixed it, and added a luxurious bathroom with a shower.

Xiaofei: but it's a new idea after all. I thought you'd like it.

A Chao: remember that we are in the current stage of the project is a process of damping oscillation, to convergence and stability. Wait until the beginning of the next version to think about divergence. If you think there is something wrong with the current design, we should use DCR to manage it.

For a list of all the questions raised (the title is marked with Beta Feedback), A Chao lists the main points of DCR:

(1) how to propose DCR?

a. When submitting a DCR, select the task as the work type and mark it in the title: DCR.

b. In the description text of DCR, describe:

i. Where is the problem? the impact of the problem.

ii. What will be the consequences if no changes are made?

iii. Several modified schemes, their advantages and disadvantages, as well as costs.

(2) how to determine the execution order of DCR?

a. Consult all DCR.

b. Sort by impact and cost, get a top-down list, according to existing resources, according to the list.

In addition, the changes that are suitable for implementation in the Beta branch may not necessarily apply to the main branch (Main Branch), we should do a good job of source control.

Trick: ZBB

The team should have the ability to take care of the bug. ZBB = Zero Bug Build, that is, this version of the build eliminates all known Bug.

Zero Bug Bounce: usually after a Zero Bug Build, the number of Bug will rebound at an alarming rate, so it is called Bounce. The system goes through several bounce times, like a damped shock. After several bounces, the number of Bug is finally fixed at (or infinitely close to) 0.

It should be noted that it is necessary to ensure that the number of Bug is 0, in order to prevent some problems from dragging on, and some bug have been unresolved for a long time, but in fact, they cover up deep-seated design problems, which should be exposed early and set a time limit, which must be solved.

The picture below is the "envisioned ZBB march map" of a team of 60 people. The total number of Bug for each team adds up to the total Bug of the team. The black lines in the following figure indicate the total amount of Bug repaired.

Project ZBB = all defects reported two days ago (48 hours) in this build have been addressed.

An example of a mountain removal company:

The first ZBB was achieved, and a ZBB build was produced, and because the build was of good quality, the test team tried hard to test all the parts. At the same time, complex scenarios are tested, performance and stress tests are carried out. As a result, a lot of new problems were reported. So the Bounce after ZBB jumps very high. After the second ZBB, due to the improvement of the quality of each module, the rebound this time is much lower, with the enhancement of the quality of each ZBB process, the number of Bug will be less and less. At the same time, several features have been cut, and the Bug of these features will not be included in the total. The following ZBB trend chart shows how Bug gradually reaches zero after several bounces.

Figure 15-9 bug ZBB trend chart, Abscissa is the build version number

Trick: cut off the function

There is a module that does not seem to be able to meet the expected design requirements, time is running out, what to do?

Chop!

Yun Yun: but it took us a lot of painstaking efforts to make the design to the present stage. It seems that if we make more efforts, we can succeed. I really can't bear to retreat now. Isn't this a waste of previous investment?

Jelly: yes, we may only need an extra three days. No, just an extra three overnight nights. Besides, we can fix any new problems later.

A Chao: these words seem reasonable, but when you think about it, they don't make sense. Yun Yun, have you ever heard of the word "Sunk Cost"? If not, you should check it on the Internet and study hard. Jelly, from your history of doing things, if a similar function takes N units to complete, then we have no reason to believe that the new feature will take less than N units of time. Let's review the function / resource / time balance map we've seen before, and we need to keep the balance of these factors:

Trick: the threshold for repairing bug is gradually raised.

During the beta, the threshold for repairing bug has to be raised gradually. The same type of bug was fixed yesterday, and if a similar problem is found today, the team may not have to fix it. In the RC phase, only the influential bug can be repaired. Other lower priority bug will have to wait. If there is a serious bug to repair, then these less serious bug may have a chance to be repaired along with it.

In the alpha phase, if the developer gets a bug, he or she can fix it immediately, but tell everyone what changes have been made after checking in.

In the beta phase, before the new code is checked in, the consultation team is told what the potential risk of this change is, how to deal with it, and so on.

In the RC phase, before developers get the bug for repair work, they communicate with the consulting team to see if the bug is worth the time.

Trick: gradually freeze

With the improvement of the function of the program, we need to "freeze" all aspects of the program in order to deliver stable software to users. Generally speaking, the human-computer interface of the program begins to "freeze" at first and cannot be modified at will, because the text information of many projects has to be localized into multiple languages, and when the text and layout used in the human-computer interface are fixed, we can hand these words over to the department responsible for localization. Over time, some features can also be "frozen", these features have been fully tested, all the Bug have been resolved, and the functions have entered a stable state. Don't touch any code related to this feature before the next version. What if there are new features to write? Then put the source code branch (fork) and develop the next version of the function in the new code branch.

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.