Questions tagged «sdlc»

我希望这不是一个普遍的问题。我真的可以使用一些经验丰富的建议。 我刚刚在一家规模很小的科学家商店中担任唯一的“软件工程师”，他们在过去的10到20年中花了很多时间编写了庞大的代码库。（它是用一种几乎过时的语言编写的：G2-用图形来思考Pascal）。该程序本身是复杂的化学加工厂的物理模型。编写该程序的团队具有难以置信的深厚知识，但是很少或没有正式的编程基础培训。他们最近学到了一些关于不存在的配置管理的后果的艰难教训。代码本身中大量未记录的“污泥”的积累也极大地阻碍了他们的维护工作。我会避免给您这种情况的“政治”（总是 政治！），但足以说，就未来的道路需要什么没有达成共识。 他们要求我开始向团队介绍现代软件开发的一些原理。他们希望我介绍一些有关编码约定，生命周期管理，高级设计模式和源代码控制的行业标准实践和策略。坦白地说，这是一项艰巨的任务，我不确定从哪里开始。 最初，我倾向于在The Pragmatic Programmer或Fowler's Refactoring（“代码气味”等）的一些中心概念中对它们进行辅导。我也希望介绍一些敏捷方法。但最终，要想发挥作用，我认为我需要磨练5-7个核心基础知识。换句话说，他们可以实际开始实施的最重要的原则或实践是什么，这将使他们获得最大的“收益”。 因此，这就是我的问题：您将在最有效的策略列表中包括哪些内容，以帮助理顺意大利面（并在以后防止出现这种情况）？

470 project-management  agile  development-process  maintenance  sdlc 

有一些很好的示例，这些示例都记录了很好的代码，例如java api。但是，公共项目（例如git和公司的内部项目）中的许多代码都没有很好的文档记录，并且不是很新手。 在我所有的软件开发工作中，我不得不处理文档记录不佳的代码。我注意到以下情况- 代码中很少或没有注释。 方法和变量名不是自描述的。 很少或没有文档说明代码如何适合系统或业务流程。 雇用不良的开发者或不指导好的开发商。他们不能编写简单干净的代码。因此，包括开发人员在内的任何人都很难或不可能编写代码。 结果，我不得不阅读大量代码并与许多人交谈以学习事物。我觉得这浪费了大家的时间。它还为项目的新手带来了KT /知识转移会话的需求。 我了解到，由于以下原因，文档没有得到应有的重视： 懒惰。 开发人员只喜欢编写代码就什么都不喜欢。 就业保障。（如果没有人能轻易理解您的代码，那么您可能就很难被替换。） 艰难的截止日期几乎没有时间记录在案。 因此，我想知道是否有一种方法可以鼓励和执行公司或项目中的良好文档规范。无论项目的复杂性如何，用于为任何项目的系统和代码创建体面文档的策略是什么？有什么很好的例子，说明什么时候需要最少的文档或根本不需要文档？ 恕我直言，我认为我们应该在项目交付后对文档进行审查。如果它不简单，简洁，说明性和用户友好性，则开发人员或技术文档工程师将对此负责，并负责对其进行修复。我既不希望人们编写大量文档，也不希望它像第一本书一样对用户友好，但是我希望它消除了数小时的分析和浪费的KT会话。 有没有办法结束或减轻这种疯狂？也许是“文档驱动的开发”？

26 programming-practices  development-process  documentation  source-code  sdlc 

假设您估计一个案件的时间为3天。在第二天中，您会注意到情况不断增长，并且弹出了新的方案，这些新方案在进行时间估算时并未计算在内。新的发现导致额外的2天（总共5天）。这是一个典型的问题，您作为开发人员迟早会遇到。 当您要通知项目负责人新的交货时间时，可以使用哪种策略？ 通常您会得到一个问题，为什么？您如何激发新的交货时间？ 事实是，在SDLC期间，许多项目没有花太多时间进行分析和设计。 编辑： 在非常复杂的项目中，无论您花费多少合理的时间进行分析与设计，由于业务规则过于复杂，总是会感到意外。但是，在这种情况下，我认为项目负责人必须意识到复杂性，并在出现意外情况时保持正确的态度。问题是如何应对那些不了解复杂性的项目负责人。

26 project-management  development-process  time  estimation  sdlc 

在我的公司中，我们成功地采用了敏捷实践，但没有使用迭代。主要原因是我们找不到在迭代周期中适合QA的干净方法。 我们认为质量检查是对特定版本（候选版本）进行额外验证的一部分，然后再将其部署到客户。关键是要避免单个恶意提交会损坏整个发行版。由于您永远都不知道它是哪一个，因此质量检查人员必须等到该版本的所有功能/提交都在构建中。（不允许使用著名的最后一句话“这只是微小的变化”。） 如果质量检查人员在候选发行版中发现错误，则开发人员会在相应的发行分支中修复这些错误（并将其合并到主干中）。修复所有错误后，将部署新版本以进行质量检查以进行重新测试。仅当在某个发行候选版本中未发现错误时，才将其提供给客户进行验证。 每次发布通常需要大约2-3个候选人，大约一周。编写修补程序的时间通常比测试工作要少得多。因此，为了让开发人员忙，他们在版本N + 1上工作，而质量检查则在N上工作。 不使用迭代，这没问题，因为我们可以将版本N和N + 1的工作重叠。但是，据我了解，这与Scrum或XP等基于迭代的方法不兼容。他们要求在迭代结束时发布一个迭代，并将所有测试工作都包含在迭代中。 我发现这必然导致以下不良结果之一： （A）开发人员在迭代结束时处于闲置状态，因为质量检查需要时间来验证发布候选版本，并且错误修复工作并未完全使开发人员处于忙碌状态。 （B）质量保证在准备好第一个候选版本之前就已经开始工作。这是Stack Exchange上最推荐的方法。但这不是我公司所理解的质量检查，因为没有经过测试的特定候选发布版本。破坏一切的“微小变化”仍然可以被忽略。 （C）错误将继续进行下一次迭代。在Stack Exchange上也建议这样做。我认为这根本不是解决方案。从根本上讲，这意味着我们永远不会获得经过验证的内部版本，因​​为只要进行了错误修复，就会将未经验证的新提交也添加到同一分支中。 有没有办法摆脱这种困境？

17 agile  teamwork  qa  sdlc 

我想把这个问题扔出去，有趣地看看介质在哪里。 我要承认，在过去的12个月中，我获得了TDD和软件开发中的许多敏捷价值。我对软件开发的进步感到不知所措，以至于我永远都不会放弃它们。直到...我被任命为承包人，这使我当年的实得工资翻了一番。 我加入的公司没有遵循任何特定的方法，团队还没有听说过代码气味，SOLID等问题，而且如果团队从未做到过，我当然也不会浪费时间进行TDD在实践中看到了单元测试。我卖完了吗？不，不是完全...代码将始终被“干净地”编写（按照Bob叔叔的教）），并且SOLID的原理将始终应用于需要的我编写的代码。尽管对我来说测试已经放弃了，但坦率地说，公司无法承担如此未知的任务，即使我确实创建了测试框架，他们也永远不会正确使用/维护测试框架。 以此为例，您会说开发人员出于金钱/个人其他利益而绝不放弃其工艺原则的观点？我了解这可能是一种非常个人的看法，即人们对自己的需求，业务需求以及工艺等方面的关注程度。但是，可以考虑，例如，如果公司决定宁愿进行测试，则可以放弃测试。测试团队，而不是理解编程中的单元测试，那会不会像我那样原谅自己？因此，考虑到您会丢掉一些东西，通常业务中应该有相等的成本来弥补您丢掉的东西-希望如此，除非您当然愿意掏腰包而不是依靠社区/社会合作； ）。 加倍您的钱，回到RAD？或继续前进，寻找正在做敏捷的人，再也不回头...

16 agile  testing  unit-testing  tdd  sdlc 

考虑一家通过非敏捷方法认证的公司，并以此为卖点向客户证明自己的责任。 您如何在不破坏整个系统的情况下逐步引入看板或Scrum并仍然使他们确信它仍然可以同样负责/可审计？ 我知道这可能与“ 您将如何引入像Scrum这样的敏捷方法论 ”有关，但是在这里，我想知道如何规避/解决该公司以某种虚假借口强加某种方式管理SDLC的事实。进行审核的唯一途径。

16 project-management  agile  development-process  sdlc 

在我们的敏捷过程中，我们有2周的冲刺。每天（每天一次）交付任务，测试团队会在第二天甚至同一天立即完成测试。 我们也有开发人员代码审查，需要一些时间（1-2小时），因此每周安排3次：星期一至星期三至星期五。开发人员聚在一起，建议如何改进/重构代码。 我们的问题是，在代码审查后提出“行动项目”时，大多数任务已经过测试。测试人员不想重新测试已经通过测试的内容。他们不在乎内部开发人员的变更。 我们误解了敏捷过程吗？代码审查是否与每日发布/测试周期不兼容？我们无法每天进行代码审查，因为它们占用了每个人的时间。

14 project-management  agile  teamwork  code-reviews  sdlc 

当供应商宣布不再打算为某个软件提供任何支持或服务时（并表示打算退出该业务-不提供升级途径），客户可以使用哪种资源？ 请考虑从 客户的角度。客户的IT员工可能只会考虑技术选择，但是客户也可能会追求非技术选择。另外，客户可以提前采取什么样的合理步骤来最大程度地减少中断，例如合同条款？ 我能想到的事情： 需要购买备用硬件并设置备用环境，软件可以在该环境下继续运行。 不需要卖方参与的各种数据导出方法。（这可能包括诸如检查商品数据库后端中存储的数据之类的琐碎技术，以及诸如屏幕抓取，打印到图像然后重新扫描等更复杂的技术） 工作人员将手动或半自动将旧数据复制到新系统的并行系统 以法律手段，以防卖方出现财务问题（例如，源代码托管） 还有其他想法吗？ 假设不涉及“规避”（没有DRM，没有DMCA），数据恢复或逆向工程是否合法/可以接受？ 编辑说明： 它是几个轶事，但真实的故事的结合。我没有直接参与其中的任何一个。我只是想了解一般如何处理“软件报废”情况。我不想使原始故事听起来太“难”而无法解决。

14 contract  legacy  sdlc  software-obsolescence 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，使它成为软件工程堆栈交换的主题。 5年前关闭。 在行业中，在软件开发人员编写将由公司自己使用的代码的“内部开发”环境与构建要出售/分发的软件的适当“软件开发”环境之间存在区别。对公众。 其中，两者之间的一个明显区别是，面向软件开发的公司通常会遵循某种软件开发生命周期，例如规范编写，测试，构建等，而面向内部的商店通常会坚持因为他们自己是最终用户，并且总是可以修复未正确完成的操作，所以可以更轻松地完成操作。 作为一名学生（像其他大多数学生一样），我有点希望自己能在软件开发环境中工作，但最终我在一家以内部运作方式运作的公司中获得了第一份职位。 有时，我想知道我是否错过了成熟的软件开发经验。有这种感觉的依据吗？我是否应该寻求加入适当的软件开发环境？

13 programming-practices  skills  sdlc 

在我当地的大学中，有一个约20名学生的小型学生计算俱乐部。该俱乐部有几个小组，专门负责特定领域，例如移动开发，机器人技术，游戏开发以及黑客/安全性。 我正在向几个团队介绍一些基本的敏捷开发概念，例如用户故事，估计任务的复杂性以及持续集成以进行版本控制和自动构建/测试。 我熟悉一些基本的开发生命周期，例如瀑布，螺旋，RUP，敏捷等，但是我想知道是否存在诸如用于黑客入侵/破坏安全性的软件开发生命周期之类的东西。当然，黑客正在编写计算机代码，但是该代码的生命周期是什么？我认为他们不会太在意维护，因为一旦发现并修补了漏洞，利用该漏洞的代码就没有用了。 我认为生命周期将是这样的： 找出安全漏洞 利用安全漏洞 采购有效载荷 利用有效载荷 当产品的目的是破坏安全性时，软件的开发生命周期会有什么样的差异（如果有）？

10 development-process  security  hacking  sdlc 

一个先前的问题，为什么人们恨微软被关闭。这是对同一条基本思路提出的更具建设性的问题的尝试。但是，这一范围既宽又窄。它涉及一般的软件供应商，而不仅仅是Microsoft。通过只处理软件产品的管理来缩小范围。 因此，在管理单个软件产品时应采取（和/或避免）什么步骤，以确保不仅对单个产品，而且对整个公司都给予积极的尊重/喜欢/看好？

10 code-quality  sdlc  product-management 

我在办公室里听到这个词，并且知道它与软件开发生命周期有关。“促进”是什么意思？上下文：例如升级文件。

9 terminology  sdlc