Web applications 我应该在我的软件项目中使用正式的方法吗？

我们的客户希望我们构建一个基于web的富internet应用程序来收集软件需求。基本上，它是一个基于web的案例工具，遵循从涉众获取需求的特定过程。我是项目经理，我们仍处于项目的早期阶段

我一直在考虑使用正式的方法来帮助我的客户和开发人员明确工具的需求。所谓形式化方法，我指的是某种形式的建模，可能是基于数学的。我已经读到并正在考虑的一些东西包括Z（）、状态机、UML2.0（可能带有扩展，例如），以及一些编码级别的东西，比如契约和前置条件和后置条件。还有什么我需要考虑的吗？< 开发人员经验丰富，但根据使用的形式，他们可能需要学习一些数学

我正试图确定在这个项目上使用正式方法是否值得，如果是的话，在多大程度上值得。我知道“视情况而定”，所以对我来说最有用的答案是肯定/否定和支持性论点

---

如果你在这个项目上，你会使用正式的方法吗？

这里真正要问的问题不是是否使用它们，而是得到什么和失去什么

---

生产力和结果是否会超过复杂性和所需的学习？

一般来说，你应该使用团队满意的方法。对于新项目，将会有一个学习曲线，这意味着会有关于过程和错误的问题。您的开发时间表的一部分将用于纠正这些问题，如果您不打算在将来将这些问题用于此团队，那么通过引入新的内容，您将不会获得长期收益。更改过程需要很长时间和大量工作

如果您估计有足够的时间来处理这些问题，您可能会没事……如果您的估计是正确的。考虑到你没有和这些人一起工作（至少你的帖子听起来是这样），你的时间线可能不会像它应该的那样准确，这意味着你可能没有分配足够的时间来完成项目，更不用说引入新的流程了

你必须问自己的另一个问题是“你对你想要实施的过程有多满意？”我从不尝试在项目中引入新的过程，除非我知道如果有必要，我可以帮助团队度过难关。不时尝试新事物是好的，但你需要有一个熟悉的团队，知道如何走出困境

我一直在考虑使用正式的方法来帮助我的客户和开发人员明确工具的需求

很少有开发人员有正式的方法经验。我唯一一次看到接受正式方法培训的客户是我们移植到Windows时ZUG的成员

所谓形式化方法，我指的是某种形式的建模，可能是基于数学的。我已经读到并正在考虑的一些东西包括Z（）、状态机、UML2.0（可能带有OCL之类的扩展）、Petri网，以及一些编码级别的东西，比如契约和前置和后置条件。还有什么我需要考虑的吗？< Z是一种以集合论为基础的形式化方法，而UML是一种带有一些半形式化符号（状态机）的非正式符号，两者之间存在很大的差距

一些技术客户，比如您希望使用软件需求工具，对UML非常熟悉

创建域的Z模型可能有价值，创建客户端和服务器之间的消息传递的pi演算模型（或petri网，但我发现pi更简单、更强大）也可能有价值

域的Z模型将提供一组独立于实现的类型约束，它们比任何通用实现语言的类型系统表达得更有力

一个正式的消息传递模型将为您提供运行分析的功能，以确保您不会丢失更新或出现冲突或死锁

UML模型为您提供的是一种符号，用于将大型系统分解为功能区域（包图），显示这些区域中的类如何静态地相互关联（类图），显示这些类的实例如何动态关联（序列图、活动图和交互图），并显示如何部署包（组件和部署图）。这些工具对于团队中的沟通非常有用，可以让想法更加充实，但是没有正式定义的语义，不允许进行非常复杂的分析

我在90年代与Z专家合作过，他们认为在Z中指定casegui的想法是荒谬的。为这样的GUI创建UML模型是司空见惯的

---

我没有使用正式的契约式设计前置和后置条件，尽管我有时会在评论中添加它们，并且经常在断言中添加它们，并且我会对可能违反它们的条件进行单元测试。

我完全同意Tom的观点，并问了同样的问题

生产力和结果是否会超过所需的复杂性和学习

在我看来，除非系统/软件可以确定为“安全关键”，否则不需要正式方法

“安全关键”是什么意思：

---

当计算机系统的故障可能导致灾难性后果，如人员伤亡、环境破坏或系统本身损坏时，这种系统被称为“安全关键型”。我同意Tom和Abufardeh的观点-生产率和结果是否会超过所需的复杂性和学习能力

此外，这种方法是否更适合在开发之前获得所有需求（amd确保这些需求都是定义良好且可测试的）？通用电气