在设计方面，大多数开发人员都在一定程度上了解UML，但不一定会使用它。如果给他们 CASE 工具，他们可能会单独使用类图，但不会经常使用其他工具。 CASE 工具迫使您使用 UML 的“正式形式”，因此它们相当严格，这限制了它们的创造性使用。通常创建 CASE 模型是为了从代码生成中受益。在我自己的公司中，我们生成了大量代码，但根本不使用 UML。
对于协作设计和审查（例如，在板上绘图），UML 更常见，因为“每个人都说它”。然而，从我所做并发表的观察性研究来看，画在黑板上的UML仅仅是达到目的的手段——人们借用某些符号，但用它们来交流想法。所以你会在类图上看到序列和控制流之类的东西。所产生的工件不是您可以将其捕获到 CASE 工具中的东西。您可以查看我的论文，了解这些东西的外观的许多照片就像你召集一群经验丰富的开发人员来做设计一样。
在规划方面，我的经验是，软件公司和同时开发软件的公司之间存在很大差异。对于后者（占大多数），宏观层面的规划通常是根据企业文化和商业风格规划来完成的，这些都是你在 MBA 中学到的东西。它通常不是特定于软件的，就管理层而言，您可能正在构建软件或烘烤松饼，这只是数字。在更微观的层面上，实际上并没有使用任何官方系统。甘特图和电子表格等工具用于跟踪最佳情况的猜测和延误的时间表。但最终，这取决于管理层的经验——前开发人员通常在这方面更擅长。某些实践（例如敏捷）在某些方面简化了规划。
I think you're confusing planning and design/architecture. Planning usually refers to the business side of things - how many people will do something in how long. Design/architecture should deal with how to do things right assuming you had enough time and budget.
In terms of design, most developers know UML to some degree, but don't necessarily use it. If they are given CASE tools, they might use class diagrams for individual use, but not use the others frequently. CASE tools force you to use the "formal form" of UML so they are fairly strict and that limits their creative use. A CASE model is often created to benefit from code generation. In my own company, we produce a ton of code but don't use UML at all.
For collaborative design and review (e.g., drawing on the board), UML is more common because "everyone speaks it". However, from observational studies that I've done and published, UML drawn on the board is merely means to an end - people borrow certain notations, but use them to communicate ideas. So you would see things like sequences and control flow on a class diagram. The resulting artifacts are not something you could just capture into a CASE tool. You can see my dissertation for many photos of what these things look like when you group a bunch of experienced developers to do design.
In terms of planning, my experience is that this highly differs between software companies and companies that also develop software. In the latter (which are the majority) macro-level planning is often done based on corporate culture and business style planning, the kind of stuff you learn in MBAs. It is typically not specific to software, and as far as management is concerned you could be building software or baking muffins, it's just numbers. On a more micro-level, there isn't really any official system used. Tools like Gantt charts and spreadsheets are used to keep track of what are essentially best-case guesses and slipped schedules. But in the end, it depends on management's experience - former devs are usually stronger at it. Certain practices like Agile simplify planning in some ways.
发布评论
评论（1）
我认为你混淆了规划和设计/架构。规划通常指的是事情的业务方面——有多少人会在多长时间内做某事。设计/架构应该处理如何在假设您有足够的时间和预算的情况下正确地做事。
在设计方面，大多数开发人员都在一定程度上了解UML，但不一定会使用它。如果给他们 CASE 工具，他们可能会单独使用类图，但不会经常使用其他工具。 CASE 工具迫使您使用 UML 的“正式形式”，因此它们相当严格，这限制了它们的创造性使用。通常创建 CASE 模型是为了从代码生成中受益。在我自己的公司中，我们生成了大量代码，但根本不使用 UML。
对于协作设计和审查（例如，在板上绘图），UML 更常见，因为“每个人都说它”。然而，从我所做并发表的观察性研究来看，画在黑板上的UML仅仅是达到目的的手段——人们借用某些符号，但用它们来交流想法。所以你会在类图上看到序列和控制流之类的东西。所产生的工件不是您可以将其捕获到 CASE 工具中的东西。您可以查看我的论文，了解这些东西的外观的许多照片就像你召集一群经验丰富的开发人员来做设计一样。
在规划方面，我的经验是，软件公司和同时开发软件的公司之间存在很大差异。对于后者（占大多数），宏观层面的规划通常是根据企业文化和商业风格规划来完成的，这些都是你在 MBA 中学到的东西。它通常不是特定于软件的，就管理层而言，您可能正在构建软件或烘烤松饼，这只是数字。在更微观的层面上，实际上并没有使用任何官方系统。甘特图和电子表格等工具用于跟踪最佳情况的猜测和延误的时间表。但最终，这取决于管理层的经验——前开发人员通常在这方面更擅长。某些实践（例如敏捷）在某些方面简化了规划。
I think you're confusing planning and design/architecture. Planning usually refers to the business side of things - how many people will do something in how long. Design/architecture should deal with how to do things right assuming you had enough time and budget.
In terms of design, most developers know UML to some degree, but don't necessarily use it. If they are given CASE tools, they might use class diagrams for individual use, but not use the others frequently. CASE tools force you to use the "formal form" of UML so they are fairly strict and that limits their creative use. A CASE model is often created to benefit from code generation. In my own company, we produce a ton of code but don't use UML at all.
For collaborative design and review (e.g., drawing on the board), UML is more common because "everyone speaks it". However, from observational studies that I've done and published, UML drawn on the board is merely means to an end - people borrow certain notations, but use them to communicate ideas. So you would see things like sequences and control flow on a class diagram. The resulting artifacts are not something you could just capture into a CASE tool. You can see my dissertation for many photos of what these things look like when you group a bunch of experienced developers to do design.
In terms of planning, my experience is that this highly differs between software companies and companies that also develop software. In the latter (which are the majority) macro-level planning is often done based on corporate culture and business style planning, the kind of stuff you learn in MBAs. It is typically not specific to software, and as far as management is concerned you could be building software or baking muffins, it's just numbers. On a more micro-level, there isn't really any official system used. Tools like Gantt charts and spreadsheets are used to keep track of what are essentially best-case guesses and slipped schedules. But in the end, it depends on management's experience - former devs are usually stronger at it. Certain practices like Agile simplify planning in some ways.