Questions tagged «specifications»

我正在为客户设计必须有效且适合用途的产品。 它基于LAMP堆栈（PHP / Cake）构建，因此具有GPL，MIT，PHP，APACHE许可证： “按现状”，没有任何明示或暗示的保证或条件，包括但不限于标题，非侵权，可贸易性或特定用途的适用性的任何保证或条件。您应自行负责确定使用或重新分发作品的适当性，并承担与您根据本许可行使许可有关的任何风险。 我的理由是我的产品有效且适合以下用途： 签名的UAT文档证明其有效性和适用性。 堆栈被开发人员，行业和最终用户（netcraft，gartner等统计数据）广泛使用，以至于人们普遍认为该堆栈适用于目标。（即我们可以在一定程度上忽略保修免责声明中的适用性声明） 这是有效的观点吗？我可以声称我的软件适合使用吗？

15 licensing  documentation  specifications 

通常，我遇到的情况是，新客户使用的应用程序实际上具有数百个不必要的功能，很显然，要使项目有成功的机会，就必须彻底简化事情。您如何说服客户采取更可行的最低可行产品（MVP）方法并进行简化？ 编辑： 因此，当前的最佳答案是为客户提供庞大应用程序的时间/成本估算。我不太喜欢这个答案，因为它不能解决这种情况下的真正问题。那就是-选择一个大型应用程序然后尝试从头开始构建它是一个不好的做法。最初建立一个小型，简单的MVP基础时，我感到更加自在。然后在基础上逐个添加一些小功能。那么，如何说服客户以这种方式开发软件呢？

15 client-relations  specifications 

正如我在其他问题中所写的那样，我正在从事的项目现在没有软件过程。这意味着没有文档（包括硬拷贝要求或规范），没有源代码控制，没有错误数据库，（已修复）错误（希望）并且同时添加了新代码，也没有正式的测试人员-我们将在Joel测试中失败太糟糕了，甚至都不好笑。 昨天，我的经理要我写一份有关如何解决这些缺陷的文档。请注意，我只是一个实习生，在这里工作了6个月。我将在十一月感恩节左右回到学校。但是，我认为我也许可以使这个项目朝着正确的方向发展，但是我不确定从哪里开始。我目前正在使用CiteSeer和Wikipedia来查找一些描述软件过程并实现它们的论文，但是任何建议，个人经验或指向博客，论文，Wiki文章或其他任何内容的链接都将不胜感激。

13 development-process  specifications 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，以使它成为软件工程堆栈交换的主题。 6年前关闭。 我们知道与客户协商规范更正的最佳情况，使规范能够满足客户的要求，而不是客户的要求或想法。正在谈判，解释。 有时，我们无法说服客户。我们被迫按照设计生产破碎的产品。这被魔术师称为“恶魔学”，恶魔召唤恶魔并真正实现他们的愿望，导致魔术师消亡，这是另一种方法，一旦客户意识到自己的错误，他们就会非常不满意，当然还要设法锁定责怪开发商。 现在，我面对的是一个截然不同的方法：客户创建了简单的规范，这些规范不能解释一些关键的警告，并且完全不愿意修复它们，承认明显的错误并接受建议的更正。按照这些规格制造的产品将严重损坏，并可能导致人员伤亡。不过，现在完全放弃合同为时已晚。合同对此有惩罚性条款，我们真的不能接受。 老板的决定？我们会正确地完成工作，并根据规格向客户说谎。有问题的算法隐藏在表面之下足够深的位置，产品可以很好地完成工作，在出现警告的情况下不会失败，并且除非有人挖得太深，否则他们将永远不会发现我们没有按要求进行破解。 这种执行规范的策略有一些通用名称吗？

12 design  specifications 

我注意到了各种原型制作方法，并且在Internet上找到了几种定义，但是我想确认一下我学到了什么。 我知道一次性原型是从规范的概述中开发出来的，交付并修改了各种原型，直到客户对其功能满意为止。 另一方面，演化原型是根据最终用户收集的基本要求构建的。最初的原型将提供给用户并进行评估。根据反馈修改原型，直到客户满意为止。 它是否正确？有没有更好的抛弃式和进化原型的定义？

12 prototyping  specifications 

我对一位不了解迭代开发的高级主管有疑问（更不用说敏捷了）。他坚持要在编写任何代码行之前先完成我们的软件设计规范（SDS）。对他来说，完整意味着所有功能细节都在那里。另外，作为一名前Cobol程序员，他希望查看“模块”和流程图。这是一个Java Web应用程序，可大声喊叫！ 无论如何，我试图找到一个简单的位置来轻轻地指点他，以表明在开始编码之前SDS不一定是100％完整的（也不能完整）。有什么建议？ 谢谢！

12 design  agile  specifications 

我正在阅读C＃规范。我可以在一个段上使用澄清： C＃具有统一的类型系统。所有C＃类型（包括基本类型（如int和double））都从单个根对象类型继承。因此，所有类型都共享一组通用操作，并且任何类型的值都可以以一致的方式存储，传输和操作。此外，C＃支持用户定义的引用类型和值类型，从而允许对象的动态分配以及轻量级结构的内联存储。 在这种情况下，“轻型结构的在线存储”是什么意思？

11 c#  specifications 

今天，我和我的一位同事辩论了“我们应该将规范文档放到诸如SVN之类的源代码控制系统中吗？”。我认为应该是。与开发项目有关的一切都应使用源代码控制系统进行仔细控制。在软件开发过程中这是一个错误的概念吗？

11 version-control  specifications 

我想解释一下为什么在开发期间不得针对新计划部门员工更改规范。

11 requirements  specifications  requirements-management 

在我看来，仅由于自然语言的非正式性质，您不可能用完全没有歧义的英语来编写软件规范，因此，真正明确的规范必须包括以正式指定的语言编写的代码。 这是已知结果还是我缺少什么？

10 documentation  specifications 

我和我的团队开发了客户可以用来与客户互动的软件。此外，我们还吃自己的狗粮，并自己使用该软件与客户互动。 因此，有时可能很难解释用例和场景，因为我们的员工可以是操作员，我们的客户可以是操作员，而我们的客户的客户可以是访客。 但是，我们的客户也可以是与我们的运营商员工互动的访客，我们的客户的顾客可以是与我们的客户或员工互动的访客。 这是一个模型，其中： A is an employee B is a customer C is our customers' customer X interacts with Y Operator --> Visitor A --> B A --> C B --> C 因为有时我们的客户可以扮演不同的角色，所以有时有必要引用特定的角色，即操作员或访客，而不是雇员和客户。 一直说“客户的顾客”也是一个大嘴巴。 我想知道其他开发商店在编写用例和场景时如何处理这些语义细节。 是否有任何一个单词的通用术语可适用于涉及三级参与者的任何产品？ 除了使用特定角色（运营商和访客）以外，还可以使用哪些词来识别客户的客户？ 这个词必须足够短以便在组织内采用。如果音节长于一对音节，则它的缩写形式必须与其他演员区分开。

10 communication  naming  specifications 

我曾经在一家专业的咨询公司工作，而我们是根据许多不同的合同条款工作的。当我们可以获得时间和材料项目时，我们使用SCRUM运行了该项目，并在问题跟踪系统中跟踪了积压工作。 但是，大多数时候，我们必须按照固定价格合同交货。这需要一份规格文件作为合同的附录。因此，我们总是最终从规范中批量导入工作项（或更糟糕的是，手动输入）。变更单花费了大量时间来确保所有内容都保持同步，尤其是在项目结束时。 有没有使整个过程保持干燥的方法论或软件工具？我已经做了一些搜索，但显然没有使用正确的术语。我的大多数专业网络都不做固定价格工作。 我愿意接受： 切换我的错误跟踪器或购买插件（当前使用FogBugz）。 遵循不同的开发方法 编写软件来管理规范并更新Bug跟踪器和规范文档（但这听起来可能需要大量工作才能带来可疑的收益） 最后，这真的值得解决吗？在某些项目上，这花费了我们很多时间，但在其他项目上，它并没有最终影响我们。

9 issue-tracking  specifications  methodology 

按照目前的情况，这个问题不适合我们的问答形式。我们希望答案会得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 7年前关闭。 我正在寻找一个Wiki或类似Wiki的系统来编写和管理软件项目的规范和文档。 我知道有很多Wiki实现可用，但是是否有一些特别适合此类任务的实现？ 实际上，它不必是Wiki，而仅仅是一个可以轻松编写和浏览规格和文档并支持变更跟踪的系统。

9 specifications  wiki 

我们为两个开发团队编写了完整的功能规范。我们没有专业的测试人员，但是我们已经在可用的服务台人员的帮助下起草了“ QA测试”。 过去，我们遇到了无法使用全部功能的问题，或者交付的代码完全不符合规范。 我的问题是：在什么阶段开发人员应该停止将代码移交给质量检查小组？在移交给质量检查团队之前，要求开发人员对照规范检查其代码是否过多？

9 testing  qa  specifications 

我简直无法想象没有规范就可以编写软件。无论是粗略的还是高级的，规范对于向无知的程序员解释程序的功能是很重要的。 但是规范的问题在于，在整个软件开发周期中，它多少有些二等公民。当发展加速时，它就被忽略了。但是，当出现争议时，开发人员，测试人员和销售人员会争先恐后地找到规范以证明其根据。 一种或多种情况都会发生： 规范无法恢复，没人知道规范在哪里 规范的不同版本来自不同的来源。它需要很大的困难，找出哪个版本是最新版本，或是否有是可用的最新版本。 规范不完整，所指文件的某些部分丢失了。 因此，规范管理非常重要，每个人只有一个单一的规范来源也同样重要。 您如何管理规格？我试图让所有人使用Google文档，但所有人都反对。每个人都对Microsoft Word太着迷和迷恋，他们认为Microsoft Word非常易于使用，易于插入图像，非常容易键入方程式等等。 如何使他们相信MS Word只是可怕的共享？

9 specifications