MKS要求的完整性

Question

与其他源代码控制相比，我在这里注意到了关于MKS完整性的文章。是否有人使用MKS完整性来管理需求？最近过得怎样？如果你能对此有任何见解，我将不胜感激：

• 您安装并使用它，
• 对它进行了评估，但决定使用其他

我注意到它宣传说它可以做很多其他的事情，并可能与其他系统结合(JIRA，Test？)协调过程(bug跟踪、测试和覆盖)-集成有多复杂？有人想报告所有这些集成系统吗？

很多问题都有很大的答案..。我知道..。但是，任何关于任何一点的评论都会受到堆栈溢出世界的赞赏:)

Answer 1

我们在工作中使用MKS进行版本控制、问题跟踪和需求管理。一切都很糟糕。如果可能的话，尽量避免。MKS需求管理非常缓慢、过于复杂和繁琐。

在DOORS和MKS工作了7年之后，我不得不说需求管理在总体上被高估了。在穿领带的人中，这只是一种时髦的表达。

到目前为止，我从RM工具中看到的是，没有什么是像样的Wiki引擎所不能做的。想想Redmine:它有Wiki、问题跟踪和版本控制集成。

这一问题还有另一个方面，即专有工具价格过高。我们在门上投入了大量的工作来满足我们的需求，然后突然高层管理层决定门被关闭了，因为它太贵了。多年的工作或多或少地失去了。而且MKS比门贵得多。

与主流观点相反，对开放源码工具的支持非常好，而且它们在导入/导出以及与其他工具的一般工作方面要好得多。而且，没有任何危险，整个工具将被关闭，因为成本节省。

Answer 2

也许对你来说已经太晚了，但我在MKS方面的经验也很糟糕:一个昂贵的垃圾，仍然让我们头痛。与其他工具的“集成”主要是使用SCC接口，特别是在Windows 7 64位时，您可能会遇到一些问题，因为到目前为止，MKS还没有64位版本。

我真的看不出有多大的收益比较，让我们说，一个体面的关系数据库甚至excel！