如何开始为 Web 应用程序建模？
我问这个问题是因为明天是我与客户的第一次会面，她在会上告诉我她现在正在做什么（手动）以及它是什么，新的 Web 应用程序最终应该做什么。
我想知道，在她向我展示该过程的步骤期间我做了什么。 我是否能够识别用例并直接对其进行建模？ 我是否用散文描述了这个过程？ 我如何描述/转录从现实世界到模型的过程，然后模型成为代码的基础？
对您来说开始新开发的最佳实践是什么？ 有小费吗？
I ask this, because tomorrow is my first meeting with the client, in which she tells me, what she is doing right now (by hand) and what it is, what the new web-application should do in the end.
I wondered, what I do during she shows me the steps of the process. Do I recognize use cases and model them directly? Do I describe the process in prosa? How do I describe/transcribe the process from real world to a modell which then is the basis for the code?
What is the best-practice to start with a new development for you? Any tips?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
这一切都与流程和管理期望有关，与技术关系不大。 大多数客户（尤其是小型咨询公司）所犯的错误（恕我直言）是他们选择固定价格合同（可能会按 T&M 计费：时间和材料）。 他们这样做是为了风险管理，所以这是可以理解的。
问题在于，他们通过三种方式为较低的风险付出代价：
所有这些都会使最终结果对客户来说更加昂贵，从而降低开发人员的积极性（谁想编写 300 页的 Word 文档？说真的！）并且它延迟了客户实际获得任何东西（从而增加了范围蔓延的风险，这与项目的长度成正比）。
通过将 T&M 方法与某种形式的快速原型制作方法相结合，并定期向客户交付成果或演示，间隔时间不超过 4-6 周，双方通常会得到更好的服务。 这有助于管理期望。 如果客户可以看到正在发生的事情，他们就会感到轻松，并让您可以继续工作（而不是在会议上等待时间查看甘特图）。
因此，您应该做的是尝试并说服您的客户采用渐进的方法（婴儿步骤），让他们可以看到自己得到了什么，它是如何发展的并参与这个过程。 它可以更快地获得结果，并且最终更便宜（双方分担风险负担）。
许多开发商似乎还忘记了一件事，那就是他们就像 15 世纪法国的皇室臣民。 他们可能拥有特权，甚至财富和许多特权，但他们为国王（或王后）服务，国王可以随心所欲地将他们斩首。 我的意思是，客户最终拥有权力，而你作为开发人员的存在是为了让他们的生活更轻松，而不是相反。
如果客户想要一个用 Cobol on Rails 开发的粉色和绿色网站，运行在老板 iphone 上的虚拟 Vax/VMS 服务器上，那么他们就会得到。 现在你可以利用你的专业知识和经验来尝试说服他们这不是一个好主意，但最终如果这是他们想要的，你有两个选择：给他们或步行。
太多的开发人员陷入了这样的陷阱：给人们他们认为他们应该拥有的东西，而不是他们要求的东西。 大错。 这个过程的一部分是保持与客户的沟通渠道畅通，这样当他们期待完全不同的东西时，你就不会偏离主题，认为他们想要一些东西（或决定他们应该拥有一些东西）。
即使是一个小型的软件开发项目也很容易达到 6 位数。 对于支付费用的人来说，这通常是一笔巨大的投资。 他们有权利感到紧张，而你有责任让他们快乐。
It's all about process and managing expectations and very little to do with the technical. The mistake (imho) most clients make--particularly with smaller consultancies--is that they go for a fixed price contract (possibly with support being billed T&M: time and materials). They do this as a risk management exercise so it's understandable.
The problem is that they are paying for that lower risk in three ways:
All of this serves to make the end result more expensive for the client, demotivating for the developer (who wants to write 300 page Word docs? Seriously!) and it delays the client actually getting anything (thus increasing the risk of scope creep, which is directly proportional to the length of the project).
Both parties would often be better served by taking the T&M approach combined with some form of rapid prototyping methodology with regular deliverables or demonstrations to the client no more than 4-6 weeks apart. This goes towards managing expectations. If the client can see something is happening it puts them at ease and lets you get on with the job (rather thans pending time in meetings going over GANTT charts).
So what you should do is try and voncince your client to go for a graduated approach (baby steps) where they can see what they're getting, how it's evolving and participate in the process. It gets results faster and is ultimately cheaper (with both parties sharing the risk burden).
One thing many developers also seem to forget is that they are like royal subjects in 15th century France. They may have privilege, even riches, and many perqs but they serve at the pleasure of the king (or queen), who can behead them on a whim. By this I mean that the client ultimately wields the power and you, as a developer, exist to make their life easier and not the other way around.
If the client wants a pink and green website developed in Cobol on Rails running on a virtual Vax/VMS server on the boss's iphone well that's what they get. Now you can use your expertise and experience to try and convince them that's not a good idea but ultimately if that's what they want you have two choices: give it to them or walk.
Too many developers fall into the trap of giving people what they think they should have, not what they ask for. BIG MISTAKE. Part of the process is to keep communication channels open with the client such that you don't go off on a tangent thinking they want something (or deciding they should have something) when they're expecting something completely different.
Even a small software development project can easily run into 6 figures. This is typically a large investment for whoever is paying for it. They have a right ot be nervous and you have a responsibility to make them happy.
我不认为你的客户想和你谈论任何这些事情......我打赌她会向你展示一些关于页面应该如何组织以及她期望事情如何工作的图画。
您应该按照她的演示提出问题（始终从用户的角度出发），这样您就可以按照她的期望完成您的工作。 把技术方面的东西留给你自己吧；）
I don't think your client wants to talk to you about any of those things... I Bet she is going to show you some drawings on how the page should be organized and how she expect things to work.
You should just follow her presentation asking questions (always for the user point of view), so you can do your job as she expects. Leave the technical stuff for yourself ;)
大多数开发人员不会花时间这样做，而是直接跳到类图和系统架构建模中，但我最想说的是写下她提到的每一个功能。 不必担心分组或它们如何组合在一起。 那时，您只需要从她那里获得所有可能的功能即可。 当您离开并开始考虑应用程序时，您将开始绘制功能块之间的相关性，这些功能最终将分组为具有属性和方法的对象。
Most developers don't take the time to do this, and jump right into modeling class diagrams and the system architecture, but more than anything I would say to write down every single feature she mentions. Don't worry about groupings, or how they all fit together. At the time, you just need to get from her every piece of functionality possible. When you leave, and begin to think about the application, it is then that you will start to draw correlations between pieces of functionality, which will end up eventually grouped into objects with properties and methods.
客户很可能在您与他们交谈的前 5 分钟内就告诉您他们想要什么。 之后的一切都只是枕边说说而已。
The client most likely told you what they want in the first 5 minutes you talked to them. Anything after that is just pillow talk.
我衷心推荐 Eric Evans 的“领域驱动设计”。 它解释了如何对问题域进行建模，并在此过程中建立一种通用语言，您和客户可以通过该语言清楚地沟通应用程序的功能。
另外，看看您是否可以找到适合您的目标平台的快速开发工具，以便您可以快速地将东西呈现在客户面前以获得早期反馈。 例如，如果您使用的是 Java EE，请查看 Spring Roo，它支持往返。
I can heartily recommend "Domain Driven Design" by Eric Evans. It explains how to model the problem domain and in the process establish a ubiquitous language by which you and the client can communicate clearly about the application's features.
Also, see if you can find a rapid development tool for your target platform, so that you can get something in front of your client quickly for early feedback. For example if you're using Java EE, check out Spring Roo, which supports round-tripping.
用户对其如何工作不感兴趣。 对他们来说，一切都与界面的组织和执行操作的必要步骤有关。 我同意上述建议，写下功能和接口要求，让他们看看如何以及是否可以建模。
分析后再次与她讨论您可以做什么和不能做什么，并提出解决方案或改进措施。
Users are not interested in how its going to work. To them its all about the organization of the interface and the necessary steps to perform the operations. I agree with the above suggestions, write down functionality and interface requirements and them see how and if they can be modeled.
After the analysis talk to her again about what you can and cannot do and present solutions or improvements.