软件过程综合实践第1讲.ppt

软件过程综合实践,郑大鹏 ,第1讲 实践要求及开始阶段要点,内容 本实践课要求 如何开始实践项目 目的 了解实践目标、内容、组织形式 复习软件项目起始阶段工作内容、方法,本实践课要求,本实践属于必修课，4学分； 要求综合应用所学软件开发知识，在四周内完成一个软件项目 目标：通过本课程，达到以下五项目标。,本实践课要求,1能理解客户的总体需求，并进而识别系统的范围，发掘系统的详细需求，编写有关需求阶段文档； 2能根据需求确定系统的测试方案，编写测试计划，准备测试用例； 3能根据需求确定系统的设计，并将设计文档化。理解设计的要素和工作过程；,本实践课要求,4能用所学的程序设计知识，将系统设计转化为代码，并进行测试和排错。所设计的代码应有良好的风范； 5理解软件开发的过程，学会组织和管理一个软件开发项目。懂得软件项目中不同角色的定位和工作任务，学会与项目团队成员间的沟通和协调。,本实践课要求,实践题目： 根据老师列出的题目，挑选一个； 信息系统、电子商务网站。 可以在原来课程设计基础上进一步深化，也可以结合毕业设计的选题。 建议以小组为单位完成。每小组45人；,本实践课要求,小组成员分工（4人一组）： 项目管理+系统分析+代码编写 架构设计+代码编写 测试+代码编写 数据库设计+代码编写 代码、文档可以分工完成。要注明完成者，以便评分。代码要注意规范，必须有头注。文档要按照模板格式写。,本实践课要求,项目过程和文档要求,本实践课要求,编程要求,本实践课要求,编程要求,本实践课要求,编程要求,本实践课要求,提交要求,本实践课要求,考核方法：,本实践课要求,考核方法： 一个小组各组员的得分，以小组提交的作品得分为基准，考虑小组成员的表现进行上、下浮动。 表现可以从考勤、完成的工作和答辩表现看出。 答辩：由于元旦放假，答辩必须在12月31日结束。如果小组提前完成了的，可以提前于28日开始进行答辩。最迟不能迟于12月31日下午。 答辩的条件是必须提交文档和代码，并能演示代码。,如何开始实践项目,组队、分工、选题 业务分析 项目范围识别 系统功能需求识别与记录 系统非功能需求识别与记录 确定核心功能和性能 需求阶段的文档 工作安排,组队、分工、选题,由于本实践课的目的之一是要模拟真实工作环境，让大家亲身经历软件开发过程，因此，要求大家尽量以小组方式开展实践 但每组人数不能太多。建议4人，最多5人。 每个人要有明确的分工。在最后完成的文档和代码中，每个人要在完成品上注明自己的姓名。,组队、分工、选题,要求大家从老师提供的选题中选择； 因为老师作为所有系统的需方，要向学生解释系统的需要。针对这些题目，老师事先已经作了大量的准备。 原则上，每个小组的题目要求不同。,业务分析,选定题目后，首先要了解课题所涉及的业务领域及其业务运行规则； 在此活动中，需要反复向需方了解。本实践中，由老师模拟需方的代表。 所谓业务分析，就是搞清楚业务对象，业务活动，活动的流程及规则。,业务分析,例如，业务服务对象是谁，服务内容有那些，过程如何，规则如何。服务活动涉及那些概念、物品、设施等。 业务分析的结果可以用文档记录，也可以不写入文档。这要看系统业务是否复杂。 对于很简单的系统或业务，业务分析所用时间可以很短（如30分钟）。,项目范围识别,所谓项目范围识别，是指与需方探讨和确认在业务活动中，那些活动或者活动的流程由软件完成，那些是在软件之外进行的。也可称为软件系统边界识别。 一个必须明白的事实是，开发软件就是在建造一个基于计算机的系统。基于计算机的系统，不一定所有活动都要由软件系统完成。例如，有些过程必须由人工完成，有些由其他的系统（也可能是软件）完成，但在我们要构建的软件系统之外。,项目范围识别,项目范围识别有时候是很容易的，有时候需要认真权衡。例如，有的过程既可以由人工完成，也可以由机器设备或者软件完成。究竟该如何做呢？ 这要考虑系统的成本、工期、业务量、服务质量等各种因素。 既要考虑需方的意愿，也要给需方合理的建议。,系统功能需求识别与记录,确定系统边界后，从边界入手，可以方便地识别系统需求。 主要考虑有哪些处在边界外的对象或系统需要与系统发生交互 在交互过程中，需要向系统输入什么，或者得到什么； 交互的过程（活动及步骤）是怎样的。,系统功能需求识别与记录,用例模型就是基于上述思想的需求模型。在用例模型中，系统由用例构成，操作者（actor）处在系统边界之外与用例发生交互。 需求方法中的用例法，其大致思路是先识别系统的操作者，然后分析每个操作者有哪些用例，将用例的步骤描述出来。,系统非功能需求识别与记录,用例一般用来描述系统的功能性需求。而非功能性需求也很重要； 非功能性需求包括性能、伸缩性、可维护性、安全性、平台要求等。 非功能性需求一般也是在分析用例的过程中发现的，也有一些是在专门的过程识别的。需要开发经验和对业务的深入理解。,系统非功能需求识别与记录,非功能性需求如果与特定的用例有关，也可以记录在用例文档中； 但很多非功能性需求都是关于全局的，所以放在用例说明中不合适。一般将非功能性需求放在补充规格说明书中。,确定核心功能和性能,系统的功能和性能要求中，有些对系统是最核心和根本的，这部分功能和非功能需求往往会决定系统的成败，影响系统的总体设计（架构设计），称为架构因素； 在项目开始早期，要识别这些关键的需求，以免设计时不能满足要求，造成返工或者项目失败。,需求阶段的文档,愿景(Vision)：此文档的目的是收集、分析及定义要开发系统的高层需求和特性。重点关注系统各相关方及目标用户的能力需要，以及这些需要存在的理由。 关于系统如何满足这些需要的细节，在用例和补充规格说明书中说明。,需求阶段的文档,用例说明：功能需求描述； 补充规格说明：非功能需求描述。包括： 法律及规章符合要求，包括应用标准的遵从； 系统的质量特性，包括可用性、可靠性、性能及支持性。 诸如操作系统及环境、兼容性及设计限制等方面的需求。,需求阶段的文档,系统需求规格说明书（SRS）：包含功能和非功能需求说明。可以将前述用例、补充规格说明的内容集中到此文档中。 在上交文档时，只需要交这一个文档就行了。 如果分开写用例说明和补充规格说明，不写此文档也可以（不必重复）。,工作安排,今天34节完成分组和选题，向指导老师了解题目的需求； 下午到实验室完成愿景或项目开发计划（请大家自备u盘每日备份自己的工作）。 明天早晨12节继续到本教室集中授课。 有关课件和文档模板请上网络教学综合平台下载。,题目：,郑老师 网上电子商务系统（可以是各种不同业务） 医