2
A
回答
11
有一段时间，我认为正确的答案是架构。真实的故事：大约四年前，我将一个软件项目的架构作为我们季度预算审核流程的一部分提交给管理团队。该项目没有获得资助。后来，我问为什么;其中一位高管告诉我，没有人知道我在说什么，他们也没有清楚他们已经完成了多少工作，也没有剩下多少工作 - 太不确定了他们得出结论。大约一年后，我在季度预算审查中提供了另一组项目摘要。在学习了宝贵的经验之后，这一次，对于我的团队最重要的早期项目，我展示了一个GUI - 仅仅是主控制面板中的一个线框，其中只有少数按钮实际上是可点击的，其他线框将被加载。我们为每个主子目录做了这个。对于两天（夜间）的工作，我们的员工做得非常出色 - 显然我能够向管理团队展示该应用的具体功能。
结果：没有资金。我问为什么高管的一个 - 他的回应：
从您的演示 - 我们爱，顺便说一句 - 我们还以为你已经完成了它
肯定有一个教训这里;我只是不知道它是什么。
3
我会说没有区别。如果你的团队中有一位技术娴熟的建筑师 - 那么同时开发这两者都不会有任何问题。如果你的建筑师没有经验 - 你会遇到很多麻烦。
补充： 考虑您的意见，这里是应该推动你的选择：
1）如果你的项目是高度面向特征（例如一些自助服务系统，也许有些bug追踪引擎，等等， - 任何具有复杂功能的东西） - 你应该首先与建筑结合起来。否则，您会发现您的复杂架构不适合您制作的GUI，导致GUI和架构更改以及未来的许多问题。 2）如果你的项目的目标是高度用户友好，让我们说一些像Facebook，last.fm甚至是stackoverflow.com - 你应该先用GUI和架构。通过这种方式，您将确保所有用户友好性保持与设计架构的一些额外麻烦（架构师需要根据GUI设计架构）设计相同。
2
对GUI进行草图绘制或原型制作，并与您的团队（或客户项目客户）讨论它可以阐明背后的领域模型，并揭示大量业务规则和要求，否则将被忽略。
以后你是否做了最终的GUI设计仍然是开放的，但在设计架构之前根本没有考虑接口，恕我直言，有点冒险。
+0
谢谢。然而，问题在于该软件不是针对特定客户开发的，而是针对一般销售的。因此，没有现成的要求。 – Olumide 2010-08-19 14:23:47
+0
@Olumide：你说得对，你写的是。然而，原则保持不变（将更新答案）：当你用创造性的大脑进行研讨会时，考虑界面将有助于塑造需求和域模型恕我直言。 – chiccodoro 2010-10-05 06:38:59
0
GUI可以帮助架构师捕获并理解业务需求，特别是那些作为需求文档的一部分可能不被用户明确捕获的业务需求。
举一个例子：在我们的一个应用程序需求中，用户提到有一组数据输入字段 - 基于一些业务逻辑。 由于在执行GUI时，决定不应该一次全部显示这些组，并且选项卡页面种类的结构对于显示是首选，可用性问题（例如应用程序跨标签移动时保留的数据），技术问题就像所有的标签应该一次加载或按需加载等等对于架构师来说都是显而易见的。澄清这些问题的用户界面导致架构不得不适应各种手段来满足这些要求。
我的确认为，如果可以选择，首先将UI设计为参考并将其作为参考进行工作时更好。
2
我认为这取决于你的软件的类型。通常我想首先确认最困难的部分。如果你的软件GUI（和交互？）将是复杂和重要的，我会建议先设计GUI（和交互）。 （例如，你正在设计一个绘画工具或文本编辑工具）
问题的一部分是，我设想作为未来的创业公司，我希望尽可能保持尽可能低的成本，尽可能地只在需要时聘用人才，在软件架构和工程完成之前，软件开发人员不会被聘用。出于同样的原因，我希望能够在架构完成之前雇佣一名GUI设计师。问题在于GUI架构出现问题。再次，如果GUI设计师是第一个聘用的，他将需要只有建筑师才能提供的规格。结果：鸡和鸡蛋问题。 – Olumide 2010-08-19 11:52:21
@Olumide：我已经改变了我的答案，包括你的情况。 – bezmax 2010-08-19 12:08:03
我想另一种方法可能是让架构师准备初始规格（例如，列出GUI组件），然后带上设计人员来实现GUI生命并引发隐藏的问题。 – Olumide 2010-08-19 14:31:35