标签: sdlc

它在维基百科上的Systems Development Life Cycle页面中提到:

为了解决这个问题,我们创建了许多系统开发生命周期(SDLC)模型:瀑布,喷泉,螺旋,构建和修复,快速原型设计,增量,同步和稳定.

我在谷歌上发现了一些东西,但我觉得它们含糊不清,他们只是没有点击我.也许这里某人的解释可能更清楚.

您是否有任何方法/系统来激励您的开发团队成员编写"好"代码并在其代码中添加注释？我认识到"好"是一个主观术语,它涉及一个关于测量代码可维护性的早期问题,作为良好代码的一种衡量标准.

那么如何让它们在测试和生产环境之间保持同步？

当谈到数据库表的索引时,我的理念是它们是编写查询数据库的任何代码的不可或缺的一部分.如果不分析对索引的影响,则无法引入新查询或更改查询.

因此,我尽力使我的索引在我的所有环境之间保持同步,但说实话,我在自动化方面做得并不好.这是一种随意的手动过程.

我定期检查索引统计信息并删除不必要的索引.我通常通过创建一个删除脚本来执行此操作,然后将其复制回其他环境.

但是这里和那里的索引在正常过程之外被创建和删除,并且很难看出差异在哪里.

我发现一件真正有用的事情就是使用简单的数字索引名称,比如

idx_t_01
idx_t_02

其中t是表的简短缩写.当我试图让所有相关的列变得聪明时,我发现索引维护是不可能的,例如,

idx_c1_c2_c5_c9_c3_c11_5

区分这样的索引太难了.

有没有人有一个非常好的方法将索引维护集成到源代码控制和开发生命周期？

在SDLC中,测试程序应在实施后立即进行.但是,测试驱动开发鼓励我们在实施时进行测试.在我的讲座课程中,教授说测试用例应该是设计的一部分.

我是一名初级开发人员,要实现新功能,何时应该设计并记录我的测试用例？

我发现在完成实施后测试所有案例并不是那么实际.这是因为一旦案件失败,我必须更改代码并重新测试所有案例.还有另一种方法可以克服并避免这种情况吗？我知道自动化睾丸是解决方案之一,但不知何故,自动化睾丸无法刺激所有测试用例,尤其是涉及不同方的集成测试用例.

另外,在我的测试用例中,我应该测试代码的所有部分吗？或者只测试该功能请求的功能？或者它实际上取决于你有多少时间？

非常感谢.

我正在尝试确定一些表明资源有限项目的标记.

根据我的经验,项目成为"有限资源"项目,因为有人迫切希望向客户销售解决方案.结果是预算紧张,功能被淘汰,SDLC流程被削减到最低限度.采取这些捷径,使公司有机会获利甚至收支平衡.

这是我看到的与资源有限的项目齐头并进的列表:

• 分配给质量保证的最短时间
• 严格的官僚程序,适用于不合规格的工作
• 变更请求预算可能很小或根本不存在
• 正式化流程被淘汰,有利于利用时间进行开发
• 没有时间可用于增值QA,如内容检查(例如文本中的语法或拼写错误).
• 无法为客户端进行任何内容管理或数据输入
• 必须采用'足够好'的编码解决方案
• 没有时间允许走廊可用性测试.
• 没有编写用户文档或手册的预算.
• 编码前一般没有时间进行技术研究
• 没时间制作风险分析文件
• 可以使用生产检查清单代替项目计划.
• 程序员没有时间填写他们的"实际"时间与项目进度表中的估计时间.
• 给予客户的进度更新可能不太频繁或非常基本
• 花在理解客户业务领域上的时间较少
• 程序员可能不得不加班加点工作.
• 没有时间分配给项目验尸

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

===

编辑

我将尝试通过一个例子来澄清一些混乱.这就是我的意思:给客户一个提案/报价说他们的项目将花费$ 20,000.然后客户回来说"对不起,我的预算最多是16,000美元".老板说"让提案价格达到16,000美元 - 我们希望这项工作".

所以,实际上,你必须做一个预算较少的项目.如果客户要说"我的预算是4千美元"那么你就不可能做到这一点.

是的,有时预算紧张会变得如此愚蠢,以至于首先接受项目(即注定失败的项目)是一个糟糕的商业决策.

据我所知,没有预算无限的项目.通常商业人士决定是否应该开展项目(商务人士通常不是项目经理).

它不会更接近:

n * (n - 1) / 2

以上公式是这个中学数学团队问题的答案:

"你在一个房间里有n个人,他们都和其他人握手.发生了多少次握手？"

这也不适用于在软件项目中进行通信的人数吗？

放弃

我还没有读过这本书,但我已经看过n^2其他地方引用的公式.