基于敏捷开发框架的软件工程/前言/开发历史
构建用于软件工程教学的敏捷框架
摘要 本文描述了我们在职业计算学位课程的软件工程课程中,如何最终选择并教授敏捷和结构化方法的特定组合。文章首先介绍了纯结构化方法的教学背景,然后描述了八个迭代中敏捷性逐渐增强的过程。最后引入了并描述了当前采用的方法:“敏捷框架”。
关键词:顶石项目,计算机教育,价值主张
1 引言 在本科阶段教授软件工程面临着向学生呈现一个稳健的学科的同时,又要反映行业现状的挑战,因为软件工程方法自诞生以来一直在不断发展。敏捷方法的出现标志着与既定软件工程实践的显著转变。这造成了Booch (2004) 所谓的“方法论战争”。机构在这一“战场”中摸索前进的路径非常值得关注,因为它提供了一个模型,可以借鉴如何将未来尚未预见的变革纳入其中。本文描述了一个案例研究,即作者在构建“敏捷框架”过程中所走过的路径。作者面临的难题是在课程中引入敏捷开发的框架,同时又不失去过去六年成功教授的结构化方法的优势。尽管Booch (2004) 使用了军事类比,但我们认为这条路径更像是一种演变,而不是革命。在接下来的章节中,我们将首先考察教学方法的要求。然后描述所采用的教学方法的演变。
2 软件工程教学方法的要求 Boehm (2004) 描述了计划驱动或预测性方法与敏捷方法之间的冲突,并指出“成功的、可持续的软件开发需要纪律性和敏捷性”。在行业中,能够快速适应变化可以使组织在竞争中占据优势,缩短产品上市时间并更好地满足客户需求。但是,为了确保软件系统的健壮性,必须以健全、有纪律的实践为基础进行开发。在采用敏捷方法时,开发人员需要注意不要“把孩子和洗澡水一起倒掉”。传统方法虽然经常被认为是灾难性软件工程项目失败的关键因素(Standish 1994),但已成功应用于项目超过 40 年。敏捷方法也随着越来越多的开发人员在新的环境中应用其原则而不断发展。事实上,Conboy (2004) 断言,“在信息系统开发领域,没有普遍接受的敏捷方法定义”。Noble, Marshall, Marshall, & Biddle (2004) 指出,行业转向敏捷方法“需要软件工程教育做出类似的转变”,并解释说“以文档为中心的项目方法与学生对更敏捷工作方法的合理期望并不一致”。因此,问题不在于如何教授敏捷,甚至不在于如何在课程中引入敏捷元素(Keefe & Dick, 2004),而是要提出一个连贯的模型来教授“中间地带”,作为软件工程教育的可持续方法,并为顶石项目做好准备。通过为学生提供一套连贯的软件开发技术,他们就可以很好地准备在他们的顶石项目和工作中应用适当的策略。Boehm (2004) 引用Rational Unified Process的架构师Phillippe Kruchten的话,将CMM for Software比作字典——为了说明他想要表达的观点,“不需要使用所有可用的词汇”(第23页)。类似地,一个稳健的框架可以呈现软件工程的中间地带,包含来自敏捷和计划驱动方法的方法论,以及选择适合手头工作的工具的策略。软件工程教学的稳健方法需要哪些要求?它应该包含一个真实的客户,以反映行业经验。它应该具有灵活性(以展示对变化的适应能力,包括项目和教学的变化)。它应该以用户为中心——而不是以计划为中心的方法,并且它应该适用于各种项目,包括基于硬件和网络的项目。2.1 敏捷模型 2001年,一群开发人员在犹他州的斯诺伯德聚会,讨论软件开发的现状。他们通过不同的途径得出了相同的结论——通过使用“轻量级”方法,重点关注沟通、简洁和拥抱变化,可以提高软件质量。在这次会议上,创造了“敏捷方法”一词,并推出了一种全新的软件开发方法。(Smits,2005)。这些开发人员,包括肯特·贝克(极限编程)和肯·施瓦伯(Scrum 方法论),组成了敏捷联盟,致力于推广敏捷方法。他们制定了敏捷运动的共享价值观。敏捷意味着• 个人和迭代优于流程和任务• 可工作的软件优于全面的文档• 客户协作优于合同谈判• 响应变化优于遵循计划。3 案例研究:我们的演变 在回顾 1999 年的顶石项目并在评估 1998 年的项目时,我们感到学生没有获得足够的结构,并且这个过程被当作游戏来对待(这本身是前任讲师决定遵循基于模拟的体验式模型)。IT205课程为期一个学期,在第二学年开设,是顶石项目的必修先修课程。我们决定采取一种使其变得真实的策略:“为真实客户提供真实项目”,并遵循“赋权”方法(Robinson 1994)。这些决定受到当时描述新经济需求以及描述学生体验重要性的论文的影响。我们的目标是创造一个教育环境或文化,使学生能够融入新经济。这需要改变方法,将重点放在学生赋权上。这种赋权是多方面的——课程讲义以草稿形式呈现;课程内容根据项目和学生的需要进行调整;学生管理与客户的关系,项目进行自我评估等等。另一个变化是采用一个真实客户的真实项目,当年为海上主管设计了一个船舶安全系统(Mann & Buissink-Smith,2000)。课程的结构严格遵循霍弗、瓦拉奇奇和乔治(2004)所描述的七阶段以文档为中心的软件开发生命周期(SDLC)。课程不包括实施,因为我们认为,如果学生没有被他们必须构建他们所设计的东西的知识(担心)所困扰,他们将能够更好地专注于最佳开发。在这一年及随后的几年中,我们采取的方法是尝试让学生接触到“现实世界”的情况,同时保持积极和建设性的学习环境。在学术环境的范围内,并忠于SDLC,我们努力复制“现实世界的经验”。2001年,我们对项目组实施了项目交换(Smith, Mann & Buissink-Smith, 2001)。在课堂上反复使用“被公共汽车撞倒”(ROBAB)场景,以强调项目文档的重要性。在分析阶段结束时,一些小组被要求交换他们的项目文档并继续进行新的项目和文档。对一些学生来说,这种影响是灾难性的。一名学生做出戏剧性的反应,一边怒吼一边摔门而出:“我来这里是为了学习和精进,而不是处理别人的垃圾”,但大多数学生都默默地接受了修改,并开始计划他们的下一步行动。在这种情况下,学生受益于重量级结构。Smith 等人(2001)中的一条学生评论在事后看来尤其有趣
“It was important to keep in mind that the process seemed more important than the final product.” (SF)
当时我们将其理解为“我们专注于学习流程”,但事后我们不禁怀疑,流程是否过于主导,即他们是在学习SDLC而不是软件工程,或者可能是在专注于客户的产品开发?乍一看,交换流程似乎与赋权的概念相冲突。大多数赋权的概念至少受到了公交车事故的影响——特别是流程的所有权、选择权以及可能出现的“纪律的实施者和受害者”等问题。然而,赋权模型并没有说老师不能挑战学生,事实上,该模型描述了学生“积极参与教师引导的有意义的体验”。有一段时间,我们的软件工程学生认为自己毫无控制权,但很快意识到他们可以做到,这在很大程度上归功于SDLC提供的稳定性和框架。交换的学生认为我们应该重复这个练习。因此,虽然控制中心会暂时发生转移,但它很快就会恢复,并且学生对课程的总体感觉是积极的。在随后的几年中,软件工程中继续使用真实的客户和项目(Mann & Smith,2004,2005)。学生为这些客户进行开发,遵循规定的SDLC开发流程(并逐渐增加敏捷性),同时伴随着理论教学。目的是让学生体验软件工程的全部范围及其隐含的困难:客户问题;业务系统的复杂性和团队合作。敏捷性的提升是三方面的。首先,我们看到原型设计和以用户为中心的设计越来越重要。第二个因素是主要教材Hoffer等(2005)中SDLC的演变。第一版给出了一个七阶段的SDLC,到第三版变成了五阶段模型,在第四版中实际上被绘制成一个循环。敏捷性提升的第三个因素来自于越来越多样化的客户选择。我们的方法是教授整个SDLC,但重点关注特定客户项目所需的方面。例如,学习和动机软件的开发源于一种愿望,即引入一个定义不明确的项目,并且比以前的数据驱动系统具有更大的创造性工作潜力。这是教授开发早期阶段重要性的完美练习,客户对他想要什么几乎没有概念,他只认识到通过探索此类开发来“成为全球参与者并拥有更多空闲时间”将使他受益。它也很好地向学生强调了SDLC阶段在推进项目中的价值。这个项目让学生兴奋,但随着项目的进行,他们发现它令人沮丧,因为它定义不明确。动物伦理管理系统是针对开放式动机项目的回应——我们想要一个定义明确的项目。学生小组与一家皇冠研究机构的客户合作,开发了一个动物追踪和伦理审批系统。这将与现有系统集成。这种开发适合SDLC的范围,并且非常适合数据分析阶段,因为有很多现有的流程和信息:在某些情况下,SDLC强加的结构给学生传递了错误的信息,即确定性开发的信息。一个针对三个客户(小型工程企业的作业管理系统)的范围明确的通用软件开发,根据客户的不同产生了多种结果,这并没有得到学生的认可。
“why are there so many different outcomes to the same problem…I felt the lecturers let down the process by not doing enough homework on what was going to result…shouldn’t the lecturers have get a tighter reign” (SF)
我们当时的评论:“看到各小组利用SDLC从混乱中建立秩序很有趣……我们需要明确的是,学生的分数是根据他们展示流程的能力而不是实际结果来评定的。”(LecNotes)其他软件工程项目包括一个学生管理系统项目,这个项目很有趣,因为学生最初认为它太小了,但实际上,当然,这是一个巨大的任务。开发过程揭示了这一点。它成为一个具有挑战性的项目。来自海事博物馆的一位客户找到我们,说他想要一个网页。我们立即意识到,他的需求远不止于此。这项任务很有吸引力,因为它最终比学生最初的理解要大得多。博物馆数据的复杂性、许多现有系统的集成以及多个方向的潜力意味着,学生很快意识到,如果没有一个稳固的开发方法,他们将无所适从。2003年,我们能够为软件工程项目的选取制定指导方针。除了真实、令人兴奋和有趣之外,我们还指出,项目应该“促进对所选方法(SDLC,特别是每个阶段、里程碑)结构的教学。对于早期阶段的开发,客户应该有一个业务问题的概念,但没有解决方案……促进对每种方法(SDLC)的各种工具和技术的教学。更有创意的项目更适合逻辑设计工作,但难以应用于数据建模。” 2005年,我们调查了项目方法、项目规模和学生学习之间的关系。大型复杂项目强调了正式方法的价值,可以带来良好的成果,强调了在提供途径方面的作用:“当我们第一次查看“黑船长”的简报时,我们认为该项目的范围有可能比我们能够自信地开发的任何项目都要大得多”(SF)然而,这可能会产生一种使人失去力量的影响,一个潜在的巨大项目显然是不可行的,学生失去了兴趣,一些小组将项目的范围缩减得很小,以至于开发的内容只不过是登录系统。在另一个极端,一个非常小的项目可能会进一步缩小,因为学生由于觉得SDLC流程过于复杂而失去了兴趣。介于两者之间的是一些任务,这些任务最终比学生最初的理解要大得多。在2004年的一项实验中(Mann & Smith,2005),不同的学习小组被赋予了不同技术范围的项目。虽然目的是使差异在于规模,但项目的实际差异在于客户指定其业务问题的能力。同样,SDLC的结构为学生提供了一个框架,让他们能够解决问题。
“At the onset I had no clue of being able to do what was required, so I didn’t have a preconception about what it would look like. I did not think we could do it and definitely not me. Now I see it can be done…” (SF)
不幸的是,该结构并没有克服第二个问题的反复无常。相反,学生们只是走过场,经常给出毫无意义的陈述。“由于VideoShop对其当前的视频租赁系统提出了额外要求,因此有机会开发一个新的增强型系统来满足这些要求。当前系统缺乏管理层和员工在业务上取得财务进步所需的特性”(SW)。两组学生都没有对复杂交互的考虑机会做出反应,即使是最强的组也只触及了我们认定为复杂领域的表面。因此,我们看到一个模型的演变,该模型虽然基于SDLC,但已经越来越灵活。底层框架有几个优点。它提供了一个在出现问题时可以返回的基本流程,它为开发铺平了一条清晰的道路,并且具有可预测性以用于教学。与软件工程的持续发展并行的是行业或毕业设计项目本身的发展。继我们的软件工程课程之后,学生将“SDLC与原型设计相结合”描述为他们选择的方法并不令人意外。这种描述可能意味着什么的问题超出了计算机教育的范围:科学和贸易文献广泛涵盖了原型的问题(保真度、进化/革命等),但成功的集成模型仍然难以捉摸。Hakim和Spitzer(2000)认为,“挑战在于将原型系统地整合到软件设计和开发生命周期中”。2003年,我们的目标是探索开发方法在成功完成毕业设计项目中的作用,特别是原型设计的程度、性质和集成(Mann & Smith,2004)。通过检查示例项目的特征,我们描述了一个开发框架,然后使用该框架描述更大的项目语料库来验证此模型。我们将这些提炼成一个示例开发框架。1.“SDLC”识别的开发方法2. 使用原型设计3. 使用强大的功能需求4. 使用低保真度但高交互性原型测试功能需求5. 早期开发稳定的开发平台6. 原型是集成测试计划的一部分7. 向客户交付早期功能交付物8. 稳健的最终交付物9. 仍然需要“正常”设计——原型设计不能取代10. 原型设计用于与客户的沟通11. 通过革命性(cf 进化性)成熟。硬件的分阶段替换。Mann & Smith(2004)中的一个附带发现是,尽管有一个规定的以文档为中心的流程,但文档页数与评估成绩之间只有微弱的关系。我们还发现,成绩较差的组原型设计较少,这是可以理解的;他们做的其他事情也较少。关键的是,当他们进行原型设计时,他们也没有进行“正常设计”或拥有稳定的系统、早期交付等。在早期阶段使用原型的成绩较差的组也具有非常弱的功能需求,没有强大的测试计划等,换句话说,原型设计成为了整个开发过程。处于中等水平的进行原型设计的组往往具有较弱的逻辑和物理设计,相反,他们将开发视为使原型设计稳健的过程。2004年,我们得出的结论是,“通过采用一个既能被视为产生良好产品又能灵活且稳健的流程,可以减少产品和流程之间的紧张关系。我们相信此处描述的开发框架将为毕业设计课程提供基础”。2004年,此开发框架被所有毕业设计项目强制使用(Mann & Smith,2005),取得了巨大的成功。结果表明,项目组确实遵循了该框架,平均成绩显著提高,不及格成绩有所减少。同样,框架内参数之间的关系表明,对于较弱的组,增量传统的SDLC流程与早期开发模型并不相容。在实施该框架时,给出了以下说明:我们要求您在敏捷软件开发的框架下遵循SDLC。这提供了SDLC结构的优势,同时增加了敏捷开发的灵活性。项目的重点是生产稳健的工作系统(软件、硬件和维护文档)。规划、全面的开发文档和流程很重要,但它们是“目的的手段”,重点是内容而不是格式/表示形式。预计您会丢弃开发的大多数模型(尽管您必须保留它们以供评估!)。我们还强调原型设计和测试。我们正在进行两次SDLC。第一次迭代是为了分析和设计并发布(通常发布给客户)一个满足大多数功能需求的系统。第二次迭代旨在审查第一次迭代在满足业务需求方面的成功情况,审查功能需求(可能会有更多),并交付一个时尚的“防弹”实施方案。为了强制执行早期交付物等框架组件,设置了以下里程碑:您需要至少交付四个重要的系统。1. 需求原型。在分析阶段结束时。这是一个旨在测试功能需求的原型。2. 稳定的平台(第12周)。您的系统的平台应开发并测试。例如,对于具有Web前端的数据库,我们希望您通过Web演示连接性和基本数据库功能(插入、删除、查询、更新)以及任何标准基础设施(登录等)。3. 主要版本1,第25周。向客户交付一个满足其大部分需求的系统。此系统应可用且稳定。4. 主要版本2,第42周。向客户交付一个满足其所有需求的生产系统。尽管总体模式显然是成绩有所提高,但较弱的组再次表现出对敏捷方法各个方面与传统流程之间关系的困惑。这些组的特点是:要么开发原型并对其进行初始测试,但这成为了项目,随后的稳健开发很差,要么不善于将早期开发和测试整合到SDLC中。3.1迄今为止的演变总结所使用的方法主要是系统开发生命周期(基于Hoffer等,2004),但在教授这门课程的六年中已经发展起来。现有系统的局限性在于它已经变得文档繁重并且对客户的访问权限有限。此外,学生在真正了解客户的需求之前就编写了需求。由于该项目未实施,因此进入毕业设计项目的学生对实施问题几乎没有经验,并且经常无法产生所需的结果。到2005年,所教授的方法已经发展成为一个修改后的SDLC,但采用了敏捷的“框架”——认识到在整个过程中拥抱变化的重要性。已经引入了使用SoDIS工具的道德风险管理方法,并在设计中应用了可用性重点。二年级所教授的方法可以描述为一个松散的SDLC,它非常重视原型设计并且具有很强的用户重点,但没有考虑实施问题。与此同时,毕业设计项目是“两次通过SDLC”,也重点关注原型设计,其中评估的重点是实施和部署。许多敏捷方法都被积极鼓励(尤其是Scrum会议、结对编程、基于测试的开发、用户参与)。4 敏捷框架方法此处描述了一个开发框架,该框架将敏捷开发方法整合到一个结构化的框架中。项目的重点是生产稳健的工作系统(软件、硬件和维护文档)。规划、全面的开发文档和流程很重要,但它们是“目的的手段”,重点是内容而不是格式/表示形式。预计学生会丢弃他们开发的大多数模型,尽管他们必须保留这些模型以供评估,我们将其描述为证据组合。重点是合理流程的证据,因此我们鼓励花时间注释图表,而不是为了演示而整理它们。任何开发方法都可以看作是减少不确定性的过程。在开始时,我们只有一个想法,或者要解决的一个业务问题,存在很多不确定性。最后,我们拥有了一个功能性的系统。影响任何特定时间点不确定性水平的压力可以看作是交互的工作流(图1和2)。
Figure 1: Pressures affecting uncertainty.
图2:五条交互的工作流。
图3:不同方面的重要性领域每个流的不同比例融合成由可交付成果、指导和与客户的沟通定义的“领域”(图3)。此处的领域可以被视为类似于结构化的开发流程,但至关重要的是,根据项目需求允许灵活的路径。对于软件工程和毕业设计项目,我们使用三个迭代(图4)。第一次迭代旨在在开发团队和客户之间建立理解。第二次迭代旨在设计和发布(给客户)一个满足许多功能需求的系统。第三次迭代,“稳健交付”,旨在审查第二次迭代在满足业务需求方面的成功情况,审查功能需求(可能会有更多),并交付一个稳健且时尚的“防弹”实施方案。
图4:三个迭代。因此,在任何特定时间,学生都在一个由五个工作流组成的领域中工作,该领域是三个迭代之一,并且专注于特定领域。每个领域由其产生的内容定义(表1)。尽管我们的目标是为学生提供一套可在每个领域内使用的工具,但只要他们能够提供合理流程的证据(请参见下面的证据组合),我们就不太关心该领域的内部细节。领域图用于说明开发框架中的位置和信息流(图5)。这是我们混合结构和敏捷性的方法的核心。鼓励学生调整这些图表,这意味着他们不必完成建议的每个任务,只要他们能够证明从输入到输出已经有一个合理的流程(这里Petri网的概念很有用)。在第二次迭代中,我们仅以敏捷为导向地介绍工具和技术,在第三次迭代中,重点是敏捷技术。表1中的下划线项目构成了课程评估的基础。75%的分数来自实施,尽管与上述论点类似,这必须得到“决策依据”的支持。这75%由稳定平台的10%、第二次发布的15%和最终交付的50%组成。决策依据在证据组合中给出。此外,客户满意度被视为评估的阈值要求。
图 5:用于说明开发框架中的位置和信息流的扇区图(此图用于第二次迭代:设计概念)。在第一次功能发布中,重点是向客户提供一个有用的系统。评估中的组件是及时的、决策的理由和技术能力。在最终的稳健交付中,这些组件与质量保证活动和成果、实施、部署、技术复杂性和客户文档相结合。5 结论 在本文中,我们描述了我们在构建用于软件工程教学的敏捷框架时所遵循的路径。这种方法以一种促进敏捷性并为开发和教学提供底层结构的方式结合了敏捷和结构化方法。6 参考文献 Beck, K. (2000)。极限编程解释:拥抱变化。新泽西州:艾迪生-韦斯利。Boehm, B. & Turner, T. (2004)。平衡敏捷性和纪律性,困惑者的指南。马萨诸塞州波士顿:艾迪生-韦斯利。Booch, G. (2004) 前言。在 Boehm, B. & Turner, T. 平衡敏捷性和纪律性,困惑者的指南。马萨诸塞州波士顿:艾迪生-韦斯利。Conboy, K. & Fitzgerald, B. (2004)。迈向敏捷方法的概念框架:不同学科中敏捷性的研究 http://doi.Acm.Org/10.1145/1029997.1030005 2004 年 ACM 跨学科软件工程研究研讨会论文集(第 37-44 页)。美国加利福尼亚州纽波特比奇:ACM 出版社。Hakim, J. & Spitzer, T. (2000)。有效的可用性原型设计。ACM 通信设计特别兴趣小组,IEEE 专业通信学会国际专业通信会议论文集和第 18 届 ACM 国际计算机文档会议论文集:技术与团队合作。47-54 Hoffer, J. A.,George, J. F. & J. S. Valacich (2004)。现代系统分析与设计。第三版。美国雷丁:本杰明·卡明斯。
Keefe, K. & Dick, M. (2004)。在顶点项目中使用极限编程。论文发表于第六届澳大利亚计算教育会议论文集 - 第 30 卷,新西兰但尼丁。Noble, J.,Marshall, S.,Marshall, S. & Biddle, R. (2004)。更少的极限编程。论文发表于第六届澳大利亚计算教育会议论文集 - 第 30 卷,新西兰但尼丁。Mann, S. & Buissink-Smith, N. (2000)。学生学到了什么:通过授权学习。国家计算资格咨询委员会第 13 届年会,新西兰惠灵顿特帕帕,NACCQ。213-220 www.naccq.ac.nz Mann, S. & Smith, L.G. (2004) 开发方法和原型在顶点项目中的作用。第 17 届 NACCQ 年会论文集,Mann, S. & Clear, T. (编)。基督城。2004 年 7 月 6 日至 9 日。第 119-128 页。Mann S. & Smith, L.G. (2005) 软件工程项目的技术复杂性。第 18 届 NACCQ 年会论文集,Mann, S. & Clear, T. (编)。陶朗加。2005 年 7 月 10 日至 13 日。第 249-254 页 Robinson, H. (1994) 授权的人类学:课堂互动的变革力量(布里斯托尔:福尔默出版社)。Schwaber, K.,Beedle, M. (2002)。使用 Scrum 进行敏捷软件开发。新泽西州:普伦蒂斯·霍尔。Smits, H. (2005 年 3 月 12 日,2005 年)。什么是敏捷软件开发?2005 年 8 月 25 日检索自 http://www.agilealliance.org/programs/roadmaps/Roadmap/index.htm Standish。(1995)。混乱。2005 年 9 月 1 日检索自 http://www.standishgroup.com/ sample_research/PDFpages/chaos1994.pdf Smith, L.,Mann, S. & Buissink-Smith, N. (2001)。“让一辆满载授权软件工程学生的巴士失控。”新西兰应用计算与信息技术杂志 5(2):69-74。
SMITH, L.G.,MANN, S. (2004) 项目预测:选择软件工程项目,第 17 届 NACCQ 年会论文集,Mann, S. & Clear, T. (编)。基督城。2004 年 7 月 6 日至 9 日。第 183-190 页。Standish。(1994)。混乱。2005 年 9 月 1 日检索自 http://www.standishgroup.com/sample_research/PDFpages/chaos1994.pdf
迭代 1:理解扇区输出
评估管理文档(小组成立,环境背景)功能需求与客户建立访谈设计概念伦理设计设计规范系统隐喻和知识库实现概念原型(第一版)。评估向客户提出建议迭代 2:功能交付的背景
Evaluation Project estimation
功能需求功能需求文档设计概念设计概念演示设计规范设计规范(样式指南等),稳定的开发平台:应开发和测试系统的框架。实现功能交付物(第二版)。向客户交付一个满足其大部分需求的系统。该系统应可用且稳定评估功能交付物的分析迭代 3:稳健交付
Evaluation Direction for Iteration 3. Complete Ethical processes.
功能需求重新审视功能需求设计概念设计概念更新,内容制作设计规范样式指南,系统规范,实施和部署计划实现稳健交付(第三版)评估项目评估和完成。客户满意度。
表 1:每个扇区所需的输出