illustrate
This article will occasionally update my questions about the textbook, as well as questions about this class.
There is a sentence in book P2, "Users do not fully understand and master the needs of the software system they will use." This sentence is true, but I still have some doubts, if the user is clear at the beginning of the project. If the functions and requirements are directly written into the contract document and cannot be modified, will this still be the case? Personally, I think the two key points of the product are: ① the core functions of the product and the minimum requirements; ② the interface art. If these two points are clear, then it should be much better. What if the core function is not clear? Then it can only be said that you don’t even know what you want and need others to help you figure out how is this possible? Software engineers only help you to realize the specific implementation instead of the initial product idea.
Regarding some shortcomings of the book, no specific cases are given in the introduction of software engineering models. I personally feel that the same case can be used when introducing software engineering models to facilitate the comparison of the differences between different models. case, it is convenient to know the applicable domain of this model. One more thing to add, I personally feel that the class is very boring, just talking about PPT, I think the teacher should supplement the case more in the class, there are already books on the theory, and there is no need to repeat it in the class, otherwise the theory and theory, So confused.
Procedural Description Language (PDL) is also known as pseudocode language. I personally feel that this language description problem is very tasteless. It is like code, but the result is pseudo code. Many specific data structures are not clear. Sometimes the construction of programming is the construction of data structures, and there is an appropriate data structure. to better solve the problem.
Project risk management includes risk identification, risk estimation, etc., but the book only briefly summarizes this process, and does not give detailed examples to explain it. I still feel that I don't understand the specific method.
Regarding the problems of the whole book, I personally feel that the biggest problem of the whole book is that the control of engineering details is not very good. It only talks about macro methods and lacks a real sense of engineering. Personally, I think that there should be problems and actual combat operations. Find the problem first, and then give the solution to the problem, not a solution, but you just don't see the actual problem easily. Although some cases are also given in the book, I personally feel that it does not highlight the characteristics of actual combat very well, and it feels like a problem case specially designed to match the method.