问题标签 [sdlc]

作为开发团队的高级成员，我被要求帮助为我们的团队生成一个更精细的流程，该流程现在模糊地遵循 SDLC/瀑布方法，没有标准化每个阶段的边界和输出是什么（“这里有一些要求，去编码吧！”）。

如果不讨论不同的方法论，比如敏捷（我喜欢这种方法，但可能会开始另一个关于如何提出它的话题），是否有很好的资源来规范涉及开发人员的 SDLC 阶段？由于这个想法是标准化过程，因此通常需要的特定步骤或文档想法将是很好的讨论。

我已经阅读了标准的 Wikipedia 文章及其关于该主题的分支，虽然它们给出了一个很好的总体概述，但我想开始为我们提供一个通用的过程来遵循。避免大爆炸方法的增量步骤也会有所帮助。

如果有帮助，该团队主要是牛仔编码员，唯一的官方可交付成果是代码本身的最终结果。在设计、文档等方面还有许多其他的步骤和交付物，行业已经接受了，所以这就是我所追求的：当涉及到流程中的额外交付物时，哪些是有效的，哪些是无用的。

产品正在作为功能而不是发布来开发和交付，这意味着在完成功能后，它会被推送到登台，然后再投入生产。开发中可能有多个功能，并且交付时间线重叠。因此，在任何时候，开发数据库和源代码控制都具有多个开发功能。功能完成后，我只想将功能特定的代码和数据库更改推送到登台。事实证明，此过程容易出错且耗时，原因如下：

• 特定功能的数据库实体不是独立的，而是与其他功能相关且相互交织的。因此，分离出特定于功能的实体非常耗时，有时难以实现。有没有更好的方法呢？
• 在服务器端代码上，类似地分离出特定于功能的代码与 db.xml 一样繁琐。将 .NET Entity Framework 置于 DB 之上并进行其他性能优化（例如预生成视图），是否有更好的方法来部署基于功能的开发？

开发环境包括 SQL Server 2008、.NET、带有用于源代码控制的 SVN 的实体框架。

这里的术语特性与 FDD 敏捷模型无关。

有没有人有过类似的经历？

非常感谢！

嗨，我正在制作 asp.net 网站，并且我正在关注 SDLC Straitegy，因此需要绘制哪些图表。

我们正在开发一个新的 ASP.Net 站点。我们做的最后一个主要站点是在经典 ASP 中使用的——我们在那里使用的过程是首先完成 HTML，然后使用 ASP 代码“使其栩栩如生”。

在 ASP.Net 世界中，这是如何工作的？即，如果大部分标记实际上是由服务器控件生成的，那么设计人员如何进行工作？

我们还将 ASP.Net MVC 视为一种潜在的轻量级替代方案。

很想知道在与设计师合作以及将他们的工作与代码集成方面，在这两种情况下什么对人们最有效。

更新：我改进了我在这里问的问题，不是完全相同的问题，但足够相似，所以这个问题可能会与它合并。任何有关如何合并它们的建议将不胜感激。

我可以在 SDLC 的不同阶段使用哪些不同的 UML 图？我正在寻找可能的 UML 图到 SDLC 中每个不同阶段的映射。

如果这是重复的，我很抱歉，但问题搜索词非常通用。

我在一家小型（ish）开发公司工作。我说小，但公司实际上是一个公平的规模；但是，我只是第二个全职开发人员，因为过去的大部分工作都是围绕承包商组织的。

我能够定义内部项目流程和政策显而易见的东西，例如 SCM 和单元测试。方法论超出了我正在整理的文档的范围，但我真的很想将我们推向更精简（甚至可能是敏捷？）的方向。

我觉得我有很多好的实践建议，但没有足够的动力让我的文档成为我想要的精神指南。我将文件分为“原则”和“建议”。很容易提出建议。使用 SCM，争取 1 步，定期安排构建，首先进行单元测试，边做边记录...... 但是，列出应该为这些建议提供信息的原则是粗略的。

我想出了“工具为我们工作；我们永远不应该为工具工作”和一个针对我们的 QA（过于手动）的模糊条款，我想阅读“乏味是万恶之源” .

我不想错过这个文档给我们一个良好的内部开始甚至推动我们走向敏捷的机会。我缺少什么原则？

编辑 4/15 -

我可能对本文档的范围模棱两可。目前，这是我和我的共同开发人员计划遵循的政策。到目前为止，我们可以自由选择本地工具、源代码控制等，以及我们在开发中遵循的一般流程（例如构建、部署、是否使用持续集成……）。

理想情况下，我还希望本文档成为进一步改进流程的模型。我主要考虑 QA，也许会推动我们的项目管理朝着更轻松和迭代的方向发展。

我有现有的 java 代码，需要基于它创建设计文档。

对于初学者，即使我可以使用有助于整体过程的输入/输出参数获得所有功能。

注意：没有关于任何过程、函数或类的文档。

最后但并非最不重要的。让我知道任何可以减少此阶段所需时间的好工具。目前我们编写每个流程和相关的东西。

创建新版本并将其发布到生产环境的过程是 SDLC 中的关键步骤，但它通常是事后才想到的，并且从一家公司到另一家公司差异很大。

我希望人们能在他们的组织中分享他们对这个过程所做的改进，以便我们都可以采取措施来“减轻痛苦”。

所以问题是，在你的发布过程中指定一个痛苦/耗时的部分，你做了什么来改进它？

我的例子：在以前的雇主那里，所有开发人员都在一个通用开发数据库上进行了数据库更改。然后到了发布时间，我们使用 Redgate 的 SQL Compare 从 Dev 和 QA 数据库之间的差异中生成了一个巨大的脚本。

这工作得相当好，但这种方法的问题是： -

1. 开发数据库中的所有更改都包括在内，其中一些可能仍在“进行中”。
2. 有时开发人员会做出相互冲突的更改（直到发布投入生产时才注意到）
3. 创建和验证脚本是一个耗时且手动的过程（通过验证我的意思是，尝试清除问题 1 和 2 之类的问题）。
4. 当脚本出现问题时（例如，运行的顺序，例如创建依赖于脚本中但尚未运行的外键记录的记录）需要时间来“调整”它以便顺利运行.
5. 这不是持续集成的理想场景。

所以解决方案是： -

1. 强制执行对数据库的所有更改的策略必须编写脚本。
2. 命名约定对于确保脚本的正确运行顺序很重要。
3. 创建/使用工具在发布时运行脚本。
4. 开发人员拥有自己的数据库副本进行开发（因此不再有“互相踩脚”）

我们开始这个过程后的下一个版本更快，问题更少，确实发现的唯一问题是由于人们“违反规则”，例如没有创建脚本。

一旦发布到 QA 的问题得到解决，当发布到生产时，它就非常顺利了。

我们应用了一些其他更改（例如引入 CI），但这是最重要的，总体而言，我们将发布时间从大约 3 小时减少到最多 10-15 分钟。

我们的投资者想要一个 SDLC。我以前从未写过一本，也没有足够的时间去买一本书，或者花太多时间了解它们。从我被告知的情况来看，它们包括需求（需要做什么），并完成了一个清单。它是否正确？

更新：

我发现这篇文章确实有助于用简单的术语快速地解释事物。并不是说我认为 SDLC 应该很快完成。就我而言，我别无选择。

所有定制的遗留软件都需要改变，或者说我们的用户。有时他们想要添加一两个功能，以及更改一些代码、添加控件或其他一些小的升级任务所必需的所有功能。有时他们想放弃他们容易出错的 VB5 桌面解决方案，并将整个事情重写为一个丰富的 Web 2.0 ASP.NET MVC 应用程序。然而，更常见的情况是，对遗留功能的更改范围介于这两个极端之间。

您使用什么经验法则来决定是升级现有应用程序还是从头开始？