|
来源：软件需求第4章 需求改进过程在实践应用需求工程中的好方法是改进软件过程的核心。改进过程包括使用更多有效的方法避免使用过去使用过的令人头痛的方法。然而，改进之路是从失败、错误开始，还要历经那些受影响人的抵制及因任务时间紧迫导致搁置改进这样的挫折。 软件开发过程的改进有两个主要目标：解决以前项目中或目前项目中遇到的问题，以及防止和避免将来可能遇到的问题。即使你目前采用的方法很有效，也应该知道其他一些很有价值也颇有效的需求工程方法，并把它们加入到你的软件工程中。 本文介绍了需求与其它主要的项目过程和风险承担者之间的联系，推荐了一种经改进的生存期，并列出了一些重要的需求“过程精华”。此外，本文还介绍了实施改进需求工程实践的一个流程蓝图，供参考使用。 1需求与其它项目过程的联系需求在软件项目中占据核心地位，它是整个项目生命周期中的基石，影响着从项目计划、开发、测试直至交付的各个环节：
2 软件需求对其它项目风险承担者的影响在软件开发团队改变其需求管理过程时，与其他项目利益相关方的沟通接口也随之发生变化。这些接口对于项目内外部协作至关重要，涉及市场部门、管理层、系统工程部以及其他跨职能团队。为了确保接口操作顺畅，开发团队应主动与这些伙伴进行沟通，解释改进思路和计划，并强调新过程的优点，如减少问题、提高效率等。在寻求合作时，要诚恳地表达变更的原因，以及对所有人的潜在益处，以消除因未知引发的担忧和抵触。 在与各个功能领域的人员沟通时，明确指出需要他们提供的信息和支持，这对于产品开发的整体成功至关重要。遵循开发团队与其他团队之间标准化的交流接口规范，例如系统需求规格说明、市场需求文档等，并确保这些文档不仅符合严格的编写标准，还能传达客户真正关心的信息。 同时，也要询问其他团队需要从开发团队获取哪些信息和帮助，以便他们更好地履行职责。例如，了解技术可行性信息如何帮助市场部门制定更精准的产品计划，什么样的需求状态报告能让管理层更准确地掌握项目进度，以及与系统工程部如何协作以确保系统需求在软硬件之间的合理分配等。 在推行需求过程变更时，难免会遇到来自团队内部或外部的抵触和阻力。面对这种情况，首先要理解并尊重反对意见，通过充分沟通和解释来化解。例如：
3软件过程改进的基础本文鼓励你在需求工程中进行持续不断的改进，遵循以下四个基本原则以提升软件开发的质量和效率）：
4过程改进周期在活动前知道自己处于哪个阶段的重要性,为改进活动制定计划的必要性以及从自己经验中所学到的作为持续地过程改进的重要性。 4.1评估当前采用的方法在进行任何过程改进之前，首要任务是对当前组织中所采用的方法进行全面评估，识别其优点与不足。评估本身虽不能直接带来改进，但却为后续决策提供了有价值的信息，为选择适宜的改进措施打下了基础。 评估当前过程的方式可以灵活多样。例如，若已经按照前几章节的指引进行实践，实际上就已经开始了对自身需求方法和成果的非正式评估。此外，设计一套系统化的自我评价问卷也是一个低成本且有效的方法，能够系统性地评估当前的需求工程流程。 另外，还可以聘请外部顾问进行更为严谨和客观的评估。这类正式评估应当基于公认的、如软件工程研究所（CMU/SEI）开发的软件能力成熟度模型（CMM）等过程改进框架。评估者不仅会关注需求活动，还将考察整体的软件开发和管理过程。选择何种评估方法应根据组织希望通过过程改进实现的具体业务目标，而不是单纯追求符合CMM或其他特定模型的要求。 准备一份用于评估当前需求方法的自我评估问卷，可用于组织对自身当前需求工程方法的审视。通过自我评估，可以明确识别出需求过程中最亟待改进的环节。然而，单凭某个问题得分低并不能作为立即进行改进的唯一依据，应当重点关注那些可能对项目成功率产生重大影响的风险和难点。问卷中的每个问题均与本书各章节的核心议题相关。摩托罗拉公司也曾开发过一套名为“软件需求质量模型”的工具，用以评估软件需求过程。 正式评估将提供关于现行方法优缺点的详尽说明，以及针对改进机会的建设性意见。非正式评估手段，如自我评估问卷，则有助于理解并确定改进的方向。在本书的相关章节中，您会找到针对自我评估中所涉及问题的多项改进建议。在考虑每一项改进举措时，务必对其进行分析，确保在可接受的成本范围内实施，并优先选择那些预期能够带来显著投资回报的改进活动。 4.2制定改进活动计划遵循将过程改进活动视为项目管理的原则，在完成评估之后，你需要制定一个详细的活动计划。这个计划可以分为战略计划和战术行动计划两部分，如同你在收集需求时采用的系统化方法，分别描述组织整体软件过程改进的宏观路径和具体行动步骤。每项战术行动计划都应明确指出改进目标、负责人以及必须执行的活动内容，因为缺乏计划往往会遗漏关键任务，而计划的存在则提供了跟踪和监控活动进度的有效手段。 以下是一个过程改进活动计划模板的示例。为了确保计划易于执行并能迅速取得成效，建议每个活动计划中不超过10个条目。例如，在一个针对需求管理改进的活动计划中，可能包括以下活动条目：
确保每项活动都有专人负责，避免让整个团队共同负责一项任务，因为明确的个人责任将更有利于任务的执行和完成。 如果需要的活动条目超过了10个，首先应关注那些至关重要的条目，随后再逐步处理剩余的事项。请注意，过程改进是一个循环往复的过程，不断迭代优化。在后续的内容中，我们将进一步探讨如何将多个改进活动整合成为一个全面的软件开发过程改进计划。 需求过程改进活动计划模板 项目：软件开发过程改进 日期：[具体日期] 目标：通过改进需求管理过程，提高需求的准确性和及时性，减少需求变更的次数。 成功度量标准：通过需求评审会议的满意度、需求变更的频率以及需求实现与预期的一致性来衡量改进效果。 组织受影响范围：整个软件开发团队。 人员和风险承担者：项目经理负责制定和执行计划，开发团队成员参与需求分析和评审。 跟踪和报告过程：每周召开需求评审会议，记录会议内容并向团队成员发送会议纪要。 依赖、风险和限制：可能会受到需求来源方的影响，如需求变更频繁或不清晰。 估计所有活动的完成日期：预计在 6个月内完成。 活动条目：
4.3建立、实验和实施新的过程目前已对需求方法进行评估，并起草了一份活动计划，指出了可能带来收获的过程领域。现在进入较困难的一步：实施计划。许多过程改进在试图由计划付诸实践时，一开始便夭折了。 实施一项活动计划意味着开发新的、更好的方法，并且要相信它能提供一个比目前过程更好的结果。然而，并非第一次就能使新过程完美无缺。许多看起来很不错的方法付诸实施后会变得既不实用而又低效。因此，要为你建立的新过程或文档模板计划一个“实验”。运用在实验中获取的经验来调整新技术，这样当将它运用于整个目标群体时，改进活动会更有效果。请铭记下面这些关于引导实验的建议：
即便是很有激励与善于理解的团队，他们接纳变更的能力也是有限的。所以不要一次给予项目或团队太多的期望。编写出一整套实施计划，明确你将怎样把新方法运用于整个项目团队以及你能提供的训练和支持；同时也要考虑管理者如何阐明他们对新过程的期望。一份正式的关于需求工程和需求管理的文件通常要阐述清楚管理人员的任务和期望。 4.4评估结果过程改进周期的最后一步是评估已实施的活动和取得的成果，这有助于您在未来的改进活动中做得更好。评估实验工作进行得如何，新过程解决问题是否有效，以及是否需要在下次管理过程实验中稍作变更。同时，还要考虑整个新过程在团队中的执行情况，是否能让每个人都明白新过程或模板的好处，参与者是否理解并成功地应用了新过程，以及是否需要在下次工作中进行调整。 关键的一步是评估新实施的过程是否带来了期望的结果。虽然有些新技术和管理方法可以带来明显的改进，但更多的需要时间来证明其全部的价值。例如，如果您实施一种新过程来处理需求变更，您会很快看到项目变更以更规范的方式进行。然而，一个新的软件需求规格说明模板需要一段时间来证明其价值，因为分析人员和客户已经习惯了一种需求文档的格式。给予新方法足够的运行时间，并选择能说明每项过程变更成功的衡量标准。 要接受学习曲线的事实。当从业者花费时间去吸收新方法时，生产率会降低，这是组织进行过程改进的一部分投入。如果您不理解这一点，您可能在得到回报之前就放弃，白白损失了投入而没有回报。对您的管理人员和同事进行有关学习曲线的教育，并让他们明白：采用高级的需求过程将获得更广泛的项目和业务回报。 5需求过程的积累材料为了确保项目不断取得满意的结果，需要有效地执行需求工程的各个过程。这些过程包括信息获取、分析、编写规格说明、验证以及管理。为了促进执行这些步骤，应该收集过程中积累的材料，这些材料包括已完成的活动和可交付的产品。 在需求工程中，可以收集以下几种类型的文档来帮助团队成员有效地执行过程：
对于需求开发过程，可以收集以下积累材料：
对于需求管理过程，可以收集以下积累材料：
5.1需求开发过程的材料
5.2需求管理过程的积累材料您好！需求变更控制过程是指在项目开发过程中，对需求进行管理的过程。它包括以下几个步骤：明确问题、书面申请、影响分析、决策和通知。变更控制委员会(CCB)是由风险承担者的主要成员组成的，对提出的需求变更决定执行哪一项，拒绝哪一项，以及在各产品发行版本中包括哪些变更。CCB的主要活动是对提出的变更进行影响分析，为每项变更作出决定，并且告知那些将受到影响的人。 需求变更影响分析清单和模板可以帮助您估计提出的需求变更的成本费用和影响是决定是否执行变更的重要步骤。影响分析能帮助CCB作出正确的决定。一张参与人员工作表可以作为估计任务工作量的简单方法，从这里就能明白确认变更的复杂性。 需求状态跟踪过程是指监控和报告每项功能需求的状态和状态改变的条件。您需要一个数据库或一种商业需求管理工具来跟踪一个复杂系统中大量的需求状态。此过程还描述了当您随时查看收集到的需求状态时输出的报告格式。 最后，需求跟踪能力矩阵模板列出了 SRS中的所有功能需求及相应的设计模块、源文件和实施需求的过程，还有验证需求实施正确性的测试用例。跟踪能力矩阵应该也可以指出对应的上一层用户需求或系统需求。 6需求过程改进路线图改进组织的需求工程过程需要制定一个路线图，以确保改进活动的成功实施。这个路线图应该包括软件开发过程改进战略计划的一部分，并描述了改进活动的前后次序和期望的业务结果。主要的改进活动应该从左到右依次实施，每组改进活动都有一些中间的里程碑来指明取得的期望业务目标。一旦建立类似的路线图，可以指定一个人负责一个里程碑活动，并制定相应的活动计划和行动方案。在需求工程中，软件评审、简化的系统测量、采用标准和使用实例等都是重要的改进活动。同时，建立CCB并跟踪需求变更也是必要的步骤。改进后的项目应该进行状态管理和影响分析。 首先，需要更好地管理项目时间表，以确保所有需求都按时交付。其次，需要更好地与客户沟通，以确保他们的需求得到充分理解和满足。最后，需要更好地管理需求变更，以避免延误项目进度。 |
|
|
