[Full-Process Modeling] responding to Chapter 4 of qingrun Software Engineering Application Technology Survey Report-iteration and delivery cycle

Today, I finally saw some updates about the response on Mr. Zhang's page. Here is also a reply. Let's talk about iteration and delivery cycle first.

To be honest, I still haven't seen any real project data analysis in this response text, and all the content is Mr Zhang's wishful thinking, for example: Do I know iteration, the issue about the delivery time extended due to my full-Process Modeling of the RUP.

Mr Zhang's original reference

"

Evaluation of qingrun's China Software Engineering Technology Application Survey Report

[Traffic: 1651]

Author: Zhang Yu Posting date: March April 2007

Updated on 11:31:07

<Homepage> <Previous Page> <next page> <last page>
Preface to page 1/10Page 1. Popularity of XPPage 3/10 nonsense II. Applicability of RUP in ChinaPage 4/10 nonsense 3. Whether there is a software architect in ChinaPage 5/10 nonsense 4. Popularity of Project ManagementPage 5, white box and black box testingPage 6. Popularity of automated testing toolsPage 7, XP and automated testingPage 9/10 nonsense 8. Test consistencyPage 9, iteration and build frequency"Comment on the data related to RUP: from the perspective of the development process and practice of software enterprises, full useProcess framework of RUPDevelopment in China is not realistic becauseThe complexity and Management weight of the RUP process are unacceptable for large and small enterprises in China.."

-- This is obviously a nonsense!

As an expert studying the RUP, we should know that the RUP is a process framework (as mentioned by qingrun ). What does framework mean? Since it is a framework, it means that you can customize both heavyweight RUP and lightweight RUP (such as agile up ), I don't need to reference famous documents and cases at home and abroad. The RUP framework and the RUP process are two different things. In fact, after years of development, the Unified Process (up) has become a big family of process methods.

As a practitioner of the RUP, you should know that generally, the implementation of the RUP needs to be customized! The vast majority of the artifacts, steps, and roles in RUP are optional (Optional). They are placed there for the purpose of serving as a work guide and method guide and can be referenced as needed. Like the msdn library, the RUP framework is also a rich process knowledge base. No one will think that the msdn library is too heavy. Will someone question whether the library is too heavy?

How can we compare RUP with XP? XP is a specific process and is strict. There are 12 military rules (old version). If you cannot do the key items, the project may face major risks. RUP is a flexible and abstract framework. It can be either the same way or the same way. How can you compare it? We should customize a Lightweight Process (Instance) from the RUP framework to compare with XP, just like the cocktail (process) dx that Robert Martin (Uncle Bob) once called out.

Therefore, when qingrun argues that "the complexity and Management weight of the RUP process itself" and "large enterprises in China and small enterprises cannot afford it, I gave a comment on "nonsense. In fact, the RUP process can be either heavy (heavy is not bad, but the key depends on the needs of the project) or light and agile. According to qingrun's introduction, he seems to have had implementation experience in the RUP field, which is probably some of the most failed heavy-duty RUP cases. His one-sided understanding and misinterpretation of RUP, and his ignorance of the essence, essence, and common sense of RUP are beyond my expectation.

In a reply on April 7, qingrun again mentioned"Application of heavyweight process models such as RUPIt can indeed improve the quality of software to a certain extent. "It means that in the mind of qingrun, we can see that: RUP = weight. Here I will re-apply:RUP is a rich and flexible process framework, not a heavyweight process!

Today, I have been engaged in UP/RUP consulting for almost eight years. There are both state-owned enterprises, large listed companies, private enterprises, foreign-funded enterprises, and large enterprises, there are also small and medium-sized enterprises. There are enterprises that have implemented CMM/cmme, and enterprises that have adopted modern agile methods. I have participated in consulting, review, and service projects from hundreds of millions to hundreds of millions, involving a wide range of industries, projects, scales, and regions, both of them work well on the premise that you have carefully studied and have a correct understanding of and understanding of the process. My hands-on experience and experience demonstrate the wide applicability of RUP and the consensus of major international software engineering circles on it.

We recommend that you read the article Craig larman I translated two years ago, "Seven steps to implementing the RUP".

Then, qingrun mentioned in its reply:

I have a personal opinion on whether this article is nonsense.

I usedI personally participated in the project implementation of full application of RUPIn this project, I felt the advantages of UML, and later I took the initiative to promote the implementation of UML in the project, in domestic engineering projects, there were dozens of projects involving nearly 20 million contracts involving 11 provincial telecommunications companies and telecommunications group companies, ranging from dozens of days.

My understanding of domestic software enterprises, my understanding of the patience and patience of the clients, and my analysis of the application of RUP are as follows:Application of heavyweight process models such as RUPIt can indeed improve the software quality to a certain extent, but in the development cycle, in particular, the development cycle before the first delivery is relatively longer than the original development process (roughly 20% to 30% ), the cost of the first delivery brought about by the extension of this time also increases accordingly (compared with the extension of the time period, this increase is also around 30%, both of which are estimated figures, ).

Due to the chaotic management and low credibility of domestic software enterprises, the current mode that users prefer is: when the contract is signed, the software will be delivered and the contract will be paid. WhileThe extension of this time will make users feel that they have never seen software products.And generates corresponding concerns and distrust of developers. Almost all contracts will set an unreasonable delivery time as required by the user.

Therefore, based on this analysis, I think that my opinion is not a nonsense, but a result of my project experience and the accumulation of many first-line software developers, I believe that as long as the technical staff who participated in the development at the front line of the engineering software project basically share the same view.

What is the problem he encountered? Why did he come to a wrong conclusion about the RUP? Explanation:

First, qingrun declared that he had "personally participated in the whole process of applying the RUP Project", and analyzed his "Application of the RUP experience as follows: application of heavyweight process models such as RUP can indeed improve software quality to a certain extent... ". It can be seen that it is beyond doubt that greenun regards the process model as a heavyweight model (a large number of steps are required and a large number of documents are submitted. But the question is, based on qingrun's experience, why is the first delivery period extended by 20-30% after applying the RUP?

People familiar with the RUP know that iterative and incremental development is a basic feature of the RUP, and for projects with fixed delivery periods and fixed budgets (fixed time and fixed budget, it also provides good solutions. In the case of fixed time and cost, you can adjust (contract) The delivery content to achieve on-time delivery, which is a basic knowledge of modern software project management. Therefore, the first delivery time of the system does not need to be extended (fixed time) if the rational application of RUP is used correctly ). So what to say, "the delivery period and cost have increased by 20-30% because of the application of RUP" is also a nonsense. The failure of these projects (delay and overspending) it is precisely because it does not properly apply the RUP.

Qingrun also mentioned that "the extension of this time will make users feel that they have never seen software products ". Why does the user "never see software products" when applying the RUP "? I guess it is probably because qingrun does not know that the process of RUP should be iterated. The process of "never seeing software products" is not the process of RUP.

Qingrun regards the setbacks he encountered in practical projects, the misunderstanding and misuse of the RUP as the problem of the RUP, which is obviously wrong. As a result of these problems, I think it is related to qingrun's mistake of using RUP as a heavyweight process and waterfall process. It may also be related to the full modeling method created by qingrun. In my opinion, the word "full course" is itself prone to over-modeling. Qingrun clearly does not know that the application of the RUP process can deliver the product within the specified time, and the customer cannot never see the software product. Advocating UML visual modeling for complex software systems is certainly a major feature of RUP, but it also emphasizes the early delivery of stable architectures and products to users through iteration (programming implementation and testing.

Over-modeling is not a process of RUP. We cannot name all projects with UML modeling as a process of using the RUP project. Qingrun has the guts to admit that the cost and time increase of 20-30% are caused by your full-process modeling?

From the above discussion and analysis, I have come to the conclusion that qingrun basically does not understand RUP, or lacks a correct and comprehensive understanding of it, the so-called "personal participation in a project that has applied the entire process of RUP" is very suspicious. Such A project may only be called a "full-process modeling" project, but not a full-process modeling project. This is my opinion on the truth.

"

Commenting on qingrun doesn't know what iteration is!

Instead, I asked Mr. Zhang what he defined for iteration. Maybe I don't know what Mr. Zhang's iteration is, but I believe I know exactly what it means.

I know Mr. Zhang is talking about delivery, but in the process of project progress in China, users often want to directly see all available software versions, instead of publishing versions one by one, I am somewhat skeptical that Mr. Zhang has personally participated in the development of a complete domestic software product project !!!

Anyone who has participated in actual software requirements, analysis design, and coding testing knows what the first delivery means.

In addition, I have repeatedly expressed this point of view in my text: the time of the first delivery would be somewhat delayed if the process of using the RUP, even the process of reduction, was compared to the process of relatively chaotic or incomplete use of the RUP, the delay is generally about 1/3. That is to say, a 10-month project can be delivered for the first time only after a delay of three months.

Note that the delivery here must be a complete version, because in the Chinese environment, you cannot deliver an incomplete version to the end user. If you dare to do so, the customer dared to directly throw your software into the garbage bin!

Of course, the version delivered by the user still cannot fully meet the requirements of the user. It still needs to be modified and adjusted, optimized, and modified based on the user's experience.

 

Qingrun's delivery delay is due to his own suggestions for full modeling.

In this regard, I can tell Mr. Zhang that, on the contrary, it is because of my full-process modeling method that I can basically make the delivery time very close to the traditional software development time, almost no latency.

In addition, anyone who has heard of my training knows that I will use different parts of the method for different stages of different projects, and it does not require that all stages must be implemented through UML expressions, after all, our technicians are not very familiar with UML, their skills also need to be improved (at least the actual situation in the two teams that have applied the full modeling method is as follows, this is also due to the instability of Chinese software companies ).

In addition, we can consider that a relatively stable and harmonious team can omit a considerable number of documents, and a large number of documents should not be missing according to the suggestions of RUP, it cannot even be omitted, because each delivery step has its necessary documentation. During the process of writing and modifying these documents, a considerable amount of manpower and material resources will be generated. (Note: I am not saying that writing these documents is useless, however, to some extent, these documents may be ignored, but the stability of the team may lead to corresponding savings. Does this not lead to a delay in delivery?

In actual projects, project delivery is often designated, and we can postpone delivery for some reasons, for example, at the beginning of, the delivery of one of our software versions benefited from SARS and received an additional development cycle of more than two months, which allowed our project team to die. Otherwise, at that time, our project team could not deliver the software version required by the China Telecom group in middle May.

End

I still want Mr. Zhang to come up with data, instead of simply making empty-to-empty reasoning or empty-to-data reasoning here. This is not what a person should say or should write.

I once again stressed that a person who does things should use data to speak!