问题标签 [sdlc]

我正在尝试确定一些指示资源有限项目的标记。

以我的经验，一个项目变成了一个“资源有限”的项目，因为有人急于向客户出售解决方案。结果是预算紧张，功能被剔除，SDLC 流程被削减到最低限度。这些捷径被采用，因此公司有一定的机会获利甚至收支平衡。

这是我看到的与资源有限的项目齐头并进的事情清单：

• 分配给 QA 的最少时间
• 不合规格工作的严格官僚程序
• 变更请求预算可能很小或不存在
• 正式的流程被放弃，有利于利用时间进行开发
• 没有时间进行内容检查等增值质量检查（例如文本中的语法或拼写错误）。
• 不能为客户做任何内容管理或数据输入
• 必须寻求“足够好”的编码解决方案
• 走廊可用性测试没有时间限制。
• 没有编写用户文档或手册的预算。
• 编码前一般没有时间进行技术研究
• 没有时间制作风险分析文件
• 可以使用生产清单代替项目进度表。
• 程序员没有时间在项目进度表中填写他们的“实际”时间与估计时间。
• 提供给客户的进度更新可能不那么频繁或非常基本
• 可用于了解客户业务领域的时间更少
• 程序员可能不得不无偿加班。
• 没有时间分配给项目事后分析

有限资源项目还有哪些其他确定的迹象？

===

编辑

我会尝试用一个例子来消除一些混乱。这就是我的意思：给客户一份提案/报价，说他们的项目将花费 2 万美元。然后客户回来说“对不起，我的预算最高为 16,000 美元”。老板说“让提案 16,000 美元——我们想要这项工作”。

所以，实际上，你必须用比它应该有的更少的预算来做一个项目。有一些界限变得荒谬 - 如果客户说“我的预算是 4,000 美元”，那么你不可能做到。

是的，有时紧张的预算会变得如此愚蠢，以至于一开始就接受这个项目是一个糟糕的商业决定（即注定失败的项目）。

我知道没有预算不受限制的项目。业务人员通常会决定是否应开展项目（业务人员通常不是项目经理）。

Microsoft 的 Team 系统和 IBM 的 Rational Team Concert 都具有相似的特性和功能。两者都声称能够使用他们最喜欢的 IDE 支持 Java 或 .NET 开发人员。您是否有任何经验表明对于一种适用于所有人的解决方案而言，一种比另一种更好？它们之间是否有任何关键差异（功能）使您偏爱其中一个？两者的互操作性有多好？

只是试图将营销与现实分开，这些人对这两种产品都有很多知识和经验。

TIA,

斯科特

我正在为 TFS 开发几个自定义构建脚本，我想知道是否有开发、测试和部署 TFS 构建脚本的最佳实践。

您是否设置了与生产构建服务器分开的开发和 QC 环境？是否有其他方法可以将开发脚本的过程与构建过程的其余部分隔离开来，以便正在开发的构建脚本不会干扰“生产”构建？

Team Build 喜欢创建工作项、更新工作项和添加标签作为构建过程的一部分，我不希望在“测试”构建中发生这种情况。

jMM

一般来说，SDLC 有以下阶段

需求收集设计编码测试部署

但是在上面的 SDLC 中，我在哪里适合以下阶段（我知道它是围绕需求收集和设计阶段）

1) 可行性研究

战略可行性研究（我们在这个阶段做什么？） 技术可行性研究（我们在这个阶段做什么？）

2）分析（我们在这个阶段做什么？它与可行性研究有什么不同？）

3) 建模

我不确定你们中是否有人遇到过这种情况。我们有一些小项目或修复，我们需要每隔一天推送到 LIVE。

有一组团队说“在产品服务器上进行干净的构建和部署”。另一组说我们不必进行完整部署，我们只需进行 dll 删除或 aspx 删除即可。

他们列出了每种方法的一些优缺点。但是想知道您通常遵循哪种方法，每种方法都会遇到任何重大挫折。

不是更接近：

n * (n - 1) / 2

上面的公式是这个中学数学小组问题的答案：

“你有n个人在一个房间里，他们都和其他人握手。握手了多少次？”

这不也适用于在软件项目中交流的人数吗？

免责声明

我还没有读过这本书（还），但我已经看到了n^2其他地方引用的公式。

是否有人提供使用 SDLC 中的自动化工具提高生产力的数据？

我创建了一个 PHP 网络应用程序。

我有 3 个环境：DEV、TEST、PROD。

什么是我将 PHP Web 应用程序代码从 DEV 移动到 TEST 到 PROD 环境的好工具/业务实践？

意识到我的 TEST 环境仍然只连接到我的 TEST 数据库；而我需要 PROD 环境才能连接到我的 PROD 数据库。所以代码几乎是相同的，除了我需要更改我的 TEST 代码一旦移入 PROD 以连接到 PROD 数据库而不是 TEST 数据库。

我听说有人关闭 Apache，它不允许新的连接，一旦所有现有连接都空闲，它只会关闭 Web 服务器。

然后人们手动复制代码，然后手动更新 PHP 应用程序的配置文件，使其也指向 PROD 实例。

这似乎非常危险。

是否存在最佳实践？

我曾在 QA 团队从项目开始到维护期间积极参与开发过程的环境中工作。我通常发现这是有效的，因为 QA 团队在流程的早期就从业务前景中了解了正在发生的事情。他们可以很早就开始编写测试脚本。

但是，我也曾在 QA 团队与开发团队非常脱节的环境中工作。他们对流程没有兴趣，只是在“开发”阶段结束时参与进来，争先恐后地提出测试，然后根据自己对业务需求的理解执行一组有限的测试。

你对此有何感想？您认为 QA 团队在流程中的参与程度如何？如何将习惯于“不参与”的团队转变为积极参与流程的团队？

有没有面向服务的软件开发方法？