1.7 开发团队的成员
软件工程（第4版•修订版）
在本章的前面，我们看到客户、用户和开发人员在新产品的定义和创建中发挥着重要的作用。开发人员是软件工程师，但是，每一位工程师可能都只擅长于软件开发的某一特定方面。因此，我们在此更深入、详细地讨论开发团队成员的角色。
任何开发过程的第一步都是找出客户想要什么，并且将需求文档化。正如我们已经看到的，分析就是把事物分解成其组成部分的过程，以便我们能够更好地理解它们。因此，开发团队包含一个或多个需求分析员跟客户一起工作，并且把客户想要的分解为离散的需求。
一旦了解了需求并且把需求文档化，分析员就与设计人员一起工作，生成系统层描述（系统要做什么）；然后，设计人员与程序员一起工作，以程序员能够编写实现指定需求的代码行的方式来描述系统。
生成代码之后，必须对它进行测试。通常，第一次测试由程序员自己完成；有时，也使用另外的测试人员帮助程序员发现他们忽略的错误。当代码单元被集成为一个个运行的功能组时，测试人员小组与实现小组会在各部分组合构建系统的过程中，验证系统是否能够正确运行，是否符合规格说明。
当开发团队对系统的功能和质量感到满意时，注意力就转向了客户。测试小组和客户一起验证整个系统是否是客户想要的系统。他们通过把系统如何工作与最初需求规格说明进行比较，来完成这项工作；然后，培训人员向用户说明如何使用这个系统。
就很多软件系统而言，客户的验收并不意味着开发工作的结束。如果在系统验收之后发现了故障，维护小组就要修复它们。另外，随着时间的推移，客户的需求可能会发生变化，系统也必须进行相应的改变。因此，维护可能涉及分析人员，由分析人员决定增加或变更哪些需求；还可能涉及设计人员，由设计人员确定改变系统哪个部分的设计；还可能涉及实现这些变化的程序员，确保改动后的系统仍然正确运行的测试人员，以及向用户解释这些变化如何影响系统使用的培训人员。图1-11说明了开发团队的角色与开发步骤的对应关系。
就课程项目而言，学生通常会自己工作或者在一个开发团队的小组中工作。教师所要求的文档是最少的，学生常常不需要编写用户手册或培训文档。再者，布置的作业是相对稳定的，需求在项目的生命周期中不会发生变化。最后，学生构建的系统很可能在课程结束后就丢弃掉，他们的目的是证明他们的能力，而不必为实际的客户解决问题。因此，对于课程项目而言，程序规模、系统复杂性、文档化的需要以及可维护性的需要都是相对很少的。
但是，对一个实际的客户而言，系统的规模可能会很庞大，复杂性可能会很高，可能需要大量的文档，可维护性的要求也可能会很高。对于一个涉及成千上万行代码并涉及开发团队成员间很多交互的项目来说，项目各方面的控制可能是很困难的。为了支持开发团队中的每一个成员，一些人员可能在开发的最开始就要介入系统，并且自始至终都是如此。
资料管理员负责准备和存储在系统生命周期中用到的文档，包括需求规格说明、设计描述、程序文档、培训手册、测试数据、进度等。与资料管理员一起工作的是配置管理小组的成员。配置管理涉及维护需求、设计、实现和测试之间的对应关系。根据这种交叉引用，开发人员可以得知，如果需要改变需求，相应地要改变什么程序；或者如果提议进行某种改变，会影响到程序的哪一部分。配置管理成员还要协调可能建立或支持的系统的不同版本。例如，一个软件系统可能要运行在不同的平台上，或者按一系列不同的发布进行交付。配置管理要确保各个平台上系统的功能都是一致的，而且新发布的功能不会降级。
开发角色可由一个人或几个人承担。就小型项目而言，两三个人就可以承担所有角色。然而，对大型项目，通常要根据开发中的职责，把开发团队分成不同的小组。有时，维护系统的人员与最初设计和编写系统的人员是不同的。对某些规模巨大的开发项目来讲，客户甚至会雇佣一家公司做最初的开发，而用另外一家公司进行维护工作。我们在后面的章节中讨论开发和维护活动时，会讨论每种类型的开发角色需要哪些技能。
本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。