软件项目生存周期过程课件

软件工程第四讲软件项目生存周期过程的管理,软件开发本质,软件生存周期过程,定义,软件生存周期模型,软件工程生存周期过程,支持过程方向(活动与定序)的建立,形成,软件开发方法学结构化方法面向对象方法面向数据结构方法维也纳开发方法（VDM）,给出实现开发过程的途径,支持/管理技术与方法,作用于,回答:如何建立一项软件工程的生存周期过程并管理之.,3、软件工程生存周期过程管理,1)引言一个项目的软件生存周期过程管理,是该软件工程项目管理的一个子集.何谓一个项目的软件生存周期过程?无论是软件项还是硬件项，在其开发上的演化一般被称为该项的生存周期。通常，一个项的开发往往始于一个想法，依其服务情况，不断地进行改进。因此,项目的生存周期可概括为:,Recognitionofneed,Acq.Decision&Strategy,Specification,DesignAcceptance,Requirements,Maintenance,Releasetofield,Implementation,在一个项目生存周期中，每一个任务(例如Design)都通过一个或多个过程的方式来完成。在生存周期中所有这些相关过程的组合，称为项目的软件生存周期过程。,注:在这一定义中,关注开发产品所需要的工程技术和管理技术活动,从规约(Specification)一直到验收(Acceptance).,软件生存周期过程的管理管理的一般模型:所谓软件生存周期过程的管理,即从需求规约到验收，对过程、过程之间的关系以及过程产品流进行定义和控制.,P,A,D,C,具体地说，可分为4个主要阶段：选择合适的软件生存周期模型（theSoftwareLifeCycleModel,SLCM）,作为发布、支持产品所需要的一个全局过程网，作为完成其中活动所需要的活动网。通过标识和定义那些单个的任务（例如需求），创建软件生存周期（theSoftwareLifeCycle,SLC）。建立组织上和技术上的软件生存周期过程（theSoftwareLifeCycleProcess，SLCP）。在整个产品的生存周期中，管理该SLCP。,其中，规划并记录这些活动的关键手段是SLCM计划（或SLCMP）。创建这一计划的主要指南：IEEE/EIAStandard12207.0-1996软件生存周期过程IEEEStandard1074-1997软件生存周期过程的开发IEEE/EIZ12207.2-1997软件生存周期过程-实现考虑。,2)软件生存周期模型的选择在实际工程中,可供选择的四个主要软件生存周期模型为:（1）瀑布模型，（2）增量模型，（3）演化模型，（4）螺旋模型。(1)选择步骤在每一模型的优缺点评估完成之后，过程设计师必须为指定的项目选择最合适的生存周期模型。(注：这是一项重要而复杂的任务.)IEEEStandard1074-1997列出了选择项目生存周期模型的步骤(5步).,标识开发项目可用的SLCMs。在所期望的最终系统和开发环境中，标识那些会影响SLCM选择的属性。标识为选择生存周期模型所需要的任何约束,包括外部的或是内部的。例如，来自客户合同上的需求，或关键开发技能的缺乏，特别是客户强制的、具有里程碑的程序进度，以及使一个特定的应用框架或关键构件成为有用的一个策略决策。基于以往的经验和组织能力，评估第一步所选择的那几个SLCM。最后，选择最能满足项目属性和约束的SLCM。,3)生存周期过程的精化选择了一个软件生存周期模型之后，下一个任务就是将相关的生存周期活动映射到该软件生存周期模型。-精化IEEEStandard1074-1997和IEEE/EIAStandard12207将活动定义为组成一个过程的元素；把任务定义为一个活动中的最小的工作单元。至于如何确定每一个任务，这是管理的责任，这涉及到成本和进度评估和管理，即必须考虑项目的完成时间和监控它们的状态。,在确定任务的工作中，应注意：一般来说，任务是可分配给项目组成员的、定义良好的工作。一些相关的工作通常组合在一起形成活动，通常称之为“工作包”。由此可见，创建生存周期过程的任务是，选择一些要实施的任务及其所需要的方法、工具和能力。,4)项目软件生存周期过程的实现将合适的活动映射带所选择的软件生存周期模型之后，就完成了一个完整生存周期的精化.下一个任务是将组织的过程资产应用到将精化的生存周期中,其结果就是项目的软件生存周期过程的实现.组织的过程资产一般包括：l政策；l标准；l规程；l已有的SCLPs；l度量；l工具；l方法学,5)软件生存周期过程的监控(1)软件生存周期过程的监查在项目实施中,必须监查软件生存周期过程的执行情况，以确保软件开发是按规划、高效进行的。以下各任务中形成的数据，有助于过程的监查：进展与进度的跟踪。这一跟踪可以揭示过程的偏离、不期望的过程范围增大、工具或资源等问题。质量数据趋势的检查。这一检查可以用于确定软件实现组是否遵循期望的生存周期过程。,设计、编码和测试计划复审记录和动作的检查。这一检查可以用于确定过程是否产生预期结果。即给出正在实施的过程是否有效？变更要求和测试异常报告趋势的检查。这些检查提供了过程有效程度的深入了解，也能确定配置管理系统的负载是否在可支持的范围内。关键资源的有效使用。有时，这可以检测出计划中存在的隐性偏离。与项目组成员的交谈。与项目组成员进行正式或者非正式的对话，了解过程的运作情况。他们的观点，一旦由描述的客观数据所支持，那么对发现过程问题、寻找过程改善的机会是非常有价值的。,而且,还必须定期监控以上信息源.由于生存周期的监控必然带来额外的进度评估，因此应按基本的周期对进度进行修正。一个一般的原则是，在一个特定的生存周期过程中，每当进展到其进度的10%或者20，就应该进行一次检查。例如，对一个中等规模的产品来说，设计过程进行到20、40和60时，都要对已完成的工作进行检查。原因是如果完成的工作少于20，不可能产生足够的有效数据，但是如果超过了60，一旦发现问题，改变设计过程已经太晚了，以至于会产生灾难性错误。,利用以上信息，软件程序管理者和过程设计师应能确定是否需要改变生存周期和所要求的过程。作出这一决定必须非常谨慎，因为对生命周期过程的一个不合适的改变，可能会打乱整个工作程序，影响技术工作和人员情绪。另一方面，实现一个合理的改变，只有当项目组成员都认识到这一需要，才能最终有助于开发工作。,(2)生存周期过程改变所产生影响的评估一旦监控活动的过程发现一个生存周期过程并没有按预期实施，那么软件程序管理人员和过程设计师就要对可能采取的措施进行评估，这些措施包括：l什么也不做。当改变的负面影响可能超过带来的好处时。l强化过程。如果只因初始培训不充分或组织制度不够严格，导致过程没有按预期实施，那么这是一个正确的举措。,l调整过程。如果过程需要进行少量调整（如，核对表的修订或同级复审过程的调整），就可以修改过程，并调整员工的培训。l过程替换。如果一个过程根本就存在缺陷（如，只集成了系统的10，但用于监控性能的工具集却消耗了90的处理资源），那么必须替换这一过程。l以上措施的某一组合。,按以下几方面，评估以上进行的过程改变所造成的影响。l所要求的“返工”在有的情况下，一个改变只影响当前进行的过程步。而很多时候，可能需要重新实施该过程前面一些阶段的工作。无论是哪一种情况，都要考虑一个过程改变对进度和成本的影响。l资源需求进行过程改变可能会增加或者减少资源的需求，包括人员、硬件和工具。必须考虑由生存周期过程的改变所产生的全部成本，以及为获得这些资源所需要的时间。,l实施时间如果一个项目采用演化或螺旋生存周期模型，并在前面一个迭代周期中已标识了过程改变的要求，那么最好把这一改变推迟到下一个迭代周期。这样就可以用有序的方式进行这一改变。l对项目和用户的益处。建立并实施生存周期过程的理由，是为了向用户交付一个产品，这是占主导的一个考虑，因此对那些与项目和用户益处相关的因素，都要进行评估。,l员工情绪进行一个过程改变，特别是进行一个重要的改变，可能会对员工的情绪产生负面影响。当这一改变涉及到组织里那些有威信的人，包括员工、管理人员和专家，其影响尤其严重。虽然这些顾虑不应该停止项目管理人员和结构设计师进行正确的改变，但是需要认真地考虑实现这一改变的时间。如果向项目人员（他们可能是首先发现问题的员工）进行了正确、合适的说明，那么才能真正地实现这一改变。,(3)改变的实施对项目进展中的一个过程进行一个改变，必须十分谨慎。依据进行改变的时刻，要求实施以下全部或一部分工作：l围绕一个初期的主要问题，与客户进行讨论；l向项目有关成员宣布改变的需求。这是一件相当关键的事情，必须是客观的、理性的。受到一些抱怨不是什么问题，关键的是以最低成本建造一个最好的产品。,l规划改变。规划改变的工作包括：确定过程改变的时间、需要的资源和培训：可能需要返工的项；对软件规划文档的任何改变，（过程、进度）；涉及到的合同或业务需求（必须与客户协商）；标识并冻结所涉及的配置项；规划必要返工；标识不需要改变的、可以继续工作的范围。这一改变的进度必须包括获得和实现所需要的资源和培训的时间和活动。对一个增加的成分或改变的成分，.必须确定要做哪个（以上描述的）监督活动的过程。l实现改变。执行这一改变计划，继续关注并保持与项目成员的交流。,软件过程总结,三、软件需求及系统/产品(需求)规约-定义问题的基本要素是什么?-定义问题的基本格式是什么?,不论是自顶向上的软件开发,还是自底向上的软件开发,正确定义问题,是解决问题的前提.,1定义问题的基本要素定义问题的基本要素是”需求”1)何谓需求?一个需求是一个有关“要予构造”的陈述，用以描述待开发产品（或项）功能上的能力、性能参数或者其它性质。Arequirementisastatementthathasbeenconstructedtodescribeanecessaryfunctionalcapability,performanceparameter,orotherpropertyoftheintendedproduct(oritem).,例如：系统必须有能力支持100个以上的并发用户，每个用户可以处理附录A中操作任务的任选组合，平均响应时间应该小于1秒，最大响应时间应小于5秒。其中:功能-可以处理附录A中操作任务的任选组合性能-有能力支持100个以上的并发用户平均响应时间应小于1秒，最大响应时间应小于5秒。必须在对话窗口的中间显示错误警告，其中使用红色的、14点加粗Arial字体。其中:功能-能显示错误警告设计约束-在对话窗口的中间显示,并使用红色的、14点加粗Arial字体。,2)什么样的陈述可以作为需求-需求的基本性质IEEE标准830-1998要求单一需求必须具有5个基本性质:必要的(Necessary)。是要求的吗？无歧义的(Unambiguous)。只能用一种方式解释吗？可测试的(testable)。可以对它进行测试吗？可跟踪的(Traceable)。可以从一个开发阶段到另一个阶段对它进行跟踪吗？可测量的(Measurable)。可以对它进行测量吗？注:确定一个需求是否满足以上五个性质是复杂耗时的过程.,3)需求分类功能；性能；外部接口；设计约束；质量属性。功能需求功能需求规约了系统或系统构件必须执行的功能。例如：系统应对所有已销售的应纳税商品计算销售税。系统应提供一种方法，使系统用户可根据本地利率调整销售税比例.系统应能够产生月销售报表。,除了对要执行的功能给出一个陈述外，还应规约如下内容：关于该功能输入的所有假定，或为了验证该功能输入，有关检测的假定。功能内的任一次序，这一次序是与外部有关的。对异常条件的响应，包括所有内外部所产生的错误。需求的时序或优先程度。功能之间的互斥规则。系统内部状态的假定。为了该功能的执行，所需要的输入和输出次序。用于转换或内部计算所需要的公式。,关于功能需求应考虑以下问题：（1）功能源。（2）功能共享的数据。（3）功能与外部界面的交互。（4）功能所使用的计算资源。可见,功能需求是整个需求的主体，几乎构成了由交谈和小组讨论所得到的所有初始需求。这意味着:没有功能需求,就谈不上其它需求,即性能需求、外部接口需求、设计约束和质量属性。,性能需求性能需求(Performancerequirement)规约了一个系统或系统构件必须具有的性能特性。例如：系统应该在5分钟内计算出给定季度的总销售税。系统应该在1分钟内从100000条记录中检索出一个销售定单。该应用必须支持100个Windows95/NT工作站的并行访问。注1：性能需求隐含了一些满足功能需求的设计方案，经常对设计产生一些关键的影响。例如：排序，关于花费时间的规约将确定哪种算法是可行的。注2:性能需求对功能需求而言,可以是一对多的,例如:,性能x,功能,功能,功能,外部接口需求外部接口需求(Externalinterfacerequirement)规约了系统或系统构件必须与之交互的硬件、软件或数据库元素。它也可能规约其格式、时间或其他因素。例如：账户接收系统必须为月财务状况系统提供更新信息，如在“财务系统描述”第4修订版中所描述的。引擎控制系统必须正确处理从飞行控制系统接收来的命令，符合接口控制文档B2-10A4，修订版C的1到8段的规定。,-用户接口(Userinterfaces)：规约了软件产品和用户之间接口的逻辑特性。即规约对给用户所显示的数据，对用户所要求的数据以及用户如何控制该用户接口。-硬件接口(Hardwareinterfaces)：如果软件系统必须与硬件设备进行交互，那么就应说明所要求的支持和协议类型。-软件接口(Softwareinterfaces)：允许与其它软件产品进行交互，如，数据管理系统、操作系统或数学软件包。-通讯接口(Communicationsinterfaces)：规约待开发系统与通讯设施(如，局域网)之间的交互。如果通讯需求包含了系统必须使用的网络类型（TCP/IP，WindowsNT,Novell），那么有关类型的信息就应包含在SRS中。,-内存约束(Memoryconstraints)：描述易失性存储和永久性存储的特性和限制，特别应描述它们是否被用于与一个系统中其它处理的通讯。,-操作(Operation)：规约用户如何使系统进入正常和异常的运行以及在系统正常和异常运行下如何与系统进行交互。应该描述在用户组织中的操作模式，包括交互模式和非交互模式；描述每一模式的数据处理支持功能；描述有关系统备份、恢复和升级功能方面的需求。-地点需求(Siteadaptationrequirements)：描述系统安装以及如何调整一个地点，以适应新的系统。,设计约束设计约束限制了系统或系统构件的设计方案。就约束的本身而言，对其进行权衡或调整是相当困难的，甚至是不可能的。它们必须予以满足。这一性质，是与其它需求的最主要差别。为了满足功能、性能和其它需求，许多设计约束将对软件项目规划、所需要的附加成本和工作产生直接影响。例如：系统必须用C+或其他面向对象语言编写。系统用户接口需要菜单。任取10秒，一个特定应用所消耗的可用计算能力平均不超过50%。必须在对话窗口的中间显示错误警告，其中使用红色的、14点加粗Arial字体。,针对产品开发，为确定其相关的设计约束，一般需要考虑以下10个方面：-法规政策(Regulatorypolicies)；-硬件限制(Hardwarelimitations)，例如：处理速度、信号定序需求、存储容量、通讯速度以及可用性等；-与其它应用接口(Interfacestootherapplications)，如，当外部系统